Architecture d'entreprise et TOGAF : l'ADM, les domaines et la gouvernance

L'architecture d'entreprise consiste à décrire les capacités métier, l'information, les applications et la technologie d'une organisation comme un seul ensemble cohérent, afin que les décisions d'investissement soient prises en connaissance de leurs conséquences. Ce n'est pas une version agrandie de l'architecture logicielle. Un architecte de solution répond à la question « comment construire ce système ? » ; un architecte d'entreprise répond à « ce système doit-il exister, que ferait-il en double, que remplacerait-il, et en quoi nous rapproche-t-il de là où le métier doit être dans trois ans ? »

La discipline justifie son coût dans les organisations assez grandes pour que personne ne puisse garder tout le paysage en tête : là où les mêmes données client vivent dans neuf systèmes, où deux divisions achètent chacune de leur côté la même capacité, et où la décision de décommissionner une plateforme a des conséquences que personne ne sait recenser entièrement. Elle échoue, à grands frais, lorsqu'elle devient un exercice documentaire déconnecté des décisions réellement prises. TOGAF est le framework le plus largement adopté pour ce travail et, comme tout framework, c'est une source de structure dans laquelle puiser plutôt qu'un processus à suivre à la lettre.

À quoi sert l'architecture d'entreprise

Une fois le jargon mis de côté, les livrables servent une poignée de décisions récurrentes.

• Rationalisation du portefeuille. Lesquelles de nos 400 applications font la même chose, lesquelles ne sont plus supportées, lesquelles coûtent plus qu'elles ne rapportent ? Pour y répondre, il faut un portefeuille applicatif avec les responsables, le statut de cycle de vie, les coûts et les capacités que chaque application soutient.
• Priorisation des investissements. Étant donné une stratégie — conquérir un nouveau marché, réduire le coût de service, se conformer à une nouvelle réglementation —, quelles capacités doivent progresser, et quels systèmes faut-il modifier en conséquence ?
• Analyse d'impact. Si nous décommissionnons cette plateforme, qu'est-ce qui casse ? Quelles interfaces, quels processus, quels rapports ?
• Standards et réutilisation. Quelles technologies sont approuvées, lesquelles sont tolérées, lesquelles sont en voie de sortie, pour que les équipes choisissent délibérément plutôt que par préférence.
• Cohérence au fil du changement. Vingt programmes menés en parallèle, chacun raisonnable localement, qui produisent collectivement trois nouveaux modèles d'intégration et un quatrième référentiel client.

Chacune de ces questions est bel et bien posée par quelqu'un qui dispose d'un budget. Les artefacts d'architecture qui ne répondent à aucune d'elles sont un coût sans bénéfice, et le moyen le plus rapide de juger une pratique d'architecture d'entreprise est de demander quelles décisions elle a fait changer au cours de l'année écoulée.

Les quatre domaines d'architecture

TOGAF organise la description en quatre domaines, souvent abrégés BDAT (Business, Data, Application, Technology). Ce sont des vues d'une même architecture et non des architectures distinctes, et la valeur réside dans la traçabilité entre elles.

C'est la traçabilité qui rend le modèle utile. Quand une capacité est défaillante, vous voyez quelles applications la soutiennent ; quand une application est décommissionnée, vous voyez quelles capacités et quels processus sont touchés, et quelles entités de données doivent trouver un nouveau foyer. Un modèle aux quatre domaines magnifiquement dessinés mais sans relations entre eux ne peut répondre à aucune de ces deux questions.

ArchiMate est le langage de modélisation associé, organisé en couches calquées sur les domaines. Il mérite d'être utilisé dès lors que vous modélisez, car il donne aux relations une signification définie — réalisation, service, affectation — au lieu de flèches dont le sens dépend de la personne qui les a tracées.

Le cycle ADM

L'Architecture Development Method est le cœur de TOGAF : un cycle itératif pour produire et gouverner l'architecture, avec la gestion des exigences au centre, qui alimente chaque phase.

La phase préliminaire met en place la capacité d'architecture elle-même : quelles parties de l'organisation sont concernées, quels frameworks et outils sont utilisés, quels principes guideront les décisions et comment fonctionnera la gouvernance. Les principes d'architecture sont le résultat le plus durable de cette phase, et les bons ont du mordant : un principe comme « la donnée est saisie une seule fois, à sa source » tranche des débats pendant des années, alors que « nous tenons à la qualité » ne tranche rien.

Phase A — Vision de l'architecture cadre un cycle. Elle identifie les parties prenantes et leurs préoccupations, esquisse la cible à haut niveau, évalue la valeur métier et les risques, et produit le Statement of Architecture Work qui autorise le travail. Le résultat critique est l'accord sur le périmètre, car c'est un périmètre sans limites qui transforme une mission d'architecture d'entreprise en étude de dix-huit mois.

Phase B — Architecture métier décrit l'existant et la cible pour les capacités, les chaînes de valeur et les processus, puis mène une analyse d'écarts entre les deux. Bien faire ce travail est ce qui empêche l'architecture de devenir un plan technologique affublé d'une étiquette métier.

Phase C — Architectures des systèmes d'information traite ensemble les données et les applications, là encore avec existant, cible et écarts. Les constats récurrents : une maîtrise des données dupliquée, des applications qui soutiennent des capacités pour lesquelles elles n'ont jamais été conçues, un catalogue d'interfaces qu'aucune plateforme d'API management n'expose encore, et une intégration point à point — le problème que la SOA et l'ESB entendaient résoudre.

Phase D — Architecture technologique définit les plateformes et l'infrastructure qui réalisent l'architecture applicative, ainsi que les standards qui encadrent les choix futurs.

Phase E — Opportunités et solutions transforme les écarts des phases B, C et D en lots de travaux, les regroupe en projets candidats et identifie les architectures de transition : les états intermédiaires par lesquels passe l'entreprise, dont chacun doit être un point d'appui viable pendant un certain temps, puisqu'aucune organisation ne passe de l'existant à la cible en une seule étape.

Phase F — Planification de la migration ordonne et chiffre ces lots de travaux dans un plan de mise en œuvre et de migration, négocié avec les fonctions portefeuille et finance plutôt que rédigé en vase clos.

Phase G — Gouvernance de la mise en œuvre relie l'architecture à la livraison. Les projets sont revus au regard de la cible, les écarts sont consignés comme des dérogations explicites avec un responsable et une date d'expiration, et les architectes restent impliqués au lieu de se contenter de remettre un document.

Phase H — Gestion du changement d'architecture décide de la conduite à tenir quand la réalité évolue : un petit changement est absorbé, un changement important déclenche un nouveau cycle. C'est aussi là que le référentiel est tenu à jour.

La gestion des exigences se trouve au centre, recevant et redistribuant les exigences tout au long du cycle, car les exigences n'arrivent pas une fois pour toutes au démarrage.

Building blocks et référentiel

Les Architecture Building Blocks (ABB) décrivent une capacité requise en termes indépendants de toute implémentation : « gestion des identités et des accès assurant l'authentification, l'autorisation et la fédération pour les utilisateurs internes et partenaires ». Les Solution Building Blocks (SBB) sont les éléments concrets qui les réalisent : un produit précis, un service précis, un composant développé en interne. Séparer les deux est ce qui permet de remplacer un produit sans redessiner l'architecture, et c'est le même réflexe que programmer pour une interface.

L'Architecture Content Framework définit la nature des résultats et leurs relations. Ses trois niveaux méritent d'être connus, car ils clarifient bien des discussions approximatives sur les « livrables » :

• Les livrables (deliverables) sont des résultats contractuels, formellement revus et validés : l'Architecture Definition Document, le plan de migration.
• Les artefacts sont les produits de travail individuels qu'ils contiennent, de trois sortes : catalogues (listes d'éléments), matrices (relations entre deux listes) et diagrammes (vues visuelles).
• Les building blocks sont les composants réutilisables que décrivent ces artefacts.

L'Architecture Repository est l'endroit où tout cela est conservé. Les parties qui comptent en pratique sont l'Architecture Landscape (les descriptions de l'existant et de la cible à différents niveaux de détail), la Standards Information Base (ce qui est approuvé, toléré ou en voie de sortie), la Reference Library (les patterns et architectures de référence qui valent d'être réutilisés) et le Governance Log (les décisions, les dérogations et leur justification). Le Governance Log est le plus sous-estimé : un historique consultable des raisons d'une décision évite à l'organisation de la remettre en débat tous les dix-huit mois.

L'Enterprise Continuum est le schéma de classification qui permet de passer des modèles de référence génériques du secteur à des solutions propres à l'organisation. Il est plus utile sur le plan conceptuel qu'il n'est utilisé en pratique.

La cartographie des capacités

De tous les artefacts d'architecture d'entreprise, la cartographie des capacités métier est celui qui a le plus de chances d'être réellement utilisé, car elle offre aux interlocuteurs métier et technique un vocabulaire commun et stable.

Une capacité est ce que l'organisation est capable de faire, exprimé sous forme de groupe nominal et indépendamment de la manière ou des personnes : « entrée en relation client », « décision de crédit », « règlement des sinistres », « tarification ». Les capacités évoluent bien plus lentement que les processus, les structures organisationnelles ou les systèmes, et c'est précisément ce qui en fait une colonne vertébrale utile. On les décompose généralement sur deux ou trois niveaux ; au-delà, la cartographie devient un modèle de processus et perd sa stabilité.

Level 1   Customer Management
  L2      Customer Onboarding            importance: HIGH   health: POOR    apps: 4  ← invest
  L2      Customer Data Management       importance: HIGH   health: POOR    apps: 9  ← invest
  L2      Complaint Handling             importance: MED    health: GOOD    apps: 1
Level 1   Product & Pricing
  L2      Product Definition             importance: MED    health: FAIR    apps: 2
  L2      Pricing & Discounting          importance: HIGH   health: FAIR    apps: 3
Level 1   Order to Cash
  L2      Order Capture                  importance: HIGH   health: GOOD    apps: 1
  L2      Invoicing & Collections        importance: MED    health: POOR    apps: 5  ← rationalise

La cartographie justifie sa place grâce au heat mapping : on y superpose des évaluations. Quelles capacités sont stratégiquement importantes ? Lesquelles fonctionnent mal aujourd'hui ? Lesquelles reposent sur des systèmes en fin de vie, sur cinq applications qui se chevauchent, ou sur aucune ? Là où les calques « stratégiquement critique » et « mal soutenu » se croisent, vous tenez un argumentaire d'investissement qu'un dirigeant non technique peut lire sur une seule diapositive — un bien meilleur usage de l'effort d'architecture qu'un énième diagramme en couches.

Une gouvernance qui aide

La gouvernance de l'architecture est le mécanisme qui rend la cible réelle, et c'est là que les pratiques d'architecture d'entreprise deviennent le plus souvent ce que tout le monde contourne.

Ce qui fonctionne :

• Des principes et des standards publiés là où les développeurs se trouvent déjà — dans le dépôt, dans les modèles de projet, dans les contrôles de pipeline — plutôt que dans un portail que personne n'ouvre.
• Un processus de dérogation avec un registre de décisions. Les équipes auront besoin d'exceptions. Consignez l'exception, sa justification, son responsable et sa date d'expiration. Une pratique d'architecture qui dit non par défaut est contournée ; celle qui répond « oui, c'est consigné, on en reparle dans douze mois » reste informée.
• Une conformité automatisée partout où c'est possible. Règles de dépendances, images de base approuvées, métadonnées obligatoires, linting des API selon les lignes directrices de l'organisation. Un contrôle de pipeline passe à l'échelle de mille équipes ; un comité de revue, non.
• Une revue légère et au bon moment, aux points qui comptent — avant l'adoption d'une technologie, avant l'établissement d'un modèle d'intégration, avant une décision make-or-buy — plutôt qu'une barrière à chaque release.

Ce qui ne fonctionne pas : un comité qui revoit chaque projet une fois la conception terminée, des standards sans chemin de mise en conformité, des architectures cibles sans trajectoire financée depuis l'existant, et un effort de modélisation qui dépasse la volonté de l'organisation de le maintenir. Une gouvernance qui ajoute une semaine d'attente à chaque changement est l'une des raisons pour lesquelles les pratiques DevOps se sont répandues en réaction.

Les critiques, exposées honnêtement

Le framework s'attire de vives critiques, et une bonne partie est méritée.

Il est lourd. Le standard complet décrit bien plus d'artefacts qu'aucune organisation ne devrait en produire. Lu comme une obligation plutôt que comme un menu, il génère des documents que personne ne lit.

Il peut se déconnecter de la livraison. Une architecture cible à trois ans, produite par une équipe centrale, a tendance à être dépassée par les événements puis discrètement ignorée, tandis que les équipes de livraison prennent les vraies décisions en sprint planning.

La certification remplace la compétence. L'examen évalue le vocabulaire, facile à tester mais qui n'est pas ce que le métier exige.

Il suppose un degré de contrôle central qui ne correspond plus à la façon dont les logiciels sont construits. Les services cloud s'achètent avec une carte bancaire, les équipes produit choisissent leurs propres stacks, et une pratique d'architecture dont le seul instrument est l'approbation n'a que très peu d'influence.

Bien utilisé, il apporte pourtant une vraie valeur : un vocabulaire commun qui évite les dialogues de sourds, une liste de préoccupations qui prévient les oublis évidents, une structure reproductible pour l'analyse d'écarts, et un modèle de gouvernance que l'on peut renforcer ou alléger. L'approche pragmatique consiste à reprendre la structure de l'ADM et la classification du content framework, à produire le petit nombre d'artefacts qui répondent à des questions d'actualité, à automatiser la conformité, à intégrer les architectes aux équipes de livraison plutôt qu'au-dessus d'elles, et à faire du référentiel la mémoire des décisions plutôt qu'un musée de diagrammes.

Points clés à retenir

• L'architecture d'entreprise sert à éclairer les décisions de portefeuille, d'investissement, d'impact et de standards ; les artefacts qui ne répondent à aucune question d'actualité ne sont qu'un coût.
• Les quatre domaines — métier, données, applications, technologie — sont des vues d'un même modèle, et c'est dans la traçabilité entre eux que réside la valeur.
• L'ADM est un cycle itératif qui va de la vision aux architectures de domaine, puis aux opportunités, à la migration, à la gouvernance de la mise en œuvre et à la gestion du changement, avec la gestion des exigences au centre.
• Séparez les architecture building blocks des solution building blocks qui les réalisent, et conservez catalogues, matrices et diagrammes dans un référentiel doté d'un registre de gouvernance des décisions et des dérogations.
• Une cartographie des capacités métier avec des calques de chaleur est l'artefact le plus susceptible de faire changer une décision de la direction, et elle reste stable pendant que processus et systèmes évoluent sans cesse.
• Gouvernez par des standards publiés, des contrôles de conformité automatisés et un processus de dérogation consigné plutôt que par des comités qui bloquent chaque release, et traitez TOGAF comme un menu : itérez au périmètre qu'exige la décision et gardez les architectes proches de la livraison.