L'EA en 2026 ne dessine plus l'entreprise — elle gouverne ses décisions

Zachman International et le FEAC Institute publient leur feuille de route 2026 : l’EA passe d’une discipline centrée sur l’artefact à une discipline centrée sur la décision. Sur le papier, c’est stimulant. Sur le terrain, c’est plus compliqué — et c’est précisément ce que l’article esquive. Revue des angles morts d’une vision qui se veut programmatique.

Résumé factuel

Zachman International et le FEAC Institute posent une feuille de route 2026 articulée autour de 8 tendances structurantes. La thèse centrale : l’EA passe d’une discipline centrée sur l’artefact (cartes, modèles, frameworks) à une discipline centrée sur la décision. L’architecte devient opérateur de plateformes-as-policy et fournisseur de services décisionnels (analyse de risque de dépendance, évaluation de gap de capacité, étude de trade-off, criticité data).

Les 8 tendances couvrent : copilotes IA vers systèmes agentiques, gouvernance continue et opérationnelle, plateformes comme véhicules de standards, livraison de décisions plutôt que de diagrammes, donnée comme actif négocié, IA comme amplificateur des forces et faiblesses existantes, extension du risque au-delà de la cybersécurité, et un skillset hybride mêlant architecture, stratégie produit, design de gouvernance et change management.

Ce que l’article esquive

Plateformes-as-policy : la photographie d’un équilibre, pas la trajectoire

Zachman-FEAC idéalise le modèle où les standards architecturaux sont encodés dans templates, pipelines et golden paths, et où les équipes adoptent parce que “le chemin conforme est le plus facile”. C’est séduisant. Mais c’est une photographie d’un état d’équilibre — pas la trajectoire pour y arriver.

Derrière chaque golden path, il y a une équipe plateforme qui maintient, documente, forme, et arbitre les exceptions. C’est un produit à part entière, avec sa dette technique, sa roadmap, ses conflits de priorité. Les organisations qui sur-vendent le concept sans budgéter la plateforme finissent avec des anti-golden paths de fait — des contournements qui invalident la promesse initiale.

Pour l’architecte qui pousse cette idée, c’est une promesse non financée. Ce qui marche, c’est une équipe plateforme traitée comme un produit interne : sponsor clair, équipe stable, budget récurrent. Pas comme un projet d’architecture parmi d’autres.

Decisions not diagrams : qui arbitre ?

L’article est très inspirant sur le quoi (livrer des services décisionnels) mais curieusement muet sur le qui. Qui décide quelles décisions sont “architecturales” et lesquelles restent dans le périmètre métier ? Qui arbitre quand un trade study conclut à deux options équivalentes ? Qui possède la qualité du service décisionnel ?

La maturité d’une organisation à consommer des services décisionnels est très variable. Beaucoup de COMEX veulent des réponses, mais ne veulent pas entendre les hypothèses, les incertitudes, et les “ça dépend”. Un service mal outillé devient un fournisseur de réponses molles qui érode la confiance. Trop prescriptif, il devient un goulot d’étranglement.

Ce qui marche, c’est la construction progressive d’un portefeuille de 3-5 services à fort signal (dependency risk analysis en premier, presque toujours), avec un contrat de service clair, une SLA, et un feedback loop. Ce n’est pas une bascule de paradigme, c’est une discipline d’exécution qui se gagne sur 18-24 mois.

Data as a negotiated asset : le politique sous le technique

L’article identifie correctement que la data est devenue un asset à défendre juridiquement et économiquement. Mais la formulation “negociated asset” masque la dimension profondément politique de ces négociations.

Les arbitrages data impliquent des conflits de souveraineté entre directions métiers, entre entités géographiques, entre l’IT et le business. Un data contract n’est pas un document juridique — c’est un accord politique qui survit ou meurt selon la cartographie de pouvoir interne.

Ce qui marche réellement, c’est de cartographier d’abord les data owners au sens politique, pas technique. Comprendre leurs incitations, et concevoir les data contracts comme des instruments d’alignement d’incitations — pas comme des contraintes administratives. C’est de l’EA au sens plein, mais qui n’apparaît dans aucune checklist “data governance”.

Trust as an architectural quality attribute : qui le mesure ?

L’article pose que la confiance (trust) devient un attribut qualité architectural. C’est une intuition juste. Mais l’article reste flou sur les métriques et les mécanismes d’assurance.

Sans instrumentation concrète, “trust” devient un mot à la mode dans les comités, vidé de son contenu opérationnel. Les RSSI parlent déjà de “zero trust” depuis 5 ans avec des implémentations très inégales. “Architectural trust” risque le même sort si on n’ancre pas le concept dans des métriques mesurables : taux d’audit trail sur décisions automatisées, temps de détection d’un comportement d’agent aberrant, taux de re-travail pour cause d’opacité décisionnelle.

Ce qui commence à émerger dans les organisations matures, c’est un trust dashboard qui croise des indicateurs d’auditabilité, de réversibilité, et de contestabilité des décisions automatisées. C’est faisable, c’est mesurable, et c’est un terrain où l’EA peut revendiquer une compétence distinctive.

Croisements et frameworks

Avec la veille du 6 juin :

IA Act en RH : la “requalification déployeur” devient critique quand l’EA livre des décisions automatisées
Multi-cloud operating model : les 4 disciplines (mesurer / router / se conformer / récupérer) sont le substrat opérationnel de la “gouvernance continue” que Zachman-FEAC appelle de ses vœux
Shadow AI : confirme le diagnostic — quand le chemin conforme n’est pas le plus facile, les contournements explosent
Ready For IT 2026 : la triplette DSI-RSSI-DPO systématisée est l’organisation cible que Zachman esquisse en creux

Frameworks :

TOGAF ADM : phases E (Opportunities & Solutions) et F (Migration Planning) = précisément ce que l’article appelle “decision services”. L’ADM reste le contenant, le contenu sémantique change
ArchiMate 3.2 : pas de représentation native des “decision services” ni des “platforms-as-policy”. Gap de modélisation à signaler au forum Open Group
BIAN : les Service Domains commencent à intégrer des patterns de décision automatisée, mais l’effort est lent
COBIT 2019 : la cascade de goals/objectives reste valide, mais “decision service” n’est pas un first-class citizen — à pousser dans une future révision

Questions ouvertes

Qui opère les plateformes-as-policy ? L’équipe plateforme, l’EA, le CTO office ? Quel ownership évite l’orphelinage ?
Comment mesurer “architectural trust” ? Quels KPIs défendables devant un COMEX ?
Quel contrat de service pour les “decision services” ? SLA, formats, hypothèses documentées — ISO/IEC 42010 (vues) suffit-il ?
Le data contract est-il un instrument juridique ou politique ? Si politique, quel rôle pour l’EA dans la cartographie de pouvoir ?
Quel arbitrage entre les “8 skills” et l’hyperspécialisation ? Architectes généralistes (tout mais peu profond) ou spécialistes (EA plateforme, EA data, EA risque) ?

Synthèse : ce qu’on en retient

La question qu’on garde en tête, après lecture, n’est pas “faut-il basculer de maps vers managed decisions ?” — c’est : par où commencer, et qui opère la bascule ? C’est l’angle pratique que Zachman-FEAC esquive, et c’est précisément ce qu’un architecte senior ne peut pas laisser de côté.

L’apport réel de l’article est dans le vocabulaire (“platforms-as-policy”, “decision services”, “architectural trust”) plus que dans la vision. Le mouvement qu’il décrit est en cours dans les organisations matures depuis 2-3 ans — l’agent IA et l’AI Act ont juste accéléré la prise de conscience.

Tant que les questions d’ownership, de métrique de trust, et de mesure de ROI des “decision services” ne sont pas traitées, l’EA reste un fournisseur de convictions éclairées, pas de produits décisionnels industrialisés. C’est ici que l’architecte joue son rôle le plus utile : pas en théorisant la bascule, en cadrant les conditions opérationnelles qui la rendent possible — équipe plateforme sponsorisée, portefeuille de services progressif, métriques de trust instrumentées.

Perspective Philippe

« Ce ne sont pas de meilleurs modèles ni de meilleures décisions — ce sont de meilleurs aides à la prise de décisions. » — Philippe

L’article trace une trajectoire ambitieuse, mais il la pose comme une bascule de paradigme. Mon constat de terrain, après des missions dans des organisations de maturité hétérogène, c’est que la maturité organisationnelle est le premier prérequis — et c’est le sujet que l’article esquive. Quatre angles me restent en tête après lecture.

1. La maturité d’abord, l’agent ensuite

Un agent peut-il tout seul cartographier le SI ? Identifier les silos techniques et organisationnels ? Résoudre les conflits humains qui empêchent la mise en place d’une coordination des parties prenantes et d’une gouvernance efficace ? Non. Et pas parce que la techno n’est pas là — parce que la cartographie du SI commence par la cartographie des pouvoirs et des incitations, et ça reste un travail politique, pas algorithmique. Les organisations qui arrivent à ce niveau d’agentic EA sont celles qui sont déjà très avancées en gouvernance de SI. Ce n’est pas le cas partout, et un agent ne change pas ce point de départ — il l’amplifie, dans un sens ou dans l’autre.

Pour donner un ordre de grandeur de mon expérience de terrain : sur 10 organisations que je croise, 1 seule a la gouvernance et la maturité pour encaisser l’agentic. Le pattern “vocabulaire + poster, gouvernance non financée” est d’ailleurs récurrent — Zachman-FEAC 2026 avec l’agentic, c’est SAFe 2018 avec l’agilité à l’échelle. L’architecte senior ne vend plus le framework, il vend le chemin pour en extraire 2-3 patterns tenables dans le contexte de maturité réelle du client.

2. L’AE éclaire, elle ne décide pas

L’article esquisse un futur où l’architecture fournit des “decision services” à fort signal. Oui, mais la fonction d’architecture est encore très peu reconnue à sa juste valeur, et il y a peu d’investissement financier pour des projets d’architecture. Va-t-on maintenant lui confier une fonction de décision ? L’AE peut donner les garde-fous, oui — mais ce n’est pas l’architecture qui décide. Elle donne les outils, les analyses et les données pour aide à la prise de décision, mais sans plus. Confondre “fournir une analyse de risque” avec “arbitrer un trade-off” est un glissement dangereux, et Zachman-FEAC ne marque pas la frontière.

3. Sans garde-fous, c’est l’automatisation incontrôlée qui arrive

« Sans garde-corps architecturaux explicites, les organisations risquent une automatisation incontrôlée, une prise de décision opaque et une exposition réglementaire. »

Oui — et je crains malheureusement que ce soit précisément ce qui va arriver aux organisations qui n’ont pas déjà une vision claire de l’apport de l’architecture. Le diable n’est pas dans la sophistication de l’IA, il est dans la confusion entre vitesse d’automatisation et qualité de gouvernance. Une organisation qui n’a pas clarifié qui possède la décision ne gagnera rien à brancher un agent dessus — elle perdra surtout la possibilité de corriger la trajectoire quand l’agent dérape.

4. Les “decision services” nécessitent des moyens, pas juste de la vision

« Les équipes d’architecture qui réussiront en 2026 offriront des services clairs : analyse des risques de dépendance, évaluation des lacunes en capacités, criticité des données, études de trade-off d’investissement. »

Oui, mais à condition d’avoir en amont mis les moyens et les leviers entre les mains de ces équipes pour produire ces livrables. Sans sponsor exécutif, sans budget récurrent, sans mandat d’arbitrage, ces services décisionnels resteront des slides dans des comités. La roadmap Zachman-FEAC suppose un terreau organisationnel que beaucoup d’entreprises n’ont pas — et c’est précisément ce que l’article ne nomme pas.

Pour boucler sur la phrase de clôture — « l’avenir de l’EA n’est pas de plus grands modèles, ce sont de meilleures décisions, livrées en permanence » — je dirais plutôt que ce sont de meilleurs aides à la prise de décisions. La nuance est petite, mais c’est elle qui sépare une ambition éditoriale d’un projet industriel tenable.

Article source : Zachman-FEAC — Enterprise Architecture in 2026: From Maps to Managed Decisions

Méta

Source : Zachman International & FEAC Institute, 2026
Catégorie : Méthodos & frameworks
Statut : enriched (Perspective Philippe ajoutée — en attente de validation globale pour passer approved)
À publier : après enrichissement, suivre la pipeline Substack (md-to-substack.netlify.app → Cmd+V → publication)
Croisements à valoriser en chapô : convergence forte avec item 1 (IA Act RH) et item 3 (multi-cloud) de la veille du 6 juin