Posez cette question dans n'importe quelle grande entreprise : « qui est responsable de la qualité de vos données produit ? » La réponse, neuf fois sur dix, désigne une équipe IT, une équipe data, ou un chef de projet qui sert d'intermédiaire entre les deux. Rarement le chef de produit, l'équipe commerciale ou le merchandiser qui passent leurs journées à travailler avec ces données.
Ce n'est pas un accident. C'est le résultat d'une décennie d'architectures centralisées où la maîtrise technique était le ticket d'entrée pour accéder à la donnée, la modifier, ou simplement comprendre d'où elle venait. Les équipes métier se sont retrouvées dans la position du consommateur passif : elles formulent des besoins, attendent des livraisons, et constatent souvent que le résultat ne correspond pas tout à fait à ce qu'elles avaient en tête. La décision attend. Le ticket reste ouvert.
Pourquoi la centralisation a échoué
Pendant longtemps, centraliser les données dans un entrepôt unique géré par l'IT semblait la bonne réponse : une seule source de vérité, des pipelines maîtrisés, des équipes spécialisées. En théorie, c'est solide.
En pratique, les silos de données ne sont pas seulement le produit de systèmes disparates : ils reflètent des mentalités cloisonnées, où chaque département se concentre sur ses propres priorités au détriment de la collaboration. Le résultat est connu : des opportunités manquées, des coûts opérationnels qui grimpent, une capacité d'innovation entravée.
Le coût caché, lui, est rarement mesuré : selon les estimations les plus courantes, un collaborateur consacre entre un quart et un tiers de son temps à chercher une information fiable. Pas à l'analyser, pas à décider. Juste à la trouver. La plupart des entreprises ne le comptabilisent pas. Elles devraient. On ne construit pas des systèmes intelligents sur des fondations sémantiquement pauvres.
Ce que « reprendre le contrôle » veut dire concrètement
La solution que l'industrie commence à adopter sous le nom de data mesh repose sur un principe simple : la propriété des données doit revenir aux équipes les plus proches de leur création et de leur usage. Les domaines métier ne sont plus de simples consommateurs : ils deviennent responsables de la production, de la qualité et de la documentation de leurs données. L'équipe produit est responsable des données produit, l'équipe commerciale de ses données clients, la supply chain de ses données de stock. Ce n'est pas un transfert de charge, c'est une spécialisation des responsabilités là où elle a le plus de sens.
Les bénéfices sont directs : délais de mise à disposition réduits, qualité améliorée grâce à des responsabilités claires, goulots d'étranglement IT en baisse, meilleure interopérabilité entre domaines.
Mais décentraliser sans orchestrer revient à troquer un silo centralisé contre une fragmentation incontrôlée.
L'exemple le plus courant est celui du chiffre d'affaires. Marketing, finance et commercial utilisent le même terme pour désigner des périmètres différents : avec ou sans retours, brut ou net, par date de commande ou de livraison. Sans définition partagée, chaque domaine optimise dans son coin et la vue d'ensemble disparaît. Ce n'est pas un problème de bonne volonté, c'est un problème d'infrastructure sémantique : la couche qui manque entre les données distribuées et les décisions alignées.
Il serait tentant de croire qu'une nouvelle architecture suffit à faire disparaître les silos. La qualité des données reste dépendante de la qualité des processus qui les produisent. Les équipes métier doivent accepter un rôle plus actif dans leur gouvernance, et la formalisation d'une ontologie demande un effort initial de clarification qui met souvent en lumière des divergences jusque-là invisibles. Ces contraintes ne sont pas des obstacles à contourner : elles constituent précisément le travail nécessaire pour transformer des données dispersées en un actif exploitable à l'échelle de l'entreprise.
Redonner la main aux métiers, sans sacrifier la rigueur
GraphForge : l'ontologie sans la complexité
Le premier obstacle à la reprise de contrôle est technique. Définir une ontologie, c'est-à-dire un glossaire formalisé des concepts, de leurs relations et de leurs règles, exigeait jusqu'ici une expertise en web sémantique que peu d'équipes possèdent. Le résultat habituel : soit on délègue à l'IT et on perd la précision métier, soit on renonce et on documente dans un fichier que personne ne maintient.
GraphForge supprime cette barrière. Les équipes capturent leur connaissance métier et formalisent les relations entre leurs concepts sans écrire une ligne de code. Ce n'est plus l'IT qui décide de ce qu'est un « produit fini » ou une « relation de substitution » : c'est l'équipe produit, avec les outils pour encoder cette décision de façon exploitable par les machines et auditable par les directions. Les données restent dans leurs bases d'origine, la couche sémantique se construit par-dessus, sans migration.
Explorer : voir ce que les tableaux de bord cachent
Une fois le graphe construit, la navigation change de nature : on traverse les données comme un territoire, en suivant les relations, en remontant les chaînes de causalité, en détectant ce qui reste invisible dans une table plate. Pour une équipe supply chain, cela signifie voir directement quels nœuds sont sous tension, quelles routes alternatives existent, où se concentrent les risques de congestion. Pour le marketing, c'est la différence entre un rapport de segmentation figé et une exploration vivante des comportements d'achat. Pour les RH, c'est la cartographie des réseaux d'influence réels, pas de l'organigramme officiel.
KPI Forge : des indicateurs qui reflètent la réalité métier
Les KPI traditionnels mesurent ce que les outils permettent de mesurer. KPI Forge inverse la logique : les équipes définissent ce qui compte, et l'indicateur se construit à partir des parcours tracés dans le graphe. La supply chain suit son taux de congestion maillon par maillon plutôt que la moyenne globale. Le produit suit en temps réel l'impact d'un changement de référence sur la conversion. Les RH mesurent comment les talents se complètent au sein d'une équipe, au lieu de vérifier si un profil colle à un poste.
IA Chatbot : une IA enfin fiable
C'est le composant le plus différenciant, et celui qui répond à l'échec le plus documenté de l'IA en entreprise. La cause principale de cet échec n'est pas technique : les LLM sont exposés à des données sans contexte sémantique. Quand le modèle ne sait pas ce qu'est un « produit principal » dans le référentiel de l'entreprise, il produit une réponse plausible, pas une réponse juste.
En ancrant le LLM dans une ontologie métier précise, chaque réponse devient traçable et auditable jusqu'à sa source dans le graphe. Ce n'est pas une promesse d'infaillibilité : c'est une architecture qui rend les erreurs détectables et corrigeables, y compris dans les environnements réglementés. En pratique, un collaborateur peut demander « quels fournisseurs de notre réseau sont à risque si cette route d'approvisionnement est bloquée ? » et obtenir une réponse sourcée, sans ticket data, sans rapport hebdomadaire, sans intermédiaire.
Ce que les équipes y gagnent, domaine par domaine
Dans tous ces cas, la valeur ne vient pas d'un nouveau tableau de bord. Elle vient d'une vision claire des relations entre les données, qui permet de comprendre les phénomènes pour agir plus vite, ce que les architectures tabulaires ne permettent structurellement pas.
Par où commencer : une feuille de route en quatre étapes
La sémantique est un enjeu métier, pas un enjeu technique
Le mouvement de fond qui se dessine dans les organisations matures n'est pas une révolution technologique, c'est une révolution de gouvernance. La donnée a longtemps été traitée comme un sous-produit de l'informatique : quelque chose qu'on extrait, qu'on nettoie, qu'on stocke, et qu'on restitue sur demande. Le graphe de connaissance, combiné aux principes du data mesh, permet de la traiter pour ce qu'elle est réellement : un actif métier, porteur de sens, appartenant à ceux qui le produisent et le comprennent.
Reprendre le contrôle de ses données, pour une équipe produit ou commerciale, ce n'est pas apprendre à coder en SPARQL. C'est disposer d'une infrastructure sémantique qui parle le langage du métier, qui applique ses règles automatiquement, et qui rend des comptes sans intermédiaire.
La prochaine fois que votre équipe produit passe une heure à chercher pourquoi deux systèmes ne s'accordent pas sur la définition d'un « produit actif », rappelez-vous : ce n'est pas un bug, c'est un symptôme d'architecture. Et comme tout symptôme d'architecture, il a une solution d'architecture.
Sources
- Salesforce (2024) : 62 % des responsables informatiques citent les silos de données comme frein à la transformation numérique, 44 % ne peuvent pas tirer pleinement parti de l'IA.
- Gartner : au moins 30 % des projets d'IA générative abandonnés après la preuve de concept, principalement en raison de la qualité des données.
- IT for Business : les silos de données comme freins invisibles à la performance des entreprises.
- Semsimo : graphe de connaissance et architecture d'entreprise, la couche sémantique posée sans migration.