Ce qu'il faut comprendre avant de commencer
TOGAF n'est pas une procédure à suivre pas à pas. C'est une boîte à outils. Un architecte TOGAF expérimenté le traite comme un manuel de référence : il y pioche les techniques utiles selon le contexte, adapte l'ADM à la maturité de l'organisation, et ne cherche pas à tout produire d'un coup. Un cycle ADM complet peut durer entre six mois et deux ans. Rien n'oblige à le parcourir en entier pour un projet limité : les phases B, C et D peuvent parfaitement s'itérer indépendamment, sur un périmètre réduit.
L'ADM est aussi fondamentalement itératif. À chaque cycle, l'organisation alimente un Architecture Repository — un référentiel de décisions, de modèles réutilisables et de principes — qui rend les cycles suivants plus rapides. Le premier cycle est toujours le plus long et le plus difficile, précisément parce que ce référentiel est vide. TOGAF 10 renforce cette dimension en distinguant clairement le contenu fondamental stable (les concepts pérennes) des Guides de la Série TOGAF, guides pratiques adaptés à des contextes précis : transformation digitale, agilité, sécurité, microservices, etc.
Dernier point important : la gestion des exigences n'est pas une phase comme les autres. Elle est représentée au centre du diagramme ADM pour une bonne raison — elle traverse et alimente toutes les phases du cycle. Ignorer ce rôle transversal est l'une des erreurs les plus fréquentes.
Cycle ADM — Architecture Development Method
TOGAF 10 · Survoler une phase pour afficher ses détails
Phase préliminaire – Poser les fondations
Avant même de définir une vision, TOGAF demande de s'assurer que l'organisation est prête à mener une démarche d'architecture. Cette phase préliminaire établit le cadre dans lequel tout le reste va opérer. En pratique, elle répond à trois questions : qui prend les décisions d'architecture, selon quels principes, et dans quel périmètre ?
L'identification et l'engagement des parties prenantes est ici critique. Pas uniquement les directeurs IT, mais aussi les directions métier, les utilisateurs finaux, les équipes projets. TOGAF recommande de cartographier leurs intérêts, leurs résistances potentielles, et le niveau d'implication souhaité pour chacun. La carte des parties prenantes produite ici sera réutilisée tout au long du cycle.
Les principes d'architecture — sécurité, interopérabilité, maîtrise des coûts, conformité réglementaire — sont définis à cette étape. Ils servent de critères de décision dans toutes les phases suivantes. Un principe mal formulé ou non partagé génère des incohérences à chaque carrefour du cycle. En TOGAF 10, cette phase est aussi le moment d'identifier quels Guides de la Série sont pertinents pour le contexte de l'organisation.
Livrable central : le plan de gouvernance d'architecture, qui définit comment les décisions architecturales seront prises, par qui, et comment les livrables seront validés. C'est ce plan qui transforme l'architecture d'entreprise d'une discipline artisanale en une capacité organisationnelle durable.
Piège fréquent : bâcler cette phase pour « aller vite à la vraie architecture ». C'est exactement l'inverse qui se passe — les projets qui court-circuitent la phase préliminaire passent leur temps à négocier après coup des décisions qui auraient dû être posées dès le départ.
Phase A – Vision de l'architecture
La phase A définit pourquoi ce cycle ADM existe. Elle traduit les objectifs stratégiques de l'organisation en une vision architecturale : une représentation de haut niveau de l'état cible, assez précise pour mobiliser les parties prenantes, assez abstraite pour rester stable pendant le cycle.
Le travail concret consiste à organiser des ateliers avec les parties prenantes identifiées en phase préliminaire, à recueillir et prioriser leurs exigences, et à identifier le périmètre exact du cycle — quels domaines d'activité, quels systèmes, quelle temporalité. TOGAF recommande la technique des business scenarios : partir de situations concrètes que l'architecture doit permettre, pour en déduire les capacités nécessaires. C'est bien plus efficace qu'une liste d'exigences abstraites.
Le document de vision de l'architecture est le livrable principal. Il décrit l'état cible, les bénéfices attendus, les contraintes identifiées (légales, réglementaires, contractuelles), et les indicateurs de succès. Le registre des exigences, premier artefact du processus de gestion des exigences, est initialisé ici.
Ce que ça change en pratique : la phase A sert aussi à obtenir un mandat formel. Sans ce mandat — une décision explicite de la direction sur le périmètre et les objectifs du cycle —, l'architecte travaille sans filet. Chaque choix difficile, chaque arbitrage entre la dette technique et les nouvelles capacités, se retrouvera contesté faute d'une orientation claire.
Phase B – Architecture métier
La phase B modélise comment l'organisation fonctionne : ses processus, ses capacités, ses acteurs, ses flux d'information. C'est ici que l'architecte descend dans le métier — souvent le domaine qui lui est le moins familier. TOGAF recommande le BPMN (Business Process Model and Notation) pour la représentation standardisée des processus, mais la notation importe moins que la rigueur de l'analyse.
Le travail central est l'analyse des écarts (gap analysis) entre l'état actuel (AS-IS) et l'état futur défini en phase A (TO-BE). Pour chaque capacité ou processus, l'architecte détermine si l'état actuel est conforme à la cible, s'il faut le modifier, le créer, ou le supprimer. Cette technique d'analyse des écarts, l'une des plus utilisées en pratique, produit une vue claire de ce qui doit changer et de son impact.
En phase B, l'architecte établit aussi les liens explicites entre les processus métier et les systèmes d'information. Ce pont entre le métier et l'IT est ce que TOGAF appelle l'alignement — et c'est là que se gagnent ou se perdent la crédibilité et l'utilité de la démarche. Un modèle BPMN déconnecté des applications réelles ne sert à rien.
Piège fréquent : produire des modèles de processus trop détaillés, trop tôt. En phase B, le niveau de granularité utile est celui qui permet de comprendre les capacités et les décisions, pas celui d'un manuel opérateur. Le détail viendra lors de l'implémentation.
Phase C – Architecture des systèmes d'information
La phase C traite deux volets complémentaires : l'architecture des données et l'architecture des applications. En pratique, ces deux volets s'informent mutuellement et s'itèrent souvent en parallèle.
Sur le volet données, il s'agit de cartographier les structures de données existantes — schémas, bases de données, entrepôts, flux — et de définir comment elles doivent évoluer pour répondre aux objectifs métier. Les modèles de données produits vont du niveau conceptuel (entités et relations) au niveau logique (structures de données indépendantes de la technologie). Les catalogues de données documentent la gouvernance et les règles de confidentialité, point qu'un architecte sensible aux enjeux réglementaires (RGPD, secteurs régulés) ne peut pas ignorer.
Sur le volet applications, la cartographie applicative recense les applications existantes, leurs fonctions, leurs utilisateurs et leurs interdépendances. La matrice d'interopérabilité est le livrable clé : elle montre qui échange quoi avec qui, selon quels protocoles et formats. C'est souvent sur ce travail de cartographie que l'architecte révèle des doublons fonctionnels, des silos de données, ou des dépendances critiques non documentées.
Ce que ça change en pratique : la phase C est souvent celle où les directions métier et IT se retrouvent pour la première fois à parler du même objet — les données — avec des visions différentes. L'architecte joue ici un rôle de traducteur et de médiateur, pas seulement de modélisateur.
Phase D – Architecture technique
La phase D définit l'infrastructure technologique nécessaire pour supporter les architectures métier, données et applications définies dans les phases précédentes. C'est le territoire des réseaux, serveurs, plateformes cloud, middlewares, protocoles de sécurité.
TOGAF insiste sur un principe souvent négligé : la technologie doit être choisie en réponse aux besoins des phases B et C, jamais l'inverse. En pratique, les équipes techniques ont souvent des préférences technologiques préexistantes — un cloud provider, un stack applicatif — que l'architecte doit évaluer objectivement par rapport aux exigences de performance, scalabilité, résilience, interopérabilité et sécurité identifiées en amont.
Le document des normes technologiques est le livrable structurant de cette phase. Il définit les standards retenus — hardware, software, protocoles de communication, standards de sécurité — et crée un référentiel technique qui s'appliquera à tous les projets d'implémentation. Un standard bien défini ici évite des décisions incohérentes prises projet par projet.
Lien avec l'article sur les architectures noyau Windows et Linux : le choix de l'infrastructure en phase D dépend directement des contraintes de sécurité, de performance et de gestion que ces architectures imposent au niveau système.
Phase E – Opportunités et solutions
Les phases A à D produisent une connaissance. La phase E commence à construire un plan. Elle identifie les projets et initiatives spécifiques qui permettront de combler les écarts identifiés et de réaliser la vision architecturale, puis les organise en une feuille de route cohérente.
Ce travail d'identification et de priorisation est plus politique que technique. Chaque projet a des sponsors, des contraintes budgétaires, des dépendances avec d'autres initiatives. L'architecte ne décide pas seul — il travaille avec les parties prenantes pour évaluer les options (make/buy/outsource, refonte vs. migration progressive), analyser leur faisabilité, et intégrer les contraintes réelles de l'organisation.
La feuille de route d'architecture (Architecture Roadmap) est le livrable central de cette phase. Elle montre, dans le temps, comment les différents projets s'enchaînent, quelles dépendances les lient, et comment ils contribuent collectivement à l'évolution de l'architecture d'entreprise. Un diagramme de Gantt enrichi d'une dimension architecturale — quelle capacité est activée par quel projet, à quel horizon.
Ce que ça change en pratique : la phase E est souvent vécue comme le moment de vérité. La vision était abstraite ; les projets et leur coût sont concrets. Les arbitrages qui semblaient évidents en phase A deviennent douloureux en phase E. L'architecte doit être capable de défendre ses choix avec des données, pas des intuitions.
Phase F – Planification de la migration
La phase F transforme la feuille de route de la phase E en plan d'implémentation détaillé. Elle répond à des questions concrètes : dans quel ordre migrer les systèmes existants ? Quelle infrastructure déployer en premier ? Comment former les équipes ? Quels sont les risques de chaque étape et comment les mitiger ?
La gestion des ressources est centrale ici : ressources humaines (compétences disponibles, formations nécessaires), ressources financières (phasage budgétaire), ressources techniques (capacité de l'infrastructure à absorber une migration). La tentation est de planifier dans un monde idéal — la réalité de la migration impose des contraintes que seule une analyse de risque sérieuse permet d'anticiper.
TOGAF insiste sur la gestion du changement organisationnel, souvent sous-estimée dans les projets d'architecture. Une migration technique réussie qui échoue à l'adoption métier n'est pas un succès. Le plan de migration doit inclure une stratégie de communication, de formation et d'accompagnement au changement pour chaque groupe d'utilisateurs concerné.
Livrable clé : le calendrier de mise en œuvre, souvent sous forme de diagramme de Gantt, avec jalons, dépendances et échéances. Ce document n'appartient pas à l'équipe architecture seule — il est partagé et validé avec les équipes projet, les directions métier et la direction IT.
Phase G – Gouvernance de l'implémentation
Quand les projets d'implémentation démarrent, l'architecte ne disparaît pas. La phase G assure que les projets respectent les principes et standards d'architecture définis en amont. C'est la fonction de conformité architecturale — distincte de la gestion de projet, qu'elle ne remplace pas.
Concrètement, l'architecte conduit des revues de conformité régulières : les solutions déployées respectent-elles les normes technologiques de la phase D ? Les interfaces respectent-elles les protocoles définis en phase C ? Les processus implémentés correspondent-ils aux modèles de la phase B ? Ces revues produisent des rapports de conformité qui documentent les écarts constatés et les décisions prises.
La gestion des demandes de changement est l'autre activité centrale de la phase G. Tout projet génère des évolutions par rapport aux plans initiaux. L'architecte évalue l'impact de chaque changement sur l'architecture globale avant de l'approuver, le modifier ou le rejeter. Ce processus de contrôle du changement — formalisé par des contrats d'architecture (Architecture Contracts) entre l'équipe architecture et les équipes projet — est l'un des mécanismes de gouvernance les plus concrets de TOGAF.
Piège fréquent : transformer la phase G en bureaucratie de validation qui ralentit les projets sans apporter de valeur. La gouvernance doit être proportionnée aux risques. Une déviation mineure sur un système secondaire n'a pas le même poids qu'un choix technologique sur un système cœur de métier.
Phase H – Gestion du changement d'architecture
La phase H ferme la boucle et la rouvre. Elle surveille l'architecture en production, identifie ce qui doit évoluer face aux changements internes et externes — nouvelles technologies, évolutions réglementaires, transformations organisationnelles — et décide s'il faut initier un nouveau cycle ADM ou simplement mettre à jour l'architecture courante.
Cette distinction — mise à jour incrémentale versus nouveau cycle — est l'une des décisions clés de la phase H. TOGAF ne définit pas de critères universels, parce que le seuil de tolérance au changement dépend de chaque organisation. Ce qui compte, c'est d'avoir défini ces critères à l'avance, en phase préliminaire, plutôt que de les improviser sous pression.
Les rapports de maintenance documentent l'état de l'architecture, les composants vieillissants, les dettes techniques accumulées. Les documents de révision formalisent chaque modification significative avec sa justification et son analyse d'impact. C'est à travers ces documents que l'Architecture Repository s'enrichit au fil des cycles.
La phase H, bien menée, transforme TOGAF d'un projet ponctuel en une capacité organisationnelle continue. C'est elle qui justifie l'investissement initial dans la démarche.
La gestion des exigences – Le fil rouge transversal
La gestion des exigences n'est pas une phase du cycle ADM — elle en est le centre de gravité. Représentée au cœur du diagramme circulaire, elle alimente et reçoit des informations de toutes les phases simultanément.
Son fonctionnement est simple en théorie : recueillir les exigences des parties prenantes, les classifier (fonctionnelles, non fonctionnelles, contraintes), les valider, les prioriser et les suivre tout au long du cycle. En pratique, les exigences évoluent, se contredisent, se précisent. Le registre des exigences — le livrable central de ce processus — est un document vivant que l'architecte maintient à jour et utilise comme outil de décision permanent.
Un registre bien tenu permet de répondre à une question que les parties prenantes posent souvent : « Pourquoi a-t-on fait ce choix ? » La traçabilité entre une décision architecturale et les exigences qui la justifient est la mémoire institutionnelle de la démarche. Sans elle, chaque nouveau projet recommence de zéro.
Utiliser TOGAF sans se noyer dedans
TOGAF est souvent critiqué pour sa complexité et son volume (le standard dépasse 500 pages dans certaines éditions). La critique est juste si on le lit comme une procédure. Elle devient infondée si on le lit comme un catalogue de bonnes pratiques à activer selon le contexte.
Un architecte expérimenté utilise rarement toutes les phases dans l'ordre. Pour un projet d'architecture de solution, il se concentre sur les phases B, C et D. Pour une mission de gouvernance, il travaille principalement en G et H. Pour une transformation majeure, il parcourt le cycle complet — mais en deux ou trois itérations progressives plutôt qu'en un cycle monolithique.
TOGAF 10 accentue cette orientation pragmatique. La séparation entre le contenu fondamental pérenne et les guides pratiques contextuels permet à chaque organisation d'adopter le niveau de formalisme adapté à sa maturité. Une PME peut très bien utiliser la technique d'analyse des écarts et les principes d'architecture sans mettre en place un comité d'architecture formel. Une grande entreprise en transformation digitale aura besoin de tout l'outillage de gouvernance.
Ce qui ne change pas, quelle que soit l'échelle : la discipline de remonter systématiquement aux problèmes d'origine avant de proposer des solutions, l'engagement des parties prenantes dès le départ, et la rigueur documentaire qui permet à la démarche de survivre aux rotations d'équipes. Ce sont ces invariants qui font la valeur réelle de TOGAF — bien plus que la liste de ses phases.
Références
- The Open Group, TOGAF Standard, 10th Edition, 2022 — opengroup.org/togaf
- The Open Group, TOGAF ADM — Architecture Development Method — pubs.opengroup.org
- The Open Group, TOGAF Series Guides — opengroup.org/togaf-series-guides
- Projexion, Méthode TOGAF en pratique : retour d'expérience, 2025 — projexion.com
- Conexiam, TOGAF ADM Phases Explained, 2025 — conexiam.com
- Avolution, How to Master Enterprise Architecture Using TOGAF 10, 2024 — avolutionsoftware.com
- QualiWare, Most common pitfalls in TOGAF — coe.qualiware.com
- Stéphane Fosse, Architecture noyau Windows et Linux, 2026 — fosse.fr
- Stéphane Fosse, ArchiMate en pratique, 2026 — fosse.fr