Résumé
Une ontologie sans données reste un schéma sur papier. Cet article montre comment la faire vivre en six étapes: analyser, collecter, transformer, versionner, retrouver et servir. La méthode est appliquée à un système legacy mêlant C, C++, PL/SQL, PHP et vingt ans de documentation bilingue.
Les quatre premières étapes construisent et maintiennent le graphe dans un job de CI; les deux dernières s’exécutent au moment de la question. Un seul principe guide l’ensemble: les faits extraits par des outils déterministes sont considérés comme fiables, tandis que les propositions d’un LLM restent à valider. Les LLM sont exécutés localement, sans aucune sortie de données du réseau.
L’analyse définit d’abord les standards et la granularité de modélisation. La collecte s’appuie ensuite sur des outils déterministes: Tree-sitter pour les appels C, le dictionnaire de données Oracle pour les dépendances PL/SQL et nikic/php-parser pour les classes PHP. Les documents sont le seul domaine où intervient le LLM: il propose identités, versions et liens, ensuite validés par un expert.
Rien n’entre directement dans le graphe. La résolution d’entités regroupe les synonymes en concepts SKOS bilingues, SHACL valide la structure des faits et RDF-star en conserve la provenance. Le versioning repose sur un graphe par release et des faits ajoutés puis clos, avec reconstruction du triple store à partir du dépôt et de la base de faits.
Au moment de la question, le graphe sélectionne le contexte avant le LLM: liaison d’entités, traversée SPARQL filtrée par release, puis recherche vectorielle ou exacte dans les sections retenues. Deux cas — le diagnostic d’un bug et une question produit portant sur deux releases — illustrent le fonctionnement complet, ainsi que quatre objections, dont le risque d’une file de revue qui devient ingérable.
Idées clés
- Les faits déterministes sont de confiance, les propositions d’un LLM sont suspectes jusqu’à validation: les parseurs et le dictionnaire de données écrivent dans le graphe, le LLM attend dans une file de revue.
- Le graphe s’arrête là où le texte commence: modéliser la procédure, la table, le template et la section de document, et garder un pointeur sous ce plancher.
- Rien n’entre directement dans le graphe: une barrière SHACL laisse passer les faits sur leur structure, met le reste en quarantaine avec son rapport, et chaque fait accepté garde sa provenance.
- Un graphe vrai à la release N et jamais mis à jour est pire que pas de graphe: un graphe nommé par release, des faits clos plutôt que supprimés, un store reconstruit, jamais retouché.
- Les canaux de retrieval ne sont pas des pairs: le graphe décide quels artefacts, quels documents et quelle release sont sur la table, et la recherche texte ne lit qu’à l’intérieur de cette sélection.
Pourquoi j’ai écrit cet article
L’article précédent se fermait sur les six étapes en une page; celui-ci est la méthode elle-même, chaque étape avec le détail que cette vue d’ensemble ne pouvait pas donner, et les deux exécutions du pipeline, l’initialisation qui construit la base de référence et la mise à jour qui garde le graphe vrai à chaque release. Il s’arrête à la barrière: comment le type d’une question décide des canaux qui tournent est pour le prochain article.