TOGAF® 10 en pratique : structurer et rationaliser un SI complexe à l'international

Quand on intervient comme architecte d'entreprise dans un grand groupe, la première réalité qui frappe est la complexité du système d'information existant. Des centaines d'applications, des flux croisés entre filiales, des technologies hétérogènes accumulées sur trois décennies de fusions et de projets tactiques. Personne n'a de vue d'ensemble, et chaque décision d'investissement se prend dans le brouillard. C'est exactement dans ces contextes que TOGAF® 10 prend tout son sens — non pas comme un cadre théorique à réciter, mais comme une boîte à outils pragmatique pour reprendre le contrôle.

En quinze ans de missions, j'ai vu TOGAF® échouer chaque fois qu'on l'appliquait à la lettre, et réussir chaque fois qu'on l'utilisait comme une grammaire commune au service de décisions concrètes. Cet article résume ma façon de l'employer sur le terrain : un ADM adapté au contexte, une entrée par l'architecture métier et les capacités, et une cartographie qui sert à arbitrer plutôt qu'à décorer des slides.

L'ADM : un cycle à adapter, jamais à dérouler religieusement

L'Architecture Development Method (ADM) est le fil conducteur de chaque mission. En pratique, je ne déroule jamais le cycle complet de manière séquentielle, de la Vision à la Gouvernance. L'approche est itérative et opportuniste : on commence par la phase Vision pour aligner les parties prenantes sur un périmètre et un problème précis, puis on plonge dans les couches métier et applicatives en parallèle, là où la valeur est la plus immédiate.

La règle que je m'impose : produire vite des livrables exploitables. Une cartographie de capacités sur une page A3, une matrice d'impact, un diagramme de dépendances qui débloque une décision. Pas un document de 200 pages que personne ne lira et qui sera périmé avant d'être validé. L'ADM est un moyen, pas une fin — le succès se mesure aux arbitrages qu'il permet, pas au nombre de phases cochées.

Commencer par l'architecture métier, pas par la technologie

L'erreur la plus fréquente que j'observe : sauter directement aux applications et à l'infrastructure parce que c'est plus tangible. C'est précisément l'inverse qu'il faut faire. La Phase B — Business Architecture — pose les fondations de tout le reste, et son livrable cardinal est la carte des capacités métier : ce que l'organisation sait faire, indépendamment de qui le fait et avec quels outils.

La capacité est le bon point d'ancrage parce qu'elle est stable dans le temps et neutre vis-à-vis de la technologie. « Exécuter un paiement » reste une capacité, que le règlement passe par un virement, une carte ou un wallet. En accrochant le SI à des capacités plutôt qu'à des projets ou à un organigramme mouvant, on construit une architecture qui survit aux réorganisations et aux modes technologiques.

Concrètement, j'anime des ateliers courts avec les directeurs métier pour stabiliser les capacités de niveau 1 et 2, puis je relie chaque capacité aux chaînes de valeur qu'elle sert. Cette colonne vertébrale métier devient le langage commun entre la direction générale, la DSI et les équipes de delivery — le seul vocabulaire qu'un DG, un DSI et un développeur peuvent partager sans malentendu.

Capitaliser avec les Building Blocks réutilisables

Un des leviers les plus puissants de TOGAF® est la notion de Building Blocks. Au fil de mes missions chez des acteurs comme AXA ou Airbus, j'ai systématiquement capitalisé sur des patterns d'architecture réutilisables : patterns d'intégration API-first, modèles de référence pour les architectures event-driven, blueprints de rationalisation applicative, modèles de gouvernance des données.

Cette capitalisation a un effet composé : chaque mission alimente une bibliothèque qui réduit drastiquement le temps de conception de la suivante. On ne repart pas d'une page blanche — on instancie un pattern éprouvé et on l'adapte au contexte. C'est aussi ce qui distingue un architecte expérimenté d'un débutant : non pas la connaissance du framework, mais la profondeur de sa bibliothèque de solutions.

L'Enterprise Continuum : une taxonomie pour ne pas réinventer

L'Enterprise Continuum est souvent négligé, alors qu'il est essentiel. Il établit une taxonomie claire entre les assets d'architecture génériques (standards du marché, patterns sectoriels) et les solutions spécifiques à l'organisation. En mission, je l'utilise pour éviter deux pièges symétriques : réinventer un pattern qui existe déjà, ou plaquer un standard inadapté sur un contexte singulier.

Bien tenu, le Continuum devient un référentiel vivant qui répond à une question simple mais structurante : « avons-nous déjà résolu ce problème quelque part, et la solution est-elle générique ou propre à nous ? » C'est un accélérateur de décision autant qu'un garde-fou contre la dette d'architecture.

Cartographier pour décider : la matrice capacités × applications

Une cartographie n'a de valeur que si elle débouche sur un arbitrage. Mon livrable le plus rentable est la matrice capacités × applications : en lignes, les capacités métier ; en colonnes, le parc applicatif. Les croisements révèlent immédiatement les vraies décisions, sans débat politique.

• Capacité critique mais mal supportée par le SI : priorité d'investissement.
• Capacité peu stratégique mais sur-outillée (trois applications pour la même chose) : candidate à la rationalisation.
• Capacité stratégique reposant sur un fichier Excel ou un système fantôme : risque à traiter d'urgence.

Je modélise ces vues dans ArchiMate® et je les industrialise dans un outil de référentiel (MEGA HOPEX, par exemple), en exploitant la relation native entre Application et Capability. La logique est toujours la même : décrire l'écosystème actuel, décrire la cible avec le même vocabulaire, et faire de la transformation l'arbitrage explicite entre les deux.

TOGAF® 10 et agilité : des comités qui accélèrent au lieu de bloquer

TOGAF® 10 a acté une évolution majeure : l'intégration native de l'agilité. Dans mes interventions récentes, je combine systématiquement le cadre avec des cycles courts de livraison. Les comités d'architecture ne sont plus des instances bloquantes où l'on vient quémander un visa, mais des points de synchronisation légers qui accompagnent les équipes dans leurs décisions techniques.

Le secret tient en deux principes. D'abord, des « guardrails » clairs (principes d'architecture, patterns autorisés) qui permettent aux équipes de décider seules dans 80 % des cas. Ensuite, une gouvernance qui trace les décisions significatives plutôt que de tout contrôler. Une architecture d'entreprise qui ralentit le delivery a échoué, quelle que soit la qualité de ses diagrammes.

Les principes d'architecture : le contrat qui tient dans la durée

Avant le moindre diagramme, je formalise une dizaine de principes d'architecture — pas cinquante. Chacun suit la structure TOGAF® : énoncé, justification, implications. « Acheter avant de construire », « API-first par défaut », « une seule source de vérité par objet métier », « la donnée appartient au métier, pas à l'application ». Ces principes sont le contrat moral entre la DSI et les métiers.

Leur valeur n'apparaît pas le jour où on les écrit, mais six mois plus tard, quand un projet veut déroger. Le principe transforme une bataille d'opinions en une discussion d'exception documentée : on ne demande plus « qui a raison ? » mais « assume-t-on de déroger à ce principe, et à quel coût ? ». C'est ce qui rend la gouvernance soutenable sans l'architecte qui l'a mise en place.

Trois erreurs qui tuent une démarche TOGAF®

Première erreur : confondre exhaustivité et valeur. Vouloir tout cartographier avant de produire la moindre décision épuise les équipes et tue le sponsor. Quatre-vingts pour cent de la valeur tient dans vingt pour cent des objets — la carte des capacités de niveau 1-2 et la matrice capacités × applications. Le reste s'enrichit par itérations, à la demande.

Deuxième erreur : confondre capacité et processus. La capacité décrit le « quoi » (Gérer le sinistre), le processus décrit le « comment » (les étapes de traitement dans tel système). Mélanger les deux ruine toute traçabilité et produit des cartes illisibles qui changent à chaque réorganisation.

Troisième erreur : faire de l'architecture sans propriétaire métier. Sans sponsor au comité de direction, le référentiel reste un objet IT sans portée stratégique, abandonné dès que le consultant part. Sur mes missions de rationalisation applicative, c'est ce sponsoring qui fait la différence entre 20 et 30 % d'économies de maintenance réellement captées et un beau diagramme rangé dans un tiroir.

Ce que je retiens du terrain

TOGAF® 10 n'est ni une religion ni une contrainte administrative. C'est un langage partagé et une discipline qui permettent de structurer un SI complexe, de l'ancrer sur les capacités métier et de prendre des décisions d'investissement sur des faits. Utilisé avec discernement — entrée par le métier, capitalisation sur les Building Blocks, cartographie orientée décision, gouvernance agile — il transforme un paysage applicatif subi en un actif piloté.

Le vrai indicateur de succès n'est jamais le nombre de livrables produits. C'est le nombre de décisions que l'organisation a su prendre, plus vite et avec plus de confiance, parce qu'elle voyait enfin clair.