Les limites de l’IA pour développer un produit web

Les assistants de code ont changé le coût d’une première version. Une interface, des formulaires, une base de données, une mise en ligne : un agent bien guidé produit tout cela en quelques heures. Ce qui n’a pas changé, c’est la distance entre un code qui s’affiche et un produit sur lequel des clients peuvent compter. Cet article passe en revue, tâche par tâche, ce que l’IA fait bien, ce qui demande une preuve, et la preuve minimale à obtenir avant de dépendre du résultat.

Produire n’est pas prouver

Un agent de code produit du code. Il peut aussi produire des tests, des explications et un message qui affirme que « tout fonctionne ». Aucun de ces éléments n’est une preuve du comportement réel. Une preuve, c’est un test observé dans les conditions qui comptent : avec deux comptes différents, une carte refusée, une notification reçue deux fois, une sauvegarde réellement restaurée. Tant que personne ne l’a observé, c’est une hypothèse — parfois juste, parfois non.

La limite ne tient donc pas seulement à la qualité du code généré. Elle tient à ce qu’une démonstration ne montre pas : les cas d’échec, les accès entre utilisateurs, ce qui se passe à deux heures du matin quand un service tiers ne répond plus. Ces points se vérifient ; ils ne se devinent pas en regardant l’écran.

Tâche par tâche

Le tableau suit l’ordre dans lequel un produit web se construit. La dernière colonne décrit la preuve la plus simple qui change une décision : si elle échoue, on ne lance pas — ou on réduit ce qu’on lance.

Droits d’accès : là où une démonstration ne montre rien

Une démonstration se fait avec un seul compte. Un défaut d’accès — un client qui voit les factures d’un autre — ne se voit qu’avec deux. Avec Supabase, la protection repose sur la sécurité au niveau des lignes (RLS) : selon la documentation de Supabase, une fois RLS activé, aucune donnée n’est accessible par l’API avec la clé publique tant qu’aucune règle ne l’autorise ; à l’inverse, une clé secrète contourne ces règles et ne doit jamais se retrouver dans le navigateur. Un agent peut écrire ces règles correctement. Il peut aussi en écrire une trop large, ou oublier une table. Seul le test des deux comptes tranche, y compris en appelant l’API directement plutôt que par l’interface.

Paiements : la page de remerciement ne prouve rien

La documentation de Stripe sur l’exécution des commandes est nette sur deux points. D’abord, on ne peut pas se fier à la seule page de retour après paiement : rien ne garantit que le client la charge, et la notification envoyée au serveur (le webhook) est nécessaire. Ensuite, le traitement peut être appelé plusieurs fois pour le même paiement, parfois en même temps : il doit donner le même résultat à chaque fois. Certains moyens de paiement ne confirment d’ailleurs le paiement que plus tard. Un agent connaît ces règles ; le seul moyen de savoir si votre code les respecte est de rejouer la notification et de compter les accès accordés.

Tests : qui vérifie le vérificateur ?

Quand le même outil écrit le code et ses tests, les tests ont tendance à décrire ce que le code fait déjà, erreurs comprises. Un test utile échoue quand la règle métier est violée. Le contrôle est simple : modifiez volontairement une règle — laissez passer un compte qui n’a pas payé, par exemple — et vérifiez qu’un test devient rouge. S’il reste vert, il ne protège rien.

Textes du site : le volume n’est pas un effort

L’IA écrit vite et proprement. Les consignes de Google sur le contenu utile rappellent qu’utiliser l’IA générative pour produire beaucoup de texte sans relecture ni sélection humaines représente peu ou pas d’effort, et qu’un contenu doit d’abord servir des personnes. Pour un produit, cela veut dire des affirmations vérifiées, un auteur identifiable, et rien que vous ne puissiez défendre si un client vous le demande.

Quand une revue spécialisée vaut la peine

Une revue par une personne expérimentée coûte du temps et de l’argent. Elle se justifie quand une erreur coûterait plus cher qu’elle :

• De vraies données personnelles, et a fortiori des données sensibles : santé, finances personnelles, pièces d’identité, mineurs, dossiers couverts par un secret professionnel.
• Plusieurs entreprises clientes dans le même produit, chacune isolée, avec ses propres rôles.
• De l’argent qui circule autrement qu’un simple paiement : facturation à l’usage, reversements à des tiers, crédits, remboursements partiels.
• Des actions irréversibles : virements, envois en masse, suppressions, décisions automatiques qui touchent des personnes.
• Une panne qui fait perdre des ventes ou manquer un engagement envers des clients.
• Personne de nommé pour réparer après le lancement.

Pour cadrer ce qu’on vérifie, le standard ASVS de l’OWASP (version 5.0.0, publiée en mai 2025) liste les exigences de sécurité d’une application web. C’est une référence utile ; cocher une liste qui s’en inspire ne rend pas pour autant un produit « conforme » ni « certifié ».

Quand elle ne sert à rien

À l’inverse, payer une revue est souvent inutile :

• Un prototype avec des données fictives, montré à quelques personnes pour tester une idée.
• Un outil que vous êtes seul·e à utiliser, sans la donnée de personne d’autre.
• Un site vitrine sans compte ni paiement, fait avec un constructeur de sites reconnu.
• Une automatisation entre des outils existants, qui déplace des informations que ces outils protègent déjà.
• Un besoin qu’un logiciel existant couvre déjà : l’acheter et le configurer bat souvent la construction, et il n’y a alors pas de code à vous à faire relire.

Dans ces situations, le meilleur investissement est votre temps : parler à des utilisateurs, tester la demande, garder le périmètre petit.

Une règle de travail

Pour chaque point qui compte — accès, paiements, reprise — notez ce que vous savez et comment vous le savez. « Vérifié le 12 octobre, deux comptes, refus observé » vaut plus que « l’agent a dit que c’était bon ». Ce qui n’a pas été vérifié n’est pas forcément faux ; c’est inconnu. Et un inconnu n’est pas un risque faible.

Pour la liste des tests à faire juste avant un lancement, voir ce qu’un fondateur doit vérifier avant de lancer un SaaS construit avec l’IA. Pour un exemple complet de décision — ce qu’on construit soi-même, ce qu’on achète, ce qu’on fait vérifier — voir le cas d’un SaaS MVP.