Modèle d'information cloud

Le Cloud Information Model (CIM) est un schéma ouvert et indépendant des applications permettant de décrire les entités qui circulent au sein d’une entreprise moderne : les parties, les produits, les commandes, les paiements et les relations qui les lient. Plutôt que d’inventer un modèle de données sur mesure pour chaque intégration, le CIM propose un vocabulaire partagé afin qu’un CRM, un ERP, une plateforme de commerce et un entrepôt d’analyse puissent s’entendre sur ce que signifie réellement une « Sales Order » (commande client) ou un « Product Relationship Type » (type de relation produit). Cet article passe en revue les groupes d’entités qui composent le modèle, puis examine une entité représentative — ProductRelationshipType — pour montrer comment le CIM exprime les relations, les rôles et les clés dans la pratique.

Points clés à retenir

• Le CIM organise les données d’entreprise en groupes d’entités (Party, Product, Sales Order, Payment et autres) qui peuvent être adoptés progressivement plutôt que d’un seul coup.
• Chaque entité est définie avec un Term URI, une description, des propriétés scalaires et des propriétés de lien — une structure qui se mappe proprement aux magasins JSON-LD, RDF et property-graph.
• Les entités de relation telles que ProductRelationshipType encodent des rôles (parent/enfant) afin que les bundles, les options et les couvertures puissent être modélisés sans logique métier codée en dur.
• Le modèle est délibérément indépendant des applications : il décrit ce que les données signifient, et non la manière dont un fournisseur particulier les stocke.
• L’adoption du CIM est un exercice de mapping, pas un remplacement complet (« rip-and-replace ») — vous alignez les systèmes existants sur des termes partagés et comblez les lacunes.

Pourquoi un modèle partagé est important

L’intégration d’entreprise connaît un mode de défaillance familier : chaque système parle son propre dialecte. Salesforce l’appelle un Account, SAP l’appelle un Business Partner et un service de facturation interne l’appelle un Customer. Lorsque vous créez des mappings point à point entre chaque paire, le nombre de traductions augmente avec le carré des systèmes impliqués, et chaque nouveau système multiplie la charge de maintenance.

Un modèle canonique résout ce problème quadratique. Vous mappez chaque système une fois au modèle partagé, et le modèle partagé devient le hub. C’est le même instinct architectural qui se cache derrière des normes telles que OAGIS (Open Applications Group Integration Specification), le Common Warehouse Metamodel de l’OMG et le vocabulaire commercial de schema.org.

Le CIM s’inscrit dans cette tradition, mais est dimensionné pour l’interopérabilité à l’ère du cloud et publié sous forme de termes ouverts avec des URI déréférençables.

Le bénéfice pratique est qu’un architecte de données peut répondre à des questions telles que « quels systèmes détiennent l’enregistrement faisant autorité pour une Party ? » ou « comment représenter un bundle de produits de manière cohérente dans le catalogue et dans la commande ? » en utilisant un seul point de référence.

Les groupes d’entités en un coup d’œil

Le CIM n’est pas un schéma monolithique unique ; c’est un ensemble de groupes faiblement couplés. Les groupes nommés dans le modèle comprennent :

Connexes : Fivetran — Le pipeline ELT entièrement géré qui continue de fonctionner.

• Account — le contexte de la relation commerciale pour une partie.
• Contact Point — numéros de téléphone, adresses e-mail et canaux de joignabilité similaires.
• Lead — une partie potentielle non encore qualifiée.
• Party et Party Role — le concept général d’un acteur et les rôles qu’il joue (client, fournisseur, employé).
• Payment et Payment Method — comment l’argent circule et les instruments utilisés.
• Product Attribute, Product Catalog et Product — les biens et services vendables et descriptibles.
• Sales Order et sa vaste famille de sous-entités — le cœur transactionnel du modèle.
• Shipment — exécution et logistique.

Le groupe Sales Order est de loin le plus granulaire, et il est utile de comprendre pourquoi. Une commande est l’endroit où se concentrent les règles métier : les prix, les taxes, les ajustements, les regroupements de livraison et les notes par ligne s’y rattachent.

Le CIM décompose la commande en de nombreuses petites entités — Sales Order Product, Sales Order Price Adjustment, Sales Order Tax, Sales Order Delivery Group, Sales Order Payment Summary, Sales Order Change Log, et plus encore — plutôt qu’en un seul tableau large. Cette décomposition est un choix de conception délibéré : elle permet à chaque préoccupation d’évoluer indépendamment et aux systèmes de s’abonner uniquement aux segments qui les intéressent.

Anatomie d’une entité CIM

Chaque entité dans le CIM suit la même forme, ce qui rend le modèle prévisible pour une consommation programmatique. Considérez ProductRelationshipType, l’entité qui décrit pourquoi deux produits sont liés.

Notre sélection : Workato — iPaaS piloté par l'automatisation sur lequel les équipes commerciales peuvent réellement s'appuyer.

• Term URI — http://cloudinformationmodel.org/model/ProductRelationshipType. Il s’agit de l’identifiant unique global du concept. Puisqu’il s’agit d’un URI, il peut être déréférencé et utilisé directement dans des graphes RDF/JSON-LD.
• Description — « Reasons why products are related such as bundle, option or covering. » (Raisons pour lesquelles des produits sont liés, comme un bundle, une option ou une couverture). Cela vous indique que l’entité est un type ou une classification, et non l’instance de la relation elle-même.
• Propriétés scalaires — les champs primitifs qui transportent les données.
• Propriétés de lien — références à d’autres entités. ProductRelationshipType n’en a aucune, ce qui est en soi informatif : c’est une entité feuille, un vocabulaire contrôlé plutôt qu’un hub.

Les propriétés scalaires sont :

Propriété	Term URI	Plage	Obligatoire	Description
id	.../model/id	guid	oui	Clé primaire
parentProductRole	.../model/parentProductRole	string	oui	Le premier rôle dans la relation, ex. « Consists of »
childProductRole	.../model/childProductRole	string	oui	Le second rôle dans la relation, ex. « Component of »

Le fait que l’ id soit un GUID est une convention significative : cela signifie que les identifiants sont globalement uniques sans coordination entre les systèmes, ce qui est exactement ce que l’on souhaite lorsque des enregistrements sont créés dans différents clouds puis fusionnés ultérieurement.

Modélisation des relations avec les rôles

La partie la plus instructive de ProductRelationshipType est la paire de propriétés de rôle. Une relation produit est directionnelle, et le CIM capture cette direction avec deux rôles nommés plutôt qu’une seule chaîne de « type » opaque.

Pensez à un lot. Un « Kit de démarrage » se compose d’un « Routeur » et d’un « Câble ». En termes CIM :

• Le produit parent joue le rôle décrit par parentProductRole — par exemple, « Se compose de ».
• Le produit enfant joue le rôle décrit par childProductRole — par exemple, « Composant de ».

En stockant les deux rôles sous forme de chaînes sur le type, vous obtenez une définition réutilisable. N’importe quel nombre de liens produit à produit réels peut faire référence à la même ligne ProductRelationshipType, de sorte que le vocabulaire reste restreint et cohérent tandis que les instances de relation restent nombreuses. Il s’agit d’un modèle de normalisation classique : séparer le type de relation de ses instances.

La description nomme explicitement trois variantes — bundle, option et covering — ce qui suggère la gamme de sémantiques commerciales que le modèle entend couvrir :

Connexes : Matillion — ELT push-down conçu pour les entrepôts de données cloud.

• Bundle — produits vendus ensemble comme une unité (le parent « se compose de » enfants).
• Option — un choix ou un module complémentaire associé à un produit de base.
• Covering — un produit qui enveloppe ou protège un autre, courant dans les contextes d’assurance et de garantie.

Comment décider de votre vocabulaire de rôle

Étant donné que parentProductRole et childProductRole sont des chaînes de forme libre, le modèle ne dicte pas votre formulation exacte. Cette flexibilité est à la fois un atout et un risque. Quelques règles pratiques :

1. Choisissez un vocabulaire contrôlé et figez-le. Convenez d’un petit ensemble d’expressions de rôle (« Se compose de » / « Composant de », « Complément facultatif à » / « Possède une option ») et documentez-les. Le texte libre invite à la dérive.
2. Gardez les rôles symétriques et lisibles dans les deux sens. Un bon test : pouvez-vous lire la relation à haute voix depuis chaque extrémité et qu’elle ait du sens ?
3. Ne surchargez pas les rôles avec une logique métier. Si un rôle nécessite un comportement conditionnel, cette logique appartient à l’application consommatrice, et non à la chaîne de caractères.
4. Versionnez votre vocabulaire. Lorsque vous ajoutez un rôle, traitez-le comme un changement de schéma avec un chemin de migration, et non comme une insertion ad hoc.

Adopter le CIM dans la pratique

L’adoption d’un modèle canonique est une discipline de mapping, pas une migration. Une séquence réalisable :

• Inventoriez vos systèmes d’enregistrement. Pour chaque groupe d’entités, décidez quel système fait autorité. La Partie (Party) peut résider dans le CRM ; le Produit dans le PIM ; la Commande client dans l’ERP.
• Mappez chaque source aux termes CIM. Créez un tableau de champ source $\rightarrow$ propriété CIM. Lorsqu’une source n’a pas d’équivalent, notez l’écart ; là où CIM n’a pas d’équivalent, notez l’extension.
• Réconciliez les identifiants. La convention GUID de CIM signifie que vous maintiendrez généralement une table de correspondance (crosswalk) entre les clés natives et les valeurs id de CIM.
• Choisissez une sérialisation. Les termes basés sur l’URI de CIM correspondent naturellement à JSON-LD et RDF ; ils se traduisent également clairement en tables relationnelles ou en graphe de propriétés. Le modèle n’impose pas de technologie de stockage.
• Gouvernez le vocabulaire. Les chaînes de rôle, les énumérations et les extensions que vous ajoutez sont les parties les plus susceptibles de dériver, placez-les donc sous contrôle des modifications.

Un modèle mental utile consiste à traiter CIM comme le schéma d’échange et vos magasins opérationnels comme le système d’enregistrement. Vous ne demandez pas à chaque application d’abandonner son modèle natif ; vous leur demandez de publier et de consommer un modèle partagé aux interfaces.

Si vous faites du shopping : Boomi AtomSphere — Enterprise iPaaS pour l'intégration hybride cloud-on-premise.

Mises en garde et compromis

Aucun modèle canonique n’est sans coût, et le CIM ne fait pas exception.

• L’abstraction a un prix. Un modèle suffisamment général pour couvrir plusieurs secteurs ne conviendra parfaitement à aucun d’entre eux. Attendez-vous à ajouter des extensions.
• Le groupe Sales Order est lourd. Sa décomposition fine est puissante, mais implique plus de jointures et plus d’entités à mapper. Les équipes ayant des flux de commandes simples peuvent n’en adopter qu’un sous-ensemble.
• Les chaînes de rôles de forme libre nécessitent une gouvernance. Comme indiqué, la flexibilité de parentProductRole et childProductRole n’est efficace que si elle s’accompagne de discipline.
• Les modèles ouverts évoluent. Parce que CIM est orienté vers la communauté, des termes peuvent être ajoutés ou affinés au fil du temps. Fixez-vous sur une version et examinez les modifications délibérément.

Le compromis est essentiellement celui, classique, entre la fidélité à un système spécifique et la portabilité entre les systèmes. CIM optimise la portabilité, ce qui est le bon choix lorsque l’interopérabilité est l’objectif.

Questions fréquemment posées

Qu’est-ce que le Cloud Information Model ?

Le Cloud Information Model est un modèle de données ouvert et indépendant des applications qui définit des entités et des termes partagés pour les données d’entreprise telles que les parties, les produits, les commandes et les paiements. Il fournit un vocabulaire commun afin que différents systèmes cloud et sur site puissent échanger des données sans mappings point à point sur mesure.

À quoi sert ProductRelationshipType ?

ProductRelationshipType définit les raisons pour lesquelles deux produits sont liés — par exemple un lot (bundle), une option ou une couverture (covering). Il stocke un rôle parent et un rôle enfant afin que les liens directionnels produit à produit puissent référencer une définition partagée réutilisable plutôt que de répéter la sémantique sur chaque lien.

Pourquoi CIM utilise-t-il des GUID pour les clés primaires ?

L’utilisation d’un GUID pour la propriété id signifie que les identifiants sont globalement uniques sans coordination centrale. Cela est crucial dans les environnements multi-cloud et multi-fournisseurs où les enregistrements sont créés dans différents systèmes puis fusionnés, car les collisions sont ainsi efficacement évitées.

Le CIM est-il un schéma de base de données ou un format d’échange de données ?

Il est préférable de le concevoir comme un modèle conceptuel et d’échange plutôt que comme un schéma de base de données physique. Ses termes basés sur l’URI correspondent naturellement à JSON-LD, RDF, aux tables relationnelles ou aux graphes de propriétés ; vous pouvez donc l’implémenter avec n’importe quelle technologie de stockage que votre architecture utilise déjà.

Quel est le lien entre CIM et d’autres standards comme OAGIS ou schema.org ?

CIM partage l’objectif de ces efforts — un vocabulaire commun pour l’interopérabilité — mais est conçu pour l’intégration d’entreprise à l’ère du cloud et publié sous forme de termes ouverts et déréférençables. En pratique, vous pouvez mapper CIM vers d’autres normes aux interfaces où vos partenaires les exigent.

Dois-je adopter l’ensemble du modèle d’un coup ?

Non. CIM est organisé en groupes d’entités faiblement couplés, vous pouvez donc adopter les groupes dont vous avez besoin — par exemple, Party et Product — et les étendre ultérieurement. La plupart des équipes commencent par les entités qui causent le plus de difficultés d’intégration et progressent à partir de là.

Lectures complémentaires

• Commande client — Wikipédia
• Resource Description Framework (RDF) — Wikipédia
• JSON-LD — Wikipédia
• schema.org — vocabulaire partagé pour les données structurées sur le Web