Qualité, revue et contrôle

Nous l’avons posé dès le Module 1 : à l’ère de l’IA, le goulot d’étranglement n’est plus la production de code, mais sa vérification. Ce module est le cœur du métier tel qu’il se pratique désormais — et ce qui sépare un projet solide d’une bombe à retardement. C’est la compétence qui fait de vous un vrai chef de chantier.

Tester chaque modification

« Ça a l’air de marcher » n’est pas un test. Tester, c’est vérifier concrètement que le comportement attendu se produit, dans les cas normaux comme dans les cas limites. Pour la plupart des projets débutants, un test manuel rigoureux suffit au début — à condition de le faire méthodiquement : après chaque modification, parcourez le scénario concerné du début à la fin. Le formulaire de contact ? Remplissez-le, envoyez-le, vérifiez la confirmation — et testez aussi ce qui doit échouer (un e-mail invalide doit être refusé).

Réflexe essentiel : testez aussi ce qui n’était pas censé changer. C’est là que se cachent les régressions.

À mesure que le projet grandit, les tests automatisés prennent le relais : de petits programmes qui vérifient que votre code fait ce qu’il doit. Claude sait très bien les écrire (« écris un test qui vérifie que le formulaire refuse un e-mail invalide »), et un outil comme Playwright (Module 10) simule un vrai utilisateur qui clique dans le navigateur. Ne vous suréquipez pas trop tôt, mais sachez que cette pratique devient indispensable sur un projet sérieux.

Vérifier que Claude n’a rien cassé

Après chaque modification importante, posez-vous trois questions. Ce petit rituel, répété systématiquement, attrape l’immense majorité des problèmes avant qu’ils ne s’accumulent :

• La nouveauté fonctionne-t-elle ? (le test évident)
• Ce qui fonctionnait fonctionne-t-il encore ? (la chasse aux régressions)
• Le diff contient-il uniquement ce que j’ai demandé ? (la relecture des changements, Module 5)

Détecter les hallucinations de l’IA

Une hallucination, c’est quand l’IA affirme quelque chose de faux avec une confiance totale. C’est l’un des pièges les plus dangereux, car rien dans le ton de la réponse ne signale l’erreur. Les formes les plus fréquentes :

Des librairies ou fonctions inexistantes.

Claude peut inventer un package au nom plausible, ou une fonction qui n’a jamais existé.

Des API mal utilisées.

Il peut se tromper sur les paramètres d’une fonction ou sur son comportement.

De fausses certitudes.

Affirmer qu’un code est sécurisé, performant ou conforme, sans que ce soit vérifié.

La parade est le réflexe de vérification systématique : vérifier qu’une librairie inconnue existe vraiment (sur son site officiel, pas sur parole) ; demander une explication quand un code « marche » sans qu’on comprenne pourquoi ; tester, toujours (une hallucination survit rarement à un test concret) ; croiser les sources sur les sujets critiques. Un signe qui doit alerter : quand vous demandez à l’IA de justifier un choix et qu’elle change complètement d’avis sous une simple question — la première réponse n’était pas fondée.

Reconnaître un mauvais code

Vous n’avez pas besoin d’être expert pour repérer les signaux d’un code de mauvaise qualité. Quelques marqueurs universels :

• La duplication : le même bloc copié à plusieurs endroits. Le jour où il faut le corriger, on l’oublie quelque part — et le bug apparaît.
• Les fonctions géantes : 200 lignes qui font dix choses. Une bonne fonction fait une seule chose.
• Les « nombres magiques » et valeurs en dur : des valeurs mystérieuses, ou des textes écrits en dur au lieu d’être centralisés.
• Le couplage excessif : modifier une partie oblige à en modifier cinq autres.
• L’absence de cohérence : styles, nommages et approches qui varient d’un fichier à l’autre.

Vous pouvez aussi demander à l’IA de s’auto-évaluer : « Ce code présente-t-il des duplications, des fonctions trop longues, des problèmes de maintenabilité ? » Elle est souvent lucide sur sa propre production — quand on l’y invite.

Reconnaître une mauvaise architecture

L’architecture, c’est l’organisation d’ensemble : comment fichiers, données et responsabilités sont répartis. Plus difficile à voir qu’un mauvais bout de code, mais ses symptômes sont reconnaissables :

• Chaque nouvelle fonctionnalité est de plus en plus difficile à ajouter.
• Une modification en casse trois autres (responsabilités mal séparées).
• Personne ne sait où mettre le nouveau code (la structure manque de logique).
• Les données sont incohérentes ou dupliquées d’un endroit à l’autre.

Ces symptômes doivent alerter tôt : une mauvaise architecture est coûteuse à corriger, car elle touche aux fondations. Enfin, une technique simple et puissante à généraliser : demandez à Claude de justifier ses choix. « Pourquoi cette approche plutôt qu’une autre ? Quelles alternatives et quels compromis ? » Si la justification est solide, vous avancez en confiance ; si elle s’effondre à la première question, vous venez d’éviter une mauvaise décision.