L1 — Dépasser le mythe technique

« The process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key principles and models that describe the enterprise’s future state and enable its evolution. » — Gartner, Clarifies the Definition of the Term “Enterprise Architecture”, 2008

« On n’apprend pas à faire de l’architecture de systèmes en lisant un livre, mais en pratiquant. » — Philippe Desfray et Gilbert Raymond, TOGAF en pratique — Modèles pour l’architecture d’entreprise, Dunod

Vidéo d’introduction (70s)

L01

Télécharger cette leçon en PDF

Le récif de Mutuelle Plus

Au début des années 2010, Mutuelle Plus fait figure de belle endormie. Fondée en 1961 par des fonctionnaires territoriaux pour garantir la santé de leurs collègues, l’organisation a grandi pendant cinq décennies jusqu’à protéger 900 000 personnes, soutenue par 800 collaborateurs. Dixième mutuelle de France, elle devrait dormir tranquille. Elle ne le peut plus.

La législation a changé. Les grandes compagnies d’assurance ont obtenu le droit de proposer des contrats santé, et la concurrence est devenue féroce. À l’intérieur, les signaux d’alerte se multiplient. Le portefeuille clients vieillit. Les coûts de couverture s’envolent. De gros contrats administratifs, perdus un à un, partent chez les concurrents qui montent en gamme. La direction technique veut réagir : « Modernisons le SI, lançons un projet d’architecture. »

L’inventaire est rude. Le catalogue de produits est devenu illisible tant il s’est étoffé. Plusieurs agences gèrent encore leurs clients sur des tableurs Excel locaux. Les contrats ne sont pas numérisés, et le délai de traitement d’un dossier dépasse les 72 heures. Le progiciel métier Gest+, déployé dix ans plus tôt comme une solution miracle, est devenu une camisole : chacun de ses écrans renvoie une erreur quand un cas déborde du cas standard, et les remboursements rendus à contretemps finissent par se retrouver dans la presse régionale.

Réunis en comité, les dirigeants poussent une conclusion convenue : *« lançons un vaste projet de refonte du SI ». * C’est une décision logique, presque inévitable. Et c’est, comme on va le voir, une erreur de catégorie — l’erreur-type que ce cursus entend vous apprendre à déjouer.

Une consultante externe est appelée. Elle ne commence pas par un audit technique. Elle organise trente ateliers de travail impliquant la majorité des employés — pas seulement la DSI. Les questions qu’elle pose ne portent pas sur les serveurs ni sur les bases de données. Elles portent sur les processus : « Quand un client appelle pour résilier, que se passe-t-il ? Par qui ? Combien de temps ? Pourquoi ? » Et petit à petit, sur ces trente ateliers, dix grands projets de transformation apparaissent — pas un, pas trois, dix. La mise en place d’un CRM, oui. Mais aussi la simplification de l’offre, l’amélioration de la qualité des données, la conformité RGPD, et cinq autres chantiers que personne n’aurait imaginés en ne regardant que le SI.

Le directoire, tenu au courant, fait quelque chose d’inhabituel : il reaffirme le positionnement de la mutuelle sur son cœur de métier, refuse de se disperser, et adopte une démarche d’architecture d’entreprise formalisée. Un Corporate Balanced Scorecard est mis en place. Le cadre de gouvernance COBIT est mobilisé. Et pour la première fois, on cesse de gérer la DSI comme une tour d’ivoire repliée sur sa dette technique.

Mutuelle Plus n’est pas devenue une autre entreprise. Elle n’a pas racheté d’assureur, n’a pas changé de nom, n’a pas multiplié les partenaires. Elle a changé de posture. Elle a cessé de croire qu’une transformation réussie consistait à installer de nouveaux outils, et accepté l’idée qu’elle exigeait de repenser les processus, la gouvernance des données, et la place du SI dans la stratégie.

La leçon de cette histoire n’est pas « il faut faire trente ateliers ». Elle est plus simple, et elle est la première de ce cursus :

L’architecture d’entreprise est un acte de communication. Le SI n’est pas l’objet de la transformation ; il en est l’un des instruments. L’objet, c’est l’organisation qui doit servir ses clients.

C’est à cette condition qu’on traverse les brouillards.

Le récit de Mutuelle Plus finit en point d’interrogation plutôt qu’en résolution complète. C’est précisément ce qui en fait un récit utile pour une leçon d’architecture d’entreprise. La transformation n’est pas terminée, ne sera jamais terminée — et c’est ce qu’il faut comprendre dès la première leçon.

La leçon qui suit (L2) vous apprendra à poser le cadrage qui rend possible ce type de transformation. Mais d’abord, regardons ce qu’enseigne le récit de Mutuelle Plus à travers un schéma qui résume le cœur du message :

📊

Schéma

L'analogie du pilote et du contrôleur aérien

Un même événement, deux perspectives légitimes. L'architecte traduit entre les deux.

Premier principe — L’AE est un acte de communication

The Open Group ne définit pas l’architecture d’entreprise comme un exercice de modélisation technique. Elle la définit comme un processus de traduction — la traduction d’une vision et d’une stratégie en changements effectifs (TOGAF, Introduction and Core Concepts, Section 3.2). L’AE sert avant tout à rendre visible ce qui, sans elle, resterait dans la tête de quelques-uns.

Cette définition a une conséquence pratique immédiate. Si votre interlocuteur ne peut pas comprendre votre schéma, votre schéma ne vaut rien — aussi élégant soit-il. « L’architecture d’entreprise est avant tout un acte de communication entre direction générale, directions métiers et informaticiens », écrivent Desfray et Raymond dans la préface de TOGAF en pratique. L’erreur du débutant consiste à dessiner des diagrammes pour lui-même : exhaustifs, jargonnants, illisibles. Le diagramme juste est celui qui filtre l’information pour la partie prenante qui le consomme.

L’analogie classique de TOGAF — celle du pilote et du contrôleur aérien — l’illustre parfaitement. Un pilote regarde un cockpit plein d’instruments ; un contrôleur aérien regarde un radar plein de plots. Les deux ont raison : ce sont deux points de vue sur le même espace aérien. L’architecte d’entreprise doit savoir produire l’un ou l’autre selon la salle où il parle. Devant un comité exécutif, il réduit le schéma aux grandes chaînes de valeur et aux capacités. Devant les experts FICO (Finance, Contrôle), il détaille les processus. Devant les développeurs, il montre les interfaces et les contrats de service. Devant les opérationnels, il résume les règles métier et les exigences non fonctionnelles.

La contrefaçon à éviter : l’« implicit architecture » — ces projets qui prétendent avoir une architecture mais ne peuvent fournir aucun diagramme de point de vue, aucune traçabilité des exigences, aucun principe directeur validé par un sponsor. C’est l’architecture qui vit dans la tête d’un seul expert, qui devient inutilisable le jour où il part, et qui n’a, en attendant, jamais instruit personne.

Et toi ? Regarde ton dernier livrable d’architecture. À qui était-il réellement destiné ? À toi-même pour clarifier ta pensée, ou à tes interlocuteurs pour les aider à décider ? Et qui n’a pas compris ton dernier schéma, alors qu’il aurait dû ?

Deuxième principe — La méthode structure l’exploration et prévient l’impasse

Sans méthode, l’architecture d’entreprise se transforme en expédition au petit bonheur. La méthode ADM (Architecture Development Method), cœur du framework TOGAF, structure rigoureusement la transformation de l’entreprise en huit phases (de A à H) articulées autour d’une gestion continue des exigences (TOGAF, Architecture Development Method, Ch. 2).

L’ADM fait trois choses que l’instinct ne fait pas. Premièrement, elle impose un ordre : avant de modéliser la cible, on s’accorde sur la vision ; avant de modéliser les applications, on valide les processus ; avant de planifier la transition, on a les écarts en main. Deuxièmement, elle rend tracables les décisions : chaque exigence métier peut être reliée à un composant d’architecture, et inversement. Troisièmement, elle ferme les portes de sortie qui mènent aux impasses — d’où la métaphore de la « checklist » chère à Desfray et Raymond : « une checklist pour vérifier que la démarche d’architecture d’entreprise que vous êtes en train d’effectuer ne fait pas des impasses ».

L’ADM ne prétend pas tout résoudre en un cycle. Un cycle ADM complet dure réalistement entre six mois et deux ans selon l’ampleur de la transformation et la maturité de l’organisation (TOGAF, Introduction, p. 6). C’est lent, et c’est précisément cette lenteur qui rend les transformations robustes.

L’ADM n’est pas non plus une prison. « TOGAF fournit […] un toolkit — il ne s’agit pas de mettre en œuvre 100 % des bonnes pratiques mais d’importer celles qui consolident les faiblesses de vos propres pratiques » (Desfray et Raymond). On n’applique pas TOGAF comme on récite un catéchisme. On choisit, dans la boîte à outils, ce qui répond aux faiblesses observées, et on laisse le reste. Adapter la méthode s’appelle le tailoring — et c’est une compétence d’architecte, pas un écart de conduite.

La contrefaçon à éviter : l’« over-modeling » — ces projets où, faute de méthode, on se jette dans une modélisation exhaustive et ultra-détaillée de l’existant, pour produire des diagrammes illisibles pour les métiers, coûteux à maintenir, et obsolètes avant d’avoir été terminés. La parade est top-down d’abord, bottom-up ensuite, sur un périmètre ciblé.

Et toi ? Dans ton dernier chantier, as-tu suivi une méthode explicite (ADM ou autre), ou as-tu improvisé ? Quelles étapes as-tu sautées ? Quelles impasses en ont résulté ?

Troisième principe — Le piège mortel : l’architecture après décision

Parmi tous les pièges que recense le corpus, le plus dangereux pour un débutant s’appelle l’« architecture après décision » (architecting after decision). Il tue la fonction d’AE plus sûrement que n’importe quel autre.

Le mécanisme est simple. L’architecte d’entreprise attend passivement d’être invité aux processus de planification stratégique ou budgétaire. Les choix technologiques ou d’investissements majeurs finissent par être actés par les dirigeants d’après les informations opérationnelles qu’ils ont sous la main le jour J. L’architecte est alors sollicité après coup pour documenter ou modéliser ce choix. Au mieux, son travail ne sert à rien — « pointless », disent les auteurs du corpus. Au pire, il démontre techniquement que la décision des dirigeants était mauvaise, ce qui génère de vives tensions et détruit la crédibilité de l’équipe d’AE pour longtemps.

L’histoire de Mutuelle Plus illustre exactement la parade. Le directoire, en refusant de lancer un « projet de refonte du SI » isolé, a évité l’« architecture après décision » en replaçant la transformation dans son cycle stratégique.

La parade : aligner impérativement les cycles de livraison d’architecture — notamment la Phase A (Vision) et les roadmaps stratégiques — sur le rythme et le calendrier budgétaire ou de planification de l’entreprise (business cycle). L’objectif n’est pas de tout livrer avant la décision, mais de fournir des recommandations prêtes à l’emploi (decision-ready) avant que la décision ne soit prise.

Deuxième contrefaçon à éviter : la confusion entre le référentiel d’AE et une CMDB. L’AE décrit les composants logiques d’architecture ; la CMDB gère les configurations physiques des serveurs. Confondre les deux, c’est condamner l’équipe d’AE à de la saisie de données opérationnelles, au lieu de conception stratégique.

Et toi ? Dans ton organisation actuelle, à quelle fréquence es-tu consulté sur les décisions stratégiques — une fois par an, jamais, ou après les décisions ? Quand pourrais-tu être consulté avant, et qu’est-ce qui t’en empêche ?

Quatrième principe — La posture de l’architecte : praticien, communiquant, humble

Le corpus insiste sur un point qui manque dans la plupart des manuels : l’architecture d’entreprise est un art difficile où l’expérience reste irremplaçable, où la lecture seule des théories ne suffit pas à faire un expert.

Trois attitudes résument la posture attendue.

Le praticien. « On n’apprend pas à faire de l’architecture de systèmes en lisant un livre, mais en pratiquant » (Desfray et Raymond). Ce cursus vous donne un cadre, des concepts, un vocabulaire, des outils. Aucun de ces éléments ne vous rend architecte. Ce qui vous rend architecte, c’est ce que vous en faites dans vos projets. La règle empirique du corpus est sans appel : ne jamais concevoir un composant pour la réutilisation à moins d’avoir immédiatement au moins deux cas d’usage réels et distincts qui vont l’implémenter à court terme (Desfray et Raymond). L’anticipation spéculative est une perte de temps.

Le communiquant. Mutuelle Plus a réussi parce que la consultante a pris le temps de parler aux employés, pas seulement aux serveurs. Vous passerez 30 à 50 % de votre temps à expliquer, à écouter, à reformuler. Si vous n’aimez pas cette part du métier, l’AE n’est pas pour vous.

L’humble. Vous serez presque toujours le moins senior dans la salle quand vous présenterez à un comité exécutif. Vous n’avez pas la légitimité du poids hiérarchique ; vous avez celle de la clarté de vos modèles et de la solidité de vos arguments. Assumez votre ignorance des détails business ; assumez aussi que vos interlocuteurs détiennent des éléments que vous n’avez pas. La fonction d’AE est une fonction de traduction, pas de surplomb.

|> Et toi ? Sur tes trois derniers mois de pratique, quelle part de ton temps as-tu consacrée à lire / modéliser, et quelle part à écouter / expliquer ? Cette proportion est-elle soutenable pour le travail qui t’attend ?

Module complémentaire — Au-delà de la posture : le leadership politique de l’AE

Le quatrième principe parle d’attitudes (praticien, communiquant, humble). Ce module ajoute une dimension supplémentaire : la dimension politique. Une posture d’humilité mal comprise peut devenir une posture de retrait ; une posture de communicant sans stratégie politique peut devenir une posture de transparence naïve. Ce module trace la frontière.

L’AE n’a pas d’autorité hiérarchique. C’est un fait structurel, pas un défaut. Le pouvoir formel (direction de projet, budget, sanction) appartient à d’autres : DSI, directeurs métiers, chefs de projet, RSSI. Le rôle de l’AE est de rendre visibles des choses que personne d’autre ne voit (cohérence transverse, dette technique, risques de solvabilité) et de convaincre que la cible technique sert une cible métier. Convaincre n’est pas imposer.

Cinq leviers d’influence sont à la disposition de l’architecte. Ils seront développés en détail dans la leçon 13 (L13 — Le leadership politique de l’architecte) ; cette section les introduit pour ancrer la posture dès la première leçon.

L’expertise : la légitimité technique est le ticket d’entrée. Sans elle, personne n’écoute. Mais elle ne suffit pas.
La coalition : on ne convainc pas seul. Identifier ses alliés naturels (RSSI, DAF, contrôle interne) et construire avec eux des arbitrages défendables.
La persuasion par la valeur métier : le jargon technique est un mur. Traduire en TCO, ROI, risque de solvabilité, time-to-market.
L’échange et la réciprocité : la transformation n’est pas un dû. Le small win (numériser un dossier critique pour désengorger un service) prouve la valeur de la coopération.
La contrainte douce : le comité d’architecture n’est pas un tribunal. C’est un lieu de traçabilité des écarts. La documentation des écarts est plus persuasive que l’interdiction.

Trois postures qui tuent la crédibilité (qui seront détaillées en L13) :

Donner des ordres quand on n’a pas de pouvoir hiérarchique. C’est le meilleur moyen de créer des conflits de territoire.
Se cacher derrière les standards (« la méthode l’impose »). Quand un interlocuteur entend cette phrase, il entend : « je ne sais pas justifier la valeur métier ».
Feindre de tout savoir face à des experts qui ont vingt ans de maison. L’arrogance est suicidaire. Adopter la posture de l’apprenant expert : maîtriser la méthode et la vision, accepter d’apprendre les détails.

Cartographier le pouvoir avant de cartographier le SI. Cette phrase résume l’essentiel. Un schéma directeur qui ne commence pas par une cartographie des parties prenantes (Pouvoir × Intérêt — voir L2 Phase Préliminaire, module Mendelow) est un schéma qui s’effondrera au premier conflit politique.

La posture de l’architecte n’est pas une attitude statique. C’est un positionnement dynamique, ajusté en temps réel selon la salle, l’audience, l’enjeu. L’architecte qui ne bouge pas est un architecte qui finit par disparaître.

Application — Ma charte d’architecte

À rédiger séance tenante. Cinq éléments précis. À afficher à un endroit visible et à confier à deux personnes de confiance (mentor, pair ou manager).

Mon manifeste personnel — En une phrase, pourquoi je fais de l’architecture d’entreprise. Pas ce que je produis, mais ce que je veux produire comme effet.
Mes trois personas prioritaires — Les trois types d’interlocuteurs que je veux servir en priorité dans les 90 jours qui viennent (ex. : DSI, directeur métier, sponsor exécutif). Nommer les personnes réelles, pas les fonctions abstraites.
Mes trois principes directeurs — Trois règles opérationnelles que je m’engage à suivre (ex. : « toujours un diagramme par page de slide », « jamais plus de 9 objets par vue », « toute exigence métier reliée à un composant d’architecture »).
Mes trois engagements datés — Trois actions concrètes à des échéances précises (30, 60, 90 jours). Pas des vœux. Des livrables avec date, livrables et témoins.
Mon premier allié — Une personne à qui je confie ma charte dans les 7 jours, en lui demandant de me rappeler mes engagements à la fin de chaque période.

Cette page est votre premier livrable d’architecte. C’est le début de votre dossier.

Encadré Au lecteur / À l’animateur

Question d’ouverture (à poser à voix haute avant la lecture) : « Racontez-moi un projet de votre organisation où vous avez le sentiment qu’on a transformé le SI sans transformer l’organisation. Qu’est-ce qui a manqué ? »

Profils à observer chez l’apprenant :

Le technicien qui se cache derrière les diagrammes. Produit des modèles impeccables et inutiles. Question : « À qui doit servir ce schéma ? Montrez-leur. »
L’architecte solo qui croit tout pouvoir porter. Refuse de faire valider ses principes, livre seul, découvre trop tard. Question : « Qui vous a mandaté sur ce sujet ? »
Le pressé qui veut brûler les phases. Saute directement aux applications. Question : « Que savez-vous du contexte métier de cette application ? »
Le dogmatique qui récite TOGAF. Connaît le framework, ne l’adapte pas. Question : « Qu’avez-vous ajouté à TOGAF pour votre contexte ? »

Pièges d’animation :

Ne pas laisser la discussion dériver vers la seule technique. Rappeler que la leçon 1 porte sur la posture, pas sur les outils.
Ne pas laisser un apprenant croire qu’il « sait ». La charte (application) le ramènera à sa propre capacité à se poser les bonnes questions.

Si profil d’apprenant ≠ novice : ouvrir la discussion sur ce qui, dans l’organisation actuelle de l’apprenant, fait obstacle aux trois promesses du cursus (sécuriser, langage commun, aligner). Adapter les exemples à son secteur.

Ce que la leçon 2 vous demande

Ouvrez votre dossier d’architecte à la page suivante. Préparez :

Un mémo d’une page sur le contexte de votre organisation (taille, secteur, gouvernance du SI actuelle, culture de la décision).
Le nom d’un sponsor exécutif potentiel à qui présenter votre charte dans les 30 jours.
Un premier obstacle identifié dans votre pratique, à formuler en deux phrases au plus.