Idée principale

Une ontologie métier tenue à jour automatiquement depuis le code a un défaut symétrique de celui de la documentation qui vieillit : si elle change systématiquement pour suivre le code, elle ne contrôle plus rien. Quand un agent introduit une erreur, un second agent qui met l'ontologie à jour pour la rendre acceptable transforme la dérive en règle. Le modèle devient une documentation régénérée en continu.

L'excès inverse ne vaut pas mieux : un modèle qui interdit toute évolution contraire à ses règles actuelles empêche le produit de changer.

La voie entre les deux consiste à traiter explicitement chaque évolution du modèle. Quand l'évolution est intentionnelle et claire, on prépare une modification versionnée de l'ontologie, éventuellement appliquée dans une branche de travail avant validation. Quand la modification du code paraît contraire à l'intention, on corrige le code plutôt que le modèle. Quand l'intention est ambiguë, on demande une décision au lieu d'inventer une règle.

Pourquoi c'est important

Le modèle devient un contrat évolutif entre l'intention et l'implémentation, et non le reflet du dernier état du code. C'est la condition pour qu'il serve de filet de sécurité : le code ne doit pas avoir automatiquement raison.

Cela impose un historique. Un concept renommé ne doit pas devenir deux concepts indépendants, et une règle supprimée doit rester reliée à la décision qui a justifié sa disparition — par exemple dans un petit registre de décisions inspiré des ADR.

Nuances et limites

Chaque évolution traitée explicitement a un coût d'attention humaine. Si toutes les évolutions passent par une décision, le dispositif ralentit le développement qu'il devait sécuriser.

Questions ouvertes

• À partir de quel volume d'évolutions à valider les équipes cessent-elles de lire les propositions de modification du modèle et les approuvent-elles par défaut ?