Les assistants de code (Claude Code, Cursor, GitHub Copilot, Windsurf, Codex) ont changé la vitesse à laquelle on écrit du logiciel. Là où un développeur passait une journée à écrire une fonction, un assistant la propose en quelques secondes, et la propose souvent correcte. C’est un fait acquis (on a fait le point sur les gains réels et les limites des copilotes de code). Ce qui est moins acquis, c’est la conséquence logique de cette vitesse : la revue humaine, elle, n’a pas accéléré.
Il y a une tension nouvelle, et il faut la regarder en face. L’assistant produit plus de code, plus vite. L’humain qui doit vérifier ce code a toujours le même nombre d’heures et la même attention limitée. Le rapport entre le volume produit et la capacité de contrôle s’est inversé. C’est exactement dans cet écart que se nichent les bugs, et c’est exactement pour cela que les tests sont devenus plus importants, pas moins.
Cet article défend une position simple et têtue : l’IA accélère l’écriture, elle ne remplace pas le filet. Développer avec l’IA sans renforcer la discipline de test, c’est augmenter la vitesse à laquelle on produit des erreurs, pas la vitesse à laquelle on livre de la qualité.
La vitesse augmente le risque
Quand le code arrive par paquets entiers, la tentation est de faire confiance : ça compile, ça a l’air propre, l’assistant a l’air sûr de lui. C’est une illusion coûteuse. L’assistant est excellent pour produire du code syntaxiquement correct et sémantiquement plausible. Il ne sait pas si ce code est juste pour votre contexte, et il ne peut pas le savoir.
Le risque n’est pas que l’assistant fasse des erreurs grossières, celles-là sautent aux yeux. Le risque, c’est l’erreur subtile : la condition inversée qui passe les cas heureux, la valeur par défaut qui change un comportement en bordure, la dépendance implicite entre deux modules que rien ne documente. Ces erreurs ne se voient pas à la lecture rapide, surtout quand le code arrive à un rythme qui décourage la lecture attentive.
Sans tests automatiques, la seule barrière devient la revue humaine, et la revue humaine est débordée. Le résultat est mathématique : plus de code, plus vite, et plus d’erreurs qui passent entre les mailles. La vitesse, sans filet, se paie en dette. On en mesure l’ampleur chaque fois qu’il faut refactorer du code généré par IA livré sans tests.
Ce que l’assistant ne sait pas
Il faut comprendre la nature de la limite. L’assistant connaît la syntaxe, les idiomes, les bibliothèques. Il ne connaît pas votre contexte. Il ne sait pas que cette fonction est appelée par un chemin critique, que ce champ ne doit jamais être vide, que cette valeur vient d’un système externe qui tombe parfois, que cette règle métier a été ajoutée après un incident précis il y a deux ans.
Ce savoir-là, c’est le savoir de l’équipe, et il n’est nulle part dans le code de façon explicite. C’est précisément ce que les tests capturent : ils encodent l’intention, les invariants, les cas qui ont déjà mordu par le passé. Un test, c’est une décision prise une fois, en connaissance de cause, et qui continue de s’appliquer à chaque changement futur.
C’est pour cela que les tests ne sont pas une formalité quand on développe avec l’IA, ils sont la mémoire de l’équipe. Ils survivent au départ des gens et à l’arrivée des assistants, et ils continuent de dire ce que le code devrait faire alors même que plus personne ne s’en souvient consciemment.
Le test généré n’est pas un test réussi
On peut faire générer des tests par l’IA. C’est utile pour démarrer, pour couvrir les cas triviaux, pour gagner du temps sur la structure. Mais il y a un piège à connaître : un test généré à partir du code teste ce que le code fait, pas ce qu’il devrait faire.
La différence est fondamentale. Si le code inverse une condition, l’assistant générera un test qui valide l’inversion, parce qu’il ne connaît pas l’intention, seulement le code. Le test passera, et il donnera l’illusion de la sécurité alors qu’il verrouille un bug. Un test qui passe n’est pas un test utile ; un test utile est un test qui aurait échoué si l’intention n’était pas respectée.
La valeur d’un test vient de l’humain qui écrit l’attendu. L’IA peut préparer, structurer, compléter : écrire le squelette d’un test pytest ou Vitest, ou un scénario Playwright de bout en bout à partir d’un parcours que vous décrivez. La définition de ce que le logiciel doit faire, elle, reste une décision humaine, et c’est elle qui fait la différence entre un filet et un décor.
La discipline qui ne change pas
Alors, qu’est-ce qui change réellement quand on développe avec l’IA ? La partie écriture, et c’est à peu près tout. Le reste de la discipline reste identique, et doit même être plus rigoureuse pour compenser le volume.
Les tests s’écrivent avec ou avant la feature, pas après. L’intégration continue (GitHub Actions, GitLab CI) fait tourner la suite à chaque changement, sans exception. L’assistant peut d’ailleurs être cadré dans ce sens : un fichier CLAUDE.md pour Claude Code, ou des règles de projet dans Cursor, lui demandent de lancer les tests et de ne pas les modifier pour les faire passer. La revue humaine se concentre sur ce qui compte : l’intention, les cas limites, les choix d’architecture. Et la couverture de test n’est pas un objectif cosmétique, c’est la mesure de ce qu’on ose modifier sans trembler.
Il y a une règle simple pour vérifier qu’on est sur la bonne voie : si déployer ne fait plus peur, c’est que le filet existe. Si déployer fait toujours peur, c’est que l’IA a accéléré l’écriture sans qu’on ait accéléré la confiance. La peur de déployer est un indicateur fiable, et il faut l’écouter.
Quand le rythme de livraison accélère avec l’IA, la recette doit suivre : voir la méthode pour réaliser la QA fonctionnelle quand les livraisons s’accélèrent.
Le premier pas pour développer avec l’IA sans sacrifier la qualité
Développer avec l’IA en gardant la discipline est une pratique qui s’acquiert. Nos développeurs travaillent chaque jour avec Claude Code ou Cursor, avec trois règles constantes : tests écrits avec la feature, intégration continue à chaque changement, revue centrée sur l’intention.
Si votre équipe produit plus de code qu’elle ne peut en vérifier, une option consiste à renforcer l’équipe avec des développeurs augmentés par l’IA, dédiés ou au forfait, qui arrivent avec cette discipline déjà en place.
