Idée principale

Vérifier après coup le code produit par un agent contre une ontologie métier fonctionne, mais trop tard : l'agent a déjà créé des classes, ajouté des méthodes et écrit des tests autour d'une mauvaise lecture du métier, et il faut revenir sur tout cela.

Le TDD a résolu le même problème pour le comportement : on écrit le test avant le code. Transposé au modèle métier, cela donne un ordre différent pour l'agent. Avant d'écrire une ligne, il identifie les concepts et les règles de l'ontologie que la demande touche, relève les contradictions entre la demande et le modèle, les fait résoudre, puis développe, et vérifie enfin que le code produit tient avec le modèle attendu.

Dans un ERP où toute commande provient obligatoirement d'un devis, la demande « permettre une commande sans devis » se heurte à une règle avant que le moindre fichier soit modifié. La contradiction est visible au moment où elle ne coûte encore qu'une décision.

Pourquoi c'est important

Le contrôle cesse d'être une correction pour devenir un cadrage. L'agent part d'une compréhension explicite du domaine plutôt que de sa propre interprétation, et les décisions métier sont prises avant d'être encodées.

L'agent n'a pas besoin de charger toute l'ontologie pour cela : il sélectionne les concepts, relations et règles que la demande touche.

Nuances et limites

L'analogie avec le TDD a une limite nette : une ontologie n'est pas une suite de tests, et une analyse par un LLM n'offre pas la garantie d'une assertion déterministe. Ce qu'on reprend est l'ordre des opérations, pas la certitude du verdict.

Une contradiction relevée en amont n'est pas forcément une erreur de la demande : elle peut annoncer une évolution voulue du métier.

Questions ouvertes

• Combien de contradictions relevées en amont par l'agent se révèlent, à l'examen, de faux positifs ?