Notion · Pratique et outillage
TDD (développement piloté par les tests)
Une méthode qui définit ce que le système doit réussir avant de réaliser ou modifier la solution. Avec l’IA, les tests posent des limites vérifiables autour de résultats qui peuvent varier.
Comment ça marche
Le développement piloté par les tests est une vieille méthode : avant d’écrire une fonctionnalité, on écrit le test qui vérifie qu’elle marche, on le voit échouer, puis on écrit le code jusqu’à ce qu’il passe. Avec un agent de code, cette méthode change de statut : elle devient le moyen le plus sûr de lui dire ce qu’on veut, et de savoir s’il l’a fait.
Concrètement, on décrit les cas attendus, l’agent les traduit en tests, on les relit, et seulement ensuite on lui demande d’écrire le code. L’agent exécute les tests, corrige, recommence, jusqu’à ce que tout passe. Il ne peut pas prétendre avoir fini tant qu’un test échoue. Et quand on modifie quelque chose plus tard, les tests disent immédiatement si on a cassé autre chose.
Un exemple concret
- Les règles, en français : un repas est plafonné à 25 euros ; au-delà, il faut un justificatif de la raison ; un déplacement en train ne demande pas de motif ; un ticket sans date est refusé.
- Les tests, par l’agent : un cas par règle, plus les cas limites : 25 euros exactement, un ticket du 31 février, un montant négatif. Une douzaine de tests, relus en dix minutes.
- Le code, par l’agent : il écrit l’outil, lance les tests, en voit trois échouer, corrige, relance. Vingt minutes.
- Trois mois plus tard : le plafond passe à 30 euros. On change le test, l’agent met à jour le code, tous les autres tests confirment que rien d’autre n’a bougé.
Les règles écrites en français au départ sont restées la référence. Les tests en sont la traduction vérifiable.
Ce que ça change pour une équipe
- On peut déléguer sans lire tout le code. Les tests sont le contrat. S’ils passent et qu’ils couvrent les cas qui comptent, l’outil fait ce qu’on attend.
- Les règles du métier deviennent explicites. Écrire les cas force à trancher les ambiguïtés que tout le monde contournait.
- Les modifications deviennent sûres. Un outil avec des tests se fait évoluer sans peur. Un outil sans tests se fige, parce que personne n’ose y toucher.
- L’agent travaille mieux. Un objectif vérifiable le rend plus efficace : il itère sur un résultat objectif au lieu de deviner ce qui vous plairait.
Les limites et les erreurs fréquentes
- Laisser l’agent écrire les tests et le code sans relecture. Il peut écrire des tests qui passent trivialement. Les tests se relisent, surtout les cas limites.
- Tester seulement le cas normal. Les bugs vivent dans les exceptions : vide, trop grand, mal formé, en double. Ce sont ces cas qu’il faut décrire.
- Croire que les tests remplacent la sécurité et la revue. Ils vérifient le comportement attendu, pas l’absence de faille ni la qualité du code. La revue reste nécessaire.
- Vouloir tout couvrir. Cent pour cent de couverture coûte cher et rassure à tort. Couvrir ce qui est risqué et ce qui change souvent suffit.
Pour aller plus loin
Les tests unitaires des composants déterministes se combinent à des évaluations des sorties du modèle. On peut vérifier schémas, invariants, permissions et critères métier sur plusieurs exécutions. Réussir ces tests ne garantit pas tous les comportements futurs.
Où ça se situe chez Opora
Programme 04 · Construire des agentsIngénierie agentique pour les équipes techniques
Faire travailler un agent de code avec des tests écrits d’avance, c’est la méthode que nous enseignons dans le programme Construire des agents.
Questions fréquentes
Faut-il savoir coder pour pratiquer le TDD avec un agent ?
Il faut savoir décrire ce qu’on attend, cas par cas : « si on envoie une facture sans numéro, l’outil doit la refuser avec ce message ». L’agent transforme ces attentes en tests, puis écrit le code qui les fait passer. Comprendre les tests est à la portée de quelqu’un qui comprend le métier.
Pourquoi les tests d’abord, et pas après ?
Un test écrit après coup vérifie ce que le code fait. Un test écrit avant décrit ce que le code doit faire. Avec un agent, c’est la différence entre lui laisser décider du comportement et le lui imposer. Les tests écrits avant sont aussi la condition d’arrêt : l’agent sait quand c’est fini.
Est-ce que ça marche aussi pour les réponses d’un modèle, pas seulement pour du code ?
Oui, sous une forme adaptée : on constitue un jeu de questions avec les réponses attendues, et on mesure le taux de réussite à chaque changement de consigne ou de modèle. C’est l’évaluation, le pendant du TDD pour les usages de l’IA.