Une ligne sans convention signée reste un trait sur une carte
Le schéma directeur est validé. Le tracé est connu, les variantes ont été comparées, les lots de travaux sont découpés : terrassement, voie, signalisation, gares. Et pourtant rien ne bouge. Tant que le programme pluriannuel n'est pas écrit et que la convention de financement n'est pas signée, la ligne reste un trait sur une carte.
C'est le moment où le dossier change de nature. Jusqu'ici, on étudiait. À partir de maintenant, on engage de l'argent, des équipes et des dates. Chaque tronçon reçoit un coût, une année d'ouverture, un maître d'ouvrage. Et quelqu'un, au ministère ou à la région, dit oui ou non.
La phase F de l'ADM joue exactement ce rôle. La phase E a sorti une première feuille de route : des lots de travail, des architectures de transition, un brouillon de plan. La phase F en fait des projets datés, financés et acceptés, puis passe le relais à la gouvernance d'implémentation.
Dans le TOGAF Standard, publié par The Open Group, c'est l'une des phases les plus courtes à lire. En pratique, c'est l'une des plus décisives : c'est ici que la direction s'engage, ou pas.
Ce billet suit la phase dans l'ordre où elle se déroule : sa finalité, ses sept étapes, la façon de donner une valeur et une priorité à chaque lot, le modèle de gouvernance qu'elle lègue à la phase G, puis l'approche d'ensemble. Et pour finir, un cas réel, celui d'une migration bancaire dont le plan n'a pas joué son rôle de garde-fou.
La phase F ne dessine plus rien. Elle transforme une feuille de route en engagements : des projets, des coûts, des dates, et une signature.
La phase F en une page
Le planificateur du réseau n'a pas la main sur le budget de l'État, ni sur le calendrier des autres grands chantiers du pays. Son programme doit tenir dans une enveloppe, se glisser entre d'autres priorités, et rester lisible pour des élus qui ne liront jamais une notice technique.
La finalité de la phase F tient en trois points. Produire un plan d'implémentation et de migration détaillé, en coopération avec ceux qui gèrent les projets et les portefeuilles. Vérifier que les ressources existent et seront disponibles au bon moment. Et ordonner les lots par valeur, effort et risque, pour que les premières livraisons soient aussi les plus utiles.
Sa sortie se décrit tout aussi simplement : des projets approuvés, chacun avec ses objectifs, ses contraintes, ses ressources et ses dates. Plus un ensemble de livrables finalisés : la feuille de route, le document de définition d'architecture, la spécification des exigences, et le modèle de gouvernance d'implémentation que la phase G va utiliser.
Le standard lui fixe trois objectifs :
- finaliser la feuille de route d'architecture et le plan d'implémentation et de migration qui la soutient ;
- coordonner ce plan avec la manière dont l'entreprise gère et implémente le changement dans l'ensemble de son portefeuille ;
- faire comprendre aux parties prenantes clés la valeur métier et le coût de chaque lot de travail et de chaque architecture de transition.
Le deuxième objectif est celui qu'on oublie. Une architecture n'est jamais le seul changement en cours. Il y a d'autres programmes, d'autres budgets, d'autres équipes déjà prises. Le plan de la phase F doit s'y insérer, pas s'y superposer.
Sur le cadran, F est en bas à gauche, juste avant la remontée vers G. C'est la dernière phase où l'architecte produit de l'architecture.
La phase F est la dernière phase de développement de l'architecture. Tout ce qui suit, G et H, relève de la réalisation et du contrôle.
Les sept étapes
Avant d'inscrire un tronçon au programme, l'autorité d'infrastructure vérifie avec qui elle doit se coordonner : la direction du budget, la direction des grands projets, les exploitants qui feront rouler les trains le jour de l'ouverture. Chacun a son calendrier et ses règles. Le programme ne vaut que s'il parle à tous.
Le standard découpe la phase F en sept étapes. Elles s'enchaînent, mais comme toujours dans l'ADM, on y revient autant que nécessaire.
avec les cadres de management"] --> S2["2. Assigner une valeur métier
à chaque lot de travail"] S2 --> S3["3. Estimer ressources, délais
et véhicules de livraison"] S3 --> S4["4. Prioriser par coût et bénéfice,
valider les risques"] S4 --> S5["5. Confirmer la feuille de route,
mettre à jour le document de définition"] S5 --> S6["6. Compléter le plan
d'implémentation et de migration"] S6 --> S7["7. Clore le cycle,
documenter les leçons apprises"] S7 -.->|"passage de relais"| G["Phase G
Gouvernance de l'implémentation"] classDef etape fill:#d89253,stroke:#8a4d16,color:#2c3338; classDef decision fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; classDef sortie fill:#2c3338,stroke:#1f2428,color:#f5f2ec; class S1,S2,S3,S5,S6 etape; class S4,S7 decision; class G sortie;
Confirmer les interactions avec les cadres de management. Quatre cadres se croisent ici : la planification métier, qui fixe la stratégie et le budget ; l'architecture d'entreprise, qui porte la cible ; la gestion de portefeuille et de projet, qui exécute ; la gestion des opérations, qui exploitera le résultat. La première étape consiste à s'assurer que le plan parlera le langage de chacun : mêmes jalons, mêmes catégories de coût, mêmes instances de décision.
| Cadre de management | Ce qu'il apporte au plan | Ce que le plan lui apporte |
|---|---|---|
| Planification métier | Stratégie, enveloppe budgétaire, priorités de la direction | Un calendrier d'investissements lisible et justifié |
| Architecture d'entreprise | La cible, les transitions, les écarts, les principes | Des projets fidèles à la cible et traçables jusqu'aux exigences |
| Gestion de portefeuille et de projet | Méthodes, jalons, capacité réelle des équipes, projets déjà engagés | Des chartes de projet, des dépendances explicites, un véhicule de livraison par lot |
| Gestion des opérations | Contraintes d'exploitation, fenêtres de changement, coûts de fonctionnement | Des coûts d'exploitation anticipés et des transitions exploitables seules |
Assigner une valeur métier à chaque lot. On s'appuie sur des critères que l'entreprise reconnaît déjà : critères d'évaluation de la performance, retour sur investissement, facteurs clés de succès, mesures d'efficacité, adéquation stratégique. La section suivante détaille la mécanique.
Estimer les ressources, les délais et les véhicules de livraison. Combien de personnes, quelles compétences, pendant combien de temps. Le standard insiste sur un point : séparer le coût d'investissement, celui qui crée la capacité, du coût d'exploitation et de maintenance, celui qui la fait vivre. Et pour chaque lot, choisir le véhicule : un projet dédié, un programme existant qui l'absorbe, un portefeuille.
Prioriser par coût et bénéfice, valider les risques. On classe les projets de migration en croisant ce qu'ils coûtent, ce qu'ils rapportent et ce qu'ils font courir comme risque. L'évaluation des risques de la phase E, au sens d'ISO 31000 (l'effet de l'incertitude sur les objectifs), est reprise et revalidée lot par lot. Le résultat se négocie avec les parties prenantes : la priorité est un consensus, pas un calcul.
Confirmer la feuille de route et mettre à jour le document de définition. Les transitions sont figées : lesquelles, dans quel ordre, avec quel écart de temps entre elles. Le document de définition d'architecture est complété pour décrire chaque architecture de transition, et la spécification des exigences est finalisée.
Compléter le plan d'implémentation et de migration. Le brouillon de la phase E devient un plan complet : projets, dépendances, dates, ressources, intégré au calendrier des autres changements de l'entreprise.
Clore le cycle et documenter les leçons apprises. La phase F ferme le cycle de développement. Ce qu'on a appris sur la méthode, les outils ou l'organisation remonte vers la capacité d'architecture, sous forme de demandes de changement.
Les étapes 2 à 4 sont le cœur de la phase : donner une valeur, estimer un coût, trancher. Le reste met en forme ce qui a été tranché.
Donner une valeur à chaque lot, puis trancher
Deux tronçons attendent leur financement. L'un ouvre une gare dans une ville moyenne, l'autre supprime un goulet d'étranglement qui ralentit tout le corridor. Le second est moins visible, mais il fait gagner du temps à tous les trains. Sans méthode pour comparer, c'est la gare qui passe en premier, parce qu'elle fait une belle inauguration.
La phase F existe pour éviter ce biais. Elle demande qu'on attache à chaque lot une valeur métier explicite, puis qu'on ordonne les lots sur une base que tout le monde a vue avant de connaître le résultat.
La valeur métier d'un lot
Le standard propose une technique simple : évaluer chaque lot sur deux axes, un indice de valeur et un indice de risque, chacun composé de critères pondérés.
L'indice de valeur combine en général la conformité aux principes d'architecture, la contribution financière, l'alignement stratégique et l'effet sur la position concurrentielle. L'indice de risque combine la taille et la complexité du lot, la technologie engagée, la capacité de l'organisation à l'absorber et l'impact d'un échec. Les poids sont ceux de l'entreprise, pas ceux du standard. Change le poids d'un critère et le classement bouge : c'est pour ça qu'on les fixe avant.
Voici à quoi ressemble le résultat pour un programme fictif de refonte de la relation client, hérité de la phase E.
| Lot de travail | Écarts couverts | Critère de valeur dominant | Indice de valeur (sur 10) | Indice de risque (sur 10) |
|---|---|---|---|---|
| Plateforme d'intégration par API | Interfaces point à point non documentées | Alignement stratégique, réutilisation | 7 | 4 |
| Référentiel client unique | Données client dupliquées dans quatre applications | Conformité aux principes (source d'autorité unique) | 8 | 6 |
| Portail de souscription en ligne | Souscription papier, délai de dix jours | Contribution financière, position concurrentielle | 9 | 5 |
| Retrait de l'application de facturation historique | Technologie hors support, coût de licence | Contribution financière | 6 | 8 |
| Tableau de bord de pilotage commercial | Reporting manuel mensuel | Alignement stratégique | 4 | 2 |
Un lot à forte valeur et faible risque est un candidat évident pour une première transition. Un lot à forte valeur et fort risque réclame un découpage ou une atténuation avant d'être programmé. Un lot à faible valeur et faible risque peut attendre. Un lot à faible valeur et fort risque pose une question honnête : pourquoi le fait-on ?
Prioriser par coût, bénéfice et risque
La deuxième table croise ces indices avec le coût estimé à l'étape 3, en séparant investissement et exploitation. La colonne « transition » dit dans quelle architecture de transition le lot atterrit.
| Lot de travail | Investissement | Exploitation annuelle | Bénéfice attendu | Risque validé | Priorité | Transition |
|---|---|---|---|---|---|---|
| Plateforme d'intégration par API | Moyen | Faible | Prérequis de trois autres lots | Modéré | 1 | T1 |
| Référentiel client unique | Élevé | Moyen | Donnée unique, base du portail | Élevé, atténué par une reprise par segments de clientèle | 2 | T1 |
| Portail de souscription en ligne | Moyen | Moyen | Délai de souscription ramené à un jour | Modéré | 3 | T2 |
| Retrait de la facturation historique | Élevé | Économie de licence | Économie récurrente, surface technique réduite | Élevé, double exploitation pendant la bascule | 4 | T3 |
| Tableau de bord de pilotage commercial | Faible | Faible | Confort de pilotage | Faible | Reporté | Hors cycle |
La table se lit avec deux réflexes. D'abord, la dépendance prime sur la visibilité : les deux lots de fondation passent en premier parce que tout le reste s'appuie sur eux, même si le portail ferait une plus belle annonce. Ensuite, le coût d'exploitation compte autant que l'investissement : un lot bon marché à construire mais cher à faire tourner pèse sur toutes les années qui suivent.
Cette priorisation alimente aussi la table des incréments de la définition d'architecture : chaque lot inscrit dans une transition, chaque transition datée, et pour chaque brique l'état attendu à chaque étape.
La valeur d'un lot se calcule sur des critères pondérés que les parties prenantes ont acceptés avant de voir les résultats. Après, il est trop tard pour discuter la grille.
Le modèle de gouvernance d'implémentation
Entre la signature de la convention et l'ouverture commerciale, le tronçon passe sous un régime particulier : l'autorité de sécurité fixe les jalons, le maître d'ouvrage rend compte, et l'homologation ne s'obtient qu'au bout d'une liste de contrôles connue à l'avance. Personne ne découvre les règles le jour de l'inspection.
Le modèle de gouvernance d'implémentation remplit ce rôle pour les projets issus de la phase F. Sa raison d'être est simple : s'assurer qu'un projet qui passe en implémentation passe aussi sous une gouvernance d'architecture adaptée. Adaptée, c'est-à-dire dimensionnée au risque du projet.
Les organisations qui disposent déjà d'une fonction architecture ont en général un cadre de gouvernance en place. Le modèle ne le remplace pas, il le décline pour les projets en question : quels processus s'appliquent, qui siège, qui décide, à quels jalons on vérifie. Les organisations qui gouvernent projet par projet y trouvent le même service : une règle du jeu posée avant la première itération.
Le standard lui donne quatre composants.
Les jalons et leurs critères sont la partie que les équipes de projet regardent en premier. Un jalon sans critère d'échec explicite est une formalité. Un jalon avec un critère d'échec que personne n'ose appliquer est pire. Le modèle doit dire ce qui arrive quand un critère n'est pas rempli : correction, dérogation accordée par le conseil d'architecture, ou changement de la cible.
Le modèle est créé en phase F et utilisé en phase G, avec les contrats d'architecture et les revues de conformité que le prochain billet détaille. Voici où se situent les livrables de la phase F dans le cycle.
| Livrable | Créé | Enrichi | Finalisé | Utilisé |
|---|---|---|---|---|
| Feuille de route d'architecture | B, C, D (composants candidats) | E (consolidation) | F | G, H |
| Plan d'implémentation et de migration | E | F | F | G, H |
| Document de définition d'architecture | A | B, C, D | F (architectures de transition incluses) | G |
| Spécification des exigences d'architecture | A | B, C, D | F | G |
| Modèle de gouvernance d'implémentation | F | F | F | G |
| Demande de travaux d'architecture pour un nouveau cycle | F (ou H) | Préliminaire | Préliminaire | A |
| Demandes de changement sur la capacité d'architecture | F | H | Préliminaire | Préliminaire |
La gouvernance d'implémentation se décide avant que le premier projet démarre. Après, on ne gouverne plus, on négocie.
L'approche : du brouillon de la phase E au plan signé
Le dossier d'études est complet, les variantes sont tranchées. Le programme pluriannuel ne redessine rien : il prend chaque tronçon, lui donne un maître d'ouvrage, une enveloppe et une année, et le place dans le calendrier national des investissements. Puis il passe la main aux équipes de travaux.
L'approche de la phase F suit la même logique, en six mouvements.
Finaliser le plan à partir des brouillons de la phase E. La feuille de route et le plan sortent de E au niveau des lots et des transitions. F y ajoute le niveau portefeuille et projet : chaque lot devient un ou plusieurs projets nommés, avec une charte, un responsable et des dates.
Intégrer le plan aux activités de changement de l'entreprise. Il rejoint le portefeuille de changement existant et se coordonne avec le bureau des projets, les budgets annuels, les fenêtres de gel, les autres programmes qui mobilisent les mêmes équipes.
Évaluer dépendances, coûts et bénéfices à l'échelle du plan complet. Ce qui a été fait lot par lot est revu dans l'ensemble : une dépendance entre deux projets de portefeuilles différents, un coût d'exploitation cumulé, un bénéfice qui n'arrive que lorsque trois projets sont livrés.
Passer à la gouvernance d'implémentation. Le modèle de gouvernance est produit, les contrats d'architecture sont préparés, et la responsabilité du suivi passe à la phase G.
Documenter les leçons. Ce que ce cycle a appris sur la méthode, les outils et l'organisation remonte vers la capacité d'architecture.
Ouvrir le cycle suivant si nécessaire. Si une partie du travail dépasse ce que le cycle peut porter, une nouvelle demande de travaux d'architecture ouvre le cycle suivant.
Domaines et écarts"] BCD --> E["E. Lots, transitions,
feuille de route initiale"] E --> F["F. Plan daté, financé,
approuvé"] end subgraph REA["Réalisation"] G["G. Gouvernance
de l'implémentation"] --> H["H. Gestion du changement,
valeur réalisée"] end F ==>|"plan, contrats, modèle de gouvernance"| G H -.->|"demande de travaux
pour un nouveau cycle"| A classDef dev fill:#d89253,stroke:#8a4d16,color:#2c3338; classDef pivot fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; classDef rea fill:#2c3338,stroke:#1f2428,color:#f5f2ec; class A,BCD,E dev; class F pivot; class G,H rea;
Le schéma met en évidence le pivot. F est la frontière entre le développement de l'architecture et sa réalisation. À gauche, les architectes produisent ; à droite, ils surveillent ce que d'autres produisent. Les livrables de F sont ce qui traverse la frontière : le plan, les contrats, le modèle de gouvernance.
Un plan d'implémentation et de migration est un document de passage de relais. S'il ne dit pas qui prend quoi, quand et sous quel contrôle, il n'est pas terminé.
Scénario B : la migration de TSB, avril 2018
Changeons de terrain : une banque, pas une ligne de chemin de fer.
TSB est une banque de détail britannique. Après son rachat par Banco Sabadell en 2015, elle a continué d'utiliser la plateforme informatique de son ancien propriétaire, Lloyds Banking Group, dans l'attente d'une migration vers une nouvelle plateforme construite par Sabis, la filiale informatique du groupe Sabadell.
La bascule a eu lieu le week-end du 20 au 22 avril 2018. En une fois : les comptes d'environ cinq millions de clients ont été déplacés sur la nouvelle plateforme pendant un seul week-end. Dès la réouverture, les services en ligne et mobiles ont connu des défaillances. Des clients ne pouvaient plus accéder à leurs comptes, d'autres ont signalé voir des informations qui ne concernaient pas leurs propres comptes. Les incidents ont duré des semaines, et le retour à un fonctionnement normal a pris plusieurs mois.
Le conseil d'administration de TSB a commandé une revue indépendante au cabinet Slaughter and May, publiée par la banque en novembre 2019. Ses constats rendus publics portent sur trois points. La nouvelle plateforme n'était pas prête à recevoir l'ensemble des clients à la date retenue. Les tests réalisés avant la bascule étaient insuffisants au regard du risque pris par une migration en une seule fois. Et la décision de basculer a été prise alors que des signaux de non-préparation existaient.
Les régulateurs ont rendu leurs conclusions à leur tour. Le 20 décembre 2022, la Financial Conduct Authority et la Prudential Regulation Authority ont infligé à TSB des amendes d'un total de 48,65 millions de livres (29,75 millions pour la FCA, 18,9 millions pour la PRA) pour des manquements à la résilience opérationnelle. Le communiqué de la FCA relève que la banque n'a pas organisé et contrôlé le programme de migration de façon adéquate, ni géré correctement les risques liés à l'externalisation de sa plateforme. Le même communiqué indique que TSB avait versé 32,7 millions de livres de dédommagement à ses clients.
Lu avec les lunettes de la phase F, le cas tient en une phrase : le plan de migration a existé, mais il n'a pas joué son rôle de garde-fou. Le risque d'une bascule en une fois n'a pas conduit à un découpage en transitions. Les jalons, s'ils portaient des critères de non-bascule, n'ont pas arrêté la décision. Et la gouvernance d'implémentation n'a pas pesé assez lourd face au calendrier.
Le standard ne garantit rien. Mais un plan qui sépare les transitions, qui écrit les critères d'échec de chaque jalon et qui donne au contrôle le pouvoir de dire non, c'est exactement ce que la phase F demande de produire.
Un plan de migration qui ne peut pas empêcher une bascule n'est pas un plan : c'est un calendrier.
Points clés
- La phase F transforme la feuille de route de la phase E en projets datés, financés et approuvés. C'est la dernière phase de développement de l'architecture ; G et H relèvent de la réalisation.
- Chaque lot reçoit une valeur métier calculée sur des critères pondérés (indice de valeur, indice de risque), puis une priorité fondée sur le coût, le bénéfice et le risque validé.
- Le coût se lit en deux colonnes, investissement et exploitation, et la dépendance entre lots prime sur leur visibilité.
- Le modèle de gouvernance d'implémentation (processus, organisation, rôles et responsabilités, jalons et critères) est créé en F et utilisé en G ; il se dimensionne au risque du projet.
- TSB, avril 2018 : une bascule en une fois, un plan et des tests jugés insuffisants par la revue indépendante, 48,65 millions de livres d'amendes en 2022.
Dans la série
Palier 2 : Poser les rails. Domaine : Planification.
- Précédent : Phase E : opportunités, solutions, risques et feuille de route
- Suivant : Phase G : contrats d'architecture, conformité et équipes agiles
- Vue d'ensemble : Architecture d'entreprise : par où commencer
Pour aller plus loin
- Phase E : opportunités, solutions, risques et feuille de route : d'où viennent les lots, les transitions et le brouillon de plan que la phase F finalise.
- Phase G : contrats d'architecture, conformité et équipes agiles : ce que devient le modèle de gouvernance une fois les projets lancés.
- The Open Group, TOGAF Standard, 10e édition : Architecture Development Method, phase F : la source de référence pour les objectifs, les étapes et les sorties de la phase.
- The Open Group, TOGAF Standard : ADM Techniques, techniques de planification de la migration : la technique d'évaluation de la valeur métier et les tables d'incréments et d'évolution des états.
- ISO 31000, management du risque : la définition du risque reprise par le standard pour la validation des risques en phase F.
- FCA, communiqué du 20 décembre 2022 : amendes de la FCA et de la PRA contre TSB pour manquements à la résilience opérationnelle.
- Slaughter and May, revue indépendante de la migration informatique de TSB d'avril 2018, commandée par le conseil d'administration de TSB et publiée par la banque en novembre 2019 (document public, référence citée sans lien).