ArchiMate, le langage commun de l’architecture d’entreprise

Lorsque les architectes d’entreprise conçoivent le plan d’un système, depuis les processus métier jusqu’aux applications et à l’infrastructure, ils ont besoin d’un langage commun. Sans cela, la communication se fragmente : les diagrammes divergent, les définitions se contredisent et les décisions ralentissent.

ArchiMate répond précisément à ce besoin. Ce langage visuel et conceptuel offre un cadre structuré pour représenter la manière dont les métiers, les données, les applications et les technologies interagissent au sein de l’organisation.

Dans ce guide, nous verrons ce qu’est ArchiMate, comment il fonctionne et comment l’utiliser efficacement, à travers des exemples concrets, une explication claire de sa structure et des pistes pour comprendre comment des outils comme Boldo le rendent plus simple et opérationnel.

Qu’est-ce qu’ArchiMate ?

Lorsqu’un architecte dessine les plans d’un bâtiment, il ou elle s’appuie sur un ensemble de symboles normalisés afin que tous - ingénieurs, artisans ou maîtres d’ouvrage - puissent les comprendre de la même manière.

ArchiMate applique ce même principe au monde de l’entreprise : il propose un langage visuel standardisé permettant aux équipes métiers et IT de décrire leurs systèmes selon une grammaire commune.

Développé par The Open Group, ArchiMate est un langage de modélisation ouvert et indépendant des éditeurs. Il aide les organisations à décrire, analyser et communiquer leur architecture d’entreprise avec clarté et cohérence. Son ambition : rendre la structure de l’entreprise intelligible pour tous, depuis les dirigeants qui définissent la stratégie jusqu’aux équipes qui la concrétisent au quotidien.

En s’appuyant sur des formes et relations uniformes, ArchiMate élimine les ambiguïtés et garantit qu’une architecture soit représentée de manière cohérente dans toute l’organisation. Cette homogénéité renforce la collaboration, la prise de décision et l’alignement entre la vision stratégique et la réalité opérationnelle.

Une brève histoire d’ArchiMate

ArchiMate est né au début des années 2000 aux Pays-Bas, développé par le Telematica Instituut en partenariat avec le secteur public et privé. Son objectif était de créer une notation de modélisation commune capable d’unifier les visions métier et IT des organisations.

En 2009, The Open Group adopte officiellement ArchiMate comme standard, assurant sa compatibilité avec TOGAF et favorisant sa diffusion internationale. Depuis, le langage a évolué à travers plusieurs versions (2.0, 2.1, 3.0, 3.1) et s’est imposé comme une référence mondiale pour les architectes d’entreprise, les consultants et les éditeurs d’outils EA.

Logo ArchiMate (couleurs modifiées)

Le métamodèle ArchiMate : du “Pourquoi” au “Quoi”

Au cœur d’ArchiMate se trouve son métamodèle, la structure qui définit tous les éléments et relations utilisés pour décrire une entreprise. C’est ce qui rend le langage à la fois rigoureux et adaptable.

ArchiMate couvre l’ensemble du développement d’entreprise, de la motivation et de la stratégie jusqu’aux processus, applications, technologies et projets de transformation. Cette approche holistique permet de modéliser à la fois la vision globale et les détails opérationnels dans un cadre cohérent.

Mais il n’est pas nécessaire d’utiliser tous les concepts à la fois. Dans la majorité des cas, une petite proportion d’éléments suffit à représenter la grande majorité des besoins. Chez Boldo, nous appliquons le principe de Pareto (80/20) à la cartographie du Système d’Information : se concentrer sur les 20 % d’éléments qui apportent 80 % de la valeur. Cette logique permet de bâtir une architecture claire, exploitable et évolutive sans se perdre dans la complexité.

L’art d’utiliser ArchiMate consiste à choisir juste assez d’éléments pour représenter le système avec clarté, sans surmodéliser.

Le Métamodèle de base fournit l’essentiel : les acteurs, les processus, les applications, les données et l’infrastructure.

Le Métamodèle complet ajoute la stratégie et la motivation, c’est-à-dire le “pourquoi” derrière chaque conception, ainsi que les éléments d’implémentation qui traduisent le “comment” du changement.

Une bonne pratique de modélisation suit une logique simple:

• "Pourquoi” : identifier les moteurs, objectifs et exigences qui justifient le changement.
• “Comment” : les capacités et ressources nécessaires pour le réaliser.
• “Quoi” : les processus, systèmes et technologies qui concrétisent cette vision.

Couches du métamodèle d'ArchiMate

Ce flux maintient la cohérence de l’architecture d’entreprise en reliant l’intention, la conception et l’exécution.

Deux approches en découlent naturellement. La première, fondée sur les capacités, organise la transformation autour de ce que l’entreprise doit être capable de faire. La seconde, orientée services, met l’accent sur la valeur délivrée à travers les services métiers, applicatifs ou technologiques plutôt que sur des systèmes isolés.

En combinant ces deux visions, ArchiMate devient un outil puissant pour construire des architectures à la fois structurées, intentionnelles et traçables.

Des couches aux actifs : ce que chaque niveau représente

Chaque couche du métamodèle ArchiMate correspond à des actifs réels de l’entreprise, c’est-à-dire les éléments concrets qui composent son système. Ces actifs peuvent être visualisés, reliés et analysés dans des outils comme Boldo, transformant une architecture abstraite en une cartographie exploitable.

Couche Motivation et Stratégie - Pourquoi nous agissons

La couche Motivation et Stratégie définit la finalité. Elle exprime l’intention derrière chaque initiative, ce qui motive le changement et les capacités nécessaires pour le réaliser. On y retrouve des objectifs, des moteurs, des parties prenantes, des principes, des capacités et des ressources. Par exemple, “Améliorer la satisfaction client” comme objectif peut être réalisé par la “Capacité d’engagement client”.

Couche Motivation et Stratégie - (Représentations simplifiées, non officielles de The Open Group)

Couche Métier - Comment nous créons de la valeur

La couche Métier représente l’organisation en action : les acteurs, rôles, processus et services qui produisent les résultats. On y trouve des acteurs métiers, des rôles, des fonctions, des processus, des produits et des services. Par exemple, le “Processus de gestion des commandes” est exécuté par le département des ventes, qui délivre le “Service de traitement des commandes”.

Actifs - Couche Métiers - (Représentations simplifiées, non officielles de The Open Group)

Couche Applicative - Quels systèmes nous soutiennent

La couche Applicative décrit les systèmes numériques qui soutiennent les processus et les échanges d’information. On y retrouve des applications, des composants, des services, des objets de données et des intégrations. Par exemple, l’“Application CRM” fournit le “Service de profil client” au processus de vente.

Actifs - Couche Applicative - (Représentations simplifiées, non officielles de The Open Group)

Couche Technologique - Quelle infrastructure les exécute

La couche Technologique modélise la base technique qui héberge les applications et garantit la continuité opérationnelle. On y retrouve des serveurs, des plateformes, des réseaux, du middleware ou des ressources cloud. Par exemple, une “Machine virtuelle Azure” héberge le composant applicatif CRM.

Actifs - Couche Technologique - (Représentations simplifiées, non officielles de The Open Group)

Couche Mise en œuvre et Migration - Comment nous évoluons

Enfin, la couche de Mise en œuvre et de Migration représente la transformation dans le temps, avec les projets, livrables et étapes de migration. On y retrouve des programmes, des lots de travaux, des livrables et des architectures de transition. Par exemple, le “Programme Customer360” est composé de trois lots : intégration des données, montée de version CRM et formation des équipes.

Actifs - Couche Mise en Oeuvre et Migration - (Représentations simplifiées, non officielles de The Open Group)

Éléments Composites - Comment nous structurons

La couche des actifs composites apporte du contexte et organise les autres éléments de l’architecture. Elle permet de regrouper ou de localiser des actifs pour mieux comprendre leur rôle et leurs interactions.

On y retrouve notamment :

• Emplacement : représente un lieu physique ou logique où les éléments opèrent (ex. : «EMEA» pour un datacenter).
• Regroupement : assemble plusieurs éléments en un ensemble cohérent (ex. : « Plateforme Data » rassemblant entrepôt, moteur de traitement et APIs).

Ces actifs structurent la cartographie et facilitent sa lecture, transformant une liste d’éléments en une vision claire et organisée.

Éléments Composites - (Représentations simplifiées, non officielles de The Open Group)

Comprendre les relations ArchiMate

Si les éléments sont les mots du langage ArchiMate, les relations en sont la grammaire.
Elles définissent comment les actifs métier, applicatifs et technologiques se connectent entre eux, constituant l’ossature logique de tout modèle d’architecture.

ArchiMate classe ces relations en quatre grandes familles, chacune ayant un rôle précis pour décrire comment les différentes parties de l’entreprise interagissent.

Relations structurelles

Elles décrivent comment les éléments sont composés ou affectés les uns aux autres — autrement dit, la logique du « fait partie de » ou du « est construit par ».

• Composition : un élément est constitué d’un ou plusieurs autres.
  Exemple : un « Système CRM » est composé de plusieurs « Applications » (Salesforce, Mailchimp, etc.).
• Agrégation : version plus souple de la composition : les éléments sont regroupés mais peuvent exister indépendamment.
  Exemple : une « Suite de gestion client » agrège un « CRM » et un « Portail support ».
• Affectation : attribue une responsabilité entre un élément actif (rôle, composant…) et un comportement.
  Exemple : le « Département des ventes » exécute le « Processus de traitement des commandes ».
• Réalisation : indique qu’un élément implémente ou concrétise un autre.
  Exemple : le « Composant applicatif CRM » réalise le « Service de gestion des données clients ».

Relations structurelles - (Représentations simplifiées, non officielles de The Open Group)

Relations de dépendance

Elles décrivent comment un élément dépend d’un autre pour accomplir sa fonction.

• Service : un élément fournit une fonctionnalité utilisée par un autre.
  Exemple : le « Service d’authentification » sert l’« Application CRM ».
• Accès : définit comment un comportement accède à des données ou des informations.
  Exemple : le « Processus de facturation » lit la « Base de données clients ».
• Influence : modélise la façon dont des objectifs, principes ou exigences affectent d’autres éléments.
  Exemple : le « Principe de durabilité » influence l’« Exigence de sélection du fournisseur cloud ».

Relations de dépendance - (Représentations simplifiées, non officielles de The Open Group)

Relations dynamiques

Elles représentent les flux et déclencheurs : la logique de cause à effet de l’entreprise.

• Déclenchement : un processus ou un événement en initie un autre.
  Exemple : l’« Événement commande reçue » déclenche le « Processus de traitement de commande ».
• Flux : représente le transfert de données, d’informations ou de valeur entre éléments.
  Exemple : l’« Application CRM » envoie les données clients à la « Plateforme marketing ».

Relations dynamiques - (Représentations simplifiées, non officielles de The Open Group)

Autres relations

Elles apportent souplesse structurelle et précision sémantique aux modèles.

• Spécialisation : indique une version plus spécifique d’un autre élément.
  Exemple : le « Service de paiement en ligne » spécialise le « Service de paiement ».
• Association : lien générique entre des éléments qui ne relèvent pas des autres catégories.
  Exemple : un « Employé » est associé à un « Ordinateur portable ».
• Jonction : fusionne ou divise des relations pour modéliser une logique complexe.
  Exemple : deux « Événements » peuvent converger vers un même « Processus » grâce à une jonction de type ET.

Autres Relations - (Représentations simplifiées, non officielles de The Open Group)

En combinant ces quatre types de relations, ArchiMate permet de modéliser non seulement les éléments de l’architecture, mais aussi leurs interactions, transformant un simple inventaire en une vision cohérente et dynamique de l’entreprise.

Le métamodèle Boldo : flexibilité et standards réunis

Chaque organisation a un niveau de maturité différent en architecture. Certaines débutent avec des outils simples, d’autres pilotent déjà des environnements complexes. Pour s’adapter à cette diversité, le métamodèle de Boldo est conçu pour évoluer avec l’entreprise. Sa structure modulaire permet de commencer par modéliser applications, processus et données, puis d’ajouter progressivement des notions plus avancées comme les capacités, les services ou les projets de transformation.

Boldo prépare aussi l’arrivée d’un métamodèle ArchiMate natif, conforme au standard du The Open Group. Il offrira interopérabilité, rigueur sémantique et lisibilité immédiate pour les équipes formées à ArchiMate.

Concrètement, deux approches seront possibles : un modèle adaptatif, rapide et collaboratif pour structurer les premières cartographies, et un modèle ArchiMate structuré pour les besoins de standardisation et de gouvernance. Les deux peuvent être combinés pour faire évoluer la cartographie au rythme de la maturité de l’organisation.

Cette double approche illustre la philosophie de Boldo : rendre l’architecture d’entreprise à la fois accessible et rigoureuse, afin que chaque équipe partage la même vision au bon niveau de détail.

Conclusion

L’architecture d’entreprise est à la fois une science et un art. Elle relie la stratégie, les systèmes et les personnes. ArchiMate fournit le langage pour exprimer cette complexité, transformant des idées abstraites en modèles structurés.

Boldo, lui, donne vie à ce langage.

FAQ