80% des entreprises du Global 50 utilisent TOGAF. 100 000 professionnels certifiés dans le monde. Mais combien d'entre eux sont enlisés dans la sur-documentation ?
TOGAF (The Open Group Architecture Framework) est le framework d'architecture d'entreprise de référence. Son objectif : aligner l'IT avec la stratégie business à travers une architecture structurée et cohérente. Quand une organisation a 200 applications, 3 datacenters, 15 projets de transformation en cours et aucune vue d'ensemble, TOGAF est la réponse.
Le problème : TOGAF est puissant mais lourd. La tentation de documenter chaque couche, chaque composant, chaque dépendance crée un monstre bureaucratique qui produit des tonnes de livrables que personne ne lit. L'architecture devient une fin en soi, pas un outil de décision.
Ce guide explique ce qu'un DSI doit retenir de TOGAF, les pièges classiques, ce que TOGAF 10 change, comment il se compare aux alternatives, et surtout comment démarrer sans s'enliser.
TOGAF démystifié — ce qu'un DSI doit retenir
TOGAF est un framework qui structure la pratique de l'architecture d'entreprise. Pas l'architecture technique (ça, c'est le travail des architectes solutions). L'architecture d'entreprise — la discipline qui assure la cohérence entre stratégie business, processus métiers, systèmes d'information et infrastructure technique.
L'ADM : le cœur de TOGAF
Le cœur de TOGAF est l'ADM — Architecture Development Method. C'est un processus itératif (pas linéaire, contrairement à ce que beaucoup croient) composé de 10 phases :
- Préliminaire — Définir le cadre, les principes, les outils
- Phase A : Vision — Définir la portée et les objectifs de l'architecture
- Phase B : Architecture Business — Modéliser les processus et capacités métiers
- Phase C : Architecture des Systèmes d'Information — Données et applications
- Phase D : Architecture Technologique — Infrastructure et plateformes
- Phase E : Opportunités et Solutions — Identifier les projets de transformation
- Phase F : Planification de la Migration — Séquencer les transformations
- Phase G : Gouvernance de l'Implémentation — Superviser la mise en œuvre
- Phase H : Gestion du Changement — Gérer les évolutions continues
- Gestion des Exigences — Transverse à toutes les phases
A retenir
L'ADM est itératif par conception. Tu peux — et tu dois — revenir en arrière, sauter des phases non pertinentes, et adapter le cycle à ton contexte. L'erreur fatale : traiter ces phases comme un waterfall.
Les 4 domaines d'architecture
TOGAF structure l'architecture d'entreprise en 4 domaines :
- Architecture Business — Les processus métiers, les capacités organisationnelles, la stratégie
- Architecture des Données — Le modèle de données, les flux d'information, la gouvernance des données
- Architecture des Applications — Le portefeuille applicatif, les interactions entre systèmes
- Architecture Technologique — L'infrastructure, les plateformes, le réseau, la sécurité
Ces 4 domaines doivent être alignés. Un changement dans l'architecture business (nouveau processus métier) impacte l'architecture des applications (nouveau système ou modification d'un existant), qui impacte l'architecture technologique (nouvelle infrastructure). TOGAF fournit le cadre pour gérer ces impacts en cascade.
TOGAF 10 — la version actuelle
TOGAF 10, publié en 2022, représente une modernisation significative. La structure est devenue modulaire : un noyau stable (TOGAF Fundamental Content) complété par des guides thématiques que tu actives selon tes besoins. Cloud, microservices, IA, IoT, sécurité Zero Trust — tout est couvert via des modules complémentaires.
C'est un changement important : tu n'es plus obligé d'avaler TOGAF en entier. Tu prends le noyau et les modules pertinents pour ton contexte.
L'Architecture Repository — la mémoire de ta DSI
L'Architecture Repository est l'asset stratégique que la plupart des implémentations TOGAF négligent. C'est le référentiel centralisé de toutes les décisions architecturales, modèles, standards et composants.
La structure du Repository comprend 6 éléments :
- Architecture Metamodel — Le modèle qui décrit comment décrire ton architecture
- Architecture Capability — Les compétences, processus et outils de ton équipe d'architecture
- Architecture Landscape — L'état actuel, les états cibles, et les architectures de transition
- Standards Information Base — Les standards technologiques autorisés, en évaluation, ou obsolètes
- Reference Library — Les patterns, templates et architectures de référence réutilisables
- Governance Log — L'historique des décisions architecturales, des dérogations et de leurs justifications
Sans Repository, les décisions se perdent
Le nouvel architecte qui arrive 6 mois plus tard ne sait pas pourquoi on a choisi Kafka plutôt que RabbitMQ, pourquoi on a 3 bases de données différentes, ou pourquoi le module de paiement est isolé sur un serveur dédié.
Le Repository n'est pas un logiciel spécifique. C'est un concept que chaque organisation implémente différemment : un wiki Confluence bien structuré, un outil EA dédié (LeanIX, Mega, Ardoq, BiZZdesign), ou même un repository Git avec des ADR (Architecture Decision Records). L'important, c'est que le Repository soit vivant, mis à jour, et consulté — pas un document mort sur un SharePoint.
Les chiffres d'adoption
TOGAF n'est pas un framework de niche. C'est le standard de facto de l'architecture d'entreprise.
Adoption : 80% du Global 50 et 60% du Fortune 500 utilisent TOGAF sous une forme ou une autre. Ce n'est pas toujours une adoption complète — beaucoup d'organisations utilisent des éléments de TOGAF (l'ADM, la classification en 4 domaines) sans implémenter le framework intégralement. Et c'est très bien.
Certifications : Plus de 100 000 professionnels certifiés dans le monde. La certification TOGAF Foundation coûte environ 500$ et prend 4-5 jours de formation. La certification Practitioner, plus avancée, ajoute 3-4 jours.
ROI typique : Le retour sur investissement vient principalement de deux sources. La première : la rationalisation du portefeuille applicatif. Une cartographie ADM rigoureuse révèle les redondances — 3 CRM différents, 5 outils de reporting, 2 systèmes de facturation. Supprimer ces doublons génère des économies opérationnelles significatives.
La deuxième source : la réduction des erreurs architecturales. Un projet de transformation sans architecture d'ensemble risque de créer des incompatibilités, des dépendances cachées, ou des choix technologiques qui devront être refaits 2 ans plus tard.
Dairy Farm Group — rationalisation à grande échelle
Ce géant du retail asiatique (plus de 10 000 magasins) a utilisé l'ADM pour cartographier un portefeuille de 230+ applications. La cartographie a révélé que 40% des applications étaient redondantes ou sous-utilisées. Le programme de rationalisation qui a suivi a généré des économies significatives en licences, maintenance et support — tout en simplifiant l'infrastructure.
Westpac Bank — l'architecture comme levier stratégique
La banque australienne a utilisé TOGAF pour structurer sa transformation digitale. Résultat : 95% de confiance des parties prenantes dans la capacité de l'architecture à soutenir la croissance. L'architecture d'entreprise est passée d'un centre de coûts à un partenaire stratégique reconnu par le business.
Le marché des outils EA : Gartner cite LeanIX (racheté par SAP en 2023), Mega, Ardoq et BiZZdesign comme les leaders. Le marché est en croissance parce que les DSI réalisent qu'un Repository architectural en Confluence ne tient pas l'échelle quand on dépasse 100 applications.
Le coût d'un programme EA : Pour une ETI, compte entre 200 000$ et 2M$ (outillage + formation + 1-2 consultants EA sur 12-18 mois). Le ROI typique est atteint en 18-24 mois via la rationalisation du portefeuille applicatif. L'erreur classique : investir dans l'outil EA avant d'avoir les compétences pour l'utiliser.
Les 5 pièges classiques de TOGAF
TOGAF est un framework puissant. Mais cette puissance le rend dangereux quand il est mal utilisé.
Piège 1 : La paralysie par sur-documentation
C'est le piège numéro un. L'ADM produit des artefacts à chaque phase : visions, diagrammes, matrices de dépendances, catalogues de composants, documents de gouvernance. Si tu les produis tous pour chaque phase, tu génères des centaines de pages que personne ne lira.
Le signal d'alerte
Tes architectes passent 80% de leur temps à documenter et 20% à décider. Le ratio devrait être inversé.
La solution : applique le principe de « minimum viable architecture ». Documente juste assez pour prendre des décisions éclairées, pas plus. Un diagramme clair vaut mieux que 50 pages de texte.
En pratique, limite tes artefacts à ce qui est actionnable : un diagramme d'architecture cible par domaine, une liste de principes architecturaux, un catalogue des applications avec leur criticité. Si un document n'influence aucune décision dans les 3 prochains mois, ne le produis pas.
Piège 2 : L'approche Waterfall
L'ADM a 10 phases numérotées de A à H. La tentation est forte de les suivre séquentiellement : on fait la Phase A, puis la B, puis la C, etc. Pendant 18 mois. Et à la fin, l'architecture est obsolète parce que le business a changé.
L'ADM est itératif par conception. Tu peux faire un cycle complet en 3 mois pour une architecture de haut niveau, puis approfondir chaque domaine dans des cycles spécialisés. Tu peux sauter la Phase B si l'architecture business est stable. Tu peux revenir de la Phase D à la Phase B si une contrainte technique invalide un choix business.
Piège 3 : L'exercice purement technique
TOGAF commence par l'architecture business (Phase B) avant l'architecture technique (Phase D). Ce n'est pas un hasard. L'architecture d'entreprise part du business, pas de la technologie.
Pourtant, beaucoup d'implémentations de TOGAF sont menées par les architectes techniques, sans implication des dirigeants métiers. Le résultat : une architecture techniquement cohérente mais déconnectée de la réalité business. Un château en l'air parfaitement documenté.
Règle d'or
Pas d'architecture sans sponsor business. Si le directeur métier ne participe pas à la Phase B, ne passe pas à la Phase C.
Piège 4 : Appliquer le framework « by the book »
TOGAF est un framework de 1 000+ pages. Il couvre tous les cas possibles. Mais ton organisation n'a pas tous les cas possibles. Appliquer TOGAF intégralement à une ETI de 500 personnes, c'est comme utiliser un marteau-piqueur pour planter un clou.
The Open Group le dit lui-même : TOGAF est conçu pour être adapté. Tu prends ce qui est pertinent, tu laisses le reste. Une ETI n'a probablement pas besoin du Repository d'entreprise complet ni de la gouvernance multi-niveaux. Un ADM simplifié avec les 4 domaines d'architecture suffit largement.
Piège 5 : Gouvernance sur le papier
Tu as défini des principes architecturaux. Tu as un comité d'architecture qui se réunit mensuellement. Les règles sont documentées. Mais quand un projet dévie de l'architecture cible, personne ne fait rien. Les exceptions deviennent la norme. L'architecture existe sur le papier, pas dans la réalité.
Un comité sans pouvoir est un comité de lecture
La gouvernance architecturale ne fonctionne que si elle a des dents. Définis des mécanismes concrets : revue obligatoire avant le lancement d'un projet, critères de conformité mesurables, escalade claire en cas de dérogation.
Le Governance Log du Repository Architecture est l'outil pour ça : chaque dérogation est documentée avec sa justification, son sponsor, et sa date d'expiration. Sans ce log, les dérogations « temporaires » deviennent permanentes et l'architecture cible reste un rêve sur PowerPoint.
TOGAF 10 — la modernisation qui change la donne
TOGAF 10, publié en 2022, n'est pas une simple mise à jour. C'est une réponse aux critiques de la version 9.2 et aux évolutions technologiques de la dernière décennie.
Structure modulaire
Le changement le plus fondamental : TOGAF 10 est modulaire. Le framework est divisé en un noyau stable (TOGAF Fundamental Content) et des guides complémentaires (TOGAF Series Guides) couvrant des sujets spécifiques.
Concrètement, ça signifie que tu peux adopter le noyau de TOGAF (ADM, 4 domaines, principes de gouvernance) sans te préoccuper des guides avancés. Et quand tu en as besoin — architecture cloud, architecture de données, architecture de sécurité — tu ajoutes le guide correspondant.
Architectures modernes couvertes nativement
TOGAF 9.2 peinait à adresser les architectures cloud-native, les microservices et l'IoT. TOGAF 10 intègre ces architectures dès la conception :
- Cloud et multi-cloud — Modèles de référence pour les architectures cloud hybrides
- Microservices — Patterns d'architecture applicative distribuée
- IA et Machine Learning — Considérations architecturales pour les systèmes d'IA
- IoT — Architecture pour les systèmes connectés et l'edge computing
Les TOGAF Series Guides — le modèle à la carte
TOGAF 10 introduit les Series Guides — des guides thématiques spécialisés que tu actives selon tes besoins :
- Business Architecture Guide — Comment aligner l'architecture sur les capacités métiers et les flux de valeur
- Information Architecture Guide — Architecture de données, gouvernance, qualité, flux d'information
- Security Architecture Guide — Sécurité by design, Zero Trust, conformité RGPD/NIS2
- Agile Architecture Guide — Comment pratiquer l'EA dans un contexte Agile/DevOps
- Digital Practitioner's Guide (DPB) — Le pont entre TOGAF et les équipes DevOps/Agile
Le Digital Practitioner's Guide
Particulièrement intéressant pour les DSI modernes. Conçu pour les architectes qui travaillent avec des équipes produit, pas dans une tour d'ivoire. Il traduit les concepts TOGAF en pratiques compatibles avec les cycles courts de livraison.
Un autre guide essentiel : l'Architecture Principles Catalog. Comment formaliser 5 à 10 principes architecturaux actionnables — pas 50 principes théoriques. Exemples de bons principes : « Cloud-first pour tout nouveau service », « Les données clients ne quittent jamais l'UE », « Pas de couplage fort entre services ». Des principes testables, pas des vœux pieux.
Intégration Agile/DevOps
TOGAF 10 reconnaît que l'architecture d'entreprise doit coexister avec les pratiques Agile et DevOps. L'ADM peut être exécuté en sprints : des cycles courts de 2-4 semaines qui produisent des décisions architecturales incrémentales au lieu de documents monumentaux.
C'est l'architecture continue : au lieu d'un big bang architectural tous les 3 ans, des ajustements permanents alignés sur le rythme de livraison des équipes de développement.
Sécurité Zero Trust
TOGAF 10 intègre les principes de sécurité Zero Trust dans l'architecture d'entreprise dès la Phase D. Ce n'est plus un ajout après coup — la sécurité est une contrainte architecturale native, pas une couche qu'on superpose à la fin.
TOGAF vs les alternatives
TOGAF n'est pas le seul framework d'architecture d'entreprise. Voici comment il se compare.
| Critère | TOGAF | Zachman | FEAF/DoDAF |
|---|---|---|---|
| Nature | Méthodologie actionnable (ADM) | Ontologie / taxonomie (matrice 6x6) | Frameworks sectoriels (gouv. US / défense) |
| Approche | Processus itératif avec livrables | Classification des artefacts | Prescriptif et spécifique au contexte |
| Cible | Toute organisation | Complémentaire à TOGAF | Secteur public US / défense |
| Adoption | 80% du Global 50 | Niche académique | Obligatoire dans leur secteur |
TOGAF et ArchiMate — le couple méthodologie + langage
ArchiMate n'est pas un concurrent de TOGAF — c'est son complément naturel. TOGAF est la méthodologie (quoi faire, dans quel ordre). ArchiMate est le langage de modélisation (comment représenter visuellement l'architecture).
ArchiMate 3.2 (2023) est aligné avec TOGAF 10 et couvre les 4 domaines d'architecture avec une notation visuelle standardisée. Au lieu de diagrammes PowerPoint que chaque architecte dessine à sa façon, ArchiMate fournit un vocabulaire visuel commun.
La plupart des outils EA (LeanIX, Mega, BiZZdesign, Ardoq) supportent ArchiMate nativement. Si tu investis dans un outil EA, la compatibilité ArchiMate est un critère de sélection non négociable — sinon tu te retrouves enfermé dans un format propriétaire.
Quand TOGAF est justifié
TOGAF est justifié quand la complexité du SI dépasse la capacité de coordination informelle :
- Organisation de 500+ personnes avec un SI complexe — la coordination informelle ne tient plus quand 15 équipes modifient 200 applications en parallèle
- Transformation digitale d'envergure (migration cloud, refonte applicative) — sans architecture cible, chaque équipe migre dans sa direction
- Portefeuille de 100+ applications avec des redondances visibles — la cartographie ADM est le seul moyen de voir l'ensemble
- Multi-cloud ou architecture hybride — la cohérence entre AWS, Azure, on-premise et SaaS ne s'improvise pas
- Exigences réglementaires fortes (banque, assurance, santé) — les régulateurs demandent une vue d'ensemble documentée
- Plusieurs projets de transformation en parallèle — TOGAF assure la cohérence entre des projets qui s'ignorent mutuellement
Le signal le plus clair
Quand deux projets découvrent tardivement qu'ils ont des dépendances architecturales non identifiées et que le retard coûte des centaines de milliers d'euros. C'est exactement ce que TOGAF prévient.
Quand TOGAF est overkill
- PME avec un SI simple (10-20 applications standard SaaS) — un simple diagramme d'architecture sur un whiteboard suffit
- Stack technique homogène sans dette technique significative — pas besoin de 4 domaines d'architecture
- Startup en phase de croissance — l'agilité prime sur l'architecture formelle. Quand tu pivotes tous les 3 mois, un ADM de 6 mois est un frein
- Équipe IT de moins de 30 personnes — la coordination informelle fonctionne encore
Le test
Si tu peux dessiner l'intégralité de ton SI sur un tableau blanc en 30 minutes et que tout le monde est d'accord, tu n'as pas besoin de TOGAF. Si tu ne peux pas, tu en as besoin.
Comment démarrer avec TOGAF sans s'enliser
Tu es convaincu que TOGAF est pertinent pour ta DSI. Voici comment démarrer sans tomber dans les pièges.
Étape 1 : Commencer par l'architecture business
Résiste à la tentation de commencer par la technologie. La Phase B (Architecture Business) est la fondation. Sans compréhension claire des processus métiers, des capacités organisationnelles et des objectifs stratégiques, l'architecture technique est un exercice dans le vide.
Implique les directeurs métiers dès cette phase. Pose la question : quels sont les 5 processus métiers les plus critiques ? Quelles sont les capacités qui manquent ? Quels sont les objectifs à 3 ans ? Les réponses guideront toute l'architecture.
Étape 2 : Adapter l'ADM à ton contexte
Ne fais pas les 10 phases complètes. Identifie les phases pertinentes pour ton premier cycle :
- Vision (Phase A) — Toujours nécessaire. Définit la portée et les objectifs.
- Architecture Business (Phase B) — Nécessaire si tu n'as pas de cartographie métier claire.
- Architecture des Applications (Phase C) — Nécessaire si tu as un problème de portefeuille applicatif.
- Architecture Technologique (Phase D) — Nécessaire si tu planifies une migration cloud ou une refonte d'infrastructure.
Les autres phases (E, F, G, H) viennent après, quand tu as une base solide. Ne les force pas dans le premier cycle.
Étape 3 : Livrer des quick wins
L'architecture d'entreprise a un problème de perception : elle est vue comme un investissement long-terme sans retour immédiat. Corrige cette perception en livrant des quick wins architecturaux dans les 3 premiers mois.
Exemples de quick wins
Identifier et proposer la suppression de 5 applications redondantes. Produire une cartographie des flux de données critiques. Définir 3 principes architecturaux qui simplifient les décisions futures. Ces quick wins créent de la crédibilité et justifient l'investissement continu.
Étape 4 : La certification comme investissement ciblé
La certification TOGAF Foundation (~500$, 4-5 jours) donne une compréhension solide du framework. Suffisante pour un DSI ou un responsable IT qui veut comprendre les concepts.
La certification Practitioner (~800$, 3-4 jours supplémentaires) est destinée aux architectes d'entreprise qui vont implémenter le framework au quotidien.
Ne certifie pas 50 personnes. Certifie 2-3 architectes clés, et laisse-les diffuser les connaissances en interne.
Étape 5 : Le calendrier et le budget réalistes
Pour une ETI, voici la trajectoire réaliste :
- Mois 1-2 : Formation TOGAF Foundation pour 2-3 architectes clés (~500$/personne). Mise en place d'un Repository Architecture léger.
- Mois 2-3 : Cartographie rapide du portefeuille applicatif. Phase A (Vision) et Phase C simplifiée (Applications).
- Mois 3-4 : Identification des quick wins : 5 à 10 applications candidates à la suppression ou la consolidation.
- Mois 4-6 : Premier cycle ADM complet mais léger. Production des premiers principes architecturaux et du premier Architecture Landscape.
Budget réaliste pour une ETI : 50 000 à 150 000$ (formation + outil EA léger + 1 consultant EA senior à mi-temps pendant 6 mois). Le gros du budget est le consultant — et c'est de l'argent bien dépensé si le consultant transfère ses compétences à l'équipe interne.
Budget pour un grand groupe : 200 000$ à 1M+ (formation étendue + outil EA dédié type LeanIX ou Mega + équipe EA dédiée de 2-3 architectes). Le ROI vient de la rationalisation : supprimer 30 applications redondantes peut économiser 500 000$ à 2M$ par an en licences et maintenance.
Ce qu'il faut retenir
TOGAF est le framework d'architecture d'entreprise de référence — 80% du Global 50, 100 000+ certifiés, et TOGAF 10 l'a modernisé avec une structure modulaire, des Series Guides à la carte, et une intégration native des architectures cloud, microservices et IA.
Mais c'est un outil puissant qui peut facilement devenir un monstre bureaucratique si tu ne l'adaptes pas. Les 5 pièges à éviter : sur-documentation, approche waterfall, exercice purement technique, application « by the book », et gouvernance sur le papier.
A retenir
L'Architecture Repository est l'asset stratégique que la plupart des organisations négligent. ArchiMate fournit le langage visuel commun. Les outils EA fournissent la plateforme. Mais l'outil sans la compétence est de l'argent perdu.
La clé : commencer par l'architecture business, adapter l'ADM à ton contexte, livrer des quick wins, investir dans le Repository, et surtout ne pas oublier que l'architecture est un moyen — pas une fin. Le but n'est pas de produire des diagrammes parfaits. Le but est de prendre de meilleures décisions, plus vite.