Vérifier du code IA sans programmer : sept contrôles

L’IA a créé un site web ou un bot pour vous en une soirée. Tout s’ouvre, les boutons fonctionnent et le projet semble tourner. Vous le montrez à des gens, puis un jour plus tard, vous découvrez que le formulaire de paiement débite de l’argent, mais que les commandes n’arrivent jamais. Ou que la base de données contenant les numéros de téléphone de vos clients est accessible à tout Internet.

Moi aussi, j’ai livré mes premiers projets comme ça : des choses qui semblaient fonctionner réservaient des surprises aux vrais utilisateurs. Aujourd’hui, avant de montrer quoi que ce soit, je passe le projet au crible de la même liste de contrôle. Je ne lis pas une seule ligne de code pour cela — je ne suis pas venu pour ça, et vous non plus, probablement.

Et ce n’est pas de la paranoïa. Anthropic a analysé 400,000 sessions Claude Code : sur sept mois, la part du travail consacrée à la réparation du code défectueux est passée de 33 % à 19 %. Elle a baissé, mais n’a pas disparu. Une session sur cinq consiste encore à « réparer ce que l’IA a cassé ».

L’écriture du code n’est plus le goulot d’étranglement. Ce qui compte désormais, c’est votre compréhension de la tâche et votre capacité à vérifier le résultat.

Vous trouverez des ressources supplémentaires sur la configuration des outils dans la documentation Ailoot.

Pourquoi vérifier le code généré par l’IA s’il fonctionne déjà ?#

L’IA écrit du code qui passe un examen superficiel. Il s’exécute, l’écran s’affiche et la démo semble convaincante. Mais le lancement ne vous apprend rien sur l’exactitude des calculs, l’exposition de votre base de données à l’extérieur ou la stabilité du projet à l’arrivée du centième utilisateur.

Les chiffres le confirment. Le benchmark FrontierCode a évalué en juin 2026 dans quelle mesure le code généré par l’IA était prêt à être utilisé dans un vrai travail sans modification. Même pour les meilleurs modèles sur les tâches les plus difficiles, cette part était d’environ 13 %. Autrement dit, pour les tâches sérieuses, la plupart des codes générés par l’IA doivent être peaufinés à la main avant qu’on puisse s’y fier.

La bonne nouvelle, c’est que tout le monde peut faire ces vérifications. Voici la conclusion qu’Anthropic a tirée de ces mêmes 400,000 sessions :

Votre avantage sur les programmeurs auxquels vous pourriez faire appel, c’est que vous comprenez votre tâche. Vérifier, c’est aussi comprendre ; vous n’avez pas besoin de lire du code. Les vérifications ci-dessous sont précisément à votre portée, sans difficulté.

Qu’est-ce qui peut réellement mal tourner avec du code généré par l’IA ?#

Avant de vérifier, il est utile de savoir ce que vous cherchez. Le code généré par l’IA présente cinq problèmes typiques, que vous pouvez tous repérer sans lire le code, en observant le comportement du projet.

Voici sept vérifications, dans l’ordre. Les premières détectent les cas où le projet « ne fonctionne pas » ou « fonctionne mal » ; celles du milieu couvrent la sécurité et les inventions ; les dernières sont des garde-fous avant la publication. Mieux vaut les faire dans l’ordre : chacune s’appuie sur la vérification précédente.

Vérification 1 : demandez à l’IA d’expliquer son code en termes simples#

Vous avez décrit la tâche avec des mots. L’IA l’a traduite en code. Du sens peut se perdre entre ces deux étapes : l’IA vous a peut-être mal compris, a pris des initiatives ou a fait des raccourcis. Vous pouvez repérer l’écart sans lire le code : demandez-lui simplement de décrire en termes simples ce qu’elle a fait.

Explique en langage simple, sans code, exactement ce que tu viens de faire :

quelle tâche ce code résout

ce qui se passera quand un utilisateur cliquera sur le bouton ou enverra le formulaire

où les données sont stockées et qui y a accès

ce qui pourrait ne pas fonctionner et dans quelle situation

Écris comme si tu l’expliquais à quelqu’un qui n’a jamais programmé. Si tu n’es pas sûr qu’une partie soit correcte, dis-le clairement.

Lisez la réponse et comparez-la à ce que vous aviez en tête. Si elle correspond, continuez. Si l’IA « tourne autour du pot », se perd dans sa propre explication ou décrit autre chose que ce que vous avez demandé, c’est qu’elle ne comprend pas entièrement ce qu’elle a construit. Demandez-lui de revoir son travail en précisant votre demande, au lieu de la croire sur parole.

Au fait, si l’IA fait régulièrement autre chose que ce que vous demandez, le problème vient souvent de la formulation de la tâche, et non du modèle lui-même. J’ai consacré un article distinct à pourquoi Claude ne fait pas ce que vous lui demandez.

Vérifier le résultat de l’IA fait partie du Context Engineering : vous contrôlez ce que vous fournissez à l’IA en entrée et la façon dont vous évaluez le résultat en sortie. La boîte à outils comprend un clone d’IA, un Second Brain et le Context Engineering. Ensuite, Claude cesse d’être un « assistant qui hallucine » et devient un outil auquel vous pouvez réellement confier un projet.

Vérification 2 : parcourez les scénarios comme le ferait un vrai utilisateur#

Une démo d’IA suit toujours le scénario idéal : données correctes, un clic, tout se passe bien. Un vrai utilisateur ne se comporte pas ainsi. Il fait des erreurs, clique au mauvais endroit ou saisit un emoji dans le champ du téléphone. Votre tâche consiste à parcourir le projet comme il le ferait.

1. Suivez le scénario principal du début à la fin

   Faites ce pour quoi le projet existe : inscrivez-vous, passez une commande ou envoyez une demande. Allez jusqu’au bout, pas seulement à mi-chemin.

2. Vérifiez les paiements séparément et pour de vrai

   Si le projet accepte de l’argent, effectuez vous-même un paiement du montant minimum en mode test. Vérifiez que la commande est créée, que son statut change et qu’un e-mail est envoyé à vous-même et au client. Un paiement qui « passe » sans créer de commande est un exemple classique de défaillance silencieuse.

3. Provoquez volontairement des erreurs

   Laissez des champs vides. Saisissez des lettres là où des chiffres sont attendus. Cliquez deux fois de suite sur « Envoyer ». Téléversez un fichier au mauvais format. Un bon projet dira poliment « vous ne pouvez pas faire ça » ; un mauvais plantera ou avalera les données sans rien signaler.

4. Ouvrez le projet sur un téléphone

   La moitié de vos utilisateurs viendront d’un téléphone. Vérifiez que la mise en page n’est pas déformée et que les mêmes boutons y fonctionnent.

Communiquez à l’IA tout ce que vous avez trouvé dans une seule liste : « Voici ce qui a échoué dans ces étapes ; corrige-le et explique-moi pourquoi. » Ne traitez pas les problèmes un par un : donnez-lui la liste complète pour qu’elle voie l’ensemble et risque moins de casser une chose en en réparant une autre.

Vérification 3 : demandez à l’IA de contrôler la sécurité — voici un prompt#

Un bouton cassé se remarque immédiatement. Une faille de sécurité, non : le projet continue à fonctionner comme si de rien n’était jusqu’à ce que quelqu’un en profite. Parmi les problèmes les plus fréquents des projets créés par vibe coding figurent les clés secrètes écrites directement dans le code, une base de données exposée sur Internet et des formulaires qui permettent d’envoyer des saisies malveillantes. L’IA peut trouver tout cela si vous le lui demandez directement.

Fais un audit de ce projet pour repérer les problèmes de sécurité et explique chaque constat en langage simple, sans jargon. Passe en revue cette liste :

Vérifie si des clés secrètes, des mots de passe ou des jetons sont écrits directement dans le code. Les secrets privés doivent être utilisés seulement sur le serveur, avec la configuration locale comme .env exclue de Git. .env et .gitignore n’empêchent pas les variables publiques du frontend d’entrer dans le build navigateur. Inspecte JavaScript, source maps, HTML et réponses réseau réellement livrés au client pour vérifier l’absence de clés privées.

Vérifie si la base de données est exposée sur Internet et qui y a accès.

Vérifie si des saisies peuvent compromettre les formulaires : injections dans les requêtes de base de données ou ajout de code dans les champs de texte.

Que se passera-t-il si un utilisateur envoie des données malveillantes ?

Vérifie si des pages internes ou le panneau d’administration sont accessibles sans mot de passe.

Pour chaque point, indique s’il y a un problème, donne un exemple clair du risque et explique comment le corriger. Commence par le problème le plus dangereux.

Vérifiez également que votre projet n’exécute pas aveuglément tout ce qu’il reçoit de l’extérieur. On appelle cela l’injection indirecte de prompt : une commande est dissimulée dans un e-mail, un commentaire ou un fichier appartenant à quelqu’un d’autre, et votre agent d’IA la suit en la prenant pour une tâche. Si le projet lit des données externes et agit en conséquence, demandez à l’IA ce qui se passerait si ces données contenaient une instruction cachée.

C’est un vaste sujet, et un seul prompt ne peut pas le couvrir entièrement. Si le projet gère de l’argent ou des données personnelles de clients, lisez le guide distinct sur la sécurité du vibe coding.

Vérification 4 : l’IA a-t-elle inventé des bibliothèques ou des données ?#

L’IA écrit avec assurance des choses qui n’existent pas. Elle peut ajouter une bibliothèque au nom plausible, mais inexistante. Elle peut aussi laisser des espaces réservés de test dans le projet : un produit appelé « Example », l’adresse e-mail example@example.com ou du texte de remplissage à la place d’un contenu réel. Cela passe facilement inaperçu dans une démo, mais c’est embarrassant ou problématique pour un vrai utilisateur.

Vous pouvez le repérer en deux étapes. D’abord, posez la question directement :

Passe le projet en revue et vérifie honnêtement :

Tous les outils externes et les bibliothèques que tu as ajoutés existent-ils vraiment et s’installent-ils correctement ? As-tu inventé quelque chose ?

Reste-t-il des espaces réservés de test, des exemples ou du texte de remplissage à la place de données réelles ?

Tous les liens, adresses et coordonnées du projet sont-ils réels et non des espaces réservés ?

Dresse la liste de tes constats et propose par quoi les remplacer.

Ensuite, lancez simplement le projet et parcourez-le. Une bibliothèque inventée provoque presque toujours une erreur au lancement. Et les espaces réservés se repèrent facilement : si la page affiche « Produit 1 », c’est que vous ne les avez pas remplacés.

Les bibliothèques inventées présentent un danger particulier, car des pirates enregistrent délibérément des outils sous des noms que l’IA aime inventer. Si vous en installez un, le code de quelqu’un d’autre se retrouve dans votre projet. C’est pourquoi vous devez prendre au sérieux la question « cette bibliothèque existe-t-elle vraiment ? » : elle concerne directement la sécurité de votre projet.

Vérification 5 : demandez à un deuxième modèle de contrôler le premier#

L’IA a un trait déplaisant : elle acquiesce. Demandez « tout va bien ici ? », et elle confirmera que tout va bien parce qu’elle s’adapte à la réponse attendue. C’est ce qu’on appelle la complaisance de l’IA, et j’ai écrit un article à ce sujet. Un interlocuteur comme celui-là sera indulgent envers son propre travail.

La solution est simple : demandez un deuxième avis. Ouvrez une nouvelle session ou utilisez un autre modèle et donnez-lui le projet à vérifier avec le même prompt que celui de la vérification 3, en ajoutant : « une autre IA a écrit ce code ; trouve ses points faibles ». Le nouveau modèle n’est pas lié à la conversation précédente et a plus de chances de signaler les problèmes.

1. Ouvrez une session vierge ou utilisez un autre modèle

   Utilisez un deuxième modèle ou le même dans une nouvelle fenêtre, sans historique de tâche.

2. Donnez-lui le projet en précisant le bon angle

   Dites clairement : « une autre IA a écrit ce code ; votre tâche consiste à trouver les erreurs et les risques, pas à le féliciter ». Cela limite la complaisance.

3. Comparez les deux avis

   Si les deux sont d’accord, ils ont probablement raison. S’ils sont en désaccord, examinez ce point : c’est là que les choses deviennent intéressantes.

C’est exactement ce qui se passe actuellement dans le secteur : l’IA écrit, l’IA vérifie et la décision finale revient à une personne. Vous ne pouvez pas la confier au modèle : c’est votre responsabilité.

Vérification 6 : comment revenir en arrière si une modification casse quelque chose ?#

Les vérifications de cette liste entraînent souvent des modifications, et celles-ci peuvent parfois casser ce qui fonctionnait. Pour éviter que cela ne tourne au désastre, enregistrez la version fonctionnelle dans git avant chaque série de corrections. C’est comme sauvegarder une partie : si vous cassez quelque chose, rechargez le dernier point de sauvegarde.

Vous n’avez pas besoin de lire le code pour cela. Demandez simplement à l’IA : « enregistre la version actuelle fonctionnelle dans git avec un libellé clair avant de modifier quoi que ce soit ». Et si tout déraille après les modifications : « restaure le projet à la version enregistrée précédemment ».

Si git est encore un territoire inconnu, voici deux guides : comment annuler des modifications dans Claude Code et que faire si l’IA a supprimé votre base de données. Le second s’adresse aux situations où il est déjà trop tard pour revenir en arrière, mais où vous pouvez encore récupérer vos données.

Vérification 7 : que vérifier en dernier avant la publication ?#

Les six premières vérifications portent sur ce que fait le code. La septième porte sur la capacité du projet à être présenté au public. C’est ici que beaucoup trébuchent : le projet fonctionne, mais ils ont oublié de passer le paiement de la clé de test à la clé réelle, si bien que les premiers clients paient « pour de faux ».

1. Paiement : du mode test au mode réel

   Si vous acceptez les paiements, assurez-vous que la clé réelle du système de paiement est connectée, et non la clé de test. Effectuez un vrai paiement du montant minimum et remboursez-vous.

2. Les secrets sont à leur place

   Demandez à l’IA : « Les clés privées sont-elles utilisées seulement sur le serveur, avec .env exclu de Git ? Le build navigateur ou une réponse client contient-il une clé privée, via une variable publique ou une source map ? » Inspectez fichiers construits et réponses réseau, pas seulement .env. L’exclusion Git ne retire pas une valeur du bundle frontend.

3. Sauvegardez les données

   Vérifiez que la base de données est automatiquement sauvegardée quelque part. Si votre projet tourne sur votre propre serveur, j’explique la publication dans le guide Coolify.

4. La publication fonctionne aussi ailleurs que sur votre appareil

   Ouvrez le projet sur votre téléphone à l’aide d’un lien externe, pas seulement sur votre propre ordinateur. Ce qui fonctionne en local ne fonctionne pas toujours une fois le projet publié.

Passez en revue ces quatre points : vous pourrez ensuite montrer le projet à des gens en toute tranquillité. Si quelque chose ne va pas, mieux vaut y consacrer une demi-heure maintenant que gérer des clients mécontents plus tard.

Et si la vérification prend trop de temps : faut-il simplement faire confiance à l’IA ?#

Je comprends la tentation. La vérification semble ennuyeuse et « ce n’est pas pour ça que j’ai pris une IA ». Mais c’est vous, pas le modèle, qui êtes responsable du résultat. L’IA n’a pas de réputation à protéger et ne subit aucune conséquence : elle a produit le code, puis l’a oublié. C’est vous qui devrez répondre au client dont le paiement n’a pas abouti.

Le créateur de Claude Code voit les choses plus largement encore :

L’écriture du code a cessé d’être le goulot d’étranglement : l’IA s’en est chargée. La valeur se trouve désormais ailleurs : dans la compréhension de la tâche et la vérification du résultat. C’est votre force : vous savez mieux que n’importe quel développeur externe quel résultat votre client devrait obtenir.

Pourquoi la vérification est-elle une compétence, et non une tâche ponctuelle ?#

Ces sept vérifications constituent le minimum pour passer de « je l’ai lancé en espérant que tout ira bien » à « je l’ai lancé et je sais que ça fonctionne ». Faites-les une fois et vous repérerez déjà la plupart des surprises avant vos clients.

Ensuite, cela devient une habitude. Donnez le bon contexte à l’IA en entrée et vérifiez le résultat en sortie ; chaque nouveau projet prendra alors forme plus rapidement, car vous ne repartirez pas de zéro.

Clone d’IA, Second Brain et Context Engineering : retrouvez des ressources supplémentaires sur les outils dans la documentation Ailoot.