Modèle CIM

Le Cloud Information Model (CIM) est un modèle de données ouvert et indépendant des applications, destiné à fournir aux entreprises un vocabulaire partagé pour les entités qui apparaissent dans les systèmes CRM, ERP, marketing, de service et d’analyse. Plutôt que de laisser chaque fournisseur inventer ses propres noms d’objets et relations, le CIM définit un ensemble commun de domaines, d’entités et d’attributs auxquels tout système peut se mapper. Le modèle est géré comme un projet open source sous l’égide de The Linux Foundation, qui héberge un large portefeuille de projets collaboratifs de données et d’infrastructure.

Cet article explique comment le CIM est structuré, comment ses composants sont liés les uns aux autres, comment fonctionnent les supertypes et sous-types, et comment les domaines sont organisés. Il couvre également les décisions pratiques auxquelles un architecte est confronté lors de l’adoption du CIM — mapping, gouvernance, gestion des versions et extension — et la place du modèle par rapport aux autres normes industrielles.

Points clés à retenir

• Le CIM organise les concepts métier en domaines (Subject Areas), chacun contenant des groupes d’entités, des entités et des attributs — une hiérarchie qui correspond clairement aux schémas, aux tables et aux colonnes.
• Les supertypes et sous-types permettent au modèle d’exprimer des caractéristiques communes (une Partie qui est une personne ou une organisation) tout en permettant la spécialisation.
• Le modèle est délibérément indépendant des applications : il décrit des concepts métier, et non l’implémentation d’un fournisseur spécifique.
• Le CIM est publié dans plusieurs formats avec des exemples de diagrammes, afin qu’il puisse être utilisé aussi bien par des outils de modélisation que par des générateurs de code ou de la documentation.
• Le nombre et la portée des domaines augmentent avec les contributions du consortium et de la communauté, l’adoption doit donc tenir compte de la gestion des versions et des changements.
• Le CIM est une option parmi d’autres ; le bon choix dépend de si vous avez besoin d’un modèle inter-domaines large ou d’une norme étroite et approfondie pour un secteur donné.

Structure du CIM

Le CIM est organisé en composants afin que le contenu puisse être parcouru et consommé plus facilement. Chaque niveau de la hiérarchie répond à une question différente, et comprendre cette hiérarchie est la première étape pour bien utiliser le modèle.

• Domaine (Subject Area) — Un concept métier majeur identifié par le consortium CIM, tel que Party. Chaque domaine contient un ou plusieurs groupes d’entités. Considérez un domaine comme un contexte délimité (bounded context) : il regroupe tout ce que l’entreprise a besoin de savoir sur un thème large.
• Groupe d’entités — Un regroupement logique d’entités liées au sein d’un domaine, tel que Account. Les groupes d’entités permettent de naviguer dans de vastes domaines et donnent aux équipes une unité naturelle pour attribuer la propriété.
• Entité — Un objet unique sur lequel une organisation collecte des informations, tel qu’un Account Contact. Une entité est analogue à une table de base de données standard.
• Attribut — Une caractéristique unique d’une entité, telle que l’Account Id ou le Contact Email. Un attribut est analogue à un champ de base de données standard dans une table.

Cette hiérarchie à quatre niveaux est intentionnellement familière. Les architectes de données ayant travaillé avec la modélisation relationnelle, la modélisation dimensionnelle ou les diagrammes entité-relation reconnaîtront immédiatement le schéma. La valeur ajoutée par le CIM n’est pas une nouvelle technique de modélisation, mais un ensemble partagé et pré-négocié de noms et de relations sur lesquels plusieurs organisations et fournisseurs peuvent s’entendre.

Un modèle mental utile : un domaine est approximativement un schéma ou un domaine ; un groupe d’entités est approximativement un espace de noms ou un module ; une entité est une table ; un attribut est une colonne. Ce mapping est approximatif — le CIM est un modèle conceptuel et logique, et non physique — mais il est utile lorsque vous traduisez le CIM en une implémentation physique.

Supertypes et sous-types

Au-delà des quatre composants principaux, la conception du CIM personnalise et étend les entités en d’autres regroupements à l’aide de supertypes et de sous-types. C’est là que le modèle acquiert une grande partie de sa puissance expressive.

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

• Supertype — Une entité qui est étendue par des entités de sous-type, et qui définit des attributs communs pour des concepts similaires.
• Sous-type — Une entité qui étend une autre entité, et hérite des attributs de son entité supertype.

L’exemple classique est Party. Une Partie est toute personne ou chose avec laquelle l’entreprise traite. Une personne et une organisation sont toutes deux des parties, et elles partagent des attributs — un nom, des identifiants, des points de contact — mais chacune possède des attributs que l’autre n’a pas.

Modéliser Party en tant que supertype avec Person et Organization en tant que sous-types évite la duplication des attributs partagés et maintient les relations (par exemple, « cette opportunité appartient à cette partie ») cohérentes, quel que soit le sous-type impliqué.

Un tel héritage est un concept bien établi dans la modélisation des données et apparaît dans des normes telles que l’UML de l’Object Management Group et dans les conventions entité-relation utilisées dans l’industrie. Lorsque vous implémentez physiquement le CIM, vous devez décider comment représenter l’héritage :

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

• Table unique — stockez tous les sous-types dans une seule table avec une colonne discriminatrice. Simple à interroger, mais peut produire de nombreuses colonnes nullables.
• Héritage de table de classes — une table pour le supertype et une par sous-type, jointes sur une clé partagée. Normalisé et propre, mais nécessite des jointures.
• Héritage de table concrète — une table distincte et autonome par sous-type. Rapide pour les requêtes spécifiques à un sous-type, mais duplique les attributs partagés.

Il n’y a pas de réponse universellement correcte. Le bon choix dépend des modèles de requête, du nombre de sous-types et de la fréquence à laquelle les attributs partagés sont lus ensemble. Documentez la décision, car elle affectera chaque intégration en aval.

Les domaines thématiques du CIM

Les domaines thématiques représentent les principaux concepts métier que le consortium a modélisés jusqu’à présent. Chacun est publié avec ses propres diagrammes et formats, et plusieurs comportent des marqueurs de version explicites (par exemple, v1.0 ou v0.1.1), reflétant le fait que certains domaines sont plus matures que d’autres.

Setup — Définit les entités avec lesquelles vous traitez, par exemple le client, le fournisseur et le vendeur. Il couvre également les concepts de logiciels et d’infrastructure qu’une organisation exploite : Software Host, Software Tenant, Software User, Software App, Software Test, Software Service, Software Batch Job et IoT Device.

Data Model — Les concepts fondamentaux de modélisation eux-mêmes.

Hire — Activités liées à la mise en place de votre entreprise, par exemple l’unité commerciale interne et le travailleur. Les groupes d’entités incluent Job Application, Employee, Compensation, Training, Location, Work Territory et Work Report.

Biz Process — Concepts de processus métier et de continuité des activités.

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

Produce — Gestion du matériel que vous allez acheter, déplacer et vendre, par exemple le produit et le produit en stock. Les groupes d’entités incluent Supplier Product, Inventory Received, Inventory Product, Inventory Transfer, Electronic Media, Purchase Order et Sales Agreement.

Market — Activités utilisées pour promouvoir votre produit, par exemple la campagne marketing et la boutique en ligne. Les groupes d’entités incluent Party Resolution, Privacy Consent, Market Audience, Campaign, Promotion, Trade Event, Ad Buy et Web Site.

Sell — Activités utilisées pour vendre votre produit, par exemple la création de devis et d’opportunités. Les groupes d’entités incluent Price Book, Shopping Cart, Quote, Contract, Opportunity, Opportunity Forecast, Sales Order, Loyalty Program et Competitor.

Coup de cœur des lecteurs : Airbyte — ELT open source avec une option de cloud géré.

Service — Activités visant à fournir une assistance pour un produit vendu ou entretenu, par exemple un cas ou une enquête. Les groupes d’entités incluent AI Assistant, Asset, Asset Subscription, Web Content, Case, Task et Event.

Fulfill — Activités que vous effectuez pour exécuter une commande client, par exemple l’expédition et la commande de retour. Les groupes d’entités incluent Fulfillment Order, Shipment, Return Order, Work Order, Work Resource et Work Forecast.

Interact — Activités permettant de suivre l’engagement avec les utilisateurs finaux ou d’autres systèmes. Les groupes d’entités incluent Engagement, Conversation, Appointment, Software Event, Data Connector, Data Movement, Loyalty Journey et Loyalty.

Finance — Activités permettant de tracer les informations financières de l’entreprise, par exemple le paiement, la facture et la note de frais. Les groupes d’entités incluent Budget, Invoice, Payment Method, Payment, Credit Memo, Financial Ledger Account, Forecast, Calendar et Tax Policy.

Analyze — Activités liées à l’analyse des données, par exemple l’analyse des modèles, de l’utilisation des produits, du mouvement des données, des modifications des données et de la satisfaction des clients. Les groupes d’entités incluent AI Model, AI Application, IoT Device Use, Data Lineage, Blockchain, Survey, Loyalty et Journal.

Remarquez comment les domaines thématiques couvrent à la fois les préoccupations opérationnelles (Sell, Fulfill, Service) et analytiques (Analyze, Finance). C’est tout l’intérêt : un modèle partagé est plus précieux lorsqu’il peut décrire le même client, le même produit ou la même commande de manière cohérente, que les données se trouvent dans un système transactionnel ou dans un entrepôt.

Choisir entre CIM et d’autres normes

Le CIM n’est pas le seul modèle partagé dans l’entreprise. Plusieurs normes établies se chevauchent avec certaines parties de son champ d’application, et une architecture mature en utilise souvent plusieurs. La décision consiste moins à choisir un gagnant qu’à adapter l’étendue et la gouvernance du modèle à votre problème.

Norme	Objectif principal	Force typique	Où le CIM diffère
CIM	Concepts métier inter-domaines	Couverture large et indépendante des applications de CRM/ERP/marketing/service	Conçu comme un parapluie partagé entre les domaines
OMG Common Core Ontologies / Modèles basés sur UML	Notation de modélisation conceptuelle et ontologies supérieures	Sémantique formelle rigoureuse	Le CIM est plus directement orienté métier
Modèles spécifiques à un secteur (ex: vente au détail, santé, finance)	Couverture approfondie d’un secteur	Précision au sein de la verticale	Le CIM privilégie la largeur à la profondeur
Modèles de données fournisseurs (plateformes CRM/ERP)	Objets d’un seul produit	Intégration étroite avec ce produit	Le CIM est neutre vis-à-vis des fournisseurs par conception

Une règle pratique :

• Si vous avez besoin d’un vocabulaire partagé entre de nombreux systèmes et fournisseurs, un modèle large comme le CIM est tout indiqué.
• Si vous avez besoin d’une sémantique approfondie, réglementée et spécifique à l’industrie, une norme verticale sera généralement plus précise, et vous pourrez la mapper au CIM aux interfaces.
• Si vous intégrez au sein de l’écosystème d’un seul fournisseur, le modèle propre à ce fournisseur peut être suffisant — mais il ne vous aidera pas à vous connecter au fournisseur suivant.

Le modèle réel le plus courant est une approche hub-and-spoke (en étoile) : le CIM (ou un autre modèle canonique) se trouve au centre, et chaque système source y est mappé. C’est le même principe que celui des modèles de données canoniques dans la gestion des données de référence (MDM) et l’idée de « dimension conforme » popularisée dans la modélisation dimensionnelle par Ralph Kimball.

Conseils pratiques pour l’adoption du CIM

Adopter un modèle partagé est autant un exercice organisationnel que technique. Quelques décisions déterminent si l’effort porte ses fruits.

Commencez avec une portée limitée. N’essayez pas de mapper chaque système à chaque domaine thématique à la fois. Choisissez un domaine à forte valeur ajoutée — Party et Sell sont des points de départ courants car les données clients et opportunités sont largement dupliquées — et prouvez le mapping de bout en bout.

Décidez tôt de votre politique d’extension. Le CIM est conçu pour évoluer avec le consortium et les contributions, mais votre organisation aura inévitablement besoin d’attributs que le modèle ne définit pas encore. Établissez une convention pour les extensions locales (par exemple, un préfixe d’espace de noms) afin que les attributs personnalisés soient clairement distinguables des attributs standard et puissent être réconciliés ultérieurement.

Traitez la gestion des versions comme une préoccupation de premier ordre. Les domaines portent des marqueurs de version tels que v1.0 et v0.1.1, ce qui signale que le modèle évolue. Épinglez la version sur laquelle vous construisez, suivez les modifications et planifiez la migration. C’est la même discipline que vous appliqueriez à toute dépendance.

Mappez, ne copiez pas. CIM est un modèle conceptuel et logique. Résistez à la tentation de générer des schémas physiques directement à partir de celui-ci sans prendre en compte les performances, l’indexation et les modèles d’accès des systèmes qui consommeront les données. Utilisez le modèle pour aligner la signification, puis concevez le stockage physique pour votre charge de travail.

Gouvernez le mappage. Le mappage entre un système source et CIM est en soi un actif. Versionnez-le, révisez-le et attribuez-en la propriété. Les outils de l’espace d’intégration de données — plateformes ETL et ELT, catalogues de données et outils de lignage — peuvent vous aider à suivre l’origine de chaque attribut et son flux, ce qui correspond exactement au type de métadonnées que le domaine Analyze anticipe avec des entités telles que Data Lineage.

Engagez la communauté. Parce que CIM est open source et piloté par un consortium, les lacunes que vous trouvez sont souvent des lacunes que d’autres ont également trouvées. Contribuer une entité ou un attribut proposé au projet est à la fois un acte de civisme et un moyen de réduire votre charge de maintenance à long terme.

Formats, diagrammes et consommation

Les conceptions CIM sont disponibles dans plusieurs formats pour chaque domaine, y compris des exemples de diagrammes. Cela est important car différents publics consomment un modèle de données différemment :

• Les architectes veulent des diagrammes et des vues de relations pour raisonner sur la structure.
• Les ingénieurs veulent des définitions lisibles par machine qu’ils peuvent intégrer dans la génération de code, la validation de schéma ou des outils de mappage.
• Les analystes et stewards veulent une documentation expliquant la signification de chaque entité et attribut en termes métier.

La publication dans plusieurs formats est un choix de conception délibéré qui réduit les obstacles à l’adoption. Lorsque vous évaluez un modèle partagé, vérifiez qu’il est livré dans des formats que votre chaîne d’outils peut réellement ingérer — un modèle qui n’existe qu’au format PDF est beaucoup moins utile qu’un modèle avec des définitions structurées.

Questions fréquemment posées

Qu’est-ce que le Cloud Information Model (CIM) ?

Le Cloud Information Model est un modèle de données ouvert et indépendant des applications qui définit des concepts métier partagés — tels que Party, Account et Sales Order — afin que différents systèmes cloud et sur site puissent échanger des données en utilisant un vocabulaire commun. Il est organisé en domaines, groupes d’entités, entités et attributs, et est géré comme un projet open source sous The Linux Foundation.

Quelle est la différence entre un supertype et un sous-type dans CIM ?

Un supertype est une entité étendue par des entités de sous-type et qui définit les attributs communs à des concepts similaires. Un sous-type étend une autre entité et hérite des attributs de son supertype. Par exemple, Party peut agir comme un supertype avec Person et Organization comme sous-types, de sorte que les attributs partagés sont définis une seule fois et que les attributs spécialisés résident dans le sous-type.

Quel est le lien entre CIM et un schéma de base de données ?

CIM est un modèle conceptuel et logique, pas un schéma physique. Ses entités sont analogues aux tables de base de données et ses attributs aux champs, ce qui rend la traduction intuitive, mais vous devez toujours concevoir le stockage physique — indexation, partitionnement, dénormalisation — autour de vos propres modèles de requête plutôt que de copier littéralement le modèle.

Le CIM remplace-t-il les normes de données spécifiques à l’industrie ?

Non. Le CIM est vaste et transversal, tandis que les normes verticales sont approfondies et spécifiques à un secteur. De nombreuses organisations utilisent une approche en étoile (« hub-and-spoke ») dans laquelle CIM sert de modèle canonique au centre et les normes industrielles ou les modèles de fournisseurs lui sont mappés en périphérie.

Pourquoi les domaines CIM ont-ils des numéros de version ?

Les marqueurs de version tels que v1.0 et v0.1.1 indiquent que le modèle évolue et que certains domaines sont plus matures que d’autres. Épingler une version, suivre les modifications et planifier les migrations est la même discipline de gestion des dépendances que vous appliqueriez à n’importe quelle bibliothèque ou schéma partagé.

Comment gérer les attributs que CIM ne définit pas ?

Établissez une convention d’extension documentée, telle qu’un préfixe avec espace de noms, afin que les attributs personnalisés se distinguent clairement des attributs standard. Envisagez ensuite de contribuer pour combler cette lacune dans le projet, puisque le modèle est conçu pour croître grâce aux contributions du consortium et de la communauté.