Le diagramme que personne ne lit
Il y a quelques mois, un directeur financier d'une entreprise luxembourgeoise m'a montré un document. Quarante-sept pages. Des boîtes bleues, vertes, jaunes. Des flèches en pointillés, en trait plein, en double trait. Des annotations en anglais technique. Un cartouche mentionnant "ArchiMate 3.2, Target State Architecture Q3 2026".
Il m'a regardé et m'a dit : "Pierre-Jean, ça fait six mois que l'équipe architecture me présente ça en comité. Je n'y comprends rien. Et je suis à peu près certain qu'eux non plus."
Il avait raison.
L'Architecture d'Entreprise, dans sa forme actuelle, est devenue un théâtre. Un spectacle de rigueur intellectuelle qui masque un échec fondamental : l'incapacité à faire dialoguer ceux qui créent la valeur business et ceux qui construisent les systèmes technologiques.
Il faut qu'on en parle. Sans complaisance.
Le dialogue de sourds permanent
La réalité du terrain dans la majorité des organisations que j'accompagne peut se résumer en trois monologues parallèles qui ne se croisent jamais.
Le Business parle en valeur
Le directeur commercial raisonne en "Value Streams" et "Business Capabilities". Il veut du ROI. Maintenant. Il veut savoir combien coûte un projet, quand il livrera ses premiers euros, et quel risque il porte. Il se moque éperdument de savoir si l'application tourne sur Kubernetes ou sur un serveur physique dans une cave. Et il a raison.
L'IT parle en infrastructure
Le directeur technique raisonne en conteneurs, VLANs, load balancers et API gateways. Il veut de la stabilité, zéro dette technique, et des systèmes qui tiennent la charge. Il se moque éperdument de savoir quel segment de marché génère le plus de marge. Et lui aussi, dans son cadre de référence, a raison.
Les architectes parlent en... ArchiMate
Et puis il y a les architectes d'entreprise. Coincés entre ces deux mondes, ils ont fait un choix tragique : créer un troisième langage que personne ne comprend. Ils passent plus de temps à débattre de la sémantique d'une flèche "Serving" versus "Realization" qu'à livrer de la valeur. Ils produisent des modèles d'une élégance formelle remarquable, et d'une utilité pratique proche de zéro.
J'ai lancé un sondage auprès de ma communauté professionnelle. La question était simple : "Quel est le vrai frein à une architecture d'entreprise agile ?" Les résultats sont édifiants :
- 46 % ont désigné la culture (guerre Biz vs IT) comme le problème principal.
- 31 % pointent les outils archaïques et chers.
- 23 % mentionnent l'élitisme des architectes.
- 0 % pensent que c'est impossible.
Autrement dit : le problème est identifié. Il est culturel, outillé et humain. Mais pas insoluble. Alors pourquoi persiste-t-il ?
ArchiMate : la délusion collective
Disons-le franchement : ArchiMate, dans sa forme actuelle d'utilisation, fonctionne comme une délusion collective.
Le framework en lui-même n'est pas mauvais. Sa structure en couches (Business, Application, Technology) est intellectuellement cohérente. Le problème, c'est ce qu'on en fait.
Le piège de la complétude
ArchiMate pousse à la complétude. À tout modéliser. À capturer chaque relation, chaque dépendance, chaque flux. Le résultat est un modèle d'une précision théorique impressionnante, et d'une obsolescence quasi instantanée. Le temps de finir la cartographie, le système a changé. On court après une cible mouvante avec un outil statique.
Le piège de la traduction
ArchiMate crée un besoin de traduction permanent. Le business doit traduire ses besoins en termes architecture. L'architecture doit traduire ses modèles en termes IT. L'IT doit traduire ses contraintes en termes architecture. Chaque traduction introduit de la perte d'information, du délai et des malentendus. L'architecte devient un perroquet trilingue qui passe sa carrière à reformuler sans transformer.
Le piège du coût
Les outils "Leaders du Magic Quadrant" qui implémentent ArchiMate (vous les connaissez) coûtent entre 50 000 et 500 000 euros par an en licences. Pour ce prix, les organisations obtiennent souvent des cimetières de données obsolètes : des référentiels que personne ne maintient, des modèles que personne ne consulte, des dashboards que personne n'utilise.
Le coût d'opportunité est vertigineux. Cet argent pourrait financer trois développeurs seniors pendant un an. Ou un programme de transformation complet.
Vers une Architecture Liquide
Le diagnostic est posé. La question devient : que fait-on ?
Je propose un changement de paradigme que j'appelle l'Architecture Liquide. Non pas un nouveau framework : le monde n'a pas besoin d'un énième méta-modèle. Mais un ensemble de principes qui redéfinissent le rôle et les outils de l'architecture d'entreprise.
Principe 1 : Zéro traduction
Le premier principe est radical : éliminer l'intermédiaire humain entre le métier et la technologie.
L'objectif est un modèle où le métier trace ses flux, en langage métier, avec ses propres concepts, et où l'IT câble la technologie en dessous, directement. Pas de couche intermédiaire où un architecte joue le rôle de traducteur. Pas de diagramme ArchiMate comme "langue pivot" entre deux mondes.
Concrètement, cela implique des outils où le business modélise ses processus dans un langage qu'il maîtrise (et non un sous-ensemble appauvri d'ArchiMate déguisé en "vue métier"), et où les décisions technologiques sont traçables directement depuis ces processus.
L'architecture as code va dans cette direction. Quand l'architecture est exprimée en code versionné, testable et déployable, la distance entre le modèle et la réalité se réduit à zéro.
Principe 2 : Low cost, high impact
Arrêtons de dépenser le budget annuel d'une startup dans des licences SaaS pour des outils d'architecture que quatre personnes utilisent.
Les alternatives existent. Des outils open source comme Archi (éditeur ArchiMate gratuit), des solutions "architecture as code" basées sur Structurizr ou Mermaid, des repositories Git pour versionner les décisions architecturales (ADR, Architecture Decision Records). Le coût : quasi nul. L'impact : direct et mesurable.
Le principe directeur : chaque euro dépensé en outillage d'architecture doit être justifié par un gain mesurable en temps de décision, en réduction de risque ou en accélération de delivery.
Principe 3 : Intelligible en dix secondes
C'est le test ultime : si votre CEO ne comprend pas le schéma en dix secondes, c'est poubelle.
Ce principe a des conséquences profondes sur la façon dont on conçoit les livrables d'architecture. Exit les modèles exhaustifs à 47 couches. Place à des vues ciblées, contextuelles, qui répondent à une question précise pour un destinataire précis.
Un schéma d'architecture pour le Comex ne ressemble pas à un schéma pour l'équipe DevOps. Et c'est normal. Le problème actuel est qu'on essaie de faire les deux avec le même outil et le même formalisme. Ça ne marche pas. Ça n'a jamais marché.
Comment casser le silo en pratique
L'Architecture Liquide n'est pas une utopie. C'est un ensemble de pratiques que certaines organisations commencent à adopter, avec des résultats tangibles.
Intégrer l'architecte dans les équipes produit
L'architecte ne peut pas être un acteur extérieur qui "valide" les choix des équipes. Il doit être intégré dans les squads, participer aux daily standups, comprendre les contraintes quotidiennes. C'est ainsi qu'il gagne la crédibilité nécessaire pour influencer les décisions.
Remplacer les reviews par des guardrails
Plutôt que des comités d'architecture qui valident (ou bloquent) des dossiers, mettre en place des guardrails automatisés : des règles dans le pipeline CI/CD qui vérifient le respect des principes architecturaux. La gouvernance devient continue et non bloquante.
Mesurer la valeur, pas la conformité
Le KPI d'une fonction architecture ne devrait jamais être "nombre de modèles produits" ou "taux de conformité au référentiel". Il devrait être : "réduction du time-to-market", "coût évité par réutilisation", "nombre de décisions éclairées par l'architecture".
Le fond du problème
Quarante-six pour cent des professionnels interrogés identifient la culture comme le frein principal. Pas les outils. Pas les frameworks. La culture.
Cela signifie que la solution n'est pas technique. Elle est humaine. Il faut des architectes qui acceptent de descendre de leur piédestal, des business leaders qui acceptent de comprendre la technologie, et des organisations qui acceptent de supprimer la frontière artificielle entre "le Business" et "l'IT".
Parce que cette frontière n'existe pas dans la réalité. Elle n'existe que dans nos organigrammes. Et c'est cette fiction organisationnelle qui alimente le dialogue de sourds.
L'Architecture d'Entreprise n'est pas une arnaque intellectuelle. Mais sa pratique actuelle en est devenue une. Et il est temps de la réinventer, non pas avec un nouveau framework, mais avec le courage de remettre en question tout ce que nous pensions savoir sur la façon de faire dialoguer la stratégie et la technologie.