Idée principale
Une ontologie métier peut être complétée par une cartographie : le concept de facture associé aux classes, fonctions, événements et opérations d'API qui participent à son implémentation. Ces associations ne définissent pas le concept ; elles disent où il est implémenté.
Cette distinction rend possibles des questions qu'aucune des deux couches ne permet seule. Si l'on modifie le concept de facture, quelles parties du code risquent d'être touchées ? Si une fonction métier disparaît, quelle règle pourrait ne plus être implémentée ? Une nouvelle opération d'API expose-t-elle un concept existant ou révèle-t-elle une notion nouvelle ? Une classe renommée relève-t-elle d'un refactoring ou d'un vrai changement du domaine ?
La cartographie peut s'entretenir au fil des modifications, mais chaque association doit garder sa preuve : les fichiers, les symboles et les changements observés qui la fondent.
Pourquoi c'est important
L'analyse d'impact cesse de dépendre de la mémoire de la personne qui connaît le code. Et en exigeant la preuve, on sépare deux choses qu'un LLM confond facilement : une correspondance démontrée et une relation simplement déduite.
Nuances et limites
Une correspondance déduite par un LLM ressemble exactement à une correspondance démontrée. Sans la preuve attachée, la cartographie accumule des liens plausibles que personne ne peut plus distinguer des vrais.
La cartographie vieillit aussi : il faut réexaminer les correspondances, à une fréquence que rien ne fixe encore.
Questions ouvertes
- À quelle fréquence faut-il réexaminer les correspondances entre concepts et code pour qu'elles restent fiables ?