Idée principale

Tenir une ontologie métier à jour face au code demande deux opérations de nature différente, qu'il faut séparer.

La première est mécanique : déterminer précisément ce qui a changé. Un script lit l'historique Git et liste les fonctions, classes, interfaces, modules, signatures d'API et contrats exposés via MCP ajoutés, modifiés ou supprimés. Un outil comme Tree-sitter permet d'analyser la structure syntaxique pour identifier les éléments touchés.

La seconde est sémantique : comprendre si ces changements introduisent, modifient ou contredisent un concept métier. Une classe n'est pas forcément un concept ; un nouveau package peut n'être qu'une réorganisation ; une fonction peut implémenter une règle sans constituer un concept. C'est là qu'intervient un LLM, qui confronte l'inventaire à l'ontologie et à la demande qui a déclenché le développement, et range chaque changement : nouveau concept, concept qui change de sens, concepts devenus incohérents, vocabulaire qui diverge, ou changement purement technique.

Pourquoi c'est important

La séparation rend le contrôle tenable. On ne demande pas à un LLM de relire toute l'application à chaque modification : on concentre son analyse sur ce que le script a désigné. Et la partie qui peut être exacte l'est, au lieu d'être confiée à un modèle qui pourrait l'approximer.

Elle protège aussi l'ontologie de l'architecture : le script décrit la structure technique, le LLM décide ce qui relève du domaine, et une architecture hexagonale ou un code désordonné n'imposent pas leur découpage au modèle métier.

Nuances et limites

Un changement métier réel peut ne laisser aucune trace dans les noms : une condition modifiée à l'intérieur d'une fonction inchangée échappe à un inventaire fondé sur les symboles. Et le jugement sémantique produit des faux positifs dont le volume n'est pas encore connu.

Questions ouvertes

• Comment détecter une modification métier qui ne change aucun nom de classe, de fonction ou de signature ?