La façon la plus fiable de vérifier du code généré par l'IA, c'est d'écrire d'abord ce que l'application doit faire dans chaque situation, puis d'essayer volontairement les cas où quelque chose peut mal tourner. Un seul exemple qui fonctionne ne prouve pas grand-chose : il montre seulement que ce chemin précis marche.
Pour une personne qui débute, cela ressemble à des connaissances de programmation. En bonne partie, ce n'en est pas. Tu n'as pas besoin de lire le code ligne par ligne pour vérifier qu'il fait ce qu'il doit faire. Il te faut des attentes claires, quelques cas de test inconfortables et l'habitude de contrôler toi-même chaque résultat.
Pourquoi un exemple réussi ne suffit pas
Imagine que tu demandes à un agent IA comme Claude Code ou Codex d'ajouter à ta liste de contacts un formulaire pour les nouveaux contacts. Tu saisis un nom et une adresse e-mail, tu cliques sur Enregistrer, et le contact apparaît dans la liste. Ça a l'air terminé.
Pourtant, plusieurs questions restent ouvertes :
- Que se passe-t-il si le champ du nom est vide ?
- « max@ » est-il accepté comme adresse e-mail ?
- Le contact est-il toujours là après le rechargement de la page ?
- Un contact déjà existant apparaît-il ensuite en double ?
L'IA a construit le chemin que tu as décrit. Les bifurcations que tu n'as pas mentionnées, elle les a peut-être prises en compte, peut-être pas. Comme le code a l'air propre et que la réponse paraît sûre d'elle, une lacune n'apparaît souvent que lorsque quelqu'un utilise vraiment l'application. Le cas normal pose rarement problème. Les erreurs se cachent surtout dans les marges.
Définir à l'avance ce qui est correct
Avant de pouvoir vérifier, il te faut une référence. Les cas d'acceptation s'y prêtent bien : de courtes phrases qui décrivent une situation et le résultat attendu. Pour un changement de statut dans une application de suivi, cela pourrait donner ceci :
- Si je passe un contact de « nouveau » à « contacté », la liste affiche immédiatement le nouveau statut.
- Si je filtre par statut, seuls les contacts ayant ce statut apparaissent.
- Si une date de suivi est dans le passé, le contact est marqué comme en retard.
Ces phrases te servent deux fois. Tu peux les donner à l'IA comme consigne, au lieu d'écrire « fais-moi un filtre ». Et tu peux ensuite cocher chaque phrase une par une. Ce que tu n'as pas formulé, tu ne peux pas non plus le vérifier. C'est pourquoi il vaut la peine de penser aux cas désagréables dès la rédaction de la consigne.
Ce que les tests apportent, et ce qu'ils n'apportent pas
Un test automatique est un petit programme qui reproduit un cas d'acceptation et indique si le résultat attendu se produit. Au lieu de cliquer à la main à chaque fois, tu lances une commande et tu vois quels contrôles passent et lesquels échouent.
Les tests apportent surtout trois choses :
- Ils fixent ce qui est correct, quelle que soit la force de conviction d'une explication de l'IA.
- Ils signalent quand une modification ultérieure casse quelque chose qui fonctionnait avant. Avec un agent IA, cela arrive facilement, parce qu'en retravaillant un endroit, il en modifie parfois un autre au passage.
- Ils rendent la vérification reproductible. Tu ne testes pas au feeling, mais chaque fois de la même manière.
Les tests ont tout de même leurs limites. Un test ne vérifie que ce qu'il contient. Si tu demandes à l'IA d'écrire le code et les tests en même temps, les deux peuvent contenir la même erreur de raisonnement. Tout est alors au vert, et pourtant faux. Lis donc au moins ce qu'un test est censé vérifier et compare-le avec tes cas d'acceptation. Et quand un test échoue, ne laisse pas simplement l'IA modifier le test jusqu'à ce qu'il passe. Clarifie d'abord si c'est le code ou le test qui est faux.
Provoquer volontairement les cas d'erreur
Les cas d'erreur sont des situations qui s'écartent du déroulement idéal. En les provoquant exprès, on trouve la plupart des faiblesses. Pour une application simple, quatre groupes couvrent déjà beaucoup.
Informations manquantes
Laisse les champs obligatoires vides. Enregistre un contact sans nom, crée un suivi sans date. Regarde si l'application affiche un message compréhensible ou si une entrée vide atterrit dans la liste. Vérifie aussi les champs qui ne contiennent que des espaces : pour beaucoup de programmes, un espace est une saisie valable.
Saisies non valables
Saisis des données qui n'ont pas la forme attendue : une adresse e-mail sans domaine, une date comme le 31 février, un texte très long. Essaie aussi des caractères spéciaux et des accents ou trémas dans le nom. Une bonne validation refuse les absurdités et laisse passer les saisies correctes comme « Müller-Zürcher ». Les deux doivent être testés.
L'interface tombe en panne ou répond autrement que prévu
Dès que ton application récupère des données depuis une interface, de nouvelles sources d'erreur apparaissent. Vérifie au moins ces cas :
- La réponse est vide. L'application affiche-t-elle une indication utile ou une surface vide et déroutante ?
- L'interface renvoie une erreur. L'application plante-t-elle, ou reste-t-elle utilisable ?
- La réponse prend du temps. Voit-on que le chargement est en cours, ou l'application semble-t-elle figée ? Peut-on cliquer deux fois entre-temps et créer ainsi des doublons ?
Avec une vraie interface, ces cas sont difficiles à provoquer, parce qu'elle fonctionne la plupart du temps. Une interface simulée, qui répond sur demande de façon vide, erronée ou lente, est beaucoup plus pratique pour cela.
Accès et secrets
Ce domaine est souvent oublié. Demande-toi qui a le droit de voir ou de modifier quelles données, et vérifie que c'est bien mis en œuvre ainsi. Contrôle aussi que les clés d'accès ou les mots de passe ne figurent pas dans le code lui-même. Il arrive que du code généré écrive ces valeurs directement dans un fichier, si la consigne ne demande rien d'autre.
Checklist pour chaque modification de l'IA
Tu peux parcourir cette courte liste après chaque étape de travail importante :
- J'ai écrit à l'avance, en une phrase, ce que la modification doit produire.
- J'ai essayé moi-même le cas normal, sans me fier au résumé de l'IA.
- J'ai testé au moins un cas avec des informations manquantes et un avec des saisies non valables.
- Si une interface est concernée : réponse vide, erreur et temps d'attente vérifiés.
- Tous les tests automatiques passent, y compris ceux qui passaient déjà avant.
- Je sais quels fichiers l'IA a modifiés et je peux expliquer en gros pourquoi.
- Le code ne contient ni mots de passe ni clés.
Si un point reste ouvert, donne à l'IA une indication concrète : quel cas, quel résultat tu attendais, ce qui s'est passé à la place. Plus la description est précise, plus la correction est ciblée.
Travailler de façon traçable avec un journal IA
Vérifier, c'est aussi savoir plus tard ce qui s'est passé. Un simple journal aide : qu'as-tu demandé à l'IA, qu'a-t-elle apporté, qu'as-tu modifié ou écarté toi-même ? Cela paraît fastidieux, mais c'est rentable dès qu'une erreur apparaît. Tu peux alors cerner à quelle étape elle s'est glissée. Si tu enregistres en plus de petits états intermédiaires avec Git, tu peux annuler une modification ratée au lieu de la recouvrir avec de nouvelles consignes.
Le journal aide aussi à expliquer. Qui sait décrire sa solution et en nommer les limites l'a vérifiée. Qui peut seulement dire « l'IA l'a fait comme ça » lui a fait confiance.
Le lien avec le cours Vibe Coding Foundation
Dans le programme Vibe Coding Foundation, tu construis avec Claude Code ou Codex une application de contacts et de suivi pour une petite entreprise, avec des données d'exemple. La vérification traverse toutes les missions. Chaque mission a un objectif, des critères sous forme de tests et des indices en trois niveaux. Sur ton ordinateur, une commande vérifie si ta solution remplit les critères. Ce qui compte, c'est la vérification sur le serveur de l'académie, dans un environnement isolé et sans réseau. Tu constates ainsi directement que « ça marche chez moi » et « ça remplit les critères » sont deux choses différentes.
Les cas d'erreur de cet article y apparaissent concrètement :
- Dans la mission 3, tu vérifies les saisies et tu ajoutes des changements de statut ainsi que des filtres.
- Dans la mission 4, tu t'exerces sur une interface simulée à gérer les réponses, les erreurs et les temps d'attente.
- Dans la mission 5, tu cernes des erreurs préparées, tu les corriges et tu vérifies des cas d'accès de base.
- Dans la mission 7, tu étends l'application avec un export CSV des suivis en retard et tu vérifies la nouvelle fonction.
Pendant tout le cours, tu tiens un journal IA. Lors de l'examen de projet écrit, tu expliques ta solution et ses limites ; la grille d'évaluation de l'examen (en allemand) montre comment c'est noté. Toutes les missions avec leurs durées prévues figurent dans la vue d'ensemble du cours (en allemand), et la mission 0 pour installer les outils est en libre accès. Le projet d'apprentissage enregistre les données dans le navigateur et est prévu pour des données d'exercice, pas pour de vraies données d'entreprise. Le prix du cours et ce qu'il comprend sont indiqués sous Prix et prestations.