TDD et IA : pourquoi le Test Driven Development est plus pertinent que jamais

Il y a plus de trois conférences à la Devoxx 2025 qui parlent de TDD et d’IA.
Les retours sont partagés. Les développeurs déjà aguerris au Test Driven Development voient tout de suite les limites des assistants : tests incomplets, implémtentations trop rapides, mauvaise compréhension du métier.

Le TDD n’a rien de nouveau : ceux qui le pratiquent sérieusement y ont consacré des dizaines, parfois des centaines d’heures. Mais aujourd’hui, avec quelques prompts bien choisis, on peut se mettre le pied à l’étrier beaucoup plus facilement.

👉 Cet article s’adresse à vous, développeurs qui vibecodent avec Copilot ou Claude Code, mais qui n’avez jamais fait de TDD. On va voir ensemble les pièges à éviter et les stratégies simples pour bien démarrer.

Sur Mars, le code est généré par IA.

Cyril Lakech, en plateau, nous parle des assistants de code.
Il raconte comment il a pris un mail des stakeholders, l’a donné à Claude Code et que l’agent a directement modifié le code, préparé le commit.

Par réflexe, il lance les tests. Tout est au vert. Une fois, deux fois.
Alors on déploie ?

La première fois que ça arrive, le doute est là.

En parallèle, un autre paysage se dessine :
– certains développeurs lancent des dizaines d’agents Claude en parallèle sur leur base de code ;
– des startups du Y Combinator annoncent plus de 95 % de code généré par des LLMs ;
– Google rapporte que 30 % de son nouveau code est généré par IA, avec +10 % de productivité.

Certaines équipes vont même jusqu’à brancher des serveurs MCP, pour que la documentation technique soit disponible directement dans l’IDE, à la fois pour les devs et pour leurs agents.

Mais il faut préciser : tout le monde n’a pas la codebase de Cyril.

• Les contributeurs sont tous des développeurs Java / Spring chevronnés.
• Ils maîtrisent le TDD, les Moduliths et l’architecture hexagonale.

C’est une base de code où les humains entrent facilement, et où les IA trouvent aussi leurs repères.

On n’est pas tous égaux devant la codebase.

“On ne remplacera pas les développeurs par des IA de sitôt, vu l’état de nos bases de code legacy.”
C’est Jérôme Fortias qui me l’a rappelé lors de la préparation du webinar sur le Vibecoding. Retrouvez le replay sur la chaîne Youtube d’Insitoo.

Et ce constat revient souvent dans la communauté WeLoveDevs : le vibecoding marche très bien sur un prototype. Mais dès qu’on branche l’IA sur un vrai projet en production, elle se perd.

Pourquoi ? Parce qu’un LLM reste limité par sa fenêtre de contexte et sa capacité d’inférence. Lâché seul sur une base de code complexe, il mélange les concepts et finit par produire du spaghetti.

👉 Le TDD apporte une réponse simple : il rend la codebase plus lisible et plus prévisible. Chaque règle métier devient un test exécutable, qui guide autant les humains que les IA.

Et le TDD n’est pas isolé. C’est une pièce d’un puzzle plus large de bonnes pratiques qui améliorent la découvrabilité du code :

• des tests unitaires qui montrent les comportements attendus,
• des noms explicites pour les variables, fonctions et modules,
• une architecture hexagonale qui sépare clairement le métier des détails techniques,
• des moduliths qui réduisent la complexité en regroupant les règles par domaine,
• des ADRs et README courts pour contextualiser les décisions.

Toutes ces pratiques aident un nouvel arrivant à comprendre un projet. Elles aident aussi une IA : moins de bruit, plus de signal.

Avec un proto, vibecoder c’est grisant. Mais sur un gros logiciel, la seule manière de garder la maîtrise, c’est de combiner ces pratiques. Le TDD assisté par IA est la première brique : un test, une implémentation minimale, un refactor.

Pourquoi et comment adopter le TDD quand on code avec l’IA ?

Avant, le TDD était difficile à adopter. Il fallait que le projet soit déjà bien outillé. On passait des heures à enchaîner des katas. Les passionnés organisaient même des Dojos ou des Code Retreats pour s’entraîner.

Aujourd’hui, l’entrée est plus simple. Avec un assistant comme Claude Code ou Copilot, vous pouvez tester la pratique beaucoup plus vite.

Dans la suite, on va partir de trois problèmes que vous rencontrez sûrement avec votre agent. Pour chacun, on verra la solution que propose le TDD avec IA. Cela vous donnera une méthode claire pour adopter cette pratique.

Sur-implémentation : L’agent a codé trois tickets en une fois.

Quand je développe, je fais une feature à la fois. Quand ça marche, je commit.
C’est une bonne pratique issue du Lean Startup et de l’eXtreme Programming.

Sauf que les agents ne respectent pas toujours ce rythme. La première fois que je lui ai demandé une feature, il en a ajouté deux autres. Et le pire ? C’était bien implémenté.

Le problème, c’est que le code sort du scope. On perd le contrôle et l’historique devient brouillon. Et surtout, je n’ai pas eu le temps de réfléchir aux fonctionnalités futures. Résultat : je doute des décisions prises par l’agent.

Solution : ritualiser la boucle Red → Green → Refactor

Mon “Système Prompt” — le CLAUDE.md ou équivalent — oblige l’agent à suivre une boucle TDD IA stricte.

Il fait encore du zèle, mais dans ce cas-là, il ajoute de la documentation, refactore les tests ou vérifie les vulnérabilités OWASP. Pas de hors-sujet.

👉 Extrait à intégrer dans ton système prompt :

## 2) Procédé TDD standard (ce que tu fais, dans l'ordre)
**Pré‑étape — Documenter avant de coder** : ADR minimal validé + risques OWASP/a11y de la feature.
1. **Reformuler les critères** d'acceptation en *batterie de tests* (liste brève).
2. **Produire les tests (RED)** :
   - 1 cas nominal + 1–2 cas bords
   - AAA (Arrange–Act–Assert), *un seul comportement logique par test*
   - Pas de réseau/FS réel (mocks/fakes quand nécessaire)
3. **Implémenter le minimum (GREEN)** — même **naïf**/**en dur** s'il le faut — pour faire passer **uniquement les tests en cours** (pas « la feature complète »).
4. **Refactor** (noms, duplication, structure) → tout **vert**.
5. **Sécurité ciblée** : ajoute 1–2 tests de sécurité concrets alignés OWASP Top 10 pertinent (p.ex. contrôle d'accès, validation d'entrée).
6. **Livrer un *pause state*** : fichiers modifiés, TODO résiduels, prochaines étapes.

> **Stop-guardrails** (documenter avant de coder)
> - **Stop** : aucun code tant que **ADR + risques sécu (OWASP)** ne sont pas validés.
> - **Pas de développement sans critères écrits** : pas de features « au cas où ».
> - Legacy non testée : **seams** + **characterization tests** avant refactor.

Explication : la boucle pour une implémentation minimale

Le TDD repose sur une boucle simple :

1. Écrire un test qui échoue (Red).
2. Écrire le code minimal pour le faire passer (Green).
3. Améliorer le code sans casser les tests (Refactor).

Un bon exercice pour commencer, c’est le FizzBuzz.

Enoncé :

# Le kata FizzBuzz
Écrivez un programme qui affiche les nombres de 1 à 100.
Pour les multiples de 3, affichez “Fizz” au lieu du nombre.
Pour les multiples de 5, affichez “Buzz”.
Pour les multiples de 3 et 5, affichez “FizzBuzz”.

## Résultat attendu : 
1
2
Fizz
4
Buzz
Fizz
7
8
Fizz
Buzz
11
Fizz
13
14
FizzBuzz
....

Comment on avance ?

Premier test : 1 doit donner « 1 ». → Rouge
J’implémente return « 1 ». → Vert

Deuxième test : 2 doit donner « 2 ». → Rouge
J’implémente avec un if. → Vert

Troisième test : 3 doit donner « Fizz ». → Rouge
J’ajoute un else. → Vert

👉 À vous de jouer : prenez un kata simple, écrivez le premier test, et voyez comment l’IA vous aide à itérer.

Tests insuffisants.

Au Devoxx, Benoît Prioux (Alan) a raconté une expérience.
Son agent générait les tests à partir d’un ticket JIRA succinct.

Problème : le ticket n’était pas assez précis. Le cas par défaut n’était pas mentionné, car on suppose que le développeur connaît le métier. Résultat : le code part en production avec des bugs. Impossible de les détecter : tous les tests étaient verts… sauf que le premier test était à l’envers.

C’est le défaut classique des tests écrits après le code : ils valident l’existant, même s’il est faux.

Solution : écrire l’oracle avant le code.

On résume souvent le TDD pré-IA à une règle simple : “écrire les tests avant le code”.
En réalité, c’est l’oracle qui compte.

C’est quoi un oracle ?

Un oracle, c’est la règle qui dit si un test doit réussir ou échouer.
Ça peut être aussi simple qu’un commentaire dans le code, qui reprend le ticket et précise les cas limites.

Exemple :
Le métier dit : “En tant qu’utilisateur, je veux valider mon panier et passer au tunnel de commande.”
L’oracle précise :

si le panier est vide → renvoyer une erreur ;
si le panier contient des produits non disponibles → renvoyer une erreur.

Pourquoi c’est important ?

Ces règles explicites, inscrites dans les tests, guident à la fois l’humain et l’IA.
Quand un bug passe entre les mailles, c’est souvent qu’un oracle manquait.
Dans le cas raconté par Benoît Prioux, que faire quand le document n’a pas d’erreur ? Le problème ne venait pas de GitHub Copilot, mais de l’oracle implicite, basé uniquement sur l’expérience métier du développeur.

Un oracle capture l’intention du développeur au moment où il écrit le code.
Cela rend la base plus maintenable : le prochain développeur comprendra non seulement ce que fait la fonction, mais aussi pourquoi elle a été écrite.
Et si le prochain développeur comprend, votre assistant IA comprendra aussi.

Perte de contexte.

Beaucoup de développeurs râlent : ils doivent réexpliquer sans cesse les mêmes choses à leurs agents… même quand c’est l’agent lui-même qui les a proposées.

Exemple : il m’a suggéré d’utiliser nodemon pour recharger mon backend automatiquement. Mais il oubliait systématiquement et lançait un simple npm run dev après chaque modification. La solution ? Documenter clairement les règles, pour l’humain comme pour l’IA.

Et pour ça, je vous renvoie à l’article précédent sur la Doc as Code et la boucle Documentation Driven Development. Si vous n’avez pas cliqué, gardez à l’esprit, qu’il faut toujours écrire un ADR avant d’écrire le code.

Voici les règles d’or à intégrer à ton système de prompt :

## 0) Rôle & règles d'or

**Tu es** un binôme de développement senior, TDD-first.

**Documentation d'abord (ADR + Sécu)** : rédige et valide un ADR minimal incluant risques OWASP/a11y **avant toute ligne de code**.
**Tests d'abord** : commence toujours par une *liste de tests* puis des *fichiers de tests* qui échouent (RED).
**Implémentation minimale** : écrire le **strict minimum** pour passer au vert (GREEN).
**Refactor en sécurité** : améliore noms/duplication/conception **sans casser le vert** (REFACTOR).
**Pas de code sans critères d'acceptation écrits** (contrat de test).
**Sécurité & a11y** : intègre tôt des contrôles OWASP pertinents et des exigences d'accessibilité quand il y a UI.
**Sorties petites & atomiques** : propose des étapes ≤ 30 minutes + *pause state* pour un handover propre.

Le test à froid pour vérifier la documentation.

Un exercice à répéter par exemple est de faire lire le Readme à l’agent pour lancer le projet. S’il prend une impasse, on lui explique, on lui demande d’améliorer la documentation. Et on reprend avec un agent neuf. 

En vrai, si une IA n’arrive pas à démarrer votre projet, y’a de fortes chances pour qu’un nouveau contributeur n’y arrive pas non plus.

Une roadmap pour adopter le TDD avec IA.

Vous avez maintenant un lot d’éléments concrets pour bien démarrer.
En complément, pensez à consulter l’article sur les Moduliths ou à regarder une conférence sur l’architecture hexagonale.

Le chemin du craftmanship est long. Et ce n’est pas en dix minutes de lecture que vous allez le parcourir.

En pratique, je vous propose cette roadmap pour suivre vos progrès et installer le TDD avec IA dans votre quotidien.