TOGAF et méthode ADM : architecture d’entreprise en pratique

TOGAF (The Open Group Architecture Framework) est le référentiel d’architecture d’entreprise le plus diffusé, et probablement le plus mal appliqué. Sa méthode ADM (Architecture Development Method) décrit comment passer d’un système d’information (SI) existant à un SI cible, en quatre vues (métier, données, applications, technologie), par étapes planifiées et sous une gouvernance qui vérifie que les projets livrent ce qui a été décidé. La position défendue ici : TOGAF est une boîte à outils à découper, pas un processus à dérouler, et sa valeur tient presque entière dans trois pièces (l’écart entre l’existant et la cible, la feuille de route de transition, le comité qui dit non).

→ Lire l’explication complète de la marmotte

Ce que TOGAF contient réellement, et ce qu’il faut en garder

La version courante, le TOGAF Standard, 10e édition (The Open Group), sépare un socle stable (le « Fundamental Content » : ADM, cadre de contenu, continuum, gouvernance) d’une série de guides thématiques qui évoluent plus vite. Ce découpage modulaire est la meilleure nouvelle des dix dernières années pour le référentiel : il officialise ce que les praticiens faisaient déjà, c’est-à-dire prendre ce qui sert et laisser le reste sur l’étagère.

Les pièces qui portent réellement la charge :

L’ADM, le cycle de phases qui structure le travail. Il se paramètre ; il ne s’exécute pas d’un bloc.
Le cadre de contenu d’architecture (Architecture Content Framework) : la liste des livrables, artefacts et briques. On y distingue les ABB (Architecture Building Blocks, briques décrivant une capacité attendue, indépendante du produit) des SBB (Solution Building Blocks, l’implémentation concrète choisie). Confondre les deux, c’est écrire « Keycloak » là où la cible demandait « fédération d’identités avec authentification forte », puis découvrir que la décision d’architecture a été prise par un comparatif de licences.
Le référentiel d’architecture (Architecture Repository) : là où vivent les modèles, principes, standards et décisions.
La gouvernance d’architecture : comité (Architecture Board), contrats d’architecture, revues de conformité, dérogations.

Le reste (continuum d’entreprise, taxonomies de référence, catalogues exhaustifs d’artefacts) sert surtout à l’examen de certification. Vingt ans de métier apprennent qu’un référentiel d’architecture rempli des 30 artefacts du catalogue se reconnaît à un détail : personne ne l’a ouvert depuis l’audit.

Le compromis central se formule ainsi : TOGAF achète de la traçabilité (chaque projet se rattache à une exigence, chaque écart à une décision) et la paie en latence et en charge documentaire. Plus le cycle est complet, plus la traçabilité est bonne et plus les projets contournent l’architecture. La règle de dimensionnement qui en découle : n’introduire un artefact que si une décision de gouvernance le consomme. Un artefact que personne ne lit au comité n’existe pas, il coûte seulement.

Les phases de l’ADM et leur enchaînement

L’ADM compte une phase préliminaire, huit phases lettrées de A à H, et une gestion des exigences au centre qui alimente toutes les autres.

Préliminaire : mandat, périmètre de l’entreprise couverte, principes d’architecture, adaptation du cadre lui-même.
A, Vision d’architecture : parties prenantes, objectifs, périmètre du cycle, déclaration de travail d’architecture (Statement of Architecture Work).
B, Architecture métier : capacités, processus, organisation, flux de valeur.
C, Architectures des systèmes d’information : données et applications, traitées ensemble ou séparément.
D, Architecture technologique : plateformes, réseau, hébergement, services d’infrastructure.
E, Opportunités et solutions : regroupement des écarts en lots de travail, premières options de réalisation.
F, Planification de la migration : séquencement, architectures de transition, plan de migration.
G, Gouvernance de la mise en œuvre : contrats d’architecture, revues de conformité des projets.
H, Gestion du changement d’architecture : surveillance des évolutions qui justifient un nouveau cycle.

Le schéma suivant montre ce que la liste rend mal : les phases B à D ne s’enchaînent pas une seule fois, et la gestion des exigences se branche partout.

Deux pièges reviennent systématiquement. Le premier : dérouler B, C et D en cascade stricte, ce qui produit une architecture métier élégante que la technologie disponible ne peut pas porter, découverte en phase D après trois mois de travail. Les itérations B, C, D sont prévues par le standard ; il faut les planifier, pas les subir. Le second : sauter la phase préliminaire au motif qu’elle « ne produit rien ». Elle produit le mandat. Sans mandat écrit d’un sponsor de direction, le comité d’architecture n’a aucun pouvoir de refus, et un comité qui ne peut pas refuser fait de la décoration.

Vues métier, données, applications et technologie

Chaque vue répond à une question distincte, et le travail utile se trouve dans les liens entre les vues plus que dans les vues elles-mêmes.

La vue métier décrit les capacités (ce que l’organisation sait faire, indépendamment de qui le fait et avec quoi), les processus et les acteurs. La carte des capacités est l’artefact le plus rentable de tout TOGAF : stable dans le temps, compréhensible par la direction, et support naturel de l’analyse de risque. Une capacité critique sans application identifiée est un trou de cartographie ; une capacité servie par quatre applications concurrentes est une dette.

La vue données décrit les entités, leur propriétaire, leur classification et leurs flux. C’est là que se jouent les exigences du RGPD (règlement (UE) 2016/679) : localisation, finalité, durée de conservation. La page sur ce que le RGPD impose à l’architecture détaille ce qui en découle. Une vue données sans propriétaire nommé par entité ne permet aucune décision : quand deux applications revendiquent le référentiel client, la vue doit dire laquelle fait foi.

La vue applications décrit les applications, leurs interfaces et leurs dépendances. Elle se confronte à la réalité via la CMDB (Configuration Management Database, base de gestion des configurations) et les outils de découverte, jamais seulement via des entretiens. Les entretiens donnent l’architecture que les équipes croient avoir ; les journaux de flux donnent celle qu’elles ont.

La vue technologie décrit plateformes, réseau, hébergement et services transverses : annuaire, fédération d’identités, PKI (Public Key Infrastructure, infrastructure à clés publiques), gestion des secrets. Côté sécurité, c’est la vue où se décident les briques communes ; une brique d’authentification décidée projet par projet donne autant de modèles de session que de projets.

Pour la modélisation, ArchiMate (langage de The Open Group, aligné sur les couches TOGAF) reste le choix rationnel : notation normalisée, format d’échange entre outils, et une couche « motivation » qui relie exigences et principes aux éléments modélisés. Le cadre conceptuel de description d’architecture (points de vue, préoccupations, parties prenantes) vient de la norme ISO/IEC/IEEE 42010, que TOGAF reprend.

La sécurité n’a pas de phase propre, et c’est voulu : elle traverse les quatre vues. Le guide TOGAF consacré à l’intégration du risque et de la sécurité, ainsi que les travaux d’alignement avec SABSA (Sherwood Applied Business Security Architecture), vont dans ce sens. En pratique, cela signifie : exigences de sécurité injectées dans la gestion des exigences dès la phase A, classification des données en phase C, briques de sécurité comme ABB en phase D. L’analyse de risque elle-même ne vient pas de TOGAF ; elle vient d’une méthode dédiée comme EBIOS RM, dont les valeurs métier et biens supports se raccordent directement à la carte des capacités et à la vue applications.

Analyse d’écarts, architectures de transition et feuille de route

L’analyse d’écarts (gap analysis) compare existant et cible, élément par élément, sur chaque vue : conservé, retiré, ajouté, modifié. C’est le livrable qui transforme une vision en travail. Une cible sans analyse d’écarts est un souhait.

La feuille de route découpe ensuite le chemin en architectures de transition : des états intermédiaires, chacun cohérent et exploitable en soi. Le mot important est « exploitable ». Une transition qui laisse coexister l’ancien annuaire et le nouveau fournisseur d’identités sans synchronisation définie n’est pas une transition, c’est un incident planifié.

Règles de construction d’une feuille de route qui tient :

chaque transition se décrit comme un état stable, avec ses flux et ses dépendances, pas comme une liste de projets ;
chaque transition a une date de décommissionnement explicite de ce qu’elle remplace, sinon l’existant ne meurt jamais et le coût d’exploitation double ;
les dépendances entre lots se lisent sur la vue technologie avant d’être promises sur la vue métier ;
la durée de vie d’une transition est bornée : une « solution temporaire » dure en moyenne le temps qu’il faut à tout le monde pour oublier qu’elle était temporaire.

Ce dernier point rejoint directement la dette de sécurité : les architectures de transition qui s’éternisent en sont la première source, parce qu’elles cumulent deux surfaces d’attaque et rarement deux équipes pour les surveiller.

Gouvernance d’architecture : comité, contrats et dérogations

La gouvernance est la seule partie de TOGAF qui produit un effet sur les projets. Tout le reste produit des documents.

Les pièces :

Le comité d’architecture (Architecture Board) : instance mandatée qui valide les cibles, arbitre les conflits et accorde les dérogations.
Le contrat d’architecture : accord entre l’architecture et un projet sur ce qui sera livré, avec les points de revue.
La revue de conformité : vérification, à des jalons définis, que la réalisation respecte le contrat.
La dérogation (dispensation) : autorisation d’écart, motivée, limitée dans le temps.

Le flux de décision ci-dessous montre l’endroit où la gouvernance réussit ou échoue : la branche de dérogation.

Ce qui casse en vrai, toujours dans le même ordre : les dérogations sans date d’expiration, puis les dérogations sans propriétaire du risque, puis un registre où les dérogations dépassent en nombre les validations. À ce stade, le standard d’architecture est devenu une suggestion. Une dérogation doit porter un propriétaire du risque côté métier, pas côté architecture ; c’est ce qui la rend coûteuse à demander, donc rare.

Le second échec classique : un comité consultatif. Si le comité ne peut pas bloquer une mise en production, les projets apprennent vite à le saisir après la mise en production, « pour information ».

TOGAF s’articule avec les référentiels voisins sans les remplacer : COBIT 2019 fixe la gouvernance du SI au niveau de la direction et ses objectifs de contrôle, TOGAF dit comment concevoir l’architecture qui les sert, et ITIL (Information Technology Infrastructure Library) prend le relais pour exploiter ce qui a été construit : la page consacrée à la gestion des services numériques le détaille. La gestion du changement d’architecture (phase H) et la gestion des changements ITIL doivent partager le même référentiel de configuration, sinon chacune décrit un SI différent. The Open Group a d’ailleurs consacré un standard entier à ce fil de données, IT4IT, preuve que le problème est assez répandu pour mériter sa norme.

Prérequis, surface d’attaque et limites du dispositif

Prérequis avant le premier cycle. Un mandat écrit d’un sponsor de direction qui donne au comité un droit de refus ; un outil de modélisation qui gère versions et format d’échange ArchiMate ; un inventaire applicatif minimal raccordé à la CMDB ; des principes d’architecture rédigés (une dizaine, chacun avec sa justification et ses implications, pas une liste de vœux) ; des architectes disposant de temps réellement alloué. Une certification TOGAF des équipes n’est pas un prérequis : elle garantit la connaissance du vocabulaire, pas la capacité à arbitrer.

Surface d’attaque. Le référentiel d’architecture est une cartographie complète du SI : flux, dépendances, briques de sécurité, dérogations en cours. Le registre des dérogations, en particulier, est la liste exacte des faiblesses connues et acceptées. Les menaces sont donc concrètes :

exfiltration du référentiel : un compte compromis avec accès lecture fournit à un attaquant la reconnaissance qu’il mettrait des semaines à faire. Contre-mesures : classification du référentiel au niveau des données les plus sensibles qu’il décrit, accès nominatif via la fédération d’identités, journalisation des exports massifs, restriction du registre des dérogations à un cercle réduit ;
altération des modèles : une modification non tracée d’un flux ou d’une classification fausse les revues suivantes. Contre-mesures : versionnement, revue à deux pour les éléments de la vue sécurité, comparaison régulière avec la découverte réseau ;
dérive entre modèle et réalité : la plus fréquente, et sans attaquant. Un flux absent du modèle n’est couvert par aucune revue. Contre-mesure : réconciliation périodique automatisée entre référentiel, CMDB et journaux de flux, avec les écarts traités comme des non-conformités ;
contournement de la gouvernance : projets lancés hors du circuit, services cloud souscrits par carte bancaire. Contre-mesure : raccorder la gouvernance aux points de passage obligés (achats, ouverture de flux, création de comptes de service), là où le contournement devient visible.

Ce que TOGAF ne garantit pas. Il ne produit aucune analyse de risque (il en consomme une, venue d’EBIOS RM ou équivalent). Il ne garantit aucune conformité réglementaire : la directive NIS2 (directive (UE) 2022/2555) exige à son article 21 des mesures de gestion des risques, dont la gestion des actifs, et une cartographie TOGAF en fournit une base, pas la preuve. Le règlement DORA (règlement (UE) 2022/2554) impose un registre d’informations sur les accords avec les prestataires de services TIC (technologies de l’information et de la communication) ; la vue applications peut l’alimenter, elle ne le remplace pas (voir la page sur DORA). Enfin, il ne garantit pas que la réalisation correspond au modèle : seules les revues de conformité et la réconciliation automatisée le vérifient.

Conditions d’exploitation. Le référentiel se sauvegarde et se restaure comme un actif critique, avec un test de restauration du format d’échange vers un second outil (un référentiel prisonnier d’un éditeur de modélisation est une dépendance non cartographiée, ce qui est un comble). Les dérogations se réexaminent à échéance, sans prolongation tacite. Les principes d’architecture se révisent à chaque cycle préliminaire. Les indicateurs utiles se comptent sur une main : taux de projets passés en revue avant conception, nombre et âge des dérogations actives, taux d’écart entre modèle et découverte. La page sur les indicateurs de sécurité utiles explique pourquoi le nombre d’artefacts produits n’en fait pas partie.

Exemple : gouverner une migration d’annuaire vers la fédération d’identités

Cible décidée en phase A : toutes les applications métier s’authentifient via un fournisseur d’identités fédéré, avec authentification multifacteur, et l’annuaire historique cesse d’être interrogé directement par les applications. L’analyse d’écarts identifie trois familles : applications compatibles SAML (Security Assertion Markup Language) ou OIDC (OpenID Connect), applications à adapter, applications qui ne parlent que LDAP (Lightweight Directory Access Protocol) en liaison directe.

Ce qu’il faut lire dans ce flux : chaque transition est un état exploitable, avec une liste fermée de flux autorisés, et les exceptions vivent dans le registre avec une date de fin. La transition 1 n’améliore rien côté annuaire, c’est assumé ; elle réduit le nombre d’applications exposées aux liaisons en clair avant de s’attaquer au reste. Les mesures de durcissement des liaisons restantes pendant la transition sont décrites dans la page sur la désactivation du simple bind LDAP en clair. Le point de contrôle décisif est le réexamen en transition 2 : sans lui, les applications sous dérogation deviennent la cible définitive, et l’annuaire reste exposé indéfiniment.

Sources

TOGAF Standard, 10e édition, The Open Group.
ArchiMate 3.2 Specification, The Open Group.
ISO/IEC/IEEE 42010, ISO.
Directive (UE) 2022/2555 (NIS2), Union européenne.
Règlement (UE) 2022/2554 (DORA), Union européenne.
Règlement (UE) 2016/679 (RGPD), Union européenne.

🐝 Ce qui arrive si on s’en passe

Sans cible ni analyse d’écarts, chaque projet choisit ses briques transverses : on obtient plusieurs mécanismes d’authentification, plusieurs modèles de session et autant de chemins de contournement à surveiller. Sans architectures de transition bornées, l’ancien et le nouveau coexistent sans date de fin, et la surface d’attaque cumule les deux. Sans registre de dérogations daté, les faiblesses acceptées ne sont réexaminées par personne et finissent par constituer la norme de fait. Sans référentiel réconcilié avec la réalité, un flux non modélisé échappe à toute revue, à l’analyse de risque et à la détection ; en cas d’incident, l’équipe de réponse découvre les dépendances pendant la crise, au lieu de les lire dans un modèle.

🦫 Explication de la marmotte 🍫

TOGAF est une méthode pour organiser l’informatique d’une grande organisation sur plusieurs années. Tout commence par un accord écrit de la direction : sans lui, personne n’a le droit de dire non à un projet mal conçu. Ensuite, on décrit la situation actuelle sous quatre angles : ce que l’organisation fait (son métier), les informations qu’elle manipule, les logiciels qu’elle utilise, et les machines et réseaux qui les font tourner. On décrit ensuite la situation souhaitée sous les mêmes quatre angles. On compare les deux, élément par élément, pour savoir quoi garder, quoi supprimer, quoi ajouter. Comme on ne peut pas tout changer d’un coup, on découpe le chemin en étapes intermédiaires, chacune devant fonctionner correctement toute seule. Un comité vérifie ensuite que chaque projet respecte ce qui a été décidé. Quand un projet ne peut pas suivre la règle, le comité peut accepter l’exception, mais seulement avec un responsable nommé et une date de fin. Si ces dates sont oubliées, les exceptions s’accumulent et la règle ne vaut plus rien. Les plans eux-mêmes sont sensibles : ils montrent toutes les connexions et toutes les faiblesses acceptées, donc ils doivent être protégés, sauvegardés et comparés régulièrement avec ce qui tourne vraiment. TOGAF ne mesure pas les risques et ne prouve pas qu’on respecte la loi : d’autres méthodes s’en chargent, et TOGAF utilise leurs résultats.

Pages voisines

La citent

TOGAF et méthode ADM : architecture d'entreprise en pratique

Elle cite

: les deux pages se citent l’une l’autre.