TOGAF est partout. Sur les CV, dans les offres d’emploi, dans les RFPs. C’est un excellent framework. C’est aussi devenu, dans certaines organisations, un alibi pour la lenteur et la complexité. Ce billet est pour ceux qui veulent en tirer la valeur sans en subir la lourdeur.

Ce que TOGAF apporte vraiment

Trois choses, qui justifient à elles seules de le maîtriser.

Un vocabulaire commun. Quand l’architecte data, l’architecte applicatif et l’architecte technique parlent tous de « capabilities », de « building blocks » et de « target state », ils peuvent enfin se comprendre. C’est trivial à dire, énorme à vivre.

Une méthode itérative (l’ADM). Le cycle Architecture Development Method n’est pas un waterfall — c’est explicitement itératif. Vous pouvez sortir de la phase E (Opportunities & Solutions) pour revenir en B (Business Architecture) si vous découvrez quelque chose. C’est ça qui en fait un framework, et pas un processus rigide.

Un méta-modèle structurant. Le Content Framework de TOGAF décrit comment articuler les concepts d’architecture entre eux. Quand vous l’avez intégré, vous ne réinventez plus la roue à chaque projet.

Les trois pièges classiques

Le piège 1 : faire l’ADM complet à chaque mission. Le cycle TOGAF en huit phases (de la Preliminary Phase à Architecture Change Management) prend 12 à 18 mois pour une grande organisation. Si vous le déroulez en entier à chaque projet, vous êtes mort. La bonne pratique : choisir un Architecture Development Iteration adapté au scope.

Le piège 2 : produire tous les artefacts du Content Framework. TOGAF en liste plusieurs dizaines. La plupart sont inutiles dans votre contexte spécifique. Choisissez ceux qui éclairent une décision réelle. Le reste, supprimez-le sans culpabilité.

Le piège 3 : confondre certification et compétence. Un certifié TOGAF qui n’a jamais piloté une transformation est moins utile qu’un architecte expérimenté qui n’a pas le badge. La certification est un point de départ, pas une fin.

Notre méthode pragmatique

Chez TechWizard, nous utilisons TOGAF comme une boîte à outils, pas comme une doctrine. Voici comment :

1. Cadrage. Nous identifions le périmètre d’architecture qui compte vraiment — souvent 20% du SI génère 80% du risque. Pas besoin d’une cartographie exhaustive avant d’agir.

2. Itération courte. Nous structurons les missions en cycles de 6 à 12 semaines avec des livrables vérifiables. Pas de programme tunnel de 18 mois.

3. Artefacts minimaux. Pour chaque projet, nous produisons 5 à 8 artefacts maximum — ceux qui éclairent les décisions du comité d’architecture. Tout le reste vit dans EA-Wizard, accessible à la demande.

4. Adaptation aux frameworks locaux. Au Maroc, en France, en Côte d’Ivoire, les contraintes réglementaires diffèrent (Bank Al-Maghrib, ACPR, BCEAO). Nous adaptons les phases TOGAF à ces référentiels au lieu de les ignorer.

Quand TOGAF ne suffit pas

TOGAF est faible sur trois sujets modernes : l’IA, les architectures composables, la data mesh. Ce n’est pas un défaut — c’est juste qu’il a été conçu à une autre époque. Pour ces sujets, nous complétons avec d’autres frameworks (DAMA-DMBOK pour la data, des patterns cloud-native pour le composable, et notre propre méthode pour l’IA augmentée).

En résumé

TOGAF est un excellent vocabulaire et une méthode itérative robuste. C’est aussi un framework qui ne pardonne pas le dogmatisme. Utilisez-le pour structurer votre pensée, pas pour la remplacer.

Le bon architecte connaît TOGAF. Le très bon architecte sait quand s’en écarter.