Comment bien choisir son métamodèle d'architecture d'entreprise

Deux organisations du même secteur, avec les mêmes logiciels, décrivent rarement leur système d'information de la même façon. Le métamodèle doit suivre cette différence, sans tourner à l'usine à gaz.

Ce qu'il faut retenir

• Un métamodèle d'architecture d'entreprise définit les types d'objets que l'on cartographie (applications, capacités métier, données, serveurs), les relations autorisées entre eux et leurs priorités : ce qu'il faut renseigner d'abord et tenir à jour en premier.
• Le bon métamodèle reflète la façon dont l'organisation pense son système d'information et son niveau de maturité en architecture.
• Pour démarrer, deux bonnes bases : un standard (TOGAF, ArchiMate) ou le métamodèle d'un éditeur, pensé pour être pragmatique. Les concepts se recoupent ; ce qui change, c'est la sélection des objets et des relations.
• L'erreur la plus fréquente consiste à vouloir tout modéliser dès le départ : le référentiel devient lourd, incomplet, et plus personne ne le met à jour.
• On démarre avec quatre couches et une poignée d'objets, puis on ajoute un type seulement quand une décision réelle le demande.

Chez Boldo, le métamodèle est entièrement configurable. Nous voyons donc chaque équipe construire le sien, et nous n'en avons encore jamais vu deux identiques. Une banque raisonne en produits et en canaux de distribution, une collectivité en services rendus aux habitants, un industriel en sites et en lignes de production.

Cet article s'adresse aux architectes, aux DSI et aux consultants qui lancent ou reprennent une cartographie du SI. Il donne une méthode pour choisir un métamodèle qui vous ressemble, et les erreurs que nous voyons le plus souvent.

Qu'est-ce qu'un métamodèle d'architecture d'entreprise ?

Un métamodèle d'architecture d'entreprise est la liste des types d'objets que vous cartographiez et des relations permises entre eux, avec leur niveau de priorité. Il fixe le vocabulaire commun : ce qu'est une application, une capacité métier ou un flux, et qui peut dépendre de quoi.

Le métamodèle est la grammaire de votre cartographie ; les applications, les flux et les serveurs que vous saisissez en sont les phrases. Si la grammaire est floue, deux contributeurs décrivent la même réalité de deux façons, et les analyses d'impact deviennent fausses.

Les priorités comptent autant que la liste. Tous les types d'actifs et toutes les relations n'ont pas le même poids : les applications critiques et leurs dépendances doivent être fiables dès le départ, un serveur de test peut attendre. Le métamodèle dit ce qui doit être complet et à jour en premier, et ce qui viendra ensuite.

Il précise aussi les propriétés de chaque objet (propriétaire, criticité, date de fin de support) et leur format. Ces définitions servent aussi aux outils : un agent IA qui interroge votre référentiel s'appuie sur elles pour comprendre ce qu'il lit.

Pourquoi chaque organisation a son propre métamodèle

Le métamodèle doit épouser le modèle mental de l'organisation et son niveau de maturité en architecture. Un métamodèle importé tel quel oblige les équipes à traduire leur réalité dans un vocabulaire qui n'est pas le leur, et la cartographie décroche.

Le modèle mental, c'est la façon dont les dirigeants et les métiers découpent l'entreprise quand ils en parlent. La maturité, c'est ce que l'équipe sait déjà tenir à jour. Voici les points de départ que nous recommandons selon la situation :

Partir d'un standard ou d'un métamodèle d'éditeur

Pour démarrer, deux familles de points de départ existent : les standards (TOGAF et ArchiMate) et les métamodèles livrés par les éditeurs d'outils d'architecture, comme SAP LeanIX ou Boldo. Dans les deux cas, on ne reprend pas tout.

Les standards : TOGAF et ArchiMate

Ils apportent un vocabulaire éprouvé que beaucoup d'architectes connaissent déjà, et prévoient eux-mêmes qu'on n'utilise pas tout.

Dans TOGAF 9, le métamodèle de contenu distingue un cœur et six extensions (gouvernance, services, processus, données, consolidation de l'infrastructure, motivation). La documentation de The Open Group précise que toutes ces extensions sont optionnelles et se choisissent pendant la phase préliminaire de la démarche. Pour aller plus loin sur le cadre, voir notre page TOGAF ou Zachman.

Le cœur d'ArchiMate tient en trois couches (métier, application, technologie, y compris le physique), complétées par la stratégie, la motivation, l'implémentation et la migration. The Open Group indique que le langage a été conçu pour être aussi réduit que possible tout en couvrant la plupart des besoins de modélisation.

Les métamodèles d'éditeurs

Les éditeurs livrent un métamodèle prêt à l'emploi, pensé pour être pragmatique et tiré de leurs projets. Celui de SAP LeanIX (version 4) compte 12 types d'objets par défaut, répartis sur quatre couches : stratégie et transformation, métier, applications et données, technique. Chez Boldo, des templates fournis jouent le même rôle : on part de l'un d'eux, puis on enrichit ou on simplifie.

Au fond, les mêmes concepts

D'une source à l'autre, les concepts se recoupent et restent cohérents. Une capacité métier, une application, un échange entre applications ou une donnée existent partout, parfois sous un autre nom. Ce qui change, c'est la sélection : quels objets on garde, et quelles relations on autorise entre eux.

Correspondances indicatives : les définitions ne se superposent pas toujours exactement d'un cadre à l'autre.

Faire le tri

Pour faire le tri, posez trois questions à chaque concept :

1. À quelle question de décideur répond-il ?
2. Qui le tiendra à jour, et à quelle occasion ?
3. Qui le lira ?

Un concept sans réponse aux trois attend son tour. Gardez aussi en tête que la notation ArchiMate parle surtout aux architectes : si les métiers doivent lire la cartographie, reprenez les concepts, pas forcément les symboles.

Commencer simple : la cartographie Pareto

Le principe de Pareto appliqué au SI consiste à cartographier d'abord les quelque 20 % d'actifs qui portent environ 80 % des enjeux. C'est là que se jouent les décisions de migration, de conformité et de budget, comme le détaille notre livre blanc sur la cartographie Pareto du système d'information.

Le métamodèle suit la même logique : il hiérarchise les types d'actifs et les relations au lieu de les mettre tous au même niveau. Voici la méthode que nous recommandons :

1. Listez les questions auxquelles la cartographie doit répondre dans les six prochains mois : quelles applications touche la migration de l'ERP, quels fournisseurs sont critiques, quelles applications portent la facturation.
2. Déduisez-en les types d'objets et les relations strictement nécessaires, puis classez-les par priorité : ce qui doit être complet tout de suite, ce qui peut attendre.
3. Rangez-les dans quatre couches : métier (capacités et processus), données (objets métier), applications (applications et flux), technologie (serveurs et technologies).
4. Donnez à chaque type un propriétaire et quelques propriétés utiles, pas plus.
5. Revoyez le métamodèle à chaque nouvelle question : un type s'ajoute quand une décision le demande, un type que personne ne renseigne se retire.

Les erreurs à éviter

L'erreur la plus courante, dans le choix d'un métamodèle, est de vouloir tout cartographier dès le premier jour. Comme le décrit notre livre blanc sur la cartographie Pareto, des mois plus tard l'inventaire n'est pas terminé, les premières données sont déjà périmées et les sponsors ont décroché.

D'autres erreurs reviennent souvent :

• Copier un métamodèle tel quel (celui d'un ancien employeur, d'un standard ou d'un outil), sans revenir aux questions de son organisation.
• Reprendre un standard en entier, y compris les concepts que personne ne lira.
• Créer un type d'objet pour ce qui devrait être une propriété : la criticité, par exemple, se porte sur l'application, elle ne mérite pas son propre type.
• Oublier les relations : un inventaire sans dépendances reste un tableur, et ne permet aucune analyse d'impact.
• Construire le métamodèle pour les seuls architectes, alors que les métiers et la direction doivent pouvoir lire la cartographie.
• Figer le métamodèle : il doit évoluer avec les questions de l'organisation.

Dans Boldo

Dans Boldo, le métamodèle se configure entièrement : types d'actifs, propriétés, relations et propriétés calculées. Des templates fournis servent de point de départ, puis on enrichit ou on simplifie. Toutes les fonctionnalités (diagrammes, cartes imbriquées, analyse d'impact) marchent sur n'importe quel type d'objet. Ajouter une couche ou un type ne demande donc pas de reconstruire les vues.

Questions fréquentes

Qui doit valider le métamodèle ?

Le métamodèle se valide avec ceux qui vont le lire et le tenir à jour, pas seulement avec l'équipe d'architecture. Un représentant des métiers, un responsable applicatif et, selon le contexte, le RSSI vérifient que les objets et les mots choisis leur parlent. L'architecte reste ensuite le gardien de sa simplicité.

Faut-il connaître ArchiMate pour construire son métamodèle ?

Non. ArchiMate aide à nommer les concepts de façon standard, mais un métamodèle simple à quatre couches se construit sans le connaître. Ce qui compte est de partir des questions que l'organisation se pose.

Criticité, coûts, fournisseurs : objet ou propriété ?

Une information devient un type d'objet quand elle a ses propres relations ; sinon, c'est une propriété. La criticité ou le coût annuel se portent sur l'application. Un fournisseur, lui, est relié à plusieurs applications et à des contrats : il mérite son propre type d'objet.

Peut-on changer de métamodèle en cours de route ?

Oui, et c'est même souhaitable. Un métamodèle vit avec l'organisation : une réorganisation, un projet de conformité ou une fusion amènent de nouvelles questions, donc de nouveaux objets. L'outil doit permettre ces changements sans reprise des données.

Sources

• Boldo, livre blanc « La cartographie Pareto de votre système d'information » (2025) : boldo.io
• The Open Group, ArchiMate 3.2 Specification : pubs.opengroup.org
• The Open Group, TOGAF 9, chapitre 30 « Content Metamodel » : pubs.opengroup.org
• SAP LeanIX, documentation « Meta Model » (version 4) : docs-eam.leanix.net