Faire vérifier son travail par l'IA :la boucle en 4 niveaux

Faire vérifier son travail par l'IA, c'est lui imposer une courte liste de commandes à exécuter, et à réussir, avant qu'elle vous montre le moindre code. Vérification des types, tests, une vraie requête, un parcours manuel. Avant les boucles de validation, 70 % de mes demandes de build exigeaient un tour de débogage. Après, 95 % fonctionnent du premier coup.

C'est l'habitude qui a le plus fort effet de levier pour un fondateur non technique qui construit avec l'IA. Voici exactement comment elle fonctionne, avec la version à copier-coller.

Pourquoi le code de l'IA a l'air parfait jusqu'à son exécution

Voici le cycle que tout fondateur qui construit avec l'IA connaît trop bien. Vous donnez un prompt à l'IA. Elle génère un code qui paraît parfait. Vous le collez. Vous l'exécutez. Ça casse : erreurs de types, tests en échec, plantages, morceaux manquants. Vous recollez l'erreur. Elle corrige celle-là. Vous relancez. Nouvelles erreurs. Dix itérations plus tard, ça marche enfin.

Je l'ai vécu. J'ai un jour demandé une fonctionnalité de scoring avec un simple prompt d'une ligne. Le code est revenu propre, puis a produit trois erreurs distinctes à l'exécution. Les corriger m'a pris 3 heures d'allers-retours. La même fonctionnalité, demandée avec une boucle de validation attachée, a pris 15 minutes, sans la moindre itération de ma part. L'IA a rencontré les mêmes erreurs, mais elle les a détectées et corrigées elle-même avant que je voie le code.

Le problème n'a jamais été que l'IA écrit des premiers jets bugués. Tous les développeurs écrivent des premiers jets bugués. Le problème, c'est de remettre un premier jet comme s'il était terminé. Une boucle de validation comble cet écart.

Faire vérifier son travail par l'IA : ce qu'est une boucle de validation

Une boucle de validation est une liste de contrôles exécutables qui vérifient le travail, classés du plus rapide au plus lent. L'IA les exécute, voit les échecs, les corrige et relance, jusqu'à ce que tout passe. Alors seulement, elle présente le code. Vous obtenez un travail qui a déjà traversé quatre niveaux de vérification.

L'ordre compte : échouer vite. Inutile de lancer une vérification de bout en bout de cinq minutes si le code ne compile même pas. La règle est simple : l'IA doit réussir le niveau 1 avant d'avoir le droit de lancer le niveau 2, et ainsi de suite jusqu'en haut de l'échelle.

La boucle de validation à copier-coller

Collez ceci à la fin de n'importe quelle demande de build. Adaptez les commandes à ce que votre projet utilise : c'est la structure qui compte.

Boucle de validation : exécute les quatre niveaux et corrige chaque échec avant de me montrer le code.

Niveau 1 : syntaxe et types. Lance la vérification de types du projet. Attendu : zéro erreur. En cas d'échec, corrige les erreurs et relance avant de continuer.

Niveau 2 : tests unitaires. Lance les tests de ce que tu as modifié. Attendu : tous les tests passent. Inclus des tests pour le cas normal, le cas vide et au moins un cas d'erreur.

Niveau 3 : intégration. Fais une vraie requête sur l'application en cours d'exécution et confirme la réponse exacte que j'ai décrite. En cas d'échec, vérifie la connexion à la base de données et les permissions.

Niveau 4 : parcours manuel. Donne-moi un chemin de clics numéroté pour que je vérifie moi-même la fonctionnalité, avec ce que je dois voir à chaque étape.

Trois détails font que ça marche. D'abord, chaque instruction est exécutable : « teste le service pour t'assurer qu'il fonctionne » n'est pas une commande, alors que « lance les tests de ce que tu as modifié » en est une. Ensuite, chaque niveau précise le résultat attendu, pour que l'IA sache à quoi ressemble le succès au lieu de deviner. Enfin, chaque niveau inclut une piste de correction, ce qui accélère considérablement l'autocorrection.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Le build qui a détecté 47 bugs avant que j'en voie un seul

Le meilleur exemple que j'aie est une fonctionnalité de matching construite pour une plateforme d'accélérateur : associer des startups à des mentors selon 12 critères, avec un scoring pondéré, des limites de disponibilité et des règles de fuseau horaire. Assez complexe pour qu'un premier jet soit forcément faux quelque part.

J'ai rédigé la demande comme une spécification structurée avec une boucle de validation complète attachée, l'approche que j'ai décrite dans la méthode PRP. L'IA a généré le code, puis a exécuté la boucle. Elle a trouvé 47 bugs : 12 erreurs de types, 18 tests en échec, 9 cas limites non gérés et 8 règles métier violées. Elle les a tous corrigés automatiquement, en relançant les contrôles après chaque correction. Je n'en ai pas vu un seul. Quand j'ai moi-même testé la fonctionnalité terminée, elle fonctionnait parfaitement.

Sans la boucle, ces 47 bugs seraient apparus un par un : chacun un message d'erreur obscur, un aller-retour avec l'IA et un test de plus. C'est la différence entre un après-midi et une semaine.

Où se cachent vraiment les bugs : les cas limites

Le niveau 2 mérite une attention particulière, car les cas limites sont à l'origine de 80 % des bugs en production. Un code qui marche avec des données parfaites s'effondre dès qu'un vrai utilisateur envoie un formulaire vide, un e-mail en double ou un message contenant un emoji.

Ne demandez donc pas simplement « des tests » : nommez les cas. Le cas normal, le cas vide, la saisie invalide, le chemin d'erreur. Si vous êtes sceptique à l'idée que l'IA corrige ses propres copies, cet instinct est sain : j'ai expliqué comment garder ces tests honnêtes dans les tests écrits par l'IA. En bref : des tests qui vérifient des valeurs attendues précises, que vous avez nommées à l'avance, sont difficiles à tromper.

Ce qui change quand l'IA se valide elle-même

Mon avant/après, sur des centaines de fonctionnalités : avant les boucles de validation, 70 % des demandes de build exigeaient des itérations de ma part. Après, 95 % fonctionnent parfaitement du premier coup. Les 5 % qui échouent encore sont généralement des problèmes d'environnement, une clé d'API manquante, la mauvaise base de données, pas des bugs de code.

Voilà le vrai changement. Sans boucle de validation, l'IA génère du code et vous passez des heures à le déboguer. Avec, l'IA génère du code, le valide, se corrige, et vous relisez quelque chose qui fonctionne déjà. Vous cessez d'être le service de contrôle qualité et redevenez le fondateur.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Questions fréquentes

Qu'est-ce qu'une boucle de validation en développement avec l'IA ?

Une boucle de validation est une liste de contrôles exécutables (vérification des types, tests unitaires, un appel d'intégration et un parcours manuel) que l'IA doit lancer et réussir avant de présenter son code. L'IA voit ses propres échecs et les corrige : vous recevez un travail pré-vérifié plutôt qu'un premier jet.

Faut-il savoir coder pour utiliser des boucles de validation ?

Non. Vous ne lisez pas le résultat des contrôles : vous posez les barrières. Le modèle ci-dessus fonctionne tel quel en copier-coller. Ce qu'il vous faut, c'est la discipline de l'attacher à chaque demande de build et de refuser tout code qui n'a pas passé les quatre niveaux.

Quel niveau de validation compte le plus ?

Le niveau 1 détecte le plus de bugs, environ 60 %, en cinq secondes environ, c'est pourquoi il passe en premier. Mais c'est au niveau 2 que se joue la qualité : les cas limites représentent 80 % des bugs en production, donc des tests qui couvrent les cas vides, invalides et d'erreur vous protègent le plus une fois les vrais utilisateurs arrivés.

L'IA peut-elle vraiment corriger ses propres erreurs ?

Oui, quand elle peut les voir. Face à un contrôle en échec et à un résultat attendu, l'IA lit l'erreur, repère la cause, la corrige et relance, parfois sur plusieurs itérations. Sur ma fonctionnalité de matching, elle a corrigé 47 bugs ainsi, sans mon intervention. Ce qu'elle ne peut pas faire, c'est corriger des erreurs qu'elle n'a jamais l'occasion d'observer.