Architecture d'entreprise : par où commencer sur Le Chemin de fer

Personne ne pose un rail sans savoir où va la ligne

Une région veut une ligne nouvelle. Les élus ont un tracé en tête, un constructeur promet des rames, une entreprise de travaux publics a des équipes libres au printemps. On pourrait terrasser dès avril. Les premiers kilomètres de plateforme sortiraient de terre avant l'été, et tout le monde aurait quelque chose à montrer.

Puis les questions arrivent, dans le désordre. La ligne sera-t-elle électrifiée à la même tension que le reste du réseau ? Qui l'exploitera, avec quel système de signalisation ? Le nœud de la gare centrale peut-il absorber six trains de plus par heure ? Aucune de ces questions ne se règle avec une pelleteuse. Une plateforme terrassée au mauvais endroit, c'est un remblai qu'on regarde pendant trente ans.

Une entreprise qui transforme son système d'information vit la même scène. Un progiciel est choisi, une équipe démarre, et six mois plus tard on découvre que personne n'a dit quels systèmes l'entreprise devait avoir, dans quel ordre les changer, ni qui tranche quand deux directions veulent des choses incompatibles. C'est précisément le travail de l'architecture d'entreprise.

Cette série suit trois mouvements, dans cet ordre : tracer la ligne, poser les rails, faire rouler les trains. C'est l'ordre dans lequel on mène un réseau ferré de l'idée au service commercial, et c'est l'ordre dans lequel une architecture d'entreprise se construit avec TOGAF.

Cette page est le plan de lecture. Elle n'enseigne aucune notion en profondeur : elle pose le décor, situe TOGAF, montre les trois paliers, les six domaines et l'ordre des dix-neuf billets. Garde-la ouverte dans un onglet, tu y reviendras entre deux étapes.

Ce qu'est l'architecture d'entreprise, et ce qu'elle n'est pas

Sur un réseau ferré, personne ne confond le plan des voies d'une gare avec le schéma national des infrastructures. Le premier dit où passe chaque aiguillage. Le second dit quelles lignes existeront dans quinze ans, lesquelles seront fermées, et pourquoi. Les deux sont indispensables, mais ils ne répondent pas à la même question et ne se lisent pas au même étage.

L'architecture d'entreprise est le second document. Elle décrit une entreprise au sens large que lui donne TOGAF : un ensemble d'organisations qui partagent des objectifs, ce qui peut déborder la société elle-même (partenaires, fournisseurs) ou n'en couvrir qu'une division. Elle en décrit la structure dans quatre domaines, le métier, les données, les applications et la technologie, dans son état actuel comme dans l'état visé, et surtout les principes qui gouvernent le passage de l'un à l'autre.

Ce qu'elle n'est pas mérite d'être dit aussi nettement. Elle n'est pas un schéma de serveurs : l'inventaire des machines est une entrée, pas un résultat. Elle n'est pas non plus un organigramme : savoir qui dépend de qui ne dit rien des systèmes que l'entreprise devrait avoir. Quant à la conception d'une application, elle commence là où l'architecture d'entreprise s'arrête : quand on en est à dessiner les composants d'un système, celle-ci a déjà fait son travail, elle a décidé que ce système devait exister.

La définition que la série retient est celle que partagent le TOGAF Standard et la norme ISO/IEC/IEEE 42010 : des éléments, les relations entre eux, et les principes qui guident leur conception et leur évolution. Le mot qui compte est « évolution ». Un schéma figé décrit l'existant. Une architecture décide aussi de ce qui a le droit de changer, et comment.

L'architecture d'entreprise répond à trois questions : quels systèmes l'entreprise doit avoir, dans quel ordre les changer, et qui décide quand deux besoins s'opposent. Tout le reste en découle.

TOGAF, en deux paragraphes

Les réseaux ferrés européens roulent sur des spécifications communes, publiées par des organismes que personne n'est forcé de suivre et que tout le monde suit, parce qu'un train incapable de franchir une frontière ne sert à rien. TOGAF joue ce rôle pour l'architecture d'entreprise. C'est le cadre de référence de la discipline, publié par The Open Group, et sa dixième édition est publiée en ligne.

Le standard apporte trois choses. Un cadre : une façon de découper le sujet en domaines, en états et en niveaux, puis de ranger ce qu'on produit dans un référentiel. Une méthode : l'Architecture Development Method, l'ADM, un cycle de phases qui va de la vision à la gestion du changement, et qu'on parcourt plusieurs fois à des niveaux de détail différents. Un vocabulaire, enfin : brique, artefact, livrable, partie prenante, point de vue, vue, écart, feuille de route. Des mots précis qui permettent à un architecte, un sponsor et un chef de programme de parler de la même chose.

La série retient les trois, dans cet ordre : le vocabulaire et le cadre d'abord, la méthode ensuite, le référentiel et la gouvernance pour finir. Elle laisse de côté ce qui relève du manuel plutôt que de la pratique : les listes exhaustives d'artefacts par phase, le détail des guides sectoriels, et tout ce qui ressemble à de la révision. On écrit un parcours de pratique. Quand une notion mérite la lettre du standard, on renvoie au texte publié par The Open Group plutôt que de le paraphraser.

TOGAF n'est pas une recette à appliquer telle quelle. Le standard lui-même demande à être adapté à l'organisation qui l'adopte. La série le prend ainsi : un cadre et un vocabulaire qu'on plie à l'entreprise, jamais l'inverse.

Trois séries d'architecture, trois échelles

Un réseau ferré se planifie à trois échelles qui ne se confondent jamais. Le schéma national dit quelles lignes existeront. Le corridor régional dit comment un axe se raccorde au reste. L'étude de ligne dit où passe chaque rail.

Ce blog compte trois séries d'architecture, et elles s'emboîtent de la même façon. Le Chantier conçoit un système : des exigences au document d'architecture, un ouvrage à la fois. La Ville le fait tenir à l'échelle : trafic, données, fiabilité, quand le système livré rencontre la charge réelle. Le Chemin de fer se place un cran au-dessus. Il décide quels systèmes l'entreprise doit avoir, dans quel ordre les changer, et qui gouverne l'ensemble.

Les trois ne s'excluent pas, elles s'alimentent. L'architecture d'entreprise produit une feuille de route. Chaque lot de cette feuille de route devient un système à concevoir. Chaque système livré devient quelque chose à faire tenir dans la durée. Si tu viens des deux autres séries, tu reconnaîtras des mots : exigences, parties prenantes, compromis. Ils changent ici de portée, pas de sens.

Le Chantier conçoit un système. La Ville le fait tenir. Le Chemin de fer décide quels systèmes il faut, dans quel ordre, et qui tranche. Même famille, pas le même étage.

Le fil rouge : Le Chemin de fer

Un même réseau ferré national sert de décor à toute la série. On le planifie sur dix ans, on le livre tronçon par tronçon, plusieurs exploitants y font rouler leurs trains sans se commander les uns les autres, et tout tient grâce à des normes communes : l'écartement des rails, la tension de la caténaire, la signalisation. Le voyageur, le cheminot et le planificateur n'en regardent pas la même carte.

Le choix n'est pas décoratif. Un réseau ferré rend visibles des contraintes que le système d'information dissimule. Personne ne discute le fait qu'un tronçon ouvert doit rester compatible avec le reste du réseau, ni qu'une ligne se décide des années avant de rouler. Voici la table de correspondance, en version courte. Chaque billet en reprend une ou deux lignes, celles qui le concernent.

La métaphore ouvre chaque section, elle ne la remplit pas. Dès que la transposition devient acrobatique, on repasse à l'architecture d'entreprise. Une précision pour éviter un malentendu : le réseau ferré est le décor, jamais le sujet. Les cas réels que la série cite, à partir du billet suivant, sont des programmes informatiques et de transformation, documentés par des rapports d'audit ou des revues indépendantes.

Une métaphore ne prouve rien. Elle aide à comprendre pourquoi une décision d'architecture prise trop tard coûte le prix d'une ligne entière.

Le plan de ligne

Trois lignes, une couleur par palier, une station par billet. C'est la carte de la série, à lire comme un plan de métro : on monte au terminus de la ligne 1 et on descend à la dernière station de la ligne 3.

Les trois lignes ne classent pas les sujets par difficulté, mais par dépendance. On ne planifie pas une migration sans architecture cible, et on ne gouverne pas une implémentation sans plan de migration. Chaque palier rend le suivant possible.

La ligne 1 est plus longue que les deux autres, et c'est voulu. Le vocabulaire et le cadrage sont ce qui manque le plus souvent quand un programme déraille.

Palier 1 : Tracer la ligne

Avant qu'un rail soit posé, quelqu'un a décidé qu'une ligne devait exister, entre quelles villes, pour quel trafic, et quelle administration en aurait la charge. Ce travail prend des années et ne produit que du papier : des cartes, des études, une lettre de mission, un schéma directeur. Et pourtant tout ce qui suit en dépend.

Ce palier ne contient aucune architecture de domaine. Il pose le vocabulaire, le cadre, la méthode en survol, puis les deux premières étapes de l'ADM, celles qui créent l'équipe et cadrent le premier cycle. Deux domaines, page du palier : Tracer la ligne.

Concepts

Les mots et les découpages que tous les billets suivants réutilisent. Ce qu'est une entreprise au sens de TOGAF, ce qu'est une architecture, à quoi elle sert et quels sont ses quatre domaines. Comment on la découpe : états (référence, cible, transition), portée, niveaux, partitions, abstractions. Ce qu'est une brique, logique ou physique, et comment le standard lui-même est structuré.

Le domaine se termine par la méthode en survol : dix phases, ce que chacune produit, et les notions transverses sans lesquelles rien ne se lit. Artefact, livrable, partie prenante, préoccupation, point de vue, vue. C'est aussi le billet qui installe le cadran de l'ADM, que les billets de phase reprendront ensuite un à un.

Lis dans cet ordre :

1. Cette page, le plan de lecture de la série.
2. Qu'est-ce que l'architecture d'entreprise ? Définition et domaines
3. Découper une architecture : états, portée, niveaux, partitions
4. TOGAF 10 et building blocks : le standard et ses briques
5. L'ADM de TOGAF : dix phases, artefacts, livrables, points de vue

Page du domaine : Concepts.

Cadrage

Les deux premières phases de l'ADM, celles qui précèdent toute conception. La phase préliminaire crée la capacité d'architecture : l'équipe, sa gouvernance, ses outils, et les principes qui guideront toutes les décisions à venir. La phase A ouvre chaque cycle : une demande de travaux arrive, on identifie les parties prenantes et leurs préoccupations, on écrit une vision et on fait signer un énoncé des travaux.

Le troisième billet outille cette phase A. Les scénarios métier pour découvrir les exigences, l'évaluation des capacités, et la question que presque tout le monde saute : l'entreprise est-elle prête à changer ?

Lis dans cet ordre :

1. Phase préliminaire : la capacité d'architecture et ses principes
2. Phase A : vision d'architecture, demande et énoncé des travaux
3. Scénarios métier, capacités et maturité : outiller la phase A

Page du domaine : Cadrage.

À la fin du palier 1, aucune architecture de domaine n'est dessinée, et c'est exactement le but. Tu sais ce qu'est une architecture, qui la demande, pour qui, et ce qu'on attend du premier cycle.

Palier 2 : Poser les rails

Le schéma directeur est signé. On entre dans les études détaillées : l'offre de service d'abord (quelles dessertes, quelles fréquences), puis les registres et les postes de commande, puis la voie, la caténaire et la signalisation. Viennent ensuite les lots de travaux, le programme pluriannuel et son financement. Chaque étude compare la carte d'aujourd'hui au tracé cible et liste les chaînons manquants.

Ce palier parcourt les phases B à F de l'ADM : les architectures de domaine, puis le passage de la cible à un plan daté et financé. Deux domaines, page du palier : Poser les rails.

Conception

Les trois phases qui dessinent la cible, domaine par domaine. B pour l'architecture métier, la première et le prérequis de toutes les autres, avec la technique d'analyse d'écarts que C et D réutiliseront. C pour les systèmes d'information, en deux volets, les applications et les données. D pour la technologie, avec un point que le standard tient à faire passer : la technologie n'est pas qu'un réceptacle de demandes, elle est aussi un moteur de changement.

Lis dans cet ordre :

1. Phase B : architecture métier et analyse d'écarts
2. Phase C : architectures des données et des applications
3. Phase D : architecture technologique et technologies émergentes

Page du domaine : Conception.

Planification

De la cible au plan. La phase E regroupe les écarts en lots de travail, vérifie les dépendances, découpe le chemin en architectures de transition et sort une première feuille de route. Deux techniques lourdes y vivent, l'interopérabilité et la gestion des risques. La phase F transforme cette feuille de route en projets datés, financés et acceptés, puis passe le relais à la gouvernance d'implémentation. Courte dans le standard, décisive en pratique : c'est ici que la direction dit oui ou non.

Lis dans cet ordre :

1. Phase E : opportunités, solutions, risques et feuille de route
2. Phase F : planifier la migration et gouverner l'implémentation

Page du domaine : Planification.

Le palier 2 produit une cible et un plan. Rien n'est encore construit. Un plan sans convention de financement reste un trait sur une carte, et une cible sans plan reste un vœu.

Palier 3 : Faire rouler les trains

Les travaux sont lancés. L'autorité d'infrastructure homologue chaque tronçon avant sa mise en service, compte les voyageurs réels face aux prévisions, reçoit la demande d'un nouvel arrêt, tient à jour le registre de l'infrastructure. Et elle s'assure que ministère, régulateur, gestionnaire et exploitants décident chacun à leur étage sans se marcher dessus.

Ce palier couvre les phases G et H, la gestion des exigences, la façon réelle d'utiliser l'ADM, le référentiel où tout se range, et la gouvernance. Deux domaines, page du palier : Faire rouler les trains.

Pilotage

La phase G est la seule où l'architecte ne produit pas d'architecture : il surveille celle que d'autres construisent, avec le contrat d'architecture, l'évaluation de conformité et une façon de servir des équipes agiles sans les étouffer. Puis H et la gestion des exigences, traitées ensemble parce qu'elles vivent ensemble : vérifier que la valeur promise arrive, décider ce qu'on fait d'une demande de changement, absorber ce que chaque phase découvre.

Un billet entier est consacré à l'usage réel du cycle : itérations, phases ouvertes en même temps, projets qui ne passent pas par toutes les phases, choix entre plusieurs cibles possibles. Le dernier billet du domaine traite de la gouvernance : qui décide, qui contrôle, qui rend des comptes, et comment la capacité d'architecture se gère comme une capacité métier à part entière.

Lis dans cet ordre :

1. Phase G : contrats d'architecture, conformité et équipes agiles
2. Phase H et gestion des exigences : piloter le changement
3. Appliquer l'ADM : itérations, phases concurrentes et compromis
4. Gouvernance d'architecture : conseil, conformité et capacité, à lire après le billet sur le référentiel.

Page du domaine : Pilotage.

Référentiel

Où tout ce que la série a produit est rangé, typé et retrouvé. Le content framework qui classe les artefacts, le métamodèle qui nomme les entités et leurs relations, le dépôt d'architecture qui les stocke avec les standards et les décisions, le continuum qui dit d'où vient chaque brique, du générique au spécifique.

Pour finir, le lexique de la série : une cinquantaine de termes définis en nos mots, chacun avec son ancre sur Le Chemin de fer et le billet qui le développe. Billet court en prose, long en tableaux, à garder sous la main.

Lis dans cet ordre :

1. Le référentiel d'architecture : métamodèle, dépôt, continuum, entre le billet sur l'application de l'ADM et celui sur la gouvernance.
2. Lexique TOGAF : les termes de l'architecture d'entreprise, en clôture de la série.

Page du domaine : Référentiel.

Ordre de lecture du palier 3 : phase G, phase H, appliquer l'ADM, le référentiel, la gouvernance, puis le lexique. Le lexique ferme la boucle et renvoie vers cette page.

Le parcours en un schéma et un tableau

Six domaines, trois paliers, de gauche à droite. On avance d'un domaine au suivant et on ne change de palier qu'une fois le précédent digéré.

Pour repérer rapidement où aller, ce tableau résume le parcours complet.

Les paliers suivent la dépendance, pas la difficulté. On ne gouverne pas un plan qu'on n'a pas écrit, et on n'écrit pas un plan vers une cible qu'on n'a pas dessinée.

Comment lire la série

Quelques repères pour en tirer le maximum.

Commence au palier 1, même si tu pratiques déjà. Beaucoup d'architectes savent dessiner une cible et bloquent sur « qui est le sponsor, au juste, et qu'a-t-il signé ? ». Les deux premiers domaines donnent le vocabulaire et le cadrage que tous les autres réutilisent.

Suis la numérotation, pas le classement. Les domaines rangent les billets par sujet, l'ordre de lecture les enchaîne par dépendance. Les deux ne coïncident pas toujours, et c'est indiqué chaque fois que le parcours change de domaine en cours de palier.

Repère l'ancre du Chemin de fer avant la transposition. Chaque billet s'ouvre sur une situation du réseau ferré, puis passe à l'architecture d'entreprise. Quand une notion résiste, retourne à son coin du réseau : la contrainte y est physique, et c'est souvent là que le déclic se produit.

Lis le scénario B comme un rapport, pas comme une morale. À partir du billet suivant, chaque billet se termine par un cas réel et public : un programme informatique ou de transformation, documenté par un audit, un post-mortem ou une revue indépendante. On rapporte ce que la source dit, rien de plus. Le but est de voir la notion du billet à l'œuvre, en positif ou en négatif.

Garde le standard à portée de main. La série explique, le standard fait foi. Quand un billet cite une phase, un livrable ou une définition, le texte de référence est celui que The Open Group publie en ligne. Lire les deux côte à côte est la meilleure façon d'apprendre à s'en servir.

Reviens à cette page entre deux paliers. En fin de palier, relis le plan de ligne et le schéma du parcours. Tu verras ce que tu viens d'acquérir et pourquoi la suite arrive maintenant plutôt qu'avant. Une carte ne sert que si on la consulte en chemin.

La série vise la pratique d'une méthode, pas la mémorisation d'un standard. Aucun billet ne remplace le texte de The Open Group ; tous cherchent à te faire poser la bonne question avant de l'ouvrir.

Points clés

• La série suit un fil rouge unique, tracer la ligne, poser les rails, faire rouler les trains, l'ordre dans lequel on mène vraiment un réseau ferré de l'idée au service commercial.
• L'architecture d'entreprise décide quels systèmes l'entreprise doit avoir, dans quel ordre les changer et qui tranche. Le Chantier conçoit un système, La Ville le fait tenir : Le Chemin de fer se place un étage au-dessus.
• TOGAF, publié par The Open Group, apporte un cadre, une méthode (l'ADM) et un vocabulaire. La série les prend comme des outils à adapter, jamais comme une recette.
• Trois paliers regroupent six domaines : Concepts et Cadrage ; Conception et Planification ; Pilotage et Référentiel. Dix-neuf billets, à lire dans l'ordre du plan de ligne.
• Chaque billet ancre sa notion dans Le Chemin de fer, puis la transpose et, dès le suivant, l'illustre par un cas réel documenté.

Dans la série

Palier 1 : Tracer la ligne. Domaine : Concepts.

• Suivant : Qu'est-ce que l'architecture d'entreprise ? Définition et domaines

Pour aller plus loin

• Qu'est-ce que l'architecture d'entreprise ? Définition et domaines, la suite immédiate de cette page.
• L'ADM de TOGAF : dix phases, artefacts, livrables, points de vue, pour la méthode en survol et le cadran que toute la série reprend.
• Les trois pages de palier regroupent leurs billets au fil des publications : Tracer la ligne, Poser les rails, Faire rouler les trains.
• Le TOGAF Standard, 10e édition, le texte de référence publié en ligne par The Open Group. C'est lui que la série cite quand elle parle d'une phase, d'un livrable ou d'une définition.
• The Open Group, l'éditeur du standard. Un parcours de certification existe chez eux ; cette série s'arrête à la pratique.
• Architecture logicielle : par où commencer sur Le Chantier, le plan de lecture de la série Architecture, un étage en dessous : concevoir un système une fois que l'entreprise a décidé qu'il devait exister.