Les assistants IA pour le développement écrivent du code rapidement. Trop rapidement, parfois, pour qu’on prenne le temps de vérifier qu’il fait vraiment ce qu’on attend. C’est précisément ce que le développement piloté par les tests (TDD) résout — et la combinaison avec Claude Code mérite qu’on s’y attarde.
Voici comment structurer cette approche pour produire un code plus fiable, sans ralentir le rythme.
Pourquoi le TDD est important maintenant
L’IA générative a transformé la vitesse à laquelle on produit du code. Mais la vitesse sans contrôle produit de la dette technique accélérée. Les équipes qui s’appuient sur Claude Code, Cursor ou GitHub Copilot sans cadre rigoureux finissent souvent avec du code qui « semble » fonctionner, jusqu’à ce qu’un cas limite révèle le problème en production.
Le TDD apporte une discipline simple : avant d’écrire du code, on écrit le test qui définit ce que ce code doit faire. Cette inversion change tout, surtout avec un assistant IA.
Claude Code excelle quand l’objectif est clair. Un test qui échoue est l’objectif le plus clair possible : « rends ce test vert. » L’IA cesse alors d’improviser et travaille sur une cible mesurable.
Ce qu’il faut comprendre
Le cycle Red-Green-Refactor
Le TDD repose sur trois phases qui se répètent :
- Rouge — On écrit un test qui décrit le comportement attendu. Ce test échoue, parce que le code n’existe pas encore.
- Vert — On écrit le minimum de code nécessaire pour que le test passe. Pas plus.
- Refactor — Une fois le test au vert, on améliore la structure du code sans casser le comportement.
Ce cycle génère naturellement une couverture de tests, force la simplicité, et limite les dérives.
Pourquoi cela fonctionne particulièrement bien avec Claude Code
Sans TDD, le dialogue ressemble souvent à : « écris cette fonction » → on lit le code → on lance manuellement → on revient avec une correction → on recommence.
Avec TDD, le dialogue devient : « écris le test » → « fais passer le test » → « refactor ». Claude peut exécuter les tests lui-même, lire les résultats, et corriger sans intervention. Le critère de succès est binaire : le test passe, ou il ne passe pas.
Applications concrètes
Mise en place dans un projet
La première étape consiste à documenter la règle dans le fichier CLAUDE.md à la racine du projet. C’est ce fichier que Claude Code lit pour comprendre les conventions de l’équipe.
# Règles de développement TDD
## Principes
1. Toute nouvelle fonctionnalité commence par un test qui échoue
2. Le code écrit doit être le minimum pour faire passer le test
3. Le refactoring suit le passage du test. Pas de régressions tolérées.
## Interdictions
- Pas de code fonctionnel sans test associé
- Pas de suppression de tests existants
- Pas de tests "à écrire plus tard"Automatiser avec les hooks
Claude Code permet de définir des hooks — des actions automatiques déclenchées à des moments précis. Pour le TDD, deux hooks sont particulièrement utiles : exécuter les tests après chaque modification de code, et bloquer la fin d’une session si les tests ne passent pas.
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "command",
"command": "npm test -- --passWithNoTests --watchAll=false",
"onFailure": "warn"
}
]
}
],
"Stop": [
{
"matcher": "*",
"hooks": [
{
"type": "command",
"command": "npm test",
"onFailure": "block"
}
]
}
]
}
}Cette configuration transforme le TDD en règle technique du projet, pas seulement une bonne intention.
Exemple concret : une liste de tâches
Imaginons une fonctionnalité simple : une classe TodoList qui doit ajouter des tâches, les lister, et marquer les terminées.
Phase rouge — on demande à Claude d’écrire le premier test :
const { TodoList } = require('./todoList');
test('ajoute une tâche à la liste', () => {
const liste = new TodoList();
liste.ajouter('Acheter du pain');
const taches = liste.obtenir();
expect(taches).toHaveLength(1);
expect(taches[0].texte).toBe('Acheter du pain');
});Le test échoue : le module n’existe pas encore. C’est attendu.
Phase verte — on demande à Claude le minimum pour faire passer ce test :
class TodoList {
constructor() {
this.taches = [];
}
ajouter(texte) {
this.taches.push({ texte });
}
obtenir() {
return this.taches;
}
}
module.exports = { TodoList };Le test passe. On ne va pas plus loin que nécessaire.
Phase suivante — on ajoute un test pour marquer une tâche comme terminée, et on itère. À chaque itération, le code grandit en restant couvert par les tests.
Points de vigilance
Le TDD n’est pas universel
Pour les prototypes exploratoires où l’on cherche encore quoi construire, écrire les tests d’abord ralentit sans raison. Idem pour les ajustements purement visuels ou les changements de configuration. Le TDD brille sur la logique métier et les algorithmes, pas sur tout.
La qualité des tests compte autant que leur présence
Un test qui vérifie que 1 + 1 = 2 ne protège de rien. L’IA peut générer rapidement beaucoup de tests, mais des tests mal conçus créent une fausse impression de sécurité. Il faut vérifier que chaque test mesure réellement le comportement attendu, pas seulement qu’il passe.
Claude peut contourner la règle
Sans hooks contraignants, Claude peut être tenté de modifier les tests pour les faire passer, plutôt que de corriger le code. C’est pourquoi le hook Stop qui exige que les tests passent est essentiel : il rend la triche impossible sans qu’on la voie.
La pyramide des tests reste valide
Beaucoup de tests unitaires, quelques tests d’intégration, peu de tests end-to-end. L’IA n’invalide pas ces principes — elle les rend simplement plus faciles à respecter.
Ce que les organisations devraient faire maintenant
Pour les équipes qui utilisent déjà Claude Code ou des assistants similaires, trois actions à court terme :
- Documenter la règle TDD dans le projet via un fichier
CLAUDE.mdou équivalent. Sans cela, l’IA ne saura pas qu’il s’agit d’une attente. - Configurer un hook minimal qui exécute les tests après chaque modification. C’est le filet de sécurité de base.
- Mesurer l’effet sur trois mois : taux de bogues en production, temps passé à corriger des régressions, couverture de tests. Sans données, il est impossible de savoir si la pratique apporte ce qu’on espère.
Pour les organisations qui n’ont pas encore de culture de tests automatisés, le TDD avec IA est une porte d’entrée naturelle. L’IA prend en charge la partie fastidieuse de l’écriture des tests, éliminant ainsi le principal obstacle à l’adoption.
Conclusion
Le TDD n’est pas nouveau. Ce qui est nouveau, c’est qu’avec Claude Code, l’argument du « ça prend trop de temps d’écrire des tests » ne tient plus. L’IA écrit les tests aussi rapidement qu’elle écrit le code, et les exécute pour vous.
Le vrai gain n’est pas la vitesse — c’est la confiance. Quand chaque ligne de code est couverte par un test qu’on a vu échouer puis passer, on sait ce que le système fait. Et dans un monde où l’IA produit de plus en plus de code, savoir ce que ce code fait devient un avantage concurrentiel.
Vous souhaitez structurer vos pratiques de développement autour de l’IA et automatiser votre assurance qualité ? FD Stratégies accompagne les équipes techniques dans l’intégration d’outils comme Claude Code, la mise en place de workflows TDD et la conception de processus de développement plus fiables.
