Comment savoir vraiment si votre application vibe-codée fonctionne ?

Vous avez construit la chose. Vous l’avez testée en cliquant partout. Le bouton a fonctionné, l’enregistrement s’est sauvegardé, le tableau de bord s’est mis à jour. Vous êtes content.

Mais vous n’avez pas écrit ce code, et si vous êtes honnête, vous ne l’avez probablement pas lu non plus. Donc, ce que vous savez vraiment, c’est que ça a fonctionné une fois, pour vous, en faisant la seule chose que vous avez essayée. Tout le reste, sur le fait que ça « fonctionne » vraiment, c’est de la confiance.

Le scénario idéal est le seul parcours que la plupart des gens testent

Voici à quoi ressemble généralement le test d’une application vibe-codée : vous chargez un fichier et il est traité. Vous soumettez un formulaire et l’enregistrement apparaît. Vous cliquez sur un bouton et le workflow se déclenche. C’est tout. C’est le test.

Ce n’est pas de la paresse. C’est la limite naturelle du test manuel effectué par quelqu’un qui n’a pas écrit la logique sous-jacente. Vous ne pouvez tester que ce que vous imaginez pouvoir mal se passer, et si vous ne pouvez pas lire le code, vous testez la démo, pas le système. Le scénario idéal est le seul parcours pour lequel l’IA optimisait vraiment, puisque c’est le scénario du prompt qui a produit l’application au départ.

Le problème, c’est que l’usage réel ne reste pas sur le scénario idéal. Les vrais utilisateurs double-cliquent. Ils ouvrent deux onglets. Ils appuient sur « retour » puis renvoient le formulaire. Rien de tout cela n’apparaît quand vous, le créateur, testez votre propre application une seule fois, avec soin, dans l’ordre où vous pensez qu’elle sera utilisée.

La concurrence, c’est là que ça casse vraiment

L’exemple le plus clair, c’est la concurrence, et c’est vraiment difficile à tester à la main, même en sachant exactement quoi chercher.

Imaginez une fonctionnalité basée sur des crédits : un utilisateur lance un processus, cela coûte des crédits, et une vérification de solde devrait le bloquer une fois qu’il n’en a plus. Maintenant, imaginez ce même utilisateur ouvrir cinq onglets et lancer cinq processus dans la même seconde, avant que la première vérification de facturation ait fini de s’exécuter. Si la logique « vérifier puis déduire » n’est pas conçue pour gérer ce chevauchement, les cinq processus peuvent tous passer la vérification de solde avant qu’aucun d’eux n’enregistre de déduction. Le résultat : un utilisateur qui exécute des processus qu’il ne peut pas se permettre, un solde de crédits qui devient négatif, et un état de compte désormais faux d’une manière que personne n’avait prévue.

Vous ne détecterez pas cela en cliquant une seule fois sur un bouton. Il faudrait penser à ouvrir cinq onglets, synchroniser les clics pour qu’ils tombent dans la même fraction de seconde, et savoir que « vérifier le solde » et « déduire le solde » sont deux étapes distinctes qui peuvent entrer en compétition. Ce n’est pas un oubli de test. C’est une catégorie de bug que le clic manuel, un à la fois, ne peut structurellement pas trouver, parce que le bug n’existe que lorsque plusieurs choses se produisent en même temps, et qu’une seule personne testant seule ne peut pas facilement créer cette condition volontairement, encore moins la reproduire.

C’est exactement le genre de cas limite que la recherche sur les applications générées par IA identifie comme le mode de défaillance dont personne ne tient compte : l’IA construit des parcours pour le scénario de succès précis qu’on lui a demandé, pas pour les modifications concurrentes, les clics en double ou les écarts de timing entre les étapes. Et comme la corruption qui en résulte ne déclenche pas d’erreur, elle reste là, silencieuse, jusqu’à ce qu’un rapport ou un solde paraisse faux des semaines plus tard.

Pourquoi presque personne n’écrit les tests qui détecteraient cela

La solution honnête pour cette catégorie de bug, c’est le test automatisé : tests unitaires, tests d’intégration, quelque chose capable de simuler cinq requêtes simultanées et de vérifier le résultat mécaniquement, plutôt que de compter sur l’imagination et la patience d’un humain. Les tests automatisés ne se fatiguent pas, n’oublient pas un cas limite, et peuvent être relancés après chaque changement pour s’assurer que ce que vous avez corrigé lundi n’a pas cassé quelque chose mardi.

En pratique, les vibe coders n’ont presque jamais cela. Écrire une suite de tests est une compétence technique à part entière, sans doute plus difficile que d’écrire l’application elle-même, puisqu’elle exige de raisonner sur les modes de défaillance et pas seulement sur le fonctionnement de la fonctionnalité. Un agent IA peut écrire des tests si vous le lui demandez, mais il faut encore savoir qu’il faut le demander, comprendre ce que les tests vérifient réellement, et les maintenir à jour à mesure que l’application change sous leurs pieds. Pour un créateur non technique qui livre un portail client un mardi après-midi, c’est un pas trop loin, et même les créateurs techniques qui codent vite s’arrêtent rarement pour écrire une couverture de tests pour un code qu’ils vont de toute façon remplacer au prochain prompt.

Donc, l’état réaliste des tests sur la plupart des applications vibe-codées, c’est : un seul passage sur le scénario idéal, fait une fois, par la personne la moins équipée pour deviner ce qui pourrait mal se passer. C’est là le fossé de confiance. Vous ne vérifiez pas que l’application fonctionne. Vous espérez qu’elle fonctionne, sur la base de la seule chose que vous avez essayée.

Ce que « certitude visuelle » veut vraiment dire

Il existe une véritable alternative à l’espoir, et ce n’est pas « apprendre à écrire des suites de tests ». C’est construire les parties risquées sur une base où la logique n’est pas cachée dès le départ.

La certitude visuelle signifie que vous pouvez ouvrir un panneau de réglages et voir exactement quel groupe d’utilisateurs peut consulter un enregistrement, exactement quel filtre un bloc applique à une source de données, et exactement ce qu’un workflow fait, étape par étape, dans l’ordre, sans lire une seule ligne de code généré. Vous ne testez pas un comportement pour en déduire la règle. Vous lisez la règle directement.

Cela compte le plus pour les catégories où le fossé de confiance coûte le plus cher : la logique de facturation, les permissions, et tout ce qui implique des utilisateurs concurrents. Une plateforme comme Softr gère cela en conservant les permissions, les restrictions de données et les étapes de workflow sous forme de configuration visuelle et inspectable, plutôt que de code généré par IA qu’il faudrait auditer ligne par ligne pour y faire confiance. Si vous voulez savoir si un client peut voir les enregistrements d’un autre client, vous ouvrez la règle de restriction de données et vous la lisez. Vous n’avez pas besoin de simuler cinq connexions simultanées en espérant que l’IA a correctement géré la situation de concurrence, parce que c’est l’infrastructure déjà testée de la plateforme qui applique la règle, pas une vérification sur mesure que l’IA a écrite pour votre prompt spécifique.

Cela ne veut pas dire que chaque fonctionnalité personnalisée disparaît dans un panneau de réglages. Pour une interface vraiment sur mesure, un bloc vibe-codé limité à un seul composant et connecté via la couche de permissions et de données existante de la plateforme représente un risque très différent d’une application entière de logique métier générée, parce que le rayon d’impact d’un « l’IA s’est trompée sur cette partie » se limite à un bloc, pas au système de facturation.

Le choix qui vous reste vraiment

Si votre application est un projet de week-end ou un prototype que personne ne paie, publiez-la, testez le scénario idéal une fois, et passez à autre chose. L’enjeu est exactement celui du test manuel que vous avez fait.

S’il s’agit d’un portail client, d’un système de réservation, ou de tout ce qui implique des crédits, des soldes ou des rôles, la question honnête n’est pas « est-ce que j’ai testé ça ? ». C’est « puis-je vraiment vérifier les parties qui feraient mal si elles étaient fausses, ou est-ce que je fais confiance à la parole d’une IA ? ». Si la réponse est la confiance, c’est le même choix dont nous avons déjà parlé avec le problème du Jour Deux, et les deux branches sont légitimes selon qui vous êtes.

Si vous savez lire le code, ou si vous êtes prêt à apprendre, comblez le fossé avec de vrais outils plutôt qu’avec un autre créateur. Cursor travaille dans une vraie base de code où vous pouvez demander des tests de concurrence et lire ce qui en résulte, et Replit vous offre un environnement cloud où faire tourner une suite de tests fait normalement partie de la boucle, et n’est pas une réflexion après coup. Dans les deux cas, le fossé n’est pas la capacité de l’IA, c’est de savoir qu’il faut demander le test et d’être capable de juger s’il est bon.

Si vous ne pouvez pas, et que vous construisez le genre d’application où une mauvaise permission ou un solde négatif est un vrai problème, déplacez les parties risquées vers une base où vous lisez la règle au lieu de la deviner. Consultez notre classement des portails clients si c’est l’application que vous construisez réellement, parce que c’est là qu’une mauvaise supposition coûte le plus cher.