Une seule question, en langage naturel, pour voir où la commonalité existe déjà, où elle devrait exister, et combien elle représente.
Pour illustrer la méthode sans exposer de données réelles, l'exemple s'appuie sur un groupe automobile fictif "Ravelin Group" avec des marques, modèles, plateformes et fournisseurs entièrement inventés. La logique, elle, est transposable à n'importe quel groupe industriel multimarques.
Chaque marque achète de son côté, avec ses références, dans son système. Même lorsque deux marques partagent la même plateforme technique (même architecture de caisse, mêmes points d'ancrage moteur) personne ne vérifie si elles n'achètent pas la même pièce sous deux références, auprès de deux fournisseurs, à deux prix.
Pas parce que les équipes font mal leur travail : parce que l'information nécessaire pour le voir est répartie entre des dizaines de systèmes qui ne se parlent pas.
Faire converger les marques vers un nombre restreint de plateformes communes est annoncé aux investisseurs, documenté, suivi par les marchés.
Entre la plateforme et l'achat réel : le modèle, l'ensemble fonctionnel, la pièce, le contrat, le fournisseur, chacun piloté par une équipe et un référentiel différents.
L'ingénierie raisonne en plateformes, les achats en références et contrats. La convergence technique existe ; la convergence achat n'est vérifiée par personne.
Un capteur ABS ou une poignée de porte électrique peut être monté sur deux véhicules d'une même plateforme, chez deux marques, sans que les deux équipes achats aient jamais comparé leurs conditions.
Cette chaîne est justement ce qui manque dans la plupart des organisations industrielles. Pas parce que les données n'existent pas. Elles sont dans le PLM, l'ERP achats, les systèmes contractuels. Mais parce qu'elles n'ont jamais été reliées dans une seule structure interrogeable.
Le lien le plus important est equivalent_to : deux pièces peuvent porter des codes totalement différents d'une marque à l'autre tout en remplissant exactement la même fonction. Sans cette relation documentée dans le graphe, cette identité reste invisible pour n'importe quel système achats classique, qui ne sait comparer que des références strictement identiques.
Fait manuellement, ce chiffrage exige de croiser une base pièces, une base prix, une base volumes et une base d'équivalence fonctionnelle documentée par les ingénieurs : quatre sources qui n'existent généralement pas sous une forme comparable.
Ici, la réponse arrive avec le chiffrage inclus, sans qu'aucun analyste n'ait croisé d'extractions Excel venues de cinq systèmes différents.
La même donnée qui décrit une plateforme technique côté ingénierie sert directement à répondre à une question achats : sans ressaisie, sans export, sans jonglage entre systèmes.
Aujourd'hui, chaque question transverse nécessite un projet ad hoc : mobiliser un data analyst, extraire des tables, les rapprocher dans un tableur, documenter les hypothèses, publier un résultat déjà partiellement obsolète parce qu'un contrat a changé entre-temps.
Jusqu'au niveau de la pièce et du fournisseur. Sans cette visibilité fine, la convergence annoncée reste une intention, pas un résultat mesurable.
Le jour où l'ingénierie veut savoir combien de plateformes partagent un composant, la même base répond : sans nouveau projet, sans nouvelle réconciliation.
Ce qui est vrai pour un groupe automobile multimarques l'est pour tout industriel structuré en entités partageant une base technique : équipementiers multi-filiales, biens d'équipement à sous-ensembles communs, programmes aéronautiques ou ferroviaires. La même question se pose, et la même méthode s'applique.
Nous modélisons un échantillon de vos données produits et achats, puis vous posez vos questions en langage naturel. Le chiffrage sort du graphe, pas d'un tableur.
Un éclairage sur les graphes de connaissance, directement dans votre boîte mail.