Angle

Un modèle métier écrit ne protège le code produit par des agents que s'il tient sa position entre deux dérives : figé, il bloque toute évolution du produit ; aligné sur le code, il entérine chaque erreur. Ce qui lui permet de tenir est un troisième terme, l'intention de la demande, qui départage l'évolution voulue de la dérive, et une boucle qui fonctionne dans les deux sens : le code fait évoluer le modèle quand l'intention le justifie, le modèle cadre le code avant qu'il soit écrit.

Synthèse

Les tests et la compilation contrôlent le comportement que l'agent vient d'écrire, pas le modèle qu'il aurait dû respecter. Le modèle métier comble ce manque, mais il n'est utile que s'il intervient à plusieurs moments : avant le code, comme le TDD, pour cadrer la demande ; pendant et après, pour qualifier les changements du dépôt ; avant l'intégration, pour produire un rapport de cohérence.

La boucle ne tient que par une répartition stricte. Ce qui peut être exact — l'inventaire des changements, les invariants transformés en tests — est confié à des scripts et à des assertions. Ce qui demande un jugement — un changement de classe est-il un changement de concept ? un écart est-il voulu ? — est confié au LLM, avec l'intention comme arbitre et la preuve comme exigence. Et chaque évolution du modèle est traitée explicitement, versionnée et reliée à sa décision, pour que le modèle reste une référence et non un miroir.

Le résultat se résume en une répartition des rôles : le code fait foi sur le comportement implémenté, l'ontologie sur le sens métier, l'intention sur la raison pour laquelle ce sens peut changer.

Tensions / contradictions

Avec la thèse selon laquelle le code est la source de vérité : ici, le code ne doit pas automatiquement avoir raison. La tension se résout par une répartition — le code fait foi sur le comportement, pas sur le sens — mais elle reste réelle quand l'intention est perdue.

Rien n'est encore mesuré. Le volume de faux positifs du jugement sémantique, le coût d'exécution et le coût d'attention humaine de la validation des évolutions restent à éprouver sur de vraies évolutions logicielles.

Questions

• Le gain de cohérence justifie-t-il le coût d'exécution et de maintenance de la boucle, et sur quels types de logiciels ?
• Comment éviter que l'ontologie se charge de détails techniques à mesure que la boucle l'alimente depuis le code ?