Le fantôme du treizième étage
Il existe, dans la plupart des grandes organisations, un personnage étrange. Il arrive aux réunions avec quinze minutes de retard, ouvre un fichier Visio d'une complexité byzantine, prononce les mots "TOGAF", "capability map" et "target state architecture" dans la même phrase, puis repart vers son bureau, souvent situé dans un étage que personne ne visite.
Ce personnage, c'est l'Enterprise Architect.
Son salaire oscille entre 90 000 et 160 000 euros annuels en Europe occidentale. Son impact réel sur le P&L de l'entreprise ? Dans la majorité des cas, personne ne saurait le chiffrer. Et c'est précisément le problème.
Quand ton impact est inférieur à ta fiche de paie, ce n'est pas l'organisation qu'il faut blâmer. C'est ton modèle d'intervention qu'il faut casser.
Le diagnostic : pourquoi les EA se font contourner
Avant de proposer un remède, posons le diagnostic avec honnêteté. J'ai été Enterprise Architect. J'ai vu le piège de l'intérieur. Et j'ai vu des dizaines de collègues y tomber.
Le syndrome du diagramme sans destinataire
L'EA moyen passe 60 à 70 % de son temps à produire des artefacts : modèles ArchiMate, cartographies applicatives, matrices de capacités, roadmaps technologiques. Ces livrables sont souvent d'une qualité technique remarquable. Mais ils ont un défaut fatal : personne ne les a demandés, et personne ne les utilise.
Le Comex veut savoir combien coûte un projet, quel risque il porte, et quand il livrera de la valeur. Il ne veut pas un diagramme de 47 couches avec des flèches "Serving" et "Realization" dont la sémantique fait débat entre trois architectes depuis six mois.
L'arrivée systématiquement tardive
Dans beaucoup d'organisations, l'EA est convoqué quand la décision est déjà prise. Le business a choisi la solution. L'éditeur a été sélectionné. Le budget est voté. Et on demande à l'architecte de "valider l'alignement avec la cible". C'est une mascarade. L'EA devient un tampon administratif, pas un acteur stratégique.
Le langage du mauvais interlocuteur
Les EA parlent technique à des décideurs business. Ils parlent frameworks à des équipes de delivery. Ils parlent théorie à des gens qui ont besoin de solutions. Ce décalage linguistique est dévastateur : il crée l'impression, souvent justifiée, que l'architecte vit dans une tour d'ivoire déconnectée de la réalité opérationnelle.
Mon modèle d'intervention en 5 points
Quand j'étais EA, j'ai refusé ce modèle de l'architecte invisible. J'ai imposé l'implication en amont, j'ai parlé P&L, et j'ai mesuré la valeur en euros et en délais, pas en artefacts. Voici le modèle d'intervention qui en est sorti.
1. Exiger un "ticket d'entrée" avant toute décision
Aucune décision architecturale ne devrait être prise sans quatre éléments sur la table :
- Objectifs business : quel problème métier résout-on ? Quel gain vise-t-on ?
- Contraintes : budget, délais, réglementation, dette technique existante.
- Hypothèses acceptables : quels compromis le business est-il prêt à faire ?
- Métriques de succès : comment saurons-nous que ça a marché ?
Ce ticket d'entrée n'est pas une formalité. C'est un acte de discipline intellectuelle qui force toutes les parties prenantes à clarifier leurs intentions avant de s'engager. Et surtout, il positionne l'EA en amont de la décision, pas en aval.
En pratique : j'ai vu des projets entiers être redéfinis simplement parce que l'exercice du ticket d'entrée révélait que le problème réel n'était pas celui que l'on croyait résoudre.
2. Parler la langue du Comex en cinq lignes
Un membre du Comité Exécutif lit entre 200 et 400 pages de documents par semaine. Il dispose d'environ 90 secondes d'attention par sujet lors d'un comité de pilotage. Dans ce contexte, l'EA qui arrive avec un deck de 35 slides a déjà perdu.
La règle que je m'impose : tout sujet architecté tient en cinq lignes :
- Le problème (une phrase)
- Le coût de l'inaction (un chiffre)
- Les options (deux ou trois, pas quinze)
- La recommandation (une phrase)
- Le risque résiduel (un chiffre)
C'est brutal. C'est réducteur. Et c'est exactement ce dont un décideur a besoin pour prendre une décision éclairée. Les détails techniques existent ; ils sont en annexe, pour ceux qui veulent creuser.
Le principe sous-jacent : l'EA doit parler coût/valeur, délai, risque. Pas conteneurs, VLANs et API gateways. La traduction technique vers business est le cœur du métier. Pas un à-côté.
3. Passer 20 % du temps sur le terrain
C'est la règle la plus impopulaire auprès des EA seniors. Et c'est la plus importante.
Un architecte qui ne lit pas de code, qui ne participe pas aux revues d'implémentation, qui n'a jamais ouvert un terminal ou une console Kubernetes en production, perd sa crédibilité auprès des équipes de delivery. Et un architecte sans crédibilité est un architecte qu'on contourne.
20 % du temps, une journée par semaine, doit être consacré à des activités "hands-on" :
- Revues de code sur les composants critiques
- Sessions de pair-programming avec les équipes
- Analyse d'incidents en production
- Évaluation technique de solutions candidates
Ce n'est pas du micro-management. C'est de la calibration. L'architecte qui connaît la réalité du terrain prend de meilleures décisions stratégiques, parce que ses modèles mentaux sont alignés avec la réalité, pas avec une abstraction.
4. Prendre part aux problèmes du Run
Voici un test simple : quand un incident majeur survient en production à 23h, l'EA est-il dans la boucle ? Dans la plupart des organisations, la réponse est non. L'architecte est un acteur du "Build", pas du "Run".
C'est une erreur stratégique. Les incidents en production sont la source d'information la plus riche sur la qualité réelle de l'architecture. Un architecte qui ne participe pas à la résolution structurelle des problèmes de production, qu'ils viennent de "son" architecture ou non, se prive de cette intelligence opérationnelle.
L'objectif n'est pas que l'EA devienne un opérationnel de nuit. L'objectif est qu'il participe à l'analyse post-mortem, qu'il identifie les causes structurelles, et qu'il traduise ces constats en actions architecturales. C'est la boucle de feedback qui transforme un architecte théorique en architecte efficace.
5. Raconter la valeur en euros, pas en artefacts
C'est le point le plus difficile, et le plus transformateur. L'EA doit être capable de chiffrer sa propre contribution :
- Réduction d'OPEX/CAPEX : "La rationalisation de la couche middleware a permis d'économiser 340 000 euros par an en licences."
- Time-to-market : "La mise en place de l'architecture microservices a réduit le cycle de livraison de 12 semaines à 3 semaines."
- Risques business évités : "L'analyse de dépendances a identifié un single point of failure dont la matérialisation aurait coûté 2 millions d'euros de perte de chiffre d'affaires."
- Taux de réutilisation : "Les composants partagés sont utilisés par 14 équipes, évitant un surcoût de développement estimé à 800 000 euros."
Si vous ne pouvez pas raconter votre valeur en euros, quelqu'un d'autre décidera de la raconter à votre place. Et sa version sera probablement : "On ne sait pas trop ce que fait l'architecte, mais il coûte cher."
Le vrai rôle de l'Enterprise Architect
L'EA n'est pas un dessinateur de diagrammes. Ce n'est pas un gardien de standards. Ce n'est pas un auditeur interne déguisé.
L'EA est un traducteur stratégique : il connecte la vision business aux capacités technologiques, et il le fait avec suffisamment de rigueur et de pragmatisme pour que cette connexion produise de la valeur mesurable.
Quand j'ai obtenu le buy-in de Comex sur des roadmaps de transformation digitale, cloud et data, ce n'est pas parce que mes diagrammes étaient beaux. C'est parce que j'ai parlé leur langue, mesuré la valeur en termes qu'ils comprennent, et livré des quick wins qui ont prouvé la crédibilité de l'approche avant d'industrialiser à grande échelle.
La question que chaque EA devrait se poser chaque trimestre : "Si on supprimait mon poste demain, quel impact mesurable cela aurait-il sur le P&L de l'entreprise dans les six prochains mois ?"
Si la réponse est "aucun" ou "je ne sais pas", il est temps de changer de modèle d'intervention.