Questions fréquemment posées

Le Cloud Information Model (CIM) est un modèle de données et un consortium ouverts et basés sur des normes, visant à rendre les applications d’entreprise et les sources de données interopérables entre les systèmes cloud et sur site. Cette FAQ développe la FAQ CIM originale en apportant un contexte pratique pour les architectes de données d’entreprise, les ingénieurs d’intégration et ETL, les fournisseurs de plateformes et les contributeurs open source. Elle préserve les réponses originales tout en approfondissant le fonctionnement du modèle, sa gouvernance et la manière de décider si et comment l’adopter.

Points clés à retenir

• Le CIM est une spécification ouverte et un consortium, et non un produit commercial ; son objectif est de fournir un modèle de données partagé et indépendant des applications qui réduit le coût et la fragilité des intégrations point à point.
• La gouvernance incombe à la Joint Development Foundation sous l’égide de la Linux Foundation, avec un comité directeur comprenant historiquement AWS, Google, Genesys et Salesforce.
• L’adhésion comporte deux niveaux : un niveau de comité directeur payant et un niveau de contributeur gratuit ; le modèle lui-même est open source.
• Le CIM est exprimé dans plusieurs formats de normes afin que les organisations utilisant différentes piles technologiques puissent l’adopter sans abandonner leurs outils existants.
• Le modèle est plus précieux lorsqu’il est traité comme un vocabulaire canonique et une cible de mappage, superposé aux systèmes d’enregistrement existants plutôt que de les remplacer.
• Les contributeurs conservent le contrôle de leurs propres données et de leur PI ; la PI générée au sein d’un groupe de travail appartient à l’entité juridique du CIM selon la politique de chaque groupe.

Qu’est-ce que le Cloud Information Model ?

Le Cloud Information Model (CIM) est un consortium ouvert formé pour fournir une solution basée sur des normes pour connecter les produits d’entreprise. Son objectif déclaré est de permettre aux organisations de créer des expériences personnelles fluides et sur mesure à travers des applications cloud natives.

En pratique, le CIM est un modèle de données partagé — un vocabulaire commun d’entités, d’attributs et de relations — auquel différentes applications peuvent se mapper. Plutôt que de laisser chaque équipe d’intégration inventer ses propres mappages de champs entre, par exemple, un CRM et une plateforme marketing, les deux parties se mappent sur les mêmes définitions canoniques. C’est là le cœur de la promesse d’interopérabilité.

Le CIM facilite l’interopérabilité de plusieurs manières concrètes :

• Délai de mise en valeur (time to value) plus rapide — les mappages réutilisables et la sémantique partagée raccourcissent chaque nouveau projet d’intégration.
• Expériences fluides et personnalisées à travers les applications cloud natives, car les systèmes s’accordent sur ce qu’est réellement un « client », une « commande » ou un « produit ».
• Une vue intersystème des données, permettant des analyses et des flux de travail opérationnels qui s’étendent sur plusieurs applications.
• Réduction du temps de construction et de maintenance des intégrations, puisque les modifications sont apportées à un modèle partagé stable plutôt qu’à des contrats binaires fragiles.

Il est utile de situer le CIM dans le paysage plus large des efforts d’interopérabilité des données. Là où les approches de « schéma à la lecture » (courantes dans les lacs de données) diffèrent la structure jusqu’au moment de la requête, et où les schémas spécifiques aux API (tels que ceux décrits par OpenAPI) décrivent un service unique, le CIM décrit un modèle de domaine que de nombreux services peuvent partager. Il est plus proche, dans l’esprit, des traditions de modélisation canonique comme celles qui sous-tendent les modèles de données industriels et des vocabulaires du web sémantique tels que ceux publiés par le W3C, bien que le CIM soit délibérément pragmatique et orienté entreprise plutôt que purement académique.

À quels défis des applications cloud le CIM répond-il ?

Le CIM est une spécification moderne et ouverte destinée à atténuer les difficultés de l’intégration des données. Il fournit une norme définie pour communiquer facilement entre différents formats de données.

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

Les problèmes sous-jacents qu’il cible sont familiers à quiconque a construit des intégrations d’entreprise :

• Inadéquation sémantique. Deux systèmes possèdent tous deux un objet « client », mais l’un traite un compte de facturation et une personne comme une seule et même chose, tandis que l’autre les sépare. Sans modèle partagé, chaque intégration doit renégocier ces définitions.
• Croissance quadratique des intégrations (N²). Connecter N applications deux à deux peut nécessiter de l’ordre de N² mappages distincts. Un modèle canonique partagé réduit cela à N mappages vers un seul modèle.
• Dépendance vis-à-vis du fournisseur (vendor lock-in) et rotation. Lorsque les intégrations sont écrites directement selon le schéma propriétaire d’un fournisseur, remplacer ce fournisseur signifie réécrire les intégrations. Le mappage vers un modèle neutre réduit le coût de changement.
• Analyses inter-domaines. Un modèle cohérent permet de joindre des données provenant des domaines des ventes, du service, du marketing et du commerce sans logique de réconciliation sur mesure dans chaque rapport.

Le CIM n’élimine pas le besoin d’outils ETL/ELT, de courtiers de messages ou de passerelles API. Il se situe au-dessus d’eux en tant que couche sémantique vers laquelle et depuis laquelle ces outils effectuent leurs mappages.

Comment le CIM est exprimé à travers les formats de normes

Les groupes de travail du CIM ont développé le modèle selon une approche basée sur des normes et l’ont traduit dans plusieurs formats standards. Cette approche permet aux entreprises utilisant diverses technologies d’adopter le CIM, responsabilise les contributeurs et favorise la croissance d’un écosystème CIM plus vaste.

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

L’implication pratique est que vous n’êtes pas contraint à une seule sérialisation ou chaîne d’outils. Un modèle exprimé dans plus d’un format peut être consommé par :

• L’outillage de schéma et d’API qui attend du JSON Schema ou des définitions structurelles similaires.
• L’outillage graphique et sémantique qui travaille avec des vocabulaires et des ontologies de style RDF.
• L’outillage relationnel et d’entrepôt qui requiert des définitions DDL ou entité-relation.
• Les générateurs de code qui produisent des classes typées ou des objets de transfert de données (DTO) pour les développeurs d’applications.

Lors de l’évaluation de l’adoption, un critère de décision utile consiste à identifier lesquels de vos outils existants peuvent déjà ingérer l’un des formats publiés. Si votre plateforme d’intégration peut consommer le modèle directement, vous évitez de construire une couche de traduction pour commencer.

Qui peut adhérer, et comment le CIM est-il gouverné ?

CIM accueille tous les contributeurs. Il est open source dans le cadre de la Joint Development Foundation, qui opère sous l’égide de la Linux Foundation. La Linux Foundation est un foyer bien connu pour les projets collaboratifs open source et fournit l’infrastructure juridique et organisationnelle qui permet aux concurrents de collaborer sur une infrastructure partagée.

La gouvernance et la participation se décomposent comme suit :

• Comité de pilotage. Historiquement, quatre entreprises ont été représentées au comité de pilotage : AWS, Google, Genesys et Salesforce. Le comité de pilotage définit l’orientation du modèle.
• Groupes de travail. Ceux-ci produisent le modèle et ses traductions dans des formats standards, en fonction de politiques prédéfinies.
• Contributeurs. Tout le monde peut collaborer et contribuer au modèle CIM via le canal « Get Involved ».

À qui appartient la production du CIM ?

Les membres de la communauté conservent le contrôle total sur leurs propres données et leur PI. La PI générée par les membres du CIM lorsqu’ils travaillent au sein d’un groupe de travail CIM est la propriété de l’entité juridique du CIM et est gérée selon la politique prédéfinie de chaque groupe de travail. Cette séparation — vos données et votre PI préexistante restent les vôtres ; les artefacts de modèle créés conjointement sont détenus par l’entité — est un modèle courant et important dans les organismes de normalisation ouverts, et il convient de lire la politique spécifique du groupe de travail avant de contribuer.

Frais et niveaux d’adhésion

Le CIM compte actuellement deux niveaux d’adhésion.

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

Niveau	Coût annuel	Exigences	Ce que vous obtenez
SteerCo	50 000 $	Votre entreprise doit être membre de la Linux Foundation	Accès au comité de pilotage
Contributeur	Gratuit	Aucune	Participation en tant que contributeur

Le niveau Contributeur ne nécessite aucun paiement. Le niveau SteerCo comporte des frais et une adhésion préalable à la Linux Foundation, reflétant la responsabilité de gouvernance et l’influence supplémentaires qu’il confère. Pour la plupart des équipes d’intégration et de plateforme, le niveau Contributeur est le point de départ naturel ; les organisations qui souhaitent façonner la feuille de route du modèle devraient peser l’engagement SteerCo par rapport à cette influence.

Comment décider d’adopter ou non le CIM

L’adoption est une décision de modélisation et de gouvernance autant que technique. Considérez ces critères :

• Avez-vous un travail d’intégration récurrent entre fournisseurs ? Si vous intégrez les mêmes domaines à plusieurs reprises auprès de fournisseurs changeants, un modèle canonique s’avère payant. Si vous disposez d’une seule intégration stable, ce n’est peut-être pas le cas.
• Vos outils peuvent-ils consommer un format publié ? Vérifiez si votre plateforme ETL, votre passerelle API ou votre magasin de graphes peut ingérer le modèle directement.
• Avez-vous un domaine couvert par le CIM ? Le CIM est orienté vers les domaines d’entreprise centrés sur le client (client, produit, commande et concepts associés). Les domaines en dehors de cette portée peuvent nécessiter une extension.
• À qui appartiendra la couche de mappage ? Quelqu’un doit maintenir les mappages entre vos systèmes d’enregistrement et le modèle canonique. Considérez cela comme une responsabilité durable et non comme une tâche ponctuelle.
• Quelle est votre stratégie de sortie ? Le CIM étant neutre, le mappage vers celui-ci devrait rendre les futurs changements de fournisseur moins coûteux : vérifiez que vos mappages sont véritablement découplés du schéma d’un fournisseur unique.

Un modèle d’adoption pragmatique consiste à commencer avec un domaine à haute valeur, à y mapper deux ou trois systèmes et à mesurer si le vocabulaire partagé a réellement réduit l’effort d’intégration avant de s’étendre.

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

Conseils pratiques pour les contributeurs et les intégrateurs

Pour ceux qui s’impliquent, quelques habitudes rendent le travail plus efficace :

• Lisez d’abord la politique du groupe de travail. Comprenez la propriété de la PI et les conditions de contribution avant d’écrire quoi que ce soit.
• Modélisez pour la réutilisation, pas pour une seule intégration. Une entité canonique doit refléter le domaine, et non les particularités d’un seul système source.
• Documentez les mappages explicitement. Tenez un registre versionné de la manière dont chaque système source est mappé vers le modèle afin que les changements soient traçables.
• Privilégiez l’extension à la mutation. Si votre domaine a besoin de quelque chose qui manque au modèle, étendez-le d’une manière qui ne rompt pas les consommateurs existants.
• Engagez-vous en amont. Contribuer aux améliorations du modèle profite à tout le monde et réduit la charge de maintenance des forks privés.

Questions fréquemment posées

Qu’est-ce que le Cloud Information Model en une phrase ?

Le Cloud Information Model est un consortium ouvert et un modèle de données partagé, gouverné sous la Joint Development Foundation au sein de la Linux Foundation, qui donne aux applications d’entreprise un vocabulaire commun et indépendant des applications afin qu’elles puissent interopérer entre les systèmes cloud et sur site.

Le CIM est-il gratuit à utiliser et à rejoindre ?

Oui. Le niveau d’adhésion Contributeur est gratuit et ne nécessite aucun paiement, et le modèle est open source. Le niveau SteerCo payant, qui donne accès au comité de pilotage, coûte 50 000 $ par an et exige que votre entreprise soit membre de la Linux Foundation.

Qui siège au comité de pilotage du CIM ?

Quatre entreprises sont actuellement représentées au comité de pilotage : AWS, Google, Genesys et Salesforce. Le comité de pilotage guide l’orientation du modèle tandis que les groupes de travail produisent les artefacts.

À qui appartient la propriété intellectuelle produite par le CIM ?

Les membres de la communauté conservent le contrôle total sur leurs propres données et leur PI. La PI générée par les membres du CIM lorsqu’ils travaillent au sein d’un groupe de travail est la propriété de l’entité juridique du CIM et est gérée selon la politique prédéfinie de ce groupe de travail.

Quel est le lien entre le CIM et les autres normes d’interopérabilité ?

Le CIM complète plutôt qu’il ne remplace les formats de description d’API, les schémas de messages et les vocabulaires sémantiques. Il fournit le modèle de domaine partagé vers lequel ces formats et outils peuvent être mappés, avec une intention similaire aux modèles de données canoniques de l’industrie, mais concentré sur les domaines d’applications cloud centrés sur le client.

Comment puis-je m’impliquer dans le CIM ?

---

Tout le monde peut collaborer et contribuer au modèle CIM via le canal « Get Involved ». Une première étape judicieuse consiste à consulter les politiques du groupe de travail, puis à commencer par un seul domaine et à cartographier un petit nombre de systèmes pour valider l’approche.

Lectures complémentaires

• Linux Foundation — Wikipédia, pour des informations sur la fondation qui héberge CIM.
• Joint Development Foundation — Wikipédia, pour la structure de l’entité juridique derrière CIM.
• World Wide Web Consortium (W3C) — pour des travaux connexes sur les normes web et sémantiques.
• OpenAPI Specification — pour comprendre comment les schémas au niveau de l’API diffèrent d’un modèle de domaine partagé.