Idée principale

Comparer le code et l'ontologie métier permet de voir un écart, pas de dire ce qu'il est. Pour le qualifier, il faut un troisième terme : l'intention, c'est-à-dire ce que le développeur a demandé à l'agent.

Dans un ERP dont l'ontologie dit qu'une commande provient obligatoirement d'un devis, Claude Code introduit la possibilité de créer une commande directement. Le code et l'ontologie sont désormais en contradiction. Si le développeur avait explicitement demandé de rendre le devis facultatif, le code respecte l'intention : c'est le modèle qui doit évoluer, et il faut chercher les autres endroits du logiciel qui supposent encore le devis obligatoire. Si personne ne l'avait demandé, le même écart est suspect, et c'est le code qu'il faut corriger.

L'écart est identique dans les deux cas. Seule l'intention les départage.

Pourquoi c'est important

Cela empêche les deux mauvaises réponses symétriques : refuser tout changement qui contredit le modèle, ce qui fige le produit ; et accepter tout ce que le code fait, ce qui transforme le modèle en description complaisante. Une incohérence n'est pas toujours un bug : elle peut signaler une transformation volontaire du métier, que le système doit rendre explicite et traçable plutôt qu'empêcher.

Nuances et limites

L'intention n'est pas toujours claire. Une demande ambiguë ne départage rien, et le bon comportement est alors de demander une décision plutôt que d'inventer une règle.

Le dispositif suppose aussi que l'intention soit conservée quelque part — la demande faite à l'agent, les directives de la tâche — et lisible au moment de la vérification.

Questions ouvertes

• Où conserver l'intention d'une demande pour qu'elle reste lisible au moment où l'écart est découvert, parfois des semaines plus tard ?