La ligne roule, et une commune réclame un arrêt
Le tronçon a été homologué, les premiers trains commerciaux circulent depuis six mois. Le planificateur n'a pas rangé ses dossiers pour autant. Il compte les voyageurs réels et les compare aux prévisions de l'étude de trafic. Il lit les retards, les incidents, les réclamations.
Et le courrier arrive. Une commune traversée par la ligne demande un arrêt qui n'était pas au schéma directeur. Un exploitant veut allonger ses rames. Le régulateur annonce une nouvelle norme de signalisation à horizon cinq ans.
Aucune de ces demandes n'est absurde. Aucune ne peut être acceptée sur un coin de table non plus, parce que chacune touche la grille horaire, la capacité de la ligne, les autres exploitants.
En architecture d'entreprise, ce moment porte un nom dans le TOGAF Standard : la phase H, gestion du changement d'architecture. Et le registre dans lequel ces demandes s'inscrivent, se trient et reçoivent une réponse, c'est la gestion des exigences, le processus au centre du cadran de l'ADM.
Ce billet traite les deux ensemble, parce qu'elles ne vivent pas l'une sans l'autre. H décide ce qu'on fait d'un changement. La gestion des exigences garde la trace de ce qui a été demandé, par qui, et de ce qui en a été fait.
Une architecture approuvée n'est pas une architecture finie. Elle est en service, donc exposée à des demandes qu'il faut compter, qualifier et arbitrer. La phase H existe pour que ces décisions ne se prennent pas par défaut.
Ce que la phase H surveille
Sur le réseau, la direction de la planification ne regarde pas les trains passer. Elle tient trois comptes : le service rendu face au service promis, les écarts entre le tracé validé et ce qui a été construit, et la file des demandes qui s'accumulent.
La phase H fait exactement cela pour une architecture.
Sa finalité, telle que le TOGAF Standard publié par The Open Group la décrit, tient en quatre points. Vérifier que la valeur promise à la fin du cycle précédent arrive bien : c'est la réalisation de la valeur. Repérer les écarts entre l'architecture cible approuvée et ce que l'implémentation a réellement produit. Gérer les changements de préférence, de priorité et d'exigence qui surviennent après la mise en service. Et produire une sortie unique : la direction que devra prendre la prochaine cible.
Ses objectifs sont plus organisationnels. Maintenir le cycle de vie de l'architecture, pour qu'il ne s'arrête pas une fois le dernier projet livré. Exécuter le cadre de gouvernance d'architecture, celui que la phase préliminaire a posé et que la phase G a mis en pratique. Et garder la capacité d'architecture elle-même au niveau des besoins de l'entreprise : une équipe dimensionnée pour un cycle ne l'est pas forcément pour le suivant.
Le cadran dit l'essentiel. H ferme le cycle et en ouvre un autre : sa sortie mène vers A. Et la gestion des exigences, au centre, reçoit ce que H constate comme elle reçoit ce que chaque autre phase découvre.
La phase H livre une décision plutôt qu'une architecture : continuer à exploiter la cible telle qu'elle est, l'ajuster à la marge, ou relancer un cycle complet.
Les sept étapes
Le planificateur du réseau a une routine : collecter les comptages, surveiller les signaux faibles, tenir à jour l'étude de danger, analyser, proposer, faire valider, lancer.
La phase H suit le même enchaînement, en sept étapes.
de réalisation de la valeur"] --> S2["2. Déployer les outils
de surveillance"] S2 --> S3["3. Gérer les risques"] S3 --> S4["4. Analyser pour la gestion
du changement d'architecture"] S4 --> S5["5. Formuler les exigences de changement
pour tenir les cibles de performance"] S5 --> S6["6. Gérer le processus
de gouvernance"] S6 --> S7["7. Déclencher le processus
qui implémente le changement"] S7 -.->|"changement courant ou nouveau cycle"| S1 classDef mesure fill:#d89253,stroke:#8a4d16,color:#2c3338; classDef analyse fill:#f5f2ec,stroke:#8a4d16,color:#1a1a1a; classDef decision fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; class S1,S2,S3 mesure; class S4,S5 analyse; class S6,S7 decision;
Les trois premières étapes installent la mesure. Le processus de réalisation de la valeur dit comment on vérifiera que les bénéfices promis dans la vision d'architecture se matérialisent, avec quels indicateurs et à quelle échéance. Les outils de surveillance alimentent ces indicateurs : suivi des coûts, performance des services, usage réel des applications, veille technologique. La gestion des risques reprend le registre ouvert en phase E et le tient à jour, parce qu'un risque accepté avant la mise en service peut changer de nature une fois le système en production.
Les deux suivantes analysent. L'étape 4 croise ce que la surveillance remonte avec les demandes reçues, et qualifie chaque écart. L'étape 5 transforme ce qui l'exige en exigences de changement, formulées pour ramener le système vers ses cibles de performance ou pour redéfinir ces cibles.
Les deux dernières décident. L'étape 6 fait passer ces exigences par le processus de gouvernance : conseil d'architecture, parties prenantes concernées, dispenses éventuelles. L'étape 7 déclenche ce qui a été décidé, soit par la gestion courante du changement, soit par une nouvelle demande de travaux d'architecture qui rouvre la phase A.
Sans processus de réalisation de la valeur posé dès la première étape, la phase H n'a rien à comparer. Elle devient une boîte aux lettres pour demandes de changement, sans moyen de dire si l'architecture en service tient ses promesses.
Les déclencheurs du changement
Deux sortes de nouvelles arrivent sur le bureau du planificateur. Celles qui viennent de la technique : un constructeur retire un modèle de rame du catalogue, une norme européenne de signalisation s'impose. Et celles qui viennent du service : un nouveau pôle d'activité réclame une desserte, une région change de stratégie de mobilité.
Le TOGAF Standard range les déclencheurs d'un changement d'architecture de la même manière, en deux familles.
| Origine | Déclencheur | Ce qu'il remet en cause |
|---|---|---|
| Technologie | Rapports sur de nouvelles technologies | Des briques technologiques cibles qui ont une alternative meilleure ou moins chère |
| Technologie | Réduction de coûts sur le parc d'actifs | Le dimensionnement et la répartition de l'infrastructure |
| Technologie | Retrait d'une technologie par son fournisseur | Des briques de solution en service, avec une date butoir |
| Technologie | Initiatives de standardisation | Le choix de briques hors standard, à faire converger |
| Métier | Développements courants de l'activité | Des capacités métier à faire évoluer sans changer la stratégie |
| Métier | Exceptions métier | Des cas que la cible n'avait pas prévus et qu'on traite à la main |
| Métier | Innovations métier | De nouveaux produits ou services, donc de nouvelles capacités |
| Métier | Innovations technologiques du métier | Des usages numériques venus des métiers eux-mêmes |
| Métier | Changement stratégique | Les objectifs qui fondaient la vision d'architecture |
La distinction compte pour l'arbitrage. Un déclencheur technologique touche souvent une brique ou une couche, et le changement reste localisé. Un déclencheur métier, surtout stratégique, remonte jusqu'aux principes et à la vision : il a toutes les chances de rouvrir le cycle.
Il y a aussi des déclencheurs que la surveillance de H produit elle-même. Un indicateur de valeur qui ne décolle pas six mois après la mise en service est un déclencheur à part entière, même si personne n'a déposé de demande.
Un déclencheur ouvre un dossier, rien de plus. L'évaluation d'impact et la classification diront si ce dossier mérite une dispense, un ajustement ou un nouveau cycle.
La demande de changement
La commune n'écrit pas « on veut un arrêt » sur une carte postale. Elle dépose un dossier : la demande, les raisons, une première estimation de ce que ça change pour la grille horaire et pour les autres gares.
La demande de changement d'architecture joue ce rôle. Le TOGAF Standard la définit comme un écart par rapport à l'approche architecturale retenue, né d'un apprentissage pendant l'implémentation ou d'un facteur extérieur, et susceptible de relancer un cycle. Son contenu est normé.
Les quatre zones se lisent dans l'ordre. La description dit ce qu'on veut changer. La justification dit pourquoi, et renvoie si possible à un déclencheur identifié. L'évaluation d'impact est le cœur du document : quelles exigences existantes sont concernées, quelle priorité les parties prenantes leur accordent, quelles phases de l'ADM il faudrait revisiter, et ce que l'équipe d'architecture recommande. La référence au dépôt relie la demande aux artefacts qu'elle vise.
Qui la rédige, et quand ? Deux phases en produisent, une seule en dispose.
| Phase | Rôle vis-à-vis de la demande de changement |
|---|---|
| F. Planification de la migration | Création, quand le découpage en projets révèle qu'une partie de la cible n'est pas réalisable telle quelle |
| G. Gouvernance de l'implémentation | Création, quand une revue de conformité constate un écart que le projet ne peut pas corriger seul |
| H. Gestion du changement d'architecture | Évaluation, classification et décision, puis déclenchement du changement ou d'un nouveau cycle |
Ce partage évite un travers courant : l'équipe projet qui, en phase G, découvre que la cible ne colle pas au terrain et la modifie elle-même, sans que personne ne mesure l'effet sur les autres projets. La demande de changement rend l'écart visible et le fait remonter là où il sera arbitré.
Une demande de changement sans évaluation d'impact est une opinion. Ce qui en fait un livrable, c'est la liste des exigences touchées et des phases à rouvrir.
Simplifier, ajuster ou refaire le cycle
Toutes les demandes ne se valent pas. Remplacer les bancs d'un quai se décide au niveau de la gare. Ajouter un arrêt impose de réécrire la grille horaire de la ligne. Dévier le tracé pour desservir une nouvelle zone relance une étude complète, avec enquête publique.
La phase H fait ce tri. Le TOGAF Standard précise que le processus de gestion du changement doit déterminer deux choses : dans quelles conditions l'architecture peut être modifiée après implémentation sans repasser par un cycle, et à partir de quand un nouveau cycle s'impose. Les critères reposent sur la valeur : ce que le changement apporte, ce qu'il coûte, et ce qu'il casse.
Trois classes en ressortent.
| Classe | Ce qui la caractérise | Ce qu'on en fait |
|---|---|---|
| Simplification | Le changement réduit un investissement ou une complexité sans toucher au cadre ; une seule partie prenante est concernée, ou une dispense suffit | Gestion courante du changement, hors cycle de l'ADM |
| Changement incrémental | Le changement tire une valeur supplémentaire de l'investissement existant ; plusieurs parties prenantes sont concernées, mais la vision et les principes tiennent | Ré-architecture partielle, sur les phases touchées |
| Ré-architecture | Le changement remet en cause la vision, les principes ou la portée de l'architecture ; il crée un nouvel investissement | Nouveau cycle complet, à partir d'une demande de travaux d'architecture |
L'arbre de décision ci-dessous résume la logique. Les deux premiers tests portent sur la nature du changement, le troisième sur la gouvernance disponible.
évaluée en phase H"] --> Q1{"La vision, les principes
ou la portée changent-ils ?"} Q1 -->|oui| RA["Ré-architecture
nouveau cycle, retour en phase A"] Q1 -->|non| Q2{"Plusieurs parties prenantes
sont-elles impactées ?"} Q2 -->|oui| INC["Changement incrémental
ré-architecture partielle"] Q2 -->|non| Q3{"Une dispense
peut-elle couvrir l'écart ?"} Q3 -->|oui| SIMP["Simplification
gestion courante du changement"] Q3 -->|non| INC classDef question fill:#f5f2ec,stroke:#8a4d16,color:#1a1a1a; classDef simple fill:#ede9e1,stroke:#8a4d16,color:#2c3338; classDef partiel fill:#d89253,stroke:#8a4d16,color:#2c3338; classDef complet fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; class CR,Q1,Q2,Q3 question; class SIMP simple; class INC partiel; class RA complet;
Le point délicat est le passage de « incrémental » à « ré-architecture ». Une entreprise qui classe tous ses changements en incrémental finit par exploiter une architecture dont la vision n'a jamais été approuvée par personne. L'inverse, relancer un cycle pour chaque demande, paralyse. Le critère de la vision remise en cause est la ligne de partage.
Classer un changement, c'est décider combien de personnes il mobilise et quel niveau de gouvernance il réveille. Mal classer coûte dans les deux sens : trop lourd et plus rien n'avance, trop léger et la cible dérive sans que personne l'ait décidé.
La gestion des exigences
Pendant l'enquête publique d'une ligne nouvelle, chaque observation est consignée dans un registre. Le registre ne décide rien. Il garantit que chaque remarque a été lue, numérotée, rattachée à une partie du dossier et qu'une réponse lui a été apportée. Et il reste ouvert bien après l'enquête, jusqu'à la mise en service et au-delà.
La gestion des exigences est ce registre, au centre du cadran de l'ADM.
Sa finalité, dans le TOGAF Standard : gérer les exigences d'architecture tout au long de l'ADM, faire fonctionner le processus qui les reçoit et les restitue, assurer leur traçabilité depuis la vision, la mission, le modèle d'affaires et la stratégie de l'entreprise, et maintenir un ensemble complet d'exigences, y compris les préférences des parties prenantes, qui ne sont pas des exigences dures mais pèsent sur les arbitrages.
Ses objectifs tiennent en trois lignes. Que le processus soit soutenu et opère pour toutes les phases concernées. Que les exigences identifiées à chaque exécution d'une phase soient capturées. Que les exigences pertinentes soient disponibles pour chaque phase au moment où elle s'exécute.
Ce dernier point explique la position au centre du cadran. La phase B a besoin des exigences métier posées en A ; la phase E a besoin des exigences consolidées de B, C et D ; la phase H a besoin de l'ensemble, pour évaluer une demande de changement. Le processus les sert à toutes.
Les dix pas, et qui fait quoi
Le TOGAF Standard décrit le fonctionnement en dix pas, répartis entre le processus de gestion des exigences et la phase de l'ADM en cours. La répartition est la clé de lecture : le processus tient le registre, les phases font le travail.
| Le processus de gestion des exigences | La phase de l'ADM en cours |
|---|---|
| Identifie et documente les exigences, par les scénarios métier ou une technique équivalente | |
| Établit la base de référence des exigences : priorités, accord des parties prenantes, enregistrement dans le dépôt | |
| Surveille la base de référence pendant son exécution | |
| Identifie les exigences changées : ajout, modification, suppression, et réévalue les priorités | |
| Enregistre les exigences changées et leurs priorités, identifie et résout les conflits, produit l'évaluation d'impact | |
| Évalue l'impact des exigences changées sur la phase en cours et sur les phases précédentes | |
| Décide si le changement est traité dans le cycle en cours ou reporté à un cycle ultérieur | |
| Implémente les exigences issues de la phase H | |
| Met à jour le dépôt des exigences avec les informations relatives aux changements demandés | |
| Implémente le changement dans la phase en cours, puis révise l'analyse d'écarts des phases passées |
L'aller-retour entre une phase et le processus se lit mieux en séquence. Prenons une phase C qui découvre, en modélisant les flux de données, une exigence de rétention que personne n'avait formulée en A.
Ce qu'on voit sur la séquence : le processus enregistre, détecte les conflits, évalue l'impact et rend la main. La phase décide, avec ses parties prenantes, et revient inscrire sa décision.
La gestion des exigences ne dispose d'aucune exigence. Elle les reçoit, les relie, en mesure l'impact et les restitue. Trancher reste le travail de la phase concernée et de ses parties prenantes.
L'évaluation d'impact des exigences
Quand la commune demande son arrêt, le bureau d'études ne répond pas oui ou non. Il rend une note : ce que l'arrêt change pour le temps de parcours, pour les sillons des autres exploitants, pour la gare suivante, et ce qu'il recommande.
L'évaluation d'impact des exigences est cette note. Le TOGAF Standard la décrit comme l'évaluation des exigences et de la spécification des exigences d'architecture pour identifier les changements à apporter et leurs implications. Son contenu est stable d'une entreprise à l'autre.
| Élément | Ce qu'il contient |
|---|---|
| Exigences concernées | La référence précise des exigences touchées, et la priorité que les parties prenantes leur ont donnée jusqu'ici |
| Phases à revisiter | Les phases de l'ADM dont le résultat doit être repris, et celle qui pilote la résolution |
| Résultats | Ce que les investigations dans ces phases ont établi, et les priorités révisées qui en découlent |
| Recommandations | Ce que l'équipe d'architecture propose pour la gestion de ces exigences : traiter maintenant, reporter, refuser |
| Références | Les numéros de référence dans le dépôt d'architecture, pour relier la note aux artefacts et à la demande de changement |
Trois points de l'approche décrite par le standard restent à retenir.
Le processus est dynamique. Il ne tourne pas une fois par cycle, mais à chaque fois qu'une phase découvre ou modifie une exigence. Il alimente les phases et récupère ce qu'elles produisent.
Ce sont les phases qui disposent. Le processus de gestion des exigences ne traite pas une exigence, ne la priorise pas et ne la rejette pas. Il la rend visible à la phase qui doit le faire. L'évaluation d'impact est son outil pour cela : une recommandation, jamais une décision.
Le dépôt des exigences a une durée de vie différente des autres livrables. La spécification des exigences d'architecture et l'évaluation d'impact appartiennent à un cycle. Le dépôt, lui, traverse les cycles : il garde les exigences stratégiques, de segment et de capacité, avec leur historique. C'est ce qui permet, en phase H, de retrouver pourquoi une exigence a été acceptée trois ans plus tôt avant de décider de la changer.
Une exigence sans historique se réécrit à chaque cycle. Le dépôt des exigences est la mémoire qui évite de rejouer les mêmes arbitrages, et de refaire les mêmes erreurs.
Scénario B : Lidl et eLWIS, 2011-2018
En 2011, le groupe Lidl engage le remplacement de son système de gestion des marchandises, développé en interne, par une solution fondée sur SAP. Le programme s'appelle eLWIS. Il doit couvrir l'ensemble des pays où l'enseigne opère.
En juillet 2018, Lidl annonce l'arrêt du programme. D'après la presse économique allemande, Handelsblatt en tête, puis heise online et la presse spécialisée, le coût engagé se situe autour de 500 millions d'euros sur sept ans. Ce chiffre vient de la presse, pas d'un rapport d'audit public ; Lidl n'a pas communiqué de montant officiel.
Ce que les articles rapportent de la cause se lit directement avec la grille de ce billet.
Lidl valorise ses stocks au prix d'achat. Le progiciel, dans son standard pour la distribution, les valorise au prix de vente. Plutôt que d'aligner son processus sur le standard, l'enseigne a maintenu son exigence, ce qui a imposé des adaptations lourdes du système, avec les effets attendus sur la complexité, les délais et la dépendance à ces développements spécifiques.
Le système avait pourtant été mis en service dans plusieurs pays, d'après la même presse, avant que le déploiement général ne soit abandonné. Dans sa communication, Lidl a indiqué que les objectifs stratégiques définis au départ ne pouvaient pas être atteints avec un effort raisonnable, et a annoncé le retour à son système historique, qu'elle continuerait à développer.
Deux enseignements en ressortent.
D'abord, une exigence métier centrale est entrée en conflit avec la brique de solution choisie dès le début. Ce conflit relevait de la gestion des exigences : l'enregistrer, en mesurer l'impact, le soumettre aux parties prenantes avec deux options claires, changer le processus ou changer la solution. La presse ne décrit pas une telle évaluation d'impact rendue tôt et tranchée.
Ensuite, le conflit a été absorbé pendant des années par des adaptations successives, c'est-à-dire traité en changement incrémental, alors qu'il touchait un principe de gestion de l'entreprise, donc la classe « ré-architecture ». La décision de relancer ou d'arrêter est arrivée en 2018, quand la phase H aurait dû la poser bien plus tôt, avec un processus de réalisation de la valeur capable de montrer que les bénéfices attendus ne venaient pas.
Je m'en tiens à ce que les articles publics établissent. Les causes internes détaillées, le partage des responsabilités entre l'enseigne, l'éditeur et les intégrateurs, et le détail des sommes n'ont pas fait l'objet d'un rapport public.
Une exigence qu'on refuse d'arbitrer ne disparaît pas. Elle se paie en adaptations, année après année, jusqu'au jour où l'arbitrage se fait de lui-même, au prix le plus élevé.
Points clés
- La phase H vérifie que la valeur promise arrive, mesure les écarts entre cible approuvée et réalisation, et décide ce qu'on fait des demandes de changement. Sa sortie est la direction de la prochaine cible.
- Les déclencheurs sont technologiques ou métier. Les premiers restent souvent localisés ; les seconds, surtout stratégiques, rouvrent le cycle.
- Trois classes de changement : simplification (gestion courante), incrémental (ré-architecture partielle), ré-architecture (nouveau cycle). Le critère de partage est la remise en cause de la vision et des principes.
- La gestion des exigences tient le registre et produit l'évaluation d'impact ; elle ne décide rien. Les phases disposent, avec leurs parties prenantes.
- Le dépôt des exigences traverse les cycles, contrairement à la spécification et à l'évaluation d'impact. C'est la mémoire qui rend la phase H possible.
Dans la série
Palier 3 : Faire rouler les trains. Domaine : Pilotage.
- Précédent : Phase G : contrats d'architecture, conformité et équipes agiles
- Suivant : Appliquer l'ADM : itérations, phases concurrentes et compromis
- Vue d'ensemble : Architecture d'entreprise : par où commencer
Pour aller plus loin
- Phase G : contrats d'architecture, conformité et équipes agiles, pour les revues de conformité qui produisent une partie des demandes de changement.
- Appliquer l'ADM : itérations, phases concurrentes et compromis, pour l'itération de gouvernance qui enchaîne G et H.
- Le TOGAF Standard, 10e édition, publié par The Open Group : les sections Phase H, Architecture Change Management et Requirements Management, ainsi que la description des livrables Architecture Change Request et Requirements Impact Assessment.
- ISO/IEC/IEEE 42010, pour les notions de partie prenante et de préoccupation dont dérivent les exigences.
- ISO 31000, Management du risque, publiée par l'ISO (iso.org), pour la gestion des risques que l'étape 3 de la phase H reprend.
- Handelsblatt, juillet 2018, et heise online, juillet 2018 : articles sur l'arrêt du programme eLWIS par Lidl, source des chiffres et des faits rapportés dans le scénario B.