Sur le plan, « voie double électrifiée, ERTMS niveau 2 »

Ouvre le dossier d'études d'une ligne nouvelle. Sur le plan, chaque tronçon porte une légende courte : « voie double électrifiée, signalisation ERTMS niveau 2 ». Quelques mots, et tout planificateur du réseau sait de quoi on parle, ce que ça permet et ce que ça exclut.

Descends sur le terrain cinq ans plus tard. Les rails viennent d'une aciérie, la caténaire d'un autre industriel, les balises de signalisation d'un troisième. Trois contrats, trois fournisseurs, trois stocks de pièces de rechange. Et pourtant le tronçon livré correspond à la légende du plan.

Cet écart entre la légende et le matériel est tout le sujet du billet. TOGAF l'a nommé : la brique d'architecture d'un côté, la brique de solution de l'autre. Et puisqu'on utilise le vocabulaire du standard, autant regarder le standard lui-même : à quoi il sert, comment il est construit, ce qu'on a le droit d'en changer.

La légende sur le plan et le matériel acheté pour la réaliser sont deux objets distincts. Les confondre revient à signer un bon de commande avant d'avoir décidé ce dont on a besoin.

Vue d'ensemble : deux outils de pensée

Avant d'entrer dans la méthode, il reste deux outils de pensée à poser. Ils reviendront dans chaque phase de l'ADM.

Le premier est la brique (building block). Une architecture se décrit comme un assemblage de briques : des paquets de fonctionnalités reconnaissables, typés par le métamodèle, réutilisables. La brique existe en deux versions. La brique d'architecture (ABB) décrit la capacité attendue. La brique de solution (SBB) la réalise avec un produit ou un développement précis.

Le second est le standard lui-même. Le TOGAF Standard, 10e édition, publié par The Open Group, est le cadre de référence de cette série. On va voir ce qu'il promet, pourquoi il tient cette promesse, comment il est découpé, et comment on l'adapte sans le vider de son sens.

Les deux sujets se répondent. Le standard décrit un cycle de changement dont la matière première est précisément la brique : chaque phase en produit, en consomme ou en transforme.

Les briques sont ce que l'architecture manipule. Le standard est la manière de les manipuler. On les sépare dans un billet par commodité, jamais dans la pratique.

La brique : un paquet de fonctionnalités qu'on reconnaît

Un cheminot n'a pas besoin qu'on lui décrive un poste d'aiguillage pièce par pièce. Il sait ce que c'est, où ça commence, où ça finit, à quoi ça se raccorde. Le poste d'aiguillage est une brique : un objet que les experts du domaine reconnaissent d'un coup d'œil, avec une frontière nette.

Ce que le standard en dit

Le TOGAF Standard définit la brique comme un composant de capacité d'entreprise, potentiellement réutilisable, qu'on combine avec d'autres pour livrer des architectures et des solutions. Quatre traits la caractérisent.

C'est un paquet de fonctionnalités défini pour répondre à des besoins métier, à l'échelle de l'organisation. Elle a un type qui correspond au métamodèle de contenu : un service métier, un composant applicatif, un composant technologique, une entité de données. Elle a une frontière définie, et les experts du domaine la reconnaissent comme « une chose » sans qu'on la leur explique. Enfin elle peut interopérer avec d'autres briques, dont elle dépend ou qui dépendent d'elle.

Une brique se décrit à plusieurs niveaux de détail. Tôt dans le cycle, c'est un nom et une phrase : « gestion des identités clients ». Plus tard, c'est une fiche complète avec interfaces, dépendances et contraintes. Le même objet, affiné au fil des phases, exactement comme les niveaux d'abstraction du billet précédent font descendre une architecture du contextuel au physique.

Les cinq caractéristiques d'une bonne brique

Toutes les briques ne se valent pas. Le standard décrit ce qui fait une brique bien conçue. Les voici en cinq tuiles.

Les cinq caractéristiques d'une bonne brique
1. Elle évolue
Elle tient compte de son implémentation et de son usage, et suit la technologie et les standards.
2. Elle se remplace
Réutilisable d'une architecture à l'autre, remplaçable sans redessiner le reste, bien spécifiée.
3. Elle s'assemble
Composée d'autres briques, ou sous-ensemble d'une brique plus large.
4. Elle interopère
Par des interfaces publiées et stables : ses voisins ne la connaissent que par là.
5. Elle se découple
Sa frontière et sa spécification sont faiblement couplées à son implémentation.
Les deux tuiles cuivre décident de la remplaçabilité. Les trois autres en découlent.

Les deux dernières tuiles sont celles qui coûtent le plus cher quand on les néglige. Une brique dont la frontière épouse l'implémentation d'un produit ne se remplace plus : changer le produit revient à redessiner l'architecture autour. Une brique sans interface stable oblige chaque voisin à se réécrire dès qu'elle bouge.

Une bonne brique se juge à une question : « si je remplace ce qu'il y a dedans, qui d'autre doit changer ? ». Quand la réponse est « tout le monde », on a dessiné un bloc, pas une brique.

ABB contre SBB : le plan et le matériel

Retour au plan. « Voie double électrifiée, ERTMS niveau 2 » décrit une capacité : faire circuler des trains dans les deux sens, sous caténaire, avec un contrôle continu de la vitesse. Aucun fournisseur n'est nommé, aucune référence de catalogue. C'est une brique d'architecture.

Les rails livrés par l'aciérie, la caténaire posée par l'industriel, les balises installées le long de la voie forment la brique de solution. Elle réalise la capacité, avec des produits précis, des versions, des contrats de maintenance.

flowchart LR P["Sur le plan
voie double électrifiée,
ERTMS niveau 2"] ABB["Brique d'architecture (ABB)
la capacité requise,
indépendante du fournisseur"] SBB["Brique de solution (SBB)
le produit ou le composant
qui réalise la capacité"] T["Sur le terrain
rails, caténaire, balises
de trois fournisseurs"] P --> ABB ABB -->|façonne la spécification| SBB SBB -->|implémente la capacité| ABB SBB --> T classDef plan fill:#ede9e1,stroke:#5f5e5a,color:#1a1a1a classDef abb fill:#8a4d16,stroke:#5f5e5a,color:#f5f2ec classDef sbb fill:#d89253,stroke:#5f5e5a,color:#1a1a1a class P,T plan class ABB abb class SBB sbb

La brique d'architecture (ABB, Architecture Building Block) capture les exigences d'architecture. Elle décrit la fonctionnalité attendue et ses attributs, ses interfaces, les briques dont elle dépend, et son rattachement aux entités métier et aux politiques de l'organisation. Elle reste indépendante du fournisseur : plusieurs réalisations sont possibles, et c'est voulu.

La brique de solution (SBB, Solution Building Block) définit les produits ou les composants qui implémentent cette fonctionnalité. Elle connaît le fournisseur et le produit. Elle porte les attributs concrets : performance, configurabilité, contraintes, choix de conception.

Le sens des flèches compte. L'ABB façonne la spécification de la SBB : elle dit ce que la solution doit satisfaire. La SBB implémente la capacité décrite par l'ABB : elle rend le service réel. Dans l'ADM, les phases B, C et D produisent surtout des ABB. La phase E commence à leur associer des SBB candidates, et la phase F décide lesquelles seront livrées, et quand.

Un gabarit minimal tient en quelques lignes.

# Fiche de brique, gabarit maison : la même capacité vue des deux côtés
abb:
  nom: Gestion des identités clients
  type: Service applicatif            # type pris dans le métamodèle
  fonctionnalite: authentifier les clients finaux et fédérer leurs identités
  interfaces:
    - OpenID Connect
    - SCIM, pour le provisionnement des comptes
  depend_de:
    - Référentiel client
  independante_du_fournisseur: true
sbb:
  realise: Gestion des identités clients
  produit: Keycloak                   # ici un produit nommé, une version, un contrat
  version: celle validée par l'équipe plateforme
  configuration:
    - un realm par marque
    - fédération vers l'annuaire interne
  contraintes:
    - hébergement dans l'Union européenne

Dernier point, souvent oublié. La façon de regrouper fonctionnalités, produits et développements en briques varie énormément d'une architecture à l'autre, et le standard ne l'impose pas. C'est l'organisation qui décide de l'arrangement de briques qui lui convient. Ce choix est lui-même une décision d'architecture, à documenter comme les autres.

L'ABB répond à « de quoi avons-nous besoin ? ». La SBB répond à « avec quoi le faisons-nous ? ». Tant que la seconde n'est pas adossée à la première, on achète à l'aveugle.

Le standard TOGAF

Un réseau ferré national tient grâce à des normes que personne ne renégocie à chaque ligne : l'écartement de 1 435 mm, la tension d'alimentation, le système de signalisation. Ces normes ne disent pas où construire la ligne. Elles disent comment la construire pour que les trains des autres exploitants puissent y rouler.

Le TOGAF Standard joue ce rôle pour l'architecture d'entreprise. Son éditeur, The Open Group, le présente comme un cadre pour développer une architecture d'entreprise dans tout contexte : organisation publique ou privée, groupe ou division, entreprise agile ou programme de transformation numérique.

Trois traits le définissent.

C'est le produit d'une communauté. Le standard est élaboré et maintenu par les membres de l'Architecture Forum de The Open Group, pas par un éditeur de logiciel ni par un cabinet de conseil. Ses évolutions passent par un consensus entre organisations qui ne se commandent pas les unes les autres.

Il décrit un cycle de changement. Le cœur du standard est une méthode, l'ADM, qui fait passer une architecture d'un état de référence à un état cible par étapes gouvernées. Le billet suivant lui est consacré.

Il décrit les briques qui livrent les services métier et les systèmes d'information. Le standard ne se limite pas à la méthode. Il fournit un métamodèle, des artefacts types et des livrables, pour que le résultat de la méthode soit descriptible, comparable d'un cycle à l'autre et réutilisable.

La 10e édition, publiée en 2022, est consultable en ligne. TOGAF est une marque de The Open Group : on cite l'éditeur, on renvoie vers le texte, on ne le recopie pas.

Le standard ne te dit pas quelle architecture construire. Il te dit comment la décrire, la faire évoluer et la gouverner pour que d'autres puissent s'y raccorder.

Pourquoi il convient

Deux réseaux voisins qui n'ont pas le même écartement se rejoignent à la frontière par un changement d'essieux ou une rupture de charge. Ça fonctionne. C'est lent, coûteux, et personne ne le choisirait en partant de zéro. L'intérêt d'un standard commun est d'éviter d'avoir à inventer la jonction.

Le standard avance quatre raisons de l'adopter plutôt que de partir d'une feuille blanche.

L'efficacité. Une méthode éprouvée, un vocabulaire partagé et des gabarits existants évitent de redécouvrir à chaque cycle ce qu'est une vision d'architecture ou un contrat d'architecture. Les équipes, les fournisseurs et les auditeurs parlent la même langue.

Des solutions réalisables et économiques. L'ADM impose d'évaluer la faisabilité, le coût et la valeur avant d'engager l'implémentation. L'architecture ne s'arrête pas au schéma. Elle va jusqu'au plan de migration et au suivi de la réalisation.

Un développement standardisé et dérisqué. Les livrables ont une forme connue et les points de contrôle sont placés aux mêmes endroits d'un cycle à l'autre. Un projet qui dérive se voit plus tôt, parce qu'on sait à quel moment du cycle on devrait être et ce qui devrait exister à ce moment-là.

Un résultat cohérent, fidèle aux parties prenantes. Le standard reprend d'ISO/IEC/IEEE 42010 la chaîne partie prenante, préoccupation, point de vue, vue. L'architecture produite répond aux préoccupations identifiées, pas à l'intuition d'un architecte seul dans son bureau.

Un standard ne rend pas une architecture bonne. Il rend ses défauts visibles plus tôt, et par des gens qui ne l'ont pas écrite.

Adapter et intégrer sans trahir

Chaque réseau national roule sur les spécifications européennes d'interopérabilité, puis ajoute ses règles maison : procédures d'exploitation, gabarits de maintenance, habilitations du personnel. Personne ne touche à l'écartement. Tout le monde adapte le reste.

Le standard est explicite là-dessus : il doit être adapté aux processus et à l'organisation qui l'utilisent. Un cadre appliqué tel quel, sans tenir compte de la gouvernance en place et des autres référentiels, produit du papier. L'adaptation est une étape de la méthode, prévue dès la phase préliminaire.

Quatre mouvements sont possibles, et ils se combinent.

Mouvement Ce qu'on fait Exemple Ce qui ne doit pas bouger
Adopter Reprendre des éléments d'autres cadres d'architecture Un modèle de capacités métier venu d'un cadre sectoriel Le cycle de l'ADM et ses points de contrôle
Remplacer ou étendre Substituer ses propres livrables aux livrables génériques, ou en ajouter Un dossier d'architecture maison à la place du document de définition La traçabilité des exigences jusqu'aux briques
Intégrer Articuler le standard avec les cadres de gestion déjà en place ITIL pour l'exploitation, COBIT pour la gouvernance IT, PRINCE2 pour les projets Qui décide quoi, écrit noir sur blanc
Utiliser seul Faire du standard l'unique cadre de la capacité d'architecture Une organisation sans référentiel préexistant Le vocabulaire : un terme, un sens

Le point d'intégration le plus fréquent concerne la gestion de projet et l'exploitation. L'ADM dit ce qu'il faut concevoir et dans quel ordre. PRINCE2 ou une méthode agile disent comment conduire le projet qui le réalise. ITIL dit comment exploiter ce qui a été livré, et COBIT comment gouverner l'ensemble du système d'information. Les cadres se recouvrent aux frontières, et c'est là qu'il faut écrire qui tranche.

Ce qui ne s'adapte pas se résume vite : le cycle, la traçabilité des exigences aux briques, et le vocabulaire. Une organisation qui appelle « brique » un composant dans un document et « module » le même objet dans un autre perd en six mois ce que le standard lui avait apporté.

Adapter le standard, c'est remplacer ses gabarits par les tiens sans changer ce que chaque gabarit doit prouver. Une adaptation qui fait disparaître une preuve a changé de nature.

La structure du standard

Le référentiel documentaire d'une autorité ferroviaire a toujours la même forme : un règlement général, court, que tout le monde doit connaître, puis des fascicules par métier que seuls les intéressés lisent en entier.

Le TOGAF Standard, 10e édition, est construit sur ce principe. Il sépare un contenu fondamental, stable et valable partout, de guides de série qui approfondissent un sujet ou un contexte sans toucher au socle.

La structure du TOGAF Standard, 10e édition
Contenu fondamental · six documents
1. Introduction et concepts de base
2. La méthode de développement d'architecture (ADM)
3. Les techniques de l'ADM
4. Appliquer l'ADM
5. Le contenu d'architecture
6. Capacité d'architecture et gouvernance
Stable, universel, c'est la règle du jeu.
Guides de série · par sujet ou contexte
Architecture métier
Architecture de l'information
Sécurité
Agilité d'entreprise
Entreprise numérique
Architecture technologique
Microservices et orientation service
Adaptation de l'ADM à un contexte
Nombreux, évolutifs, aucun n'est requis pour appliquer le socle.

Le contenu fondamental tient en six documents. Introduction et concepts de base pose le vocabulaire et les notions de ce palier. L'ADM décrit le cycle, phase par phase. Les techniques de l'ADM regroupent les méthodes réutilisables : principes d'architecture, scénarios métier, analyse d'écarts, gestion des risques, entre autres. Appliquer l'ADM traite des itérations, des niveaux et des partitions. Le contenu d'architecture définit le métamodèle, les artefacts, les livrables et les briques. Capacité d'architecture et gouvernance décrit l'organisation qui fait tourner le tout.

Un choix de conception mérite d'être relevé. Les techniques sont décrites à part, dans leur propre document, plutôt que répétées dans chaque phase. L'ADM y renvoie aux points utiles. Ça évite les doublons, et une technique peut évoluer sans qu'on réédite la méthode.

Les guides de série, eux, sont nombreux et vivent à leur rythme. Ils couvrent entre autres l'architecture métier, l'architecture de l'information, la sécurité, l'agilité, l'entreprise numérique, l'architecture technologique, les microservices et l'orientation service, ainsi que l'adaptation de l'ADM à des contextes particuliers. Chacun répond à une question que le socle laisse ouverte.

La bibliothèque TOGAF

Autour du standard, The Open Group entretient la TOGAF Library, gérée par l'Architecture Forum. Elle rassemble ce qui ne fait pas partie du standard mais aide à l'appliquer.

Type de ressource Ce qu'on y trouve Quand s'en servir
Guides Comment appliquer une partie du standard dans un contexte donné Au moment d'adapter le cadre à son organisation
Livres blancs Positions, retours d'expérience, sujets émergents Pour instruire un choix encore ouvert
Modèles de référence Des architectures génériques dont on part plutôt que d'une page blanche En phase B, C ou D, comme point de départ à spécialiser
Fiches et gabarits Des trames de livrables et d'artefacts Pour ne pas redessiner la forme d'un livrable à chaque cycle

Rien de tout ça n'est obligatoire. La bibliothèque est une boîte à outils, le standard est la règle du jeu. Le billet sur le référentiel reviendra sur la manière dont ces ressources génériques se spécialisent jusqu'aux règles maison, le long du continuum d'entreprise.

Le socle est court et stable. Tout ce qui est long ou mouvant vit dans les guides et la bibliothèque. Quand un document te paraît trop volumineux pour être une règle, vérifie d'abord dans quelle colonne il se trouve.

Scénario B : le SAP Enterprise Architecture Framework

L'adaptation décrite plus haut a une illustration publique récente, venue d'un éditeur de logiciels.

En 2023, SAP a publié son SAP Enterprise Architecture Framework, présenté sur ses pages publiques comme fondé sur TOGAF puis adapté à son portefeuille. L'éditeur décrit un cadre à plusieurs composantes : une méthodologie dérivée de l'ADM, des modèles de référence propres à SAP (une architecture métier de référence et une architecture de solution de référence) et un catalogue d'artefacts.

Ce que SAP dit avoir gardé, c'est la méthode et le vocabulaire. Les phases de l'ADM restent le squelette de la méthodologie, et les termes du standard restent les termes du cadre. Un lecteur qui connaît TOGAF s'y repère sans apprendre une nouvelle langue.

Ce que SAP dit avoir étendu et spécialisé, ce sont les livrables. Là où le standard fournit des gabarits neutres, le cadre de SAP fournit des modèles pré-remplis avec les capacités métier et les composants de solution de son portefeuille, et un catalogue d'artefacts recommandés, complété d'artefacts additionnels.

Pour notre sujet, l'intérêt est double.

D'abord, c'est la mécanique d'adaptation décrite plus haut, exécutée en grand : adopter le cycle, étendre les livrables, livrer des modèles de référence spécifiques. Le mouvement « remplacer ou étendre » du tableau d'adaptation, appliqué à l'échelle d'un portefeuille entier.

Ensuite, c'est une leçon sur la frontière entre ABB et SBB. Un modèle de référence d'éditeur tire naturellement vers la brique de solution : le composant est nommé, le produit est connu. L'organisation qui adopte un tel cadre doit garder sa propre couche de briques d'architecture, indépendante du fournisseur, sinon elle perd la capacité de comparer et de remplacer. Le cadre de SAP ne l'en empêche pas. Il ne le fait pas non plus à sa place.

On s'arrête là. Les pages publiques de SAP décrivent le cadre. Elles ne publient pas de bilan d'adoption chez ses clients, et ce billet n'en invente pas.

Un éditeur qui reprend TOGAF et le spécialise prouve que le standard s'adapte. Il rappelle aussi le prix de l'adaptation : plus les briques de référence sont concrètes, plus il faut tenir sa propre couche d'ABB au-dessus.

Points clés

  • Une brique est un paquet de fonctionnalités typé par le métamodèle, reconnaissable par les experts du domaine, décrit à plusieurs niveaux de détail et réutilisable d'une architecture à l'autre.
  • Une bonne brique évolue avec les standards, se remplace, s'assemble, interopère par une interface stable, et sa frontière reste découplée de son implémentation.
  • L'ABB décrit la capacité requise sans nommer de fournisseur ; la SBB la réalise avec un produit ou un développement précis. L'une façonne la spécification, l'autre implémente la capacité.
  • Le TOGAF Standard, 10e édition, publié par The Open Group, sépare un socle de six documents fondamentaux de guides de série spécialisés, complétés par la TOGAF Library ; les techniques sont décrites à part et référencées depuis l'ADM.
  • Le standard doit être adapté (adopter, remplacer ou étendre, intégrer avec ITIL, COBIT ou PRINCE2, ou servir seul) sans toucher au cycle, à la traçabilité ni au vocabulaire ; le cadre d'architecture de SAP, dérivé de TOGAF, en est une illustration publique.

Dans la série

Palier 1 : Tracer la ligne. Domaine : Concepts.

Pour aller plus loin