Ressources

La page Ressources est le point d’entrée pour toute personne souhaitant comprendre, adopter ou contribuer au Cloud Information Model (CIM). CIM est un modèle de données open source indépendant des applications — géré par The Linux Foundation — qui définit un vocabulaire partagé d’entités métier afin que les systèmes cloud et sur site puissent échanger des données sans que chaque équipe d’intégration n’ait à réinventer son propre schéma. Cette page rassemble les artefacts dont vous avez besoin pour évaluer CIM, les formats qu’il prend en charge, les référentiels où résident les modèles et les canaux pour s’impliquer.

Points clés à retenir

• CIM est un modèle de données partagé et neutre vis-à-vis des fournisseurs, et non un produit ou une base de données — il décrit des entités, des attributs et des relations auxquels plusieurs applications peuvent se mapper.
• Les principaux actifs techniques résident dans l’organisation CIM sur GitHub, où les définitions de modèles et l’outillage sont versionnés et sous licence ouverte.
• CIM est exprimé dans plusieurs formats standards afin qu’il puisse être consommé par différentes chaînes d’outils plutôt que de vous enfermer dans une seule sérialisation.
• Les pages de présentation, de FAQ et d’actualités constituent le moyen le plus rapide d’élaborer une analyse de rentabilisation et de répondre aux questions des parties prenantes avant une analyse technique approfondie.
• La contribution s’effectue via les référentiels GitHub et le formulaire Web du contributeur ; le modèle évolue grâce à l’examen de la communauté plutôt qu’à la feuille de route d’un seul fournisseur.

Ce qu’est réellement le Cloud Information Model

CIM est mieux compris comme un modèle canonique : une représentation neutre et convenue de concepts métier — clients, comptes, commandes, produits, contacts et les relations entre eux — qui se situe entre les systèmes que vous exploitez déjà. Plutôt que de forcer chaque application à parler le dialecte de toutes les autres, vous mappez chaque système vers CIM une seule fois, et CIM devient le point d’échange.

Il s’agit du même modèle architectural qui est apparu à plusieurs reprises dans l’intégration d’entreprise : un schéma canonique en étoile (hub-and-spoke) au lieu d’un maillage de mappages point à point. Il est conceptuellement lié à des efforts tels que l’OASIS Universal Business Language (UBL) pour les documents, l’Open Applications Group Integration Specification (OAGIS) pour les messages métier et schema.org pour les vocabulaires à l’échelle du Web. L’accent distinctif de CIM est qu’il est indépendant des applications et conçu pour la réalité hybride cloud et sur site dans laquelle la plupart des entreprises opèrent réellement.

Le gain pratique est une réduction de la prolifération des mappages. Si vous avez n systèmes et que chacun doit communiquer avec tous les autres, vous faites face à environ n² mappages. Introduisez un modèle canonique et la charge tombe à n mappages — un par système vers le modèle partagé. Cette réduction est l’argument économique central en faveur de l’adoption de CIM.

Présentation CIM

La présentation CIM est l’artefact de départ recommandé pour toute personne élaborant un dossier en interne. Elle est conçue pour être présentée à des publics mixtes — architectes, responsables de la gouvernance des données et sponsors métier — et couvre la motivation d’un modèle partagé, la portée de ce que définit CIM et la manière dont il s’intègre dans un paysage d’intégration existant.

Utilisez-la comme suit :

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

• Pour les dirigeants et les sponsors : mettez en avant le problème de la prolifération des mappages et l’argument de la neutralité des fournisseurs. La présentation présente CIM comme une réduction des risques, et non comme un remplacement complet (rip-and-replace).
• Pour les architectes et les ingénieurs : utilisez-la pour définir le contexte, puis passez immédiatement aux référentiels GitHub pour les définitions de modèle réelles.
• Pour les parties prenantes en matière de gouvernance et de conformité : utilisez-la pour ouvrir la conversation sur la propriété, le versionnage et la façon dont les modifications du modèle sont examinées.

Une présentation est un point de départ pour la discussion, pas une spécification. Considérez-la comme une rampe d’accès, et considérez les référentiels comme la source de vérité.

Formats CIM

CIM prend délibérément en charge plusieurs normes et formats plutôt qu’une seule sérialisation propriétaire. Ceci est important car les chaînes d’outils d’entreprise sont hétérogènes : votre outil de modélisation, votre plateforme ETL, votre passerelle API et votre générateur de documentation peuvent chacun préférer une représentation différente.

Les familles de formats couramment pertinentes dans cet espace comprennent :

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

• Les notations entité-relation et conceptuelles pour la révision humaine et les ateliers de conception.
• Les représentations de schéma basées sur JSON pour la consommation par les API et les applications.
• Les représentations RDF et de style ontologie pour les cas d’utilisation sémantiques et les graphes de connaissances.
• Les mappages relationnels et tabulaires pour les entrepôts de données et les pipelines ETL.

Le principe de conception est la portabilité : un modèle exprimé dans un format ouvert peut être transformé, comparé (diffed), versionné et validé par des outils standards. Lorsque vous évaluez CIM pour votre organisation, la question à poser n’est pas « quel format utilise-t-il ? » mais « puis-je faire un aller-retour avec mon modèle à travers les formats requis par mes outils sans perte ? ». Si une conversion de format supprime silencieusement la cardinalité des relations ou les contraintes d’attributs, il s’agit d’un risque d’intégration réel qui mérite d’être testé tôt.

Comment décider quel format adopter

Utilisez ceci comme guide de décision rapide :

Si votre consommateur principal est…	Favorisez une représentation qui…	Attention à…
Développeurs d’applications/API	Schémas de style JSON	Perte de sémantique relationnelle dans le JSON plat
Équipes Entrepôt de données / ETL	Mappages relationnels ou tabulaires	Relations plusieurs-à-plusieurs nécessitant des tables de jointure
Équipes Graphe de connaissances / sémantique	Représentations RDF/ontologie	Maturité de l’outillage et performance des requêtes
Ateliers de conception et de gouvernance	Notation conceptuelle/ER	Dérive entre le diagramme et le modèle lisible par machine

La dernière ligne est le mode de défaillance le plus courant : les équipes conservent un beau diagramme qui ne correspond plus au modèle versionné. Gardez le diagramme généré à partir des artefacts du référentiel, ou du moins réconcilié avec ceux-ci.

CIM dans l’actualité

La section « CIM dans l’actualité » regroupe la couverture externe — annonces, commentaires d’analystes et articles de la communauté — afin que vous puissiez voir comment CIM est reçu en dehors du projet lui-même. Ceci est utile pour deux raisons.

Premièrement, cela fournit une validation par un tiers. Lorsque vous proposez d’adopter un modèle partagé, citer une couverture médiatique indépendante est plus convaincant que de citer le propre marketing du projet. Deuxièmement, cela fait ressortir des histoires d’adoption et des modèles d’intégration concrets que la documentation de base pourrait ne pas couvrir.

Lisez la couverture médiatique de manière critique. Les annonces décrivent souvent l’intention et le partenariat plutôt que l’utilisation réelle en production. Faites la distinction entre « l’organisation X a rejoint l’effort » et « l’organisation X utilise CIM en production pour le système Y ». Le premier cas est courant ; le second est la preuve qui importe pour une décision de type « construire ou adopter ».

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

Organisation GitHub CIM

L’organisation GitHub est l’endroit où réside la substance. Pour les lecteurs techniques, c’est la destination qui compte le plus. Attendez-vous à y trouver :

• Définitions de modèles — les entités, attributs, relations et contraintes qui constituent CIM.
• Outillage — scripts et utilitaires pour valider, transformer et générer des artefacts à partir du modèle.
• Gestion des versions et historique — l’historique des commits qui montre comment le modèle a évolué et pourquoi.
• Issues et discussions — le registre de travail des propositions, questions et décisions.

Quelques habitudes pratiques rendent les référentiels bien plus utiles :

• Épinglez une version (release) ou un tag plutôt que de suivre la branche par défaut, afin que vos mappages ne changent pas en cours de projet.
• Lisez l’historique des commits pour les entités qui vous intéressent avant de les adopter. Un champ qui a changé trois fois en un an signale une zone instable.
• Vérifiez la licence de chaque référentiel. Les projets open source mélangent parfois les licences entre l’outillage et le contenu du modèle.
• Ouvrez des issues pour les ambiguïtés. Si la cardinalité d’une relation n’est pas claire, cette ambiguïté nuira à toutes les équipes en aval ; la soulever tôt améliore le modèle pour tout le monde.

Pour les organisations ayant des exigences strictes en matière de chaîne d’approvisionnement ou de provenance, examinez les référentiels comme vous examineriez toute dépendance tierce : licence, activité de maintenance, diversité des contributeurs et cadence de publication. Un modèle qui dépend d’un seul mainteneur présente un profil de risque différent de celui bénéficiant d’un large soutien organisationnel.

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

Questions fréquemment posées

Le Cloud Information Model est-il un produit que je peux acheter ?

Non. CIM est un modèle de données open source — un ensemble de définitions et d’artefacts de support — géré sous l’égide de The Linux Foundation. Vous l’adoptez en mappant vos systèmes vers celui-ci et en utilisant les définitions de modèles publiées ; il n’y a pas de frais de licence pour le modèle lui-même. Des fournisseurs peuvent créer des produits prenant en charge ou intégrant CIM, mais le modèle n’est pas une offre commerciale.

Dois-je remplacer mes systèmes existants pour utiliser CIM ?

Non, et c’est là tout l’intérêt. CIM est conçu pour se situer entre les systèmes en tant que modèle d’échange canonique. Vous conservez vos applications, bases de données et entrepôts, et vous créez des mappages de chaque système vers CIM. Cette approche est progressive : vous pouvez commencer par une seule intégration à forte valeur ajoutée et étendre la couverture au fil du temps.

Quel format dois-je utiliser pour consommer CIM ?

Cela dépend de votre consommateur. Les équipes API et applications privilégient généralement les représentations de schéma de style JSON ; les équipes d’entrepôt et ETL privilégient les mappages relationnels ou tabulaires ; les équipes de sémantique et de graphes de connaissances privilégient les représentations RDF/ontologie. Le test clé est l’aller-retour sans perte (lossless round-tripping) — vérifiez que la conversion entre les formats préserve les relations et les contraintes avant de vous engager.

Quel est le lien entre CIM et d’autres normes comme UBL ou OAGIS ?

Ils occupent des espaces problématiques adjacents. UBL et OAGIS se concentrent fortement sur les documents et les messages commerciaux échangés entre des parties, tandis que CIM met l’accent sur un modèle d’entité partagé auquel les applications se mappent. En pratique, ils peuvent être complémentaires : un modèle d’entité canonique peut éclairer la manière dont vous remplissez les normes de documents. Évaluez le chevauchement pour vos cas d’utilisation spécifiques plutôt que de supposer que l’un remplace l’autre.

Comment puis-je contribuer à CIM ?

Les contributions transitent principalement par l’organisation CIM sur GitHub — issues, pull requests et discussions — ainsi que par le formulaire web des contributeurs lié à ce site. Le modèle étant régi par la communauté, les propositions sont examinées ouvertement. Commencez petit : clarifiez une définition ambiguë ou ajoutez un attribut manquant avec une justification claire, et échangez avec les mainteneurs avant de proposer des changements structurels importants.

Par où doit commencer une partie prenante non technique ?

Commencez par la présentation CIM et la FAQ, puis parcourez « CIM dans l’actualité » pour obtenir un contexte tiers. Ces éléments vous donnent la motivation et le vocabulaire sans vous obliger à lire les définitions de modèles. Faites intervenir l’équipe technique une fois que vous avez une intégration candidate à piloter, et laissez-la travailler à partir des référentiels GitHub.

S’impliquer et poursuivre ses lectures

L’adoption d’un modèle partagé est autant un effort organisationnel que technique. Les initiatives CIM les plus réussies ont tendance à commencer par une intégration unique et bien délimitée — là où deux systèmes nécessitent actuellement un mappage personnalisé fragile — pour prouver l’approche du modèle canonique, puis à s’étendre. La gouvernance est cruciale : décidez tôt qui possède vos mappages CIM internes, comment les mises à niveau de version du modèle sont gérées et comment les conflits entre les définitions métier sont résolus.

Pour obtenir des informations sur le contexte de la gestion et de la gouvernance ouverte, consultez la page Linux Foundation sur Wikipédia. Pour les travaux de normalisation connexes, OASIS Universal Business Language et schema.org sont des points de référence utiles pour comparer les approches de modèles canoniques. Pour approfondir la modélisation sémantique, le World Wide Web Consortium (W3C) publie les spécifications RDF et OWL qui sous-tendent les représentations de style ontologie.

Utilisez la navigation de ce site pour accéder à la présentation, à la FAQ, à la documentation des formats, au résumé des actualités et aux référentiels GitHub — et utilisez le formulaire web des contributeurs lorsque vous serez prêt à participer à l’élaboration du modèle.