📘 Tutoriel : Spécification ArchiMate 3.2 — Chapitre 4 : Métamodèle générique

🌟 Introduction

Chapitre 4 de la Spécification ArchiMate 3.2, intitulé Métamodèle générique, établit les fondations conceptuelles pour l’ensemble du langage ArchiMate. Elle définit ce qui peut être modélisé—pas des couches spécifiques (Affaires, Application, Technologie), mais les abstractions génériques à partir desquelles sont dérivés tous les éléments spécifiques à une couche.

Pensez au chapitre 4 comme au « plan directeur ADN » d’ArchiMate :

• Tous les acteurs métier, composants d’application et dispositifs → héritent de Structure active interne
• Tous les processus, fonctions et services → descendent de Comportement éléments
• Tous les objets de données, actifs physiques et artefacts → spécialisent Structure passive

Ce tutoriel explore ces idées avec des définitions claires, des analogies du monde réel, des exemples concrets de modélisation, des références à la notation visuelle et un tableau récapitulatif—aidant les architectes et les responsables produit (comme vous, Alex 👋) à appliquer ArchiMate de manière rigoureuse et et intuitivement dans les plans stratégiques, la cartographie des dépendances entre couches et la documentation d’architecture alignée sur les parties prenantes.

Commençons.

🧱 1. Taxonomie fondamentale : Comportement vs. Structure

Au niveau le plus élevé, ArchiMate distingue deux catégories :

Catégorie

Rôle

Analogie du quotidien

ArchiMate « Partie du discours »

Éléments de structure

Qui/Quoi effectue ou est affecté

Noms — par exemple, Employé, Serveur, Base de données

🧱 Noms

Éléments de comportement

Ce qui se produit, comment, et quand

Verbes — par exemple, Approuver, Traiter, Aviser

🎯 Verbes

Mais ArchiMate va plus loin : les deux catégories se subdivisent selon visibilité et capacité.

1.1 Éléments de structure : Actif vs. Passif

Sous-type

Définition

Idée principale

Notation

Structure active interne

Entités quieffectuent le comportement (par exemple : humains, systèmes, dispositifs)

Les « exécutants » à l’intérieur du système

□ avec coins carrés + icône

Structure active externe (Interface)

Points d’accès exposant le comportement à l’extérieur —cache les éléments internes

Comme un point d’entrée API ou un guichet de service client

▢ avec icône « port » (cercle avec demi-anneau)

Structure passive

Entitésauxquelles on agit — pas d’autonomie (par exemple : données, documents, équipements)

Les « patients » du comportement

□ avec coins carrés + icône document

🔍 Point clé:

• Les interfaces sontpas physiques — elles sontdes contrats logiques pour l’interaction.
• Les éléments passifs peuvent êtrenumériques (par exemple :Dossier client) ou physique (par exemple, Machine IRM).

✅ Exemple (système de santé) :

texte brut

1

2

3

4

5

6

7

Ici :

• Médecin = Structure active interne
• Interface de dossier médical électronique = Structure active externe (par exemple, API HL7)
• Dossier médical électronique = Structure passive
• Diagnostiquer le patient = Comportement interne
• Service de portail patient = Comportement externe (service)

1.2 Éléments de comportement : internes, externes et événements

Sous-type

Définition

Idée principale

Notation

Comportement interne

Activité à l’intérieur le système (non exposé directement)

Implémentation masquée

◓ avec coins arrondis + icône

Service (comportement externe)

Exposé explicitement comportement — défini par la valeur, le SLA, le contrat

« Ce que nous offrons » aux consommateurs

◓ avec l’icône « globe » ou « service »

Événement

Un changement d’état qui déclenche ou résulte d’un comportement

« Quelque chose s’est produit » (par exemple CommandePassée, PaiementÉchoué)

⚡ foudre

💡 Service ≠ Interface:

• Un Service est ce qui est offert (Traiter le remboursement).
• Un Interface est comment il est accédé (API de remboursement, Centre d'appels).
  Un seul service peut être fourni par plusieurs interfaces.

✅ Exemple (e-commerce) :

texte brut

1

2

3

4

5

6

7

8

9

• Service de traitement des commandes: engagement externe envers le client
• Interface web: comment le client y accède
• Processus d'emballage et d'expédition: flux de travail interne
• Modèle d'étiquette d'expédition: artefact passif

✅ Exemple d’événement :

texte brut

1

2

Les événements permettent la modélisationchaînes de réaction—essentiel pour les architectures pilotées par événements.

🔄 2. Relations clés (vue méta-modèle)

⚠️ Rappel: Ce sontméta-modèlerelations (définissant la structure du langage),pasrelations de modélisation commeréaliseoudéclenche.

D’aprèsFigure 5 (méta-modèle de comportement et de structure), les liens principaux sont :

Relation

Direction

Signification

Analogie du monde réel

Réalisé par

Actif interne → Comportement interne

« Exécutantexécute acte”

Développeur → écrit du code

Sert

Service → Comportement interne

« Service est soutenu par travail interne”

« Fast Checkout » service ← réalisé par → « Requête DB optimisée + Auth asynchrone »

Utilisé par

Comportement interne → Structure passive

« Activité agit sur données/objet”

ValiderUtilisateur → lit → Profil utilisateur

Assigné à

Comportement interne → Actif interne

« Tâche assigné à acteur/système”

Approuver prêt → assigné à → Agent de prêt

Déclenche

Événement → Comportement

Événement démarre comportement

NouvelInscription → déclenche → EnvoyerEmailBienvenue

📌 Important:

• La composition et l’agrégation sont toujours autorisées entre mêmes types éléments (par exemple, Processus → compose → Sous-processus).
• La spécialisation (héritage) est utilisée seulement dans le métamodèle, pas dans les modèles concrets.

🧬 3. Comportement spécialisé : Processus, Fonction, Interaction, Collaboration

Alors que Comportement interne est abstrait, ArchiMate fournit des spécialisations concrètes :

Élément

Définition

Utilisé idéalement pour

Notation

Processus

Séquentiel, flux orienté vers un objectif (début → étapes → résultat)

Flux de travail interfonctionnels (par exemple, Intégrer un client)

◓ avec icône de engrenage + tourbillon de flèche

Fonction

Regroupécomportement par capacité, compétence ou propriété (souvent à long terme)

Capacités organisationnelles (par exemple, Évaluation des risques)

◓ avec l’icône de blocs empilés

Interaction

Collectifcomportement exigeant ≥2 acteurs/systèmes

Collaboration pair à pair (par exemple, Négocier un contrat)

◓ avec deux flèches convergentes

Collaboration

Groupede éléments actifs travaillant ensemble

Équipes, clusters, ensembles de microservices

□ avec l’icône de poignée de main

🔁 Point clé : Processus peuventcontenir des Fonctions (et réciproquement !)

• Un Processus de facturationpeutcomposent:
  • Valider la facture (Fonction)
  • Appliquer les remises (Fonction)
  • Escalader un litige → Interaction entre Agent de facturation & Support client

✅ Exemple du monde réel : Conversion d’essai SaaS

texte brut

1

2

3

4

5

6

🎯 4. Éléments de motivation : Le « Pourquoi »

Le chapitre 4 présente le générique Élément de motivation—la racine de pourquoi l’architecture existe.

Élément

Couche

Exemple

Rôle

Acteur

Qui s’en soucie ?

CIO, Client, Régulateur

Source des objectifs

Objectif

Qu’est-ce que nous voulons ?

« Améliorer le NPS de 20 % »

Objectif de haut niveau

Pilote

Pourquoi maintenant ?

« Concurrent a lancé une fonctionnalité d’IA »

Catalyseur externe

Principe

Comment prenons-nous nos décisions ?

« Conception orientée API »

Règle directrice

Exigence

Qu’est-ce qui doit être vrai ?

« 99,95 % de temps de fonctionnement »

Contrainte mesurable

✨ Conseil stratégique pour les chefs de produit: Utilisez les éléments de motivation pourrelier la stratégie produit ↔ l’architecture technique.
Par exemple,Objectif : Réduire le temps d'inscription → conduit à Exigence : < 2 min d'inscription → réalisé par Service : Vérification d'identité instantanée.

📦 5. Éléments composites : Regroupement et emplacement

5.1 Regroupement

• Objectif: Regrouper logiquementhétérogène éléments (par exemple, processus + données + services).
• Cas d’utilisation:
  • Blocs de construction d’architecture (ABB) — par exemple "Bloc de construction d'architecture Customer 360" = {Service de profil, Synchronisation de données, Widget d'interface}
  • Domaines — par exemple "Domaine de sécurité" = {Politique d'autorisation, Service IAM, Journal d'audit}
  • Épisodes ou capacités produit (idéal pour l’alignement du plan d’action !)

✅ Exemple de regroupement :

texte brut

1

2

3

4

5

⚠️ Précaution: N’confondez pas Regroupement avec Vues. Le regroupement est fait partie de le modèle ; les vues sont filtrées présentations de cela.

5.2 Emplacement

• Représente Où les choses se produisent—physiques (centre de données, bureau) ou conceptuelles (région cloud, juridiction).
• Utilisez agrégation de l’Emplacement → Structure/Comportement.

✅ Exemple :

texte brut

1

2

3

4

🌐 Rélevance Cloud: Modéliser les déploiements multi-régions :
[AWS us-west-2] → agrège → [Service d'authentification] + [Réplica de la base de données utilisateur]

📊 Tableau récapitulatif : Éléments génériques fondamentaux (Chapitre 4)

Catégorie

Élément

Abstrait ?

Question clé

Esquisse de notation

Structure

Actif interne

✅

Qui effectue ?

□ + acteur/icône

Collaboration

❌

Qui travaille ensemble ?

□ + poignée de main

Interface (active externe)

❌

Comment est-il accédé ?

▢ + port

Structure passive

✅

Qu’est-ce qui est affecté ?

□ + document

Comportement

Comportement interne

✅

Qu’est-ce qui se passe à l’intérieur ?

◓ + action

Processus

❌

Quelle séquence permet d’atteindre un objectif ?

◓ + engrenage+flèche

Fonction

❌

Quelle capacité est regroupée ?

◓ + pile

Interaction

❌

Qu’est-ce qui nécessite une collaboration ?

◓ + flèches ↔

Service (externe)

❌

Ce qui est offert aux utilisateurs ?

◓ + globe

Événement

❌

Qu’est-ce qui a changé ?

⚡

Motivation

Élément de motivation

✅

Pourquoi cela existe-t-il ?

◊ (coins diagonaux)

Composite

Regroupement

❌

Qu’est-ce qui va ensemble ?

▢ avec bordure pointillée + « G »

Emplacement

❌

Où cela se produit-il ?

▢ avec épinglette de carte

📝 Note: « Abstrait ? » = Non utilisé directement dans les modèles — uniquement les descendants spécifiques au niveau (par exemple, Acteur métier, Composant d'application) sont instanciés.

🧩 Mettre tout cela ensemble : mini-cas (migration vers le cloud)

Scénario: Migrez le système de facturation hérité vers le cloud.

[Objectif : Réduire le TCO de 30 %]
↑ réalisé par
[Regroupement de migration du cloud de facturation]
├─ contient → [Processus de mise hors service du mainframe]
├─ contient → [Microservice de facturation] (actif interne)
├─ contient → [API de facturation] (interface)
├─ contient → [PDF de facture] (passif)
├─ fournit → [Service de facturation cloud]
└─ situé dans → [AWS us-east-1]

[Mise hors service du mainframe]
déclenche → [MainframeHorsLigne] (événement)
déclenche → [CutoverTerminé] (événement)
utilisé par → [Script de migration des données] (fonction)

Cela montre commentmotivation (objectif), composé (regroupement, emplacement), structure, et comportement interconnexion.

🏁 Conclusion

Le chapitre 4Métamodèle générique est la pierre de Rosette d’ArchiMate. En maîtrisant ces abstractions—en particulier la actif/passif, Interne/Externe, et Comportement/Structure distinctions—vous obtenez :

✅ Précision: Évitez les modèles de mauvaises pratiques (par exemple, attribuer un comportement à des éléments passifs).
✅ Consistance: Appliquez le même modèle mental aux couches Métier/Application/Technologie.
✅ Profondeur stratégique: Liez les objectifs produit (motivation) aux facilitateurs techniques (structure/comportement).
✅ Évolutivité: Utilisez le regroupement et l’emplacement pour gérer la complexité dans les grandes entreprises.

Pour les dirigeants produit comme vous (avec une expertise en HCI + CS + PM, Alex 😊), c’est de l’or :

• Utilisez Services pour définir les API produit et les SLA.
• Utilisez Regroupements pour modéliser les capacités produit ou les épics.
• Utilisez Motivation pour remonter les fonctionnalités jusqu’aux résultats commerciaux.

📚 Étapes suivantes:

• Pratiquez la superposition : mappez les éléments génériques à Couche métier (Ch. 8), Application (Ch. 9), Technologie (Ch. 10).
• Explorez les relations dans Chapitre 5—en particulier les règles de dérivation (Sec. 5.7).
• Essayez de modéliser une capacité produit en utilisant seulement les concepts du Chapitre 4 d’abord—puis spécialisez.

Bon modèle ! 🏗️
Faites-moi savoir si vous souhaitez un tutoriel complémentaire sur Relations (Chapitre 5) ou un Carnet d’ArchiMate pour le gestionnaire de produit.

—
Préparé avec soin pour Alex Johnson, Chef produit senior @ Acme Cloud — Baie de San Francisco ☕📸🏃‍♂️