Idée principale

Écrire le test d'abord et le code ensuite inverse l'ordre habituel, mais l'intérêt n'est pas dans l'ordre. Le test décrit le quoi — voilà le comportement attendu, voilà ce qui doit rester vrai. Le code décrit le comment. Le premier est donc une pièce de la spécification, écrite dans un langage que la machine peut évaluer.

Ce que cela change se voit dans la durée. Le code sera refactoré, il rencontrera de nouvelles données, d'autres fonctionnalités s'ajouteront autour de lui. Le comportement attendu, lui, est fixé ailleurs que dans la mémoire de celui qui l'a implémenté : s'il est cassé, le test casse, idéalement sur le poste du développeur ou en qualification plutôt qu'en production.

Le TDD ne supprime pas les défauts, ne remplace pas la réflexion produit, et ne transforme pas une mauvaise spécification en bon produit. Il fait une seule chose, et elle est peu commune : il rend une partie de la qualité vérifiable avant que le code existe.

Couche apportée par « Ontology-Driven Design : et si l'ontologie devenait le filet de sécurité du code généré par l'IA ? » (2026-10-29). La même logique d'antériorité peut s'étendre à la part du comportement attendu qu'aucun test ne formalise : le modèle métier. Avant qu'un agent comme Claude Code écrive le code d'une fonctionnalité, la demande est confrontée à l'ontologie du domaine — concepts, règles, états — et les contradictions sont tranchées avant d'être encodées. L'ordre est le même que celui du TDD ; la garantie ne l'est pas, puisque le verdict vient d'une analyse par un LLM et non d'une assertion déterministe.

Pourquoi c'est important

Cela sort la discipline du registre de l'hygiène technique. Un test écrit avant est un artefact de spécification, donc un endroit où le produit et le développement peuvent se mettre d'accord sur un comportement — ce qu'un document en prose ne permet pas, faute d'être évaluable.

Cela déplace aussi le coût des tests : écrits après, ils constatent ce que le code fait ; écrits avant, ils contraignent ce qu'il devra faire.

Nuances et limites

La partie formalisable est étroite. Un test dit qu'un comportement est tenu, jamais qu'il était le bon comportement à viser — la portion de qualité qui relève du jugement produit reste entière.

Et la discipline suppose qu'on sache énoncer le comportement attendu. Devant une spécification trop floue, écrire le test d'abord ne clarifie rien : il fige l'ambiguïté au lieu de la trancher.

Questions ouvertes

• Quelle part d'un contrôle par le modèle métier peut atteindre une fiabilité suffisante pour tenir le rôle d'un test, sans en avoir la garantie déterministe ?