Demandez à n'importe qui ayant déjà essayé d'acheter une maison avec un frère ou une sœur, de partager l'addition avec un groupe d'amis ou de déterminer qui tient réellement les rênes d'une entreprise familiale, et on vous répondra tous la même chose : les relations sont compliquées. Une même personne peut être à la fois votre associé et votre beau-frère. Votre propriétaire peut également être votre client. Votre plus grand concurrent sur un marché peut être votre distributeur le plus important sur un autre.
Les entreprises sont confrontées exactement au même problème, mais à une échelle bien plus grande. Dans le domaine des logiciels d’entreprise, nous avons un terme pour désigner ce phénomène : les relations avec des partenaires commerciaux polyvalents. Et c’est l’un des problèmes les plus difficiles à résoudre et les plus systématiquement sous-estimés dans la gestion des données de référence.
Une même entreprise endossant différentes casquettes
Voici un scénario qui se produit quotidiennement au sein des grandes entreprises : un distributeur vous achète des produits finis et vous fournit également des matières premières. Une même commande peut être passée par le siège social, expédiée vers un entrepôt régional, facturée à un centre de services partagés et réglée par une entité totalement différente au sein du groupe. Ces quatre parties sont toutes légitimes et valides, et peuvent nécessiter des règles de gestion différentes : conditions de crédit pour l’une, délais de livraison pour une autre, conditions de paiement pour une troisième.
La plupart des systèmes n’ont pas été conçus pour cela. Un outil de gestion de la relation client (CRM) part du principe qu’une entreprise est un client. Le fichier fournisseurs d’un système de progiciel de gestion intégré (ERP) part du principe qu’une entreprise est un fournisseur. Lorsque la même entité juridique doit endosser ces deux rôles, la plupart des plateformes réagissent en créant deux enregistrements distincts — un pour chaque rôle — en espérant que personne n’ait jamais à les rapprocher.
Mais quelqu’un finira bien par devoir le faire, car aucune saisie de données, aussi minutieuse soit-elle, ne peut résoudre un problème d’architecture.
Pourquoi les organisations sont-elles tellement plus complexes que les individus ?
Une personne ne peut généralement endosser qu'un nombre limité de rôles à la fois. Une organisation n'a pas cette limite, et c'est précisément là que ce problème cesse d'être un cas particulier pour devenir la norme.
Une même entité juridique peut vendre ses produits via cinq zones de vente, chacune avec ses propres tarifs et conditions. Elle peut être imposée différemment dans chaque juridiction où elle opère, et soumise à un régime réglementaire différent dans chacune d’entre elles. Elle peut apparaître dans vos systèmes comme donneur d’ordre dans une transaction, destinataire de la livraison dans une autre, destinataire de la facture dans une troisième et payeur dans une quatrième : parfois ces quatre rôles sont regroupés sur une même commande, parfois ils sont répartis entre quatre entités différentes appartenant au même groupe. Ajoutez à cela plusieurs marques, quelques acquisitions et deux ou trois ERP régionaux, et ce qui était au départ « un seul client » devient désormais un réseau de rôles et de relations que personne dans l’entreprise ne peut appréhender dans son intégralité, et encore moins gérer manuellement.
C’est précisément là que la situation devient rapidement ingérable — non pas parce que quelqu’un a commis une erreur, mais parce que la complexité est bien réelle et que la plupart des plateformes n’ont jamais été conçues pour la modéliser en tant que telle. Elles ont été conçues pour la traiter comme du « bruit », à nettoyer par la suite. Or, ce « bruit » n’est jamais vraiment éliminé par la suite.
Deux types différents de « rôle » — et pourquoi cette distinction est importante
Pour démêler tout cela, il faut d’abord reconnaître que le terme « rôle » recouvre en réalité deux notions distinctes, et que c’est en les confondant que la plupart des modèles de données finissent discrètement par s’effondrer.
Le rôle de partenaire commercial répond à cette question : qu'est-ce que cette entité ? Une entreprise peut occuper plusieurs de ces rôles à la fois : elle peut être à la fois un client et un fournisseur, sur la même fiche, dans le même système. Il s’agit là du problème classique des partenaires commerciaux polyvalents, et c’est une question de classification : à quelles fonctions métier et à quelles transactions cette entité est-elle autorisée à participer ?
Le « rôle d’interaction » répond à une question tout à fait différente : en quelle qualité cette entité agit-elle vis-à-vis d’une autre entité spécifique, dans le cadre de cette transaction ? C’est là qu’interviennent les rôles « destinataire de la livraison », « destinataire de la facture », « acheteur » et « payeur ». Une même entreprise peut occuper plusieurs rôles d’interaction au sein d’une même commande, et l’entité qui remplit un rôle n’est souvent pas celle qui en remplit un autre. Il est essentiel que ces relations soient validées, et pas seulement enregistrées. Si un rôle de « destinataire de la livraison » nécessite un rôle de « payeur » à l’autre extrémité de la relation, cette condition doit être appliquée au moment de la création de la relation, et non découverte lors d’un rapport de rapprochement trois semaines plus tard.
La plupart des fournisseurs confondent ces deux concepts en une seule notion simpliste de « rôle » et espèrent que la différence n’a pas d’importance. Or, elle en a toujours une. L’un concerne ce qu’est une entité ; l’autre concerne ce qu’elle fait, pour qui, à l’instant présent.
Qui a le droit de voir quoi ?
La complexité ne se limite pas à savoir quels rôles occupe une partie. Dès lors qu’une entreprise opère par l’intermédiaire de revendeurs, de franchisés ou d’un réseau d’affiliés régionaux, une deuxième question surgit aussitôt après la première : qui est autorisé à voir cela, et qui est autorisé à le modifier ?
Un vaste réseau de distribution peut compter des dizaines de filiales, chacune gérant son propre ensemble de partenaires commerciaux, dont certains sont partagés entre deux ou plusieurs filiales travaillant sur le même compte dans différents pays. Cela soulève deux exigences distinctes.
Tout d’abord, la sécurité. Une filiale ne devrait en principe avoir accès qu’aux partenaires commerciaux qu’elle est autorisée à voir, et différents utilisateurs peuvent avoir besoin de niveaux d’accès différents à différents domaines d’un même enregistrement. Une personne qui gère les données commerciales d’un compte n’a peut-être pas à modifier ses données financières, et certains utilisateurs ne devraient pouvoir que consulter et approuver, sans pouvoir créer ni modifier quoi que ce soit.
Deuxièmement, le périmètre. Une filiale doit pouvoir consulter à la fois les données de référence véritablement partagées à l’échelle de l’entreprise — où la raison sociale et le numéro de TVA d’une société ne varient pas selon l’utilisateur — et les données qui lui sont délibérément propres, où un champ partagé peut légitimement contenir des valeurs différentes d’une filiale à l’autre.
Aucun de ces aspects n’est un simple « plus » pour une entreprise de cette nature. Si l’on se trompe sur l’un ou l’autre, soit on expose des données qu’une filiale ne devrait pas voir, soit on impose à toutes les filiales un modèle unique qui ne convient bien à personne.
En toute honnêteté, STEP, notre Trusted Intelligence Platform, dispose de la flexibilité et des mécanismes de gouvernance nécessaires pour résoudre correctement ce problème : la sécurité au niveau des nœuds, les rôles limités à un domaine, l’accès soumis à validation et la gestion contextuelle des attributs sont autant de fonctionnalités natives, et non de solutions de contournement. La manière exacte dont ces éléments sont configurés — quelle structure d’affiliation, quels domaines de données, quelles chaînes d’approbation — mérite d’être discutée directement, car cette configuration doit correspondre au fonctionnement réel de votre entreprise plutôt qu’à un modèle générique.
Si vous migrez vers SAP S/4HANA, vous ne pouvez pas éluder cette question
Pour toute organisation passant à SAP S/4HANA, cela cesse d’être une simple question théorique de modélisation des données pour devenir une décision de conception incontournable. S/4HANA unifie la gestion des clients et des fournisseurs au sein d’un concept unique de partenaire commercial (BP) : une seule entité, un ou plusieurs rôles de partenaire commercial, gérés de manière centralisée. Si vos données de référence existantes reposaient sur des fiches clients et fournisseurs distinctes et déconnectées, ce rapprochement doit avoir lieu avant ou pendant la migration. Il ne s’agit pas d’une étape facultative.
C'est précisément pour cela que STEP a été conçu. STEP prend en charge nativement le modèle de données des partenaires commerciaux SAP, y compris les rôles de partenaire, les fonctions de partenaire et les catégories de relations entre partenaires ; ainsi, les organisations qui migrent vers S/4HANA ne sont pas contraintes de choisir entre s'aligner sur le modèle SAP et conserver la gouvernance des données de référence sur laquelle elles s'appuient déjà. Que l’approche la plus adaptée à votre organisation soit un objet « partenaire commercial » unique et unifié ou des types d’objets distincts pour les clients, les fournisseurs et les interlocuteurs relève d’une décision de gouvernance, et non d’une limitation ; STEP est conçu pour prendre en charge ces deux options. Si vous souhaitez obtenir des détails techniques sur la manière dont cela se traduit concrètement, notre documentation aborde ce sujet de manière exhaustive.
Pourquoi cela revêt-il aujourd’hui plus d’importance qu’auparavant ?
Pendant des années, il s’agissait d’un problème de qualité des données: gênant, mais surmontable grâce à un nettoyage manuel suffisant. La situation évolue rapidement.
Les agents IA ne procèdent pas à un nettoyage manuel. Un agent chargé d’optimiser une chaîne d’approvisionnement, de résoudre un litige de facturation ou de signaler un risque de non-conformité doit parcourir les relations pour en tirer des conclusions, ce qui représente une évolution majeure par rapport au simple nettoyage des enregistrements. Il doit savoir quelle entité est réellement responsable de cette facture, quel entrepôt est réellement la destination de cette commande et quelle filiale est réellement la contrepartie dans ce contrat. Si ces relations ne sont pas modélisées de manière pertinente, un agent IA travaille avec une carte sur laquelle toutes les villes sont indiquées, mais aucune route n’y est tracée.
C’est le raisonnement qui sous-tend le graphe de données sémantique de STEP et notre serveur MCP : des données de référence qui stockent les relations régies et typées entre ce qui existe, mises à la disposition des agents d’IA en tant que substrat de raisonnement — et non pas simplement comme une table de correspondance.
À retenir
Les relations ont toujours été complexes. Ce qui a changé, c’est l’importance que revêt désormais leur exactitude, ainsi que la rapidité avec laquelle le coût d’une erreur se fait sentir, qu’il s’agisse d’une livraison envoyée à la mauvaise entité ou d’un agent d’IA agissant en toute confiance sur la base d’une relation qui n’a en réalité jamais été valide.
Des données de référence qui se contentent de décrire ce qu’est une entreprise étaient vouées à rester incomplètes. Les entreprises qui résolvent ce problème aujourd’hui sont celles qui investissent dans des données de référence qui décrivent également ce que fait une entreprise : dans chaque rôle de partenaire commercial qu’elle occupe, chaque rôle d’interaction qu’elle joue et chaque relation qui les relie.
