ArchiMate pour les développeurs : les 12 éléments essentiels

Les développeurs rencontrent souvent ArchiMate en comité d'architecture : un urbaniste projette un schéma couvert de boîtes colorées et demande où se place le nouveau service. La spécification est longue, et le réflexe est de l'ignorer pour dessiner ses propres boîtes. On perd alors ce qu'ArchiMate fait de mieux : un vocabulaire commun entre ceux qui écrivent le code et ceux qui décident de l'évolution du SI. Nul besoin de tout le langage : douze éléments et cinq relations suffisent à l'essentiel.

TL;DR

• ArchiMate est vaste ; les équipes qui l'utilisent bien s'en tiennent à un sous-ensemble réduit et stable.
• Douze éléments couvrent l'essentiel : acteur métier, rôle métier, processus métier, objet métier, capacité, composant applicatif, service applicatif, interface applicative, objet de données, nœud, logiciel système, service technologique.
• Cinq relations portent l'essentiel du sens : service (serving), réalisation, affectation, flux et accès.
• Trois vues répondent à la plupart des questions des développeurs : le paysage applicatif, le support des capacités et le déploiement.
• ArchiMate 4 (avril 2026) remplace les couches par des domaines et rend processus et services génériques ; le sous-ensemble reste valable.

Pourquoi apprendre un sous-ensemble d'ArchiMate plutôt que tout le langage ?

Parce qu'ArchiMate échoue par excès, pas par manque de notation. La spécification maintenue par The Open Group définit plusieurs dizaines de types d'éléments. Une équipe qui veut tous les utiliser produit des modèles que seul leur auteur sait lire, abandonnés dès qu'il change de projet.

Avec un sous-ensemble, chaque lecteur reconnaît chaque boîte, deux développeurs font les mêmes choix, et les éléments de base passent d'un outil ArchiMate à l'autre.

Vous découvrez les schémas ArchiMate ? Lisez d'abord notre guide pour comprendre la notation ArchiMate (couches, symboles, couleurs) ; cet article se concentre sur ce qu'il faut réellement utiliser.

Quels sont les 12 éléments ArchiMate dont un développeur a besoin ?

Ces douze éléments suffisent à dire qui fait quoi, avec quel logiciel, sur quelles données et où cela tourne. Ils couvrent les couches métier, applicative et technologique, plus la capacité (stratégie), qui rattache le modèle aux objectifs de l'organisation.

Quatre règles de traduction pour un développeur :

• Un dépôt Git n'est pas automatiquement un composant applicatif. Le composant est l'unité que le reste de l'organisation reconnaît : un service, un produit, un progiciel.
• Un endpoint appartient à une interface ; ce qu'il fait est un service. POST /invoices fait partie de l'API REST de facturation (interface) ; « Émettre une facture » est le service auquel elle donne accès.
• Objet métier et objet de données sont deux vues de la même chose. « Facture » est ce dont parle la comptabilité ; « enregistrement facture » est ce que stocke le service de facturation.
• Le nœud est volontairement large. VM, cluster ou plateforme serverless : tout cela est un nœud ; le logiciel système est ce qui y est installé.

Quelles sont les cinq relations à connaître ?

Cinq relations portent l'essentiel du sens : service (serving), réalisation, affectation (assignment), flux et accès. ArchiMate en définit d'autres (composition, agrégation, déclenchement, association…), plus rarement utiles.

Deux habitudes : le flux pour les données échangées entre composants, la relation de service pour « utilise » (un export nocturne est un flux, une API dont une application dépend relève du service) ; et l'accès réservé aux objets passifs, jamais entre deux composants.

Quelles trois vues couvrent la plupart des questions des développeurs ?

Trois vues répondent à l'essentiel : qui échange avec qui, quelles applications supportent quelle capacité, et où les choses tournent. ArchiMate 3.2 propose des points de vue proches (Application Cooperation, Capability Map, Technology Usage), mais le sous-ensemble suffit à les construire.

• Paysage applicatif. Des composants applicatifs reliés par des flux, avec les objets de données échangés sur les flux principaux. Elle répond à « qui consomme cette API ? » et « qu'est-ce qui casse si ce service tombe ? ».
• Support des capacités. Les capacités d'un côté, les composants applicatifs qui les supportent de l'autre. Elle répond à « quelles applications supportent la facturation ? » et révèle les capacités sans application ou redondantes.
• Déploiement. Les composants applicatifs, les logiciels système dont ils dépendent et les nœuds sur lesquels ils tournent, reliés par des relations de service. Elle répond à « quelles applications sont touchées par la montée de version de PostgreSQL ? ».

Sous le niveau du composant (conteneurs d'un service, classes d'un module), ArchiMate n'est pas le bon outil. Notre comparaison C4, ArchiMate et UML explique quelle notation choisir et comment projeter C4 sur ArchiMate.

Faites-le à la main dans Archi si vous êtes un architecte seul avec un modèle. Si plusieurs équipes doivent tenir la cartographie à jour, le plan gratuit d'UrbaHive (1 utilisateur, 25 applications, sans carte bancaire) permet de démarrer un référentiel partagé et de l'exporter vers Archi quand vous avez besoin de la notation.

Quelles sont les erreurs ArchiMate les plus fréquentes ?

L'erreur la plus fréquente est de confondre composant et service ; viennent ensuite l'excès de relations, les vues surchargées et le niveau code.

• Composant ou service. Si on peut le déployer, le redémarrer ou l'installer sur un serveur, c'est un composant ; si c'est un verbe décrivant ce qu'une chose offre, c'est un service.
• Trop de relations. Tout relié à tout par des associations, qui ne disent presque rien. Demandez-vous ce que le lecteur doit savoir.
• Vues illisibles. Une vue répond à une question pour un public ; au-delà d'une vingtaine d'éléments, découpez.
• Modéliser le code. Classes, tables et endpoints en éléments ArchiMate font du modèle une seconde copie, périmée, du code. Gardez ArchiMate au niveau de la cartographie.

Qu'est-ce qui change avec ArchiMate 4 ?

ArchiMate 4, publié par The Open Group en avril 2026 pour remplacer la version 3.2, simplifie le langage sans renier son socle. Le terme « couche » devient « domaine » ; processus, fonction, événement et service deviennent des éléments génériques communs à tous les domaines ; le rôle métier devient un rôle générique ; les éléments d'interaction, ainsi que Constraint, Contract, Gap et Representation, disparaissent.

Pour ce sous-ensemble, le processus métier devient un processus affecté à des acteurs ou rôles métier, les services applicatif et technologique deviennent des services, et le rôle métier devient un rôle. Les autres éléments et les cinq relations gardent leur sens. Les outils suivent progressivement : Archi 5.10 (septembre 2026) implémente toujours ArchiMate 3.2.

Où se situe UrbaHive ?

UrbaHive n'est pas un modeleur ArchiMate : il n'y a ni éditeur de notation, ni couches Stratégie, Motivation ou Implémentation. C'est un référentiel partagé (programmes, applications, flux, serveurs, capacités, processus, personnes) conçu pour les PME et ETI (50 à 5 000 salariés), où des non-spécialistes tiennent l'inventaire à jour sans apprendre la notation.

Le pont vers ArchiMate est le format d'échange ouvert (Open Exchange Format, XML), dans les deux sens. L'import lit un modèle Archi, ou de tout outil exportant ce format, et indique élément par élément ce qui sera créé, mis à jour ou ignoré. L'export couvre les applications, programmes, éditeurs, rôles, serveurs et infrastructures, documents d'architecture et flux, avec trois vues générées : les applications arrivent dans Archi comme composants applicatifs, les serveurs comme nœuds, les flux comme relations de flux. Capacités et processus restent dans UrbaHive, avec une matrice de couverture capacités × applications et une analyse d'impact des dépendances directes, en amont et en aval.

Questions fréquentes

Combien de temps faut-il pour apprendre ArchiMate ?

Les douze éléments et cinq relations de cet article s'apprennent en quelques heures de pratique sur un système que vous connaissez. Maîtriser tout le langage demande bien plus ; The Open Group propose une certification.

Les développeurs ont-ils besoin d'ArchiMate ?

Pas pour écrire du code, mais dès que leur travail dépasse un système : concevoir une intégration, retirer un service, passer en comité d'architecture. Le sous-ensemble permet de lire les schémas de l'urbaniste et de décrire son système dans des termes que la DSI réutilise.

Archi, le logiciel ArchiMate, est-il gratuit ?

Oui. Archi est un outil ArchiMate gratuit et open source. Sa version actuelle prend en charge ArchiMate 3.2 et le format d'échange ouvert, qui permet de faire circuler les modèles entre Archi et d'autres outils, dont UrbaHive.

Faut-il apprendre ArchiMate 3.2 ou ArchiMate 4 ?

Apprenez les concepts, qui changent peu, et utilisez la version de votre outil. Ces concepts et les cinq relations existent dans les deux ; ArchiMate 4 renomme et fusionne surtout processus et services.

Commencer par douze éléments

ArchiMate devient utile le jour où une équipe s'accorde sur un vocabulaire réduit et tient un modèle à jour. Dessinez les trois vues d'un domaine avec les douze éléments. Quand la cartographie a besoin de plus d'un mainteneur, créez un compte UrbaHive gratuit : 1 utilisateur, 25 applications, sans carte bancaire, et un export ArchiMate vers Archi dès que vous avez besoin de la notation. Pour le vocabulaire associé, consultez le glossaire de la cartographie SI et de l'architecture d'entreprise.