Pourquoi la gouvernance d'une ontologie est indispensable
Les entreprises produisent aujourd'hui des volumes considérables de données. ERP, CRM, PLM, SIRH, bases documentaires, fichiers Excel ou applications métier alimentent quotidiennement les processus opérationnels. Pourtant, malgré cette richesse informationnelle, une réalité demeure : les données restent souvent cloisonnées, décrites avec des terminologies différentes et difficiles à exploiter de manière cohérente.
C'est précisément à cette problématique que l'application Graphicient répond. À travers la fonctionnalité GraphForge, elle permet de créer une ontologie et de la connecter à des données jusque-là séparées (ERP, CRM, fichiers Excel, applications métier) au sein d'un seul graphe de connaissances Neo4j.
Une ontologie est un modèle de connaissance d'un domaine. Elle représente de manière structurée les concepts métier, leurs propriétés et les relations qui les lient, et fournit un cadre commun de compréhension partagé par l'ensemble des acteurs du domaine. Cette connaissance devient exploitable grâce à trois autres fonctionnalités : Explorer, pour visualiser les données et les liens cachés entre écosystèmes complexes ; KPI Forge, pour construire des indicateurs sur mesure ; et IA Chatbot, un agent conversationnel capable de raisonner sur les données pour produire des réponses fiables et contextualisées.
Le premier jour, on construit l'ontologie avec soin : chaque nœud est nommé, chaque relation documentée, chaque donnée à sa juste place. Puis le temps passe. Un utilisateur ajoute un attribut sans le documenter, un autre ajoute des concepts issus d'un autre domaine métier, un troisième connecte une nouvelle source de données sans se demander qui pourra y accéder. Six mois plus tard, l'ontologie ressemble à n'importe quelle autre base de données mal tenue : des définitions qui divergent, des zones d'ombre sur la confidentialité, un agent IA qui commence à raisonner sur des connaissances incomplètes ou contradictoires.
Une ontologie n'est jamais un livrable qu'on installe une fois : c'est un actif vivant, qui grandit au rythme des décisions des équipes qui l'utilisent. Chez Graphicient, ces risques ne se traitent pas après coup, mais se préviennent en amont, par une gouvernance d'ontologie qui encadre les règles, les responsabilités et les processus de validation nécessaires tout au long de son cycle de vie. Cette gouvernance s'articule autour de deux grands volets : l'analyse de l'existant et la planification de la gouvernance future.
Étape 1 : l'analyse de l'existant, un diagnostic avant toute action
Chez Graphicient, on ne construit jamais une ontologie dans le vide : elle est créée pour répondre à des use cases, des questions métier précises. Une ontologie bien construite doit servir plusieurs use cases à la fois ; à l'inverse, un seul use case ne justifie jamais, à lui seul, la création d'une nouvelle ontologie. Avant toute modélisation, chaque organisation traverse un diagnostic structuré autour de quatre volets :
- Les enjeux et objectifs du projet, qui structurent tout le reste : réconcilier des données contradictoires, accélérer les décisions grâce à une source de vérité unique, cartographier la connaissance métier.
- La définition des use cases : domaine métier concerné, description du besoin, statut, ontologie de rattachement et utilisateurs finaux, pour éviter les doublons dès le départ.
- L'inventaire des sources de données alimentant chaque ontologie : type, localisation, volume estimé, nature des données et modalités d'entrée et de destination.
- Le diagnostic de la gouvernance existante, sur quatre dimensions : qualité des données, cycle de vie, contrôle d'accès et conformité réglementaire, ainsi que les responsabilités déjà en place.
Cette phase de diagnostic n'est pas une formalité : c'est elle qui permet d'identifier, dès le départ, quelles contraintes structureront la gouvernance future.
Étape 2 : la planification de la gouvernance future
Une fois l'existant cartographié, l'accompagnement Graphicient organise ce qui va durer, autour de quatre volets indissociables : la qualité de l'ontologie et de l'agent IA, pour garantir que le modèle reste cohérent au fil de ses évolutions ; la confidentialité des données, pour que la réconciliation des sources ne se traduise jamais par une exposition non maîtrisée ; l'évolution de l'ontologie, pour encadrer les modifications du modèle, des données et des cas d'usage dans le temps ; et la répartition des responsabilités, qui précise qui porte chacune de ces décisions.
Garantir la qualité de l'ontologie dans la durée
Chez Graphicient, un principe simple guide la modélisation : la qualité d'une ontologie se construit dès sa création, et se maintient tout au long de son cycle de vie. Le module GraphForge permet de créer le modèle de données représentant un domaine métier : des nœuds, comme EMPLOYE et POSTE, reliés par des relations, par exemple OCCUPE, chacun pouvant porter des attributs, comme une date d'entrée au poste. « Julie Martin » devient alors une instance concrète du nœud EMPLOYE.
La démarche est itérative et incrémentale, en six étapes : cadrer ou réutiliser une ontologie existante, identifier, relier, documenter, instancier, valider. Elle encourage la construction progressive d'un cœur de domaine simple, étendu au fur et à mesure des besoins. Plusieurs règles transversales garantissent la lisibilité de l'ontologie par l'agent IA et par l'ensemble des utilisateurs métier, un langage commun indispensable pour qu'une ontologie serve plusieurs équipes sans ambiguïté :
- Des règles de nommage uniques pour chaque nœud, relation et attribut, rédigées en anglais avec des conventions strictes, pour que l'agent IA navigue et comprenne le graphe nativement.
- Des règles de construction précises pour arbitrer entre la création d'un nouveau nœud et l'ajout d'un simple attribut, et des informations sémantiques (définition, synonymes, règles métier) pour qu'aucun concept ne soit dupliqué ni ambigu.
- Des erreurs de modélisation à éviter, celles qui empêchent l'agent IA de raisonner correctement sur le graphe.
- Un cadre d'usage des standards sectoriels (comme Schema.org), mobilisés pour réconcilier ou comparer plusieurs ontologies entre elles.
- Une checklist de validation en trois volets : conventions et structure, enrichissement pour l'agent IA, validation et gouvernance.
Maîtriser la confidentialité, le prix de la réconciliation des données
Réconcilier des données jusque-là séparées est une formidable source de valeur, mais elle a un coût : la perte de confidentialité naturelle que procurait la fragmentation. Une fois connectées dans un même graphe, des données confidentielles peuvent devenir visibles à un public plus large qu'auparavant. Gouverner une ontologie, c'est donc aussi gouverner sa confidentialité.
Chez Graphicient, la confidentialité n'est jamais paramétrée au niveau de la donnée, mais au niveau de l'ontologie : GraphForge permet de spécifier un niveau pour chaque type de nœud, de relation et d'attribut. Dans une ontologie RH, le nœud EMPLOYE peut rester public (nom et poste visibles de tous) tandis que l'attribut salaire qui lui est associé peut être classé secret. Quatre niveaux existent, chacun héritant des niveaux inférieurs : accès public, accès intermédiaire, accès secret, accès top secret.
La classification n'est configurée qu'une seule fois et s'applique automatiquement à toutes les instances actuelles et futures de ce type. Le jour où l'administrateur classe l'attribut salaire en accès secret, la règle s'applique immédiatement à tous les employés du système, ceux déjà présents comme ceux recrutés après. Il n'existe donc aucune zone grise : dès qu'un type est classé, l'ensemble de ses instances, anciennes comme futures, est soumis à la même règle.
Cette question se résout à l'échelle du contexte, un espace de travail regroupant un projet, une ontologie et ses utilisateurs. Un même utilisateur peut ainsi avoir un accès large sur un projet dont il est responsable, et restreint sur un autre où il n'intervient qu'en support. Trois rôles structurent chaque contexte : le Propriétaire, qui a créé le contexte, définit son propre niveau de confidentialité sans limite et peut ajouter ou modifier les autres rôles ; l'Administrateur, désigné par le propriétaire, qui ajoute des utilisateurs et configure les niveaux accessibles, mais ne peut jamais changer son propre rôle ni celui du propriétaire ou des autres administrateurs ; et l'Utilisateur, qui consulte les données sans jamais pouvoir définir de niveaux de confidentialité ni modifier les rôles d'autrui, positionné par défaut au niveau d'accès le plus bas.
Mettre en place cette confidentialité repose sur une gouvernance explicite : désigner au moins un administrateur de contexte dès la création de l'ontologie, planifier une revue périodique des droits d'accès, imposer une validation explicite du niveau de confidentialité à chaque création de nœud, de relation ou d'attribut avant toute mise en production, et auditer régulièrement l'ontologie pour repérer les types qui auraient échappé à cette classification.
Faire évoluer l'ontologie sans jamais perdre le contrôle
Une ontologie n'est jamais figée. Les besoins métier évoluent, de nouvelles sources de données apparaissent, des cas d'usage montrent leurs limites. Chez Graphicient, cette évolution s'articule autour de trois déclencheurs bien identifiés.
Améliorer un use case existant. Avant toute modification (ajout, suppression ou renommage de nœuds, relations ou propriétés), la question centrale est : quels autres use cases et quels utilisateurs seraient impactés ? Une analyse d'impact est menée par le propriétaire et l'administrateur du contexte. Si aucun autre use case n'est concerné, la mise à jour est réalisée directement ; si plusieurs sont concernés, un comité de gouvernance est convoqué. Dans tous les cas, tout élément nouvellement créé doit se voir attribuer un niveau de confidentialité avant sa mise en production.
Créer un nouveau use case. La décision de rattacher ce besoin à une ontologie existante ou d'en créer une nouvelle se prend en trois questions successives : une ontologie couvre-t-elle déjà ce besoin ? Si oui, ses contraintes de confidentialité sont-elles compatibles ? Si elles le sont, la proportion de concepts déjà présents est-elle suffisante (au-delà de 50 % de couverture, l'ontologie existante est étendue ; en deçà, une nouvelle ontologie est créée) ?
Enrichir l'ontologie avec de nouvelles données. Le point de départ n'est pas un problème fonctionnel mais une opportunité de données : l'arrivée d'une nouvelle source, la mise à jour récurrente d'une source déjà connectée, ou une campagne de remise à niveau de la qualité des données, pilotée conjointement par le propriétaire du contexte et le responsable de la gouvernance des données.
Une répartition claire des responsabilités
Rien de tout ce qui précède ne fonctionnerait sans une répartition explicite des rôles et, pour chaque ontologie, sans l'identification nominative des personnes qui les occupent. Chez Graphicient, sept fonctions complémentaires sont documentées systématiquement avec le nom du responsable désigné :
- Le Propriétaire du contexte, acteur métier côté client, porte la responsabilité stratégique et fonctionnelle : il crée l'ontologie, connaît les sources, coordonne les use cases et valide les évolutions.
- L'Administrateur du contexte porte la responsabilité opérationnelle au quotidien : il ajoute les utilisateurs et classe chaque type de nœud, de relation et d'attribut.
- Le responsable technique de la source de données, côté client, garantit l'hébergement, la sécurité technique et la qualité d'exécution des flux.
- Le responsable technique de l'application Graphicient, côté Graphicient, assure la disponibilité des contextes et met en œuvre les évolutions techniques demandées.
- Le responsable de la sécurité des données, transversal à l'organisation cliente, définit les règles de contrôle d'accès et valide toute évolution susceptible d'impacter la confidentialité.
- Le responsable de la gouvernance des données, transversal côté client, coordonne l'ensemble du dispositif et anime les comités de gouvernance.
- Le comité de gouvernance intervient lorsqu'une demande d'évolution impacte plusieurs use cases ou plusieurs propriétaires de contexte, et arbitre les évolutions par consensus.
La gouvernance comme investissement, pas comme contrainte
Mettre en place une gouvernance d'ontologie chez Graphicient, ce n'est pas ajouter de la bureaucratie à un projet data. C'est un investissement de départ qui évite des coûts bien plus lourds à retardement : une ontologie dupliquée qu'il faut réconcilier après coup, un agent IA dont il faut regagner la confiance après des mois de réponses erronées. Cette discipline initiale rend possible, dans la durée, une exploration fluide avec Explorer, des indicateurs fiables avec KPI Forge, et un agent IA capable de répondre en langage naturel avec IA Chatbot, en s'appuyant sur une connaissance structurée et sécurisée.
Une ontologie sans gouvernance n'est qu'un schéma de plus parmi d'autres, condamné à se dégrader dès que plusieurs mains la modifient sans règles communes. Une ontologie gouvernée, elle, reste un actif fiable dans la durée : des responsables identifiés à chaque étape, des niveaux de confidentialité tenus à jour, des évolutions arbitrées plutôt que subies. C'est cette discipline, plus que la technologie elle-même, qui fait d'une ontologie le langage commun de toute l'entreprise, compris aussi bien par les équipes métier que par l'intelligence artificielle.