Par quoi commencer pour lancer une démarche d'architecture d'entreprise ?

La réponse tient en un mot : le diagnostic. Avant de dessiner quoi que ce soit, avant de choisir un framework ou un outil, il faut comprendre l'existant. Cela signifie interroger les parties prenantes — architectes, responsables métiers, directeurs de programme, DSI — et analyser ce qui existe déjà : les artefacts produits, les cartographies partielles, les référentiels en vigueur, les comités actifs, les outils de modélisation en usage. La plupart des organisations qui initialisent une démarche d'architecture d'entreprise ont déjà quelque chose, souvent dispersé, rarement articulé.

Ce diagnostic initial sert deux objectifs distincts. D'abord, capitaliser sur l'existant plutôt que de tout recommencer. Ensuite, calibrer le niveau de maturité réel de l'organisation. Une équipe qui croit partir de zéro découvre souvent des initiatives d'urbanisation du SI, des analyses d'impact, des cartographies fonctionnelles menées par des projets spécifiques. Ce capital silencieux est précieux. Le CIGREF, dans son rapport de 2008 issu des travaux du Cercle Architecture d'Entreprise regroupant Air France, BNP Paribas, EDF, La Poste et une trentaine d'autres grandes entreprises françaises, souligne que dans bien des cas l'organisation possède déjà les outils et méthodes nécessaires — c'est leur usage qui doit évoluer.

Le diagnostic prend idéalement la forme d'interviews structurées croisées avec une analyse documentaire. Quatre à six semaines suffisent pour une organisation de taille intermédiaire. À l'issue, on dispose d'une cartographie des pratiques, d'une liste des artefacts existants, d'une première lecture de la gouvernance en place et d'une compréhension des attentes — souvent divergentes — des différents acteurs.

Quel est le rôle du sponsor et pourquoi est-il non négociable ?

Aucune démarche d'architecture d'entreprise ne survit sans un sponsor de haut niveau qui la porte et la protège. Cette affirmation peut sembler évidente ; elle est pourtant le premier facteur d'échec des initiatives qui ne décollent pas. L'architecture d'entreprise est une démarche transverse par nature, ce qui signifie qu'elle traverse des périmètres, des budgets et des légitimités qui appartiennent à d'autres. Sans mandat explicite et soutien actif de la direction, les architectes se retrouvent rapidement à produire des livrables que personne ne consulte.

Le modèle de maturité TOGAF, dans sa version modernisée publiée en 2025 par Daniel Lambert dans Architecture & Governance Magazine, évalue le niveau de participation de la direction générale comme un domaine à part entière. Au niveau Initial (niveau 1), la direction a une compréhension limitée de l'AE et aucun investissement structuré. Au niveau Defined (niveau 3), elle fournit une direction active et un sponsorship explicite pour aligner les initiatives architecturales avec les objectifs métiers. C'est le seuil minimal pour qu'une démarche soit viable. Au niveau Measured (niveau 5), le ROI de l'architecture est mesuré et la direction s'en sert pour arbitrer les investissements. La progression d'un niveau à l'autre ne se décrète pas — elle se construit.

Trouver le bon sponsor suppose de comprendre les enjeux que l'architecture peut adresser pour cette organisation, dans cette situation. Le CIGREF identifie plusieurs configurations types : l'entreprise en croissance rapide qui doit intégrer des acquisitions, l'organisation qui subit une dette technique croissante, la DSI qui perd de la crédibilité face aux métiers, l'organisation soumise à de nouvelles exigences réglementaires. Selon la situation, le discours change, les bénéfices mis en avant changent, et les sponsors naturels sont différents. La même démarche ne se vend pas de la même façon à un directeur financier préoccupé par la rationalisation des licences logicielles et à un directeur des opérations qui veut réduire les délais de mise sur le marché.

Comment définir le périmètre initial sans se noyer ?

La tentation est grande de tout vouloir couvrir d'emblée : cartographier l'ensemble du SI, modéliser tous les processus, documenter toutes les applications. C'est le chemin le plus court vers l'immobilisme. L'architecture d'entreprise doit démarrer sur un périmètre limité, puis s'étendre — c'est la règle formulée par le CIGREF et confirmée par tous les retours d'expérience disponibles.

La phase préliminaire de TOGAF ADM (Architecture Development Method), telle que définie dans la dixième édition du standard publiée par The Open Group, formalise cette question du périmètre comme une décision structurante. Elle demande explicitement d'identifier les unités organisationnelles les plus impactées, de confirmer les frameworks de gouvernance existants, et de définir l'équipe d'architecture ainsi que ses principes directeurs avant toute activité de développement architectural. Cette phase préliminaire n'est pas un préambule formel — c'est le moment où se décident les conditions de réussite ou d'échec de tout ce qui suit.

En pratique, deux critères guident le choix du périmètre initial. D'abord, la valeur démontrable rapidement : un domaine métier où les enjeux de transformation sont connus, où les décideurs sont mobilisés et où des résultats visibles peuvent être produits en moins de six mois. Ensuite, la faisabilité avec les ressources disponibles : un périmètre trop large avec une équipe de deux architectes est pire qu'un périmètre restreint traité correctement. Gartner estime que les organisations disposant d'une architecture d'entreprise solide réduisent de 25 % leurs coûts informatiques — mais cet ordre de grandeur ne se matérialise que si la démarche est correctement ancrée, pas si elle reste à l'état de cartographie décorative.

Quelles sont les étapes concrètes des 12 premiers mois ?

Les douze premiers mois se découpent naturellement en trois séquences de valeur croissante.

Les trois premiers mois sont consacrés à la fondation. Le diagnostic est réalisé, le sponsor est identifié et son mandat formalisé, le périmètre initial est arrêté. L'équipe est constituée — même minimale : un architecte d'entreprise senior, des relais dans les domaines couverts. Les principes d'architecture sont définis, c'est-à-dire les règles de haut niveau qui guideront les décisions : préférence pour les standards ouverts, séparation des préoccupations métier et technique, modèle de données maître centralisé, ou tout autre ensemble de positions pertinentes pour l'organisation. Ces principes ne sont pas des dogmes — ce sont des repères partagés, validés par le sponsor et communiqués aux parties prenantes.

Les mois quatre à sept sont le moment des premiers livrables utiles, les fameux quick wins. Une cartographie des capacités métier (business capability map) sur le périmètre choisi, un inventaire des applications avec leur niveau de criticité et d'obsolescence, une analyse d'impact sur un ou deux projets en cours — ces livrables concrets démontrent la valeur de la démarche et maintiennent l'adhésion. Une banque de détail étudiée par McKinsey a identifié lors de l'évaluation de son portefeuille applicatif plus de 50 applications inutilisées, 150 applications redondantes à consolider et 800 interfaces point à point à placer sur une plateforme d'intégration. Ce type de résultat tangible, produit tôt, est ce qui transforme un programme d'architecture en investissement crédible aux yeux de la direction.

Les mois huit à douze sont dédiés à la gouvernance et à la roadmap. La structure de gouvernance est instaurée : un comité directeur qui décide, un comité d'orientation qui formule les recommandations, des architectes de domaine qui instruisent les dossiers. La feuille de route architecturale est construite — simple, visuelle, collaborative, alignée sur les priorités stratégiques. Elle ne doit pas être un catalogue exhaustif de projets ; elle doit montrer clairement la trajectoire entre l'état actuel et la cible, avec les jalons intermédiaires et les dépendances principales. C'est cet outil qui permet à la direction de prendre des décisions d'investissement éclairées.

Comment structurer la gouvernance architecturale sans créer une bureaucratie ?

La gouvernance est le mécanisme par lequel l'architecture d'entreprise exerce son influence sur les décisions. Sans gouvernance, elle produit des documents ; avec une gouvernance bien conçue, elle informe les choix qui engagent l'organisation sur plusieurs années. Mais une gouvernance mal calibrée peut transformer l'AE en goulot d'étranglement détesté par les équipes projets.

Le modèle recommandé par le Secrétariat du Conseil du Trésor du Québec dans son guide pratique de 2018 distingue trois niveaux : le comité directeur qui assure la gouvernance stratégique et prend les décisions en matière d'AE, le comité d'orientation composé de représentants des instances dirigeantes et des responsables de domaine, et les architectes de domaine qui instruisent les dossiers techniques. Ce modèle à trois niveaux est valide pour la plupart des organisations de taille intermédiaire à grande. Pour les structures plus petites, les deux premiers niveaux peuvent être fusionnés.

La clé d'une gouvernance efficace est la clarté des mandats et l'intégration dans les processus existants. L'Architecture Review Board (ARB) — comité de revue d'architecture — ne doit pas être un organe externe qui examine les projets après coup. Il doit être intégré au processus de décision budgétaire et au cycle projet, de sorte que les arbitrages architecturaux interviennent au bon moment, quand les options sont encore ouvertes. Le guide de Projexion insiste sur ce point : il ne s'agit pas seulement de désigner un comité, mais d'intégrer l'EAM dans la gouvernance projet et organisationnelle existante.

Une gouvernance bien construite protège aussi les équipes projets d'une architecture dogmatique. Les principes d'architecture ne sont pas des interdictions absolues — ce sont des positions par défaut qui peuvent être dérogées avec une justification explicite. Documenter les dérogations est aussi précieux que documenter les conformités, car ces exceptions révèlent souvent les zones de tension entre les contraintes architecturales et les contraintes opérationnelles réelles.

Quel framework choisir : TOGAF, Zachman, ou quelque chose d'autre ?

La question du framework est souvent posée en premier. Elle devrait être posée en dernier, ou du moins pas avant d'avoir compris le contexte, la maturité et les objectifs réels de l'organisation. Un framework d'architecture d'entreprise est un outil, pas une fin en soi.

Les frameworks disponibles se distinguent par leur nature. TOGAF (The Open Group Architecture Framework), dans sa dixième édition publiée en 2022 par The Open Group, est un framework de processus : il décrit comment développer une architecture, avec l'ADM comme cycle méthodologique central. Zachman est un framework de contenu, une taxonomie qui classe les artefacts architecturaux selon deux axes (qui, quoi, où, quand, pourquoi, comment × contexte, concept, logique, physique, représentation, instanciation). IAF (Integrated Architecture Framework), FEAF (Federal Enterprise Architecture Framework) et d'autres occupent des niches spécifiques. En pratique, la majorité des organisations qui réussissent s'inspirent de TOGAF en l'adaptant significativement à leur contexte — ce que TOGAF lui-même encourage explicitement dans sa phase préliminaire.

L'adaptation n'est pas une simplification par défaut ; c'est une décision architecturale. Une organisation de 500 personnes avec une DSI de 30 collaborateurs n'a pas les mêmes besoins qu'un groupe industriel de 50 000 employés opérant dans plusieurs pays. Le niveau de formalisme, le nombre de domaines couverts, la granularité des livrables doivent être calibrés en fonction de la taille de l'équipe d'architectes, du niveau de maturité de l'organisation et de la valeur attendue à court terme. Un framework surdimensionné décourage les contributeurs et finit par être contourné.

Ce qui compte dans le choix et l'adaptation du framework, c'est qu'il produise un langage commun compris par tous les acteurs. Le rapport du CIGREF de 2008 insiste sur ce point : la convergence sur les termes n'est pas un prérequis à la coopération, elle en est le résultat. Mais un langage partagé est le ciment qui rend la coopération durable.

Comment faire évoluer la démarche après la première année ?

À l'issue des douze premiers mois, si la démarche est bien ancrée, l'organisation dispose d'un diagnostic documenté, d'une gouvernance fonctionnelle, d'une feuille de route architecturale validée et de premiers livrables concrets qui ont démontré de la valeur. C'est le niveau 2 du modèle de maturité TOGAF — Under Development — où les efforts de formalisation existent mais restent inégaux selon les domaines.

La deuxième et la troisième année visent à atteindre le niveau Defined (niveau 3) : des frameworks d'architecture clairement établis, des modèles de référence métier et technique documentés, des roadmaps basées sur les capacités et une démarche standardisée à l'échelle de l'organisation. C'est à ce stade que l'architecture d'entreprise commence à influencer réellement les décisions d'investissement — pas seulement les auditer après coup.

L'extension du périmètre doit être progressive et pilotée par la valeur. Chaque nouveau domaine intégré à la démarche est une opportunité de tester le modèle de gouvernance, d'enrichir la cartographie des capacités et d'identifier de nouveaux quick wins. Les projets de transformation ne sont pas des contraintes pour l'architecture d'entreprise — ils sont ses vecteurs. Chaque projet est une occasion d'avancer sur le référentiel architectural, de valider les principes en situation réelle et d'apprendre.

L'outillage évolue avec la maturité. Au départ, un outil de modélisation simple et quelques tableurs suffisent. Quand la démarche atteint le niveau Managed (niveau 4), une solution EAM (Enterprise Architecture Management) comme ARIS, LeanIX, Mega Hopex ou Sparx EA devient pertinente pour centraliser la connaissance, gérer les cycles de vie des actifs et produire des analyses d'impact fiables. Le choix de l'outil doit suivre la maturité — jamais la précéder. Projexion rappelle que l'outil ne doit jamais être un silo : son adoption nécessite un accompagnement au changement et une intégration dans les processus existants qui sont souvent sous-estimés.

Le niveau Measured (niveau 5) est celui où l'architecture d'entreprise est réellement intégrée au pilotage stratégique : les capacités métier sont mesurées par des KPI, le ROI des décisions architecturales est quantifié et les insights de l'AE alimentent directement les arbitrages de la direction générale. Ce niveau prend plusieurs années à construire, et toutes les organisations n'ont pas nécessairement besoin de l'atteindre. La maturité n'est pas une fin en soi — c'est un moyen d'apporter de la valeur à une organisation qui en a besoin.

Quelles sont les erreurs les plus fréquentes qui font échouer les démarches d'AE ?

L'architecture d'entreprise échoue selon des patterns récurrents, bien documentés. Le premier est l'ivory tower : des architectes qui produisent des livrables déconnectés de la réalité opérationnelle, sans ancrage dans les projets en cours, sans relation avec les équipes qui développent. Le terme, emprunté à la littérature anglophone sur l'AE, désigne une architecture lointaine et abstraite que personne ne consulte parce que personne ne la comprend ou ne la reconnaît dans ses propres enjeux.

Le deuxième échec classique est l'excès inverse : une standardisation si prescriptive qu'elle étouffe l'innovation. Une architecture d'entreprise qui interdit toute déviation sans processus de dérogation, qui impose des technologies obsolètes au nom de la cohérence, qui crée des goulots d'étranglement dans chaque décision technique — cette architecture-là est aussi inefficace que l'absence d'architecture. Les équipes finissent par la contourner, ce qui est pire que son absence.

Le troisième écueil est de confondre l'AE avec un projet. Le CIGREF formule cela clairement : l'architecture d'entreprise est une démarche, pas un projet. Elle ne se termine pas. Elle doit s'inscrire dans le temps, évoluer avec l'organisation, absorber les changements de stratégie, de réglementation, de technologie. Une organisation qui traite son programme d'AE comme un projet avec une date de fin le condamne à redémarrer dans quelques années avec les mêmes difficultés.

Enfin, il faut nommer la question des ressources. L'architecture d'entreprise exige des ressources dédiées. Pas nécessairement importantes, mais dédiées. Un architecte partagé à 20 % sur dix projets ne peut pas construire une vision cohérente. Cette exigence est souvent mal comprise des directions qui voient l'AE comme une prestation de service ponctuelle, alors qu'il s'agit d'une capacité organisationnelle permanente à développer et entretenir.

Conclusion

Structurer une démarche d'architecture d'entreprise est un investissement dans la capacité de décision à long terme. Les résultats ne sont pas immédiats — les premières années sont celles où l'on pose les fondations, construit la crédibilité et démontre la valeur par des livrables concrets. Ce n'est qu'à partir de là que l'AE peut exercer son rôle profond : donner à l'organisation une vision cohérente d'elle-même, une capacité à anticiper les conséquences systémiques de ses choix et un langage partagé pour en parler.

Dans un contexte où les transformations s'accélèrent — migration cloud, adoption de l'IA générative, pression réglementaire croissante — cette capacité de vision systémique devient un avantage compétitif. Les organisations qui ont investi dans une architecture d'entreprise solide abordent ces transformations avec un socle de connaissance sur leurs capacités, leurs dépendances et leurs marges de manœuvre. Les autres les subissent, composant dans l'urgence sans pouvoir mesurer ce qu'elles font.