Les études de trafic avant le premier rail
Une région réclame une ligne nouvelle. Les élus la veulent, la presse en parle, le ministère a signé la lettre de mission. Avant d'étudier le moindre tracé, la direction de la planification pose trois questions qui n'ont rien de technique.
Combien de voyageurs, pour aller où, à quelle heure ? C'est l'étude de trafic. Le réseau actuel peut-il absorber ces trains, et l'autorité qui doit les planifier a-t-elle les équipes pour le faire ? C'est la capacité. La région a-t-elle le budget, les compétences et la volonté politique de tenir dix ans de travaux ? C'est la question qu'on saute, parce que la réponse dérange.
La phase A de l'ADM pose exactement ces trois questions, plus une quatrième en amont : au nom de quoi fait-on tout cela ? Le billet précédent suivait les livrables de la phase A, de la demande de travaux à l'énoncé approuvé. Celui-ci ouvre la boîte à outils qui sert à les remplir avec autre chose que des intentions.
Il clôt aussi le palier 1 de la série. La ligne est tracée ; au palier suivant, on pose les rails.
Une vision d'architecture sans scénarios métier, sans mesure des capacités et sans évaluation de la maturité est une lettre de mission recopiée au propre. Elle dit ce qu'on veut, pas ce qu'on peut.
Quatre techniques pour une seule phase
Dans le schéma directeur d'une ligne, l'étude de trafic, l'audit de capacité du réseau et l'analyse des risques régionaux ne sont pas des annexes. Ce sont les pièces qui transforment une envie politique en programme finançable.
TOGAF range parmi ses techniques de l'ADM plusieurs pratiques que la phase A mobilise ensemble. Quatre nous occupent ici.
| Question | Technique | Ce qu'elle produit | Où ça sert ensuite |
|---|---|---|---|
| Au nom de quoi change-t-on ? | Principes, objectifs et moteurs métier | Une liste confirmée et hiérarchisée de ce qui pousse l'entreprise | Validation des cibles en B, C, D |
| Quel problème, pour qui, avec quel résultat ? | Scénarios métier | Des exigences de haut niveau, des acteurs, des résultats mesurables | Gestion des exigences, architecture métier |
| Que savons-nous faire aujourd'hui ? | Évaluation des capacités | Un état des capacités métier, IT et architecture, et leurs écarts | Analyse d'écarts, planification, gouvernance |
| Sommes-nous prêts à changer ? | Maturité à la transformation | Des facteurs notés, des risques, des actions d'atténuation | Feuille de route (E), plan de migration (F) |
Les quatre se lisent dans cet ordre, qui est aussi celui de leur apparition parmi les étapes de la phase A. Chacune produit quelque chose que les phases suivantes consomment : les moteurs servent à valider les cibles, les scénarios nourrissent la gestion des exigences, l'évaluation des capacités ouvre l'analyse d'écarts, la maturité pèse sur la feuille de route et le plan de migration.
Le cadran rappelle où nous sommes.
Chaque technique répond à une question différente. En sauter une, c'est laisser une des quatre réponses au hasard, et le hasard répond toujours oui.
Principes, objectifs et moteurs métier
« Plus aucun passage à niveau sur ligne nouvelle » : un principe. « Désaturer l'axe nord-sud avant 2035 » : un objectif. « La croissance démographique du corridor et l'interdiction annoncée des poids lourds sur l'autoroute parallèle » : des moteurs. Aucun des trois n'a été écrit par un ingénieur des voies, et les trois décident du tracé.
Côté architecture d'entreprise, la logique est identique. Les principes, objectifs et moteurs métier décrivent les besoins de l'organisation et sa manière de travailler. Ils ne relèvent pas de l'architecture : le métier les possède, les formule et les change. Mais ils en déterminent le contenu, parce qu'une architecture qui ne s'y rattache pas n'a aucune raison d'exister.
Le travail de l'architecte, en phase A, n'est donc pas de les inventer. Il les retrouve, vérifie qu'ils sont toujours valides, lève les ambiguïtés et les relie explicitement aux exigences du cycle. Un moteur disparu entre le préliminaire et la phase A (un concurrent racheté, une réglementation retirée) change la vision avant même qu'elle soit écrite.
| Phase | Ce qu'on fait des principes, objectifs et moteurs métier |
|---|---|
| Préliminaire | On les confirme : existent-ils, sont-ils écrits, qui les porte ? |
| A. Vision d'architecture | On les clarifie, on lève les contradictions, on les rattache aux exigences |
| B. Architecture métier | On vérifie que l'architecture métier cible les sert |
| C. Systèmes d'information | On vérifie que les données et les applications cibles les servent |
| D. Architecture technologique | On vérifie que la technologie cible les sert |
Trois confusions reviennent. Prendre un objectif pour un moteur : le moteur est ce qui pousse, l'objectif ce qu'on vise. Écrire des objectifs qu'aucune mesure ne pourra confirmer. Et supposer que la direction est alignée parce que personne n'a contesté une présentation : le désaccord apparaît le jour où on demande de classer les objectifs par priorité.
Les moteurs, objectifs et principes métier sont hors du champ de l'architecture et en sont pourtant le point de départ. On ne les écrit pas à la place du métier : on les confirme avec lui, puis on les rattache à chaque exigence.
Les scénarios métier
Une étude de trafic ne commence pas par le nombre de voies. Elle part d'une situation : des habitants qui mettent chaque matin une heure quarante pour soixante kilomètres, une autoroute saturée, une usine qui menace de partir. On décrit le problème, le territoire, le résultat attendu, qui est concerné, quels moyens existent déjà. Le dimensionnement vient après.
Le scénario métier joue ce rôle en architecture d'entreprise. C'est la technique de TOGAF pour découvrir et documenter les exigences métier, puis en dériver les caractéristiques que l'architecture devra présenter. On part d'un besoin exprimé à haut niveau, on le décrit sous tous ses angles, et les exigences tombent de la description.
La méthode s'applique à un très gros problème (refondre la relation client d'un groupe) comme à un très petit (sécuriser le partage de fichiers d'un service). L'ampleur de la collecte change, la structure reste la même.
Cinq éléments, aucun facultatif
Ce qui ne va pas, en termes métier, et son rang parmi les autres
Organisation, contraintes, systèmes en place, côté métier et côté technique
À quoi on reconnaît que le problème est résolu
Les rôles et leurs responsabilités dans l'exécution
Les systèmes qui participent à l'exécution
Le problème dit ce qui ne va pas, en termes métier, et le classe parmi les autres problèmes. L'environnement décrit le contexte dans lequel il se pose : organisation, contraintes, systèmes en place. Les résultats attendus disent à quoi on reconnaîtra que le problème est résolu. Les acteurs humains portent des rôles et des responsabilités dans le scénario. Les acteurs informatiques sont les systèmes qui participent à son exécution.
Le standard est net : un scénario qui n'examine pas chacun de ces éléments conduit à une solution incomplète. Oublier les acteurs informatiques, c'est redécouvrir en phase C qu'un système tiers conditionne tout. Oublier l'environnement, c'est concevoir pour une organisation qui n'existe pas.
Un gabarit tient en quelques lignes. Celui-ci est fictif ; c'est la structure qui compte.
scenario: Réclamations clients, périmètre France
probleme:
enonce: Délai moyen de traitement de 12 jours, 30 % de relances
rang: 1 sur 4 problèmes identifiés
environnement:
organisation: Service client, back-office, deux prestataires
systemes: CRM, GED, outil de ticketing du prestataire
resultats_attendus:
- Délai moyen ramené à 4 jours, mesuré sur le flux complet, fin d'exercice
- Taux de relance sous 10 % sur le même périmètre, même échéance
acteurs_humains:
- Conseiller clientèle : qualifie et répond
- Gestionnaire back-office : instruit et décide
acteurs_informatiques:
- CRM : porte le dossier et son historique
- GED : conserve les pièces justificatives
Des résultats SMART
Les résultats attendus méritent une rigueur à part. Un scénario qui vise « une meilleure expérience client » n'a pas de résultat, il a une humeur. TOGAF demande des résultats SMART.
Quel résultat précis, sur quel périmètre ?
Quel indicateur, mesuré comment et par qui ?
Quelqu'un peut-il agir dessus directement ?
Atteignable avec les moyens qu'on a ou qu'on aura ?
Pour quand, exactement ?
Relis l'exemple du gabarit : délai moyen ramené de douze à quatre jours, mesuré sur le flux complet, périmètre France, fin de l'exercice. Chaque lettre de l'acronyme y trouve son mot. C'est aussi ce qui permettra, en phase H, de dire si l'architecture a tenu sa promesse.
Trois temps, cinq étapes, autant de tours qu'il faut
Le scénario se construit en trois temps : capturer la matière, l'examiner, l'améliorer. Chaque temps déroule les mêmes cinq étapes : planifier, collecter, analyser, documenter, revoir. On boucle jusqu'à ce que le résultat soit assez bon pour décider. Pas parfait : suffisant pour que les parties prenantes s'engagent sur une direction.
pour décider ?"} Q -->|non| T1 Q -->|oui| OUT["Scénario approuvé
exigences de haut niveau"] classDef temps fill:#d89253,stroke:#8a4d16,color:#2c3338; classDef etape fill:#f5f2ec,stroke:#8a4d16,color:#1a1a1a; classDef decision fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; class T1,T2,T3 temps; class E1,E2,E3,E4,E5 etape; class Q,OUT decision;
Le critère d'arrêt est ce qui fait débat. Un scénario métier n'est pas une spécification : s'il faut six mois pour l'écrire, on est en train de concevoir la solution sous un autre nom.
Ce qu'un scénario métier n'est pas
On le confond avec trois voisins.
| Scénario métier | Cas d'utilisation | Business case | Spécification d'ingénierie | |
|---|---|---|---|---|
| Question posée | Quel problème métier, pour qui, avec quel résultat ? | Comment un acteur interagit-il avec le système ? | Le jeu en vaut-il la chandelle ? | Que doit faire exactement le composant ? |
| Niveau | Entreprise, haut niveau | Système, fonctionnel | Financier et stratégique | Technique, détaillé |
| Moment | Préliminaire, A, B | Conception de la solution | Décision d'investissement | Implémentation |
| Sortie | Exigences de haut niveau, acteurs, résultats SMART | Scénarios d'interaction | Coûts, bénéfices, retour attendu | Exigences détaillées, interfaces |
Ses bénéfices découlent de sa place. Il donne un langage commun avec les fournisseurs, qui lisent un problème et des résultats au lieu d'une liste de fonctions. Il montre les exigences ensemble, dans leur contexte, au lieu de les éparpiller. Et il crée l'adhésion : des parties prenantes qui ont vu leur problème écrit avec leurs mots défendent la cible.
Il sert en phase préliminaire pour cadrer la capacité d'architecture elle-même, en phase A pour la vision, en phase B pour l'architecture métier, et en continu dans la gestion des exigences.
Un scénario métier décrit un problème, son environnement, des résultats mesurables et les acteurs qui l'exécutent. S'il manque un des cinq, la solution sera incomplète ; s'il en dit trop, c'est déjà une spécification.
L'évaluation des capacités
Avant de promettre quarante trains par jour sur une ligne nouvelle, l'autorité d'infrastructure regarde ce que le réseau encaisse déjà : les nœuds saturés, les dépôts pleins, les postes de signalisation à bout de souffle. Puis elle regarde sa propre direction de la planification : combien d'ingénieurs, quelles études en cours, quel retard sur les précédentes.
L'évaluation des capacités fait les deux. C'est un livrable créé en phase A qui mesure ce que l'entreprise sait faire aujourd'hui, à trois niveaux, puis identifie les écarts avec ce que la vision suppose.
| Niveau évalué | Question | Exemples de constats |
|---|---|---|
| L'entreprise | Quelles capacités métier existent, à quel niveau de performance ? | Un recouvrement manuel à 80 %, aucune capacité d'analyse de données |
| La fonction IT | L'IT sait-elle livrer et exploiter ce que la cible demande ? | Pas d'intégration continue, un seul administrateur sur le progiciel central |
| La fonction architecture | L'équipe d'architecture a-t-elle la maturité pour conduire le cycle ? | Pas de dépôt, des principes jamais approuvés, aucun conseil d'architecture actif |
| Les écarts | Entre ce qui existe et ce que la vision exige, que manque-t-il ? | La liste qui alimente B, C, D et la feuille de route |
Son contenu se range en quatre parties : l'évaluation de la capacité métier, celle de la capacité IT, l'évaluation de la maturité de l'architecture, et l'évaluation de la maturité à la transformation. Les trois premières décrivent ce qu'on sait faire. La quatrième, traitée dans la section suivante, dit si on est capable de changer.
Elle ne se jette pas une fois la vision approuvée. Elle suit le cycle.
| Phase | Usage de l'évaluation des capacités |
|---|---|
| A | Création : capacités métier, IT, architecture, maturité à la transformation |
| B, C, D | Point de départ des architectures de référence par domaine |
| E | Pondère les opportunités : ce qui se livre avec les capacités actuelles, ce qui attend |
| F | Alimente le plan de migration : les capacités à construire avant certains lots |
| G | Référence pour juger si les équipes d'implémentation ont les moyens annoncés |
L'erreur fréquente consiste à évaluer les capacités métier avec soin et à oublier les deux autres niveaux. Une cible ambitieuse portée par une fonction architecture qui n'a ni dépôt ni conseil est une cible sans conducteur.
L'évaluation des capacités mesure trois choses : ce que l'entreprise sait faire, ce que l'IT sait livrer, ce que la fonction architecture sait conduire. L'écart entre ces trois mesures et la vision est la première liste de travaux du cycle.
La maturité à la transformation
La région veut sa ligne. A-t-elle le budget sur dix ans, et pas seulement l'année de l'annonce ? A-t-elle les équipes pour suivre les études, acheter le foncier, tenir les concertations ? Et quand la première mairie s'opposera au tracé, les élus tiendront-ils ? Tout le reste du schéma directeur dépend de ces trois réponses, et personne n'aime les écrire.
Une architecture d'entreprise entraîne des changements considérables : organisation, processus, compétences, outils, parfois culture. Des plans brillants ne mènent nulle part dans une organisation qui ne veut pas, ne peut pas ou ne sait pas changer. L'évaluation de la maturité à la transformation mesure cela avant d'engager les travaux. C'est un effort conjoint : les ressources humaines, les directions métier et l'IT y participent, parce qu'aucun des trois ne voit l'ensemble.
TOGAF reprend cette technique du Business Transformation Enablement Program (BTEP) du gouvernement du Canada, qu'il cite comme origine. Sa thèse tient en une phrase : la dimension la plus importante du changement est humaine.
Cinq activités
de maturité pertinents"] --> A2["2. Les présenter avec
des modèles de maturité"] A2 --> A3["3. Noter chaque facteur
niveau actuel, niveau cible"] A3 --> A4["4. Évaluer les risques
et définir les atténuations"] A4 --> A5["5. Reporter dans les plans
des phases E et F"] A4 -.-> R["Registre des risques
de l'architecture"] classDef activite fill:#d89253,stroke:#8a4d16,color:#2c3338; classDef sortie fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; classDef registre fill:#f5f2ec,stroke:#8a4d16,color:#1a1a1a; class A1,A2,A3,A4 activite; class A5 sortie; class R registre;
La dernière activité est celle qu'on oublie. Une note de maturité qui reste dans un document d'évaluation ne sert à rien ; elle doit devenir des lots dans la feuille de route de la phase E et des jalons dans le plan de migration de la phase F. Pour la quatrième activité, le vocabulaire d'ISO 31000 suffit : probabilité, impact, traitement.
Douze facteurs
| Facteur | La question à poser |
|---|---|
| Vision | La direction a-t-elle une image claire et partagée de l'état cible ? |
| Volonté et détermination | L'organisation veut-elle ce changement, et tiendra-t-elle quand il coûtera ? |
| Besoin | Le changement répond-il à une nécessité reconnue, ou à une envie ? |
| Business case | Le dossier justifie-t-il l'effort par des bénéfices crédibles et mesurables ? |
| Financement | Les fonds sont-ils engagés sur toute la durée, pas seulement la première année ? |
| Sponsor et leadership | Un dirigeant porte-t-il le programme avec l'autorité nécessaire ? |
| Gouvernance | Existe-t-il des instances pour décider, arbitrer et surveiller ? |
| Responsabilité | Sait-on qui répond des résultats, nommément ? |
| Approche réalisable et modèle d'exécution | Le chemin proposé est-il crédible : pilotes, incréments, retours arrière ? |
| Capacité de l'IT à exécuter | L'IT a-t-elle les compétences, les effectifs et les pratiques pour livrer ? |
| Capacité des directions à exécuter | Les métiers peuvent-ils absorber le changement tout en continuant à fonctionner ? |
| Capacité à implémenter et exploiter | L'organisation saura-t-elle faire tourner le résultat une fois livré ? |
Chaque facteur se note deux fois : où on en est, où il faudrait être pour que la transformation réussisse. L'écart entre les deux est un risque, et parfois un lot de travail à part entière : recruter, former, obtenir un sponsor, créer une instance de gouvernance.
Une échelle pour noter
Non défini
Ad hoc
Répétable
Défini
Géré
Optimisé
L'échelle reprend la gradation familière des modèles de maturité des capacités. Les libellés exacts importent moins que la règle : les écrire une fois, puis noter tous les facteurs avec la même grille. Un « 3 » en financement doit vouloir dire la même chose qu'un « 3 » en gouvernance.
Les douze facteurs se notent avant la feuille de route, pas après. Chaque écart entre le niveau actuel et le niveau cible est un risque, et chaque risque non traité devient un lot de travail que personne n'a budgété.
Scénario B : Phoenix, la paie fédérale canadienne
En 2016, le gouvernement du Canada bascule la paie de ses fonctionnaires sur Phoenix (Phénix dans les documents francophones), un système construit sur un progiciel du marché, en deux vagues, en février puis en avril. Le programme devait remplacer un système de paie vieux de quarante ans, centraliser une partie du traitement dans un centre unique à Miramichi, au Nouveau-Brunswick, et dégager des économies annuelles.
Dans les mois qui suivent, des dizaines de milliers de fonctionnaires sont mal payés : trop, pas assez, ou pas du tout. Le Bureau du vérificateur général du Canada y consacre deux rapports, l'un à l'automne 2017, l'autre au printemps 2018.
Le premier, « Les problèmes liés au système de paye Phénix », constate que plus d'un an après la mise en service, le stock de demandes de paie en attente dépassait de loin ce que le ministère responsable savait traiter, que celui-ci n'avait pas une compréhension complète de l'ampleur ni des causes des erreurs, et que la résolution prendrait des années et coûterait bien plus que prévu.
Le second, « La construction et la mise en œuvre du système de paye Phénix », remonte à la décision de bascule. Les responsables du projet ont décidé de mettre le système en service alors qu'il n'était pas prêt. Des fonctions de paie critiques avaient été retirées du périmètre de lancement pour tenir le budget et le calendrier. Des tests avaient été réduits. Le pilote prévu avait été annulé. Les signaux de non-préparation, venus des ministères et d'un examen indépendant commandé peu avant la bascule, ont été écartés. Le vérificateur général parle d'un « échec incompréhensible » de gestion et de surveillance de projet.
Un autre constat du même rapport : les ministères avaient supprimé des postes de conseillers en rémunération en anticipation des économies, avant que le nouveau système ait prouvé qu'il fonctionnait. Quand les erreurs sont arrivées, l'expertise pour les corriger manquait.
Relis maintenant les douze facteurs avec ces constats.
| Facteur | Ce que les rapports constatent |
|---|---|
| Vision, besoin | Un système vieux de quarante ans à remplacer : le besoin n'était pas en cause |
| Business case, financement | Des économies attendues dès le lancement ; un périmètre réduit pour tenir le budget et le calendrier |
| Gouvernance, responsabilité | Une surveillance qui n'a pas arrêté une bascule dont la non-préparation était connue des responsables |
| Approche réalisable | Pilote annulé, tests réduits, fonctions critiques retirées, deux vagues rapprochées |
| Capacité des directions à exécuter | Des postes de conseillers en rémunération supprimés avant la preuve que le système fonctionnait |
| Capacité à implémenter et exploiter | Un volume de demandes en attente que le ministère ne savait ni traiter ni mesurer complètement |
Le détail qui pique : la technique d'évaluation de la maturité à la transformation que TOGAF reprend vient du BTEP, un programme du même gouvernement fédéral canadien, publié une dizaine d'années avant la bascule de Phoenix. La grille existait, dans la même administration.
Phoenix n'a pas manqué de vision ni de besoin. Il a manqué d'une évaluation de la préparation qu'on accepte de lire jusqu'au bout, et d'une gouvernance capable d'en tirer la seule conclusion utile ce jour-là : pas encore.
Points clés
- Les principes, objectifs et moteurs métier appartiennent au métier ; l'architecte les confirme en préliminaire, les clarifie en A et les valide en B, C, D.
- Un scénario métier décrit cinq éléments (problème, environnement, résultats, acteurs humains, acteurs informatiques), vise des résultats SMART, et s'itère jusqu'à être assez bon pour décider.
- L'évaluation des capacités mesure l'entreprise, l'IT et la fonction architecture, puis liste les écarts ; créée en A, elle sert jusqu'en G.
- La maturité à la transformation note douze facteurs sur une échelle commune, en déduit des risques et des atténuations, et les reporte dans les plans E et F.
- Phoenix montre le coût d'une évaluation de préparation écartée : les signaux disaient non, la décision a dit oui, et des dizaines de milliers de personnes ont payé l'écart.
Dans la série
Palier 1 : Tracer la ligne. Domaine : Cadrage.
- Précédent : Phase A : vision d'architecture, demande et énoncé des travaux
- Suivant : Phase B : architecture métier et analyse d'écarts
- Vue d'ensemble : Architecture d'entreprise : par où commencer
Pour aller plus loin
- Phase A : vision d'architecture, demande et énoncé des travaux, pour les livrables que ces quatre techniques viennent remplir.
- Phase F : planifier la migration et gouverner l'implémentation, là où les notes de maturité deviennent des jalons.
- Le TOGAF Standard, 10e édition, publié par The Open Group : les techniques de l'ADM, dont les scénarios métier, l'évaluation des capacités et la maturité à la transformation.
- Bureau du vérificateur général du Canada, Rapport 1 de l'automne 2017, « Les problèmes liés au système de paye Phénix », et Rapport 1 du printemps 2018, « La construction et la mise en œuvre du système de paye Phénix », disponibles sur oag-bvg.gc.ca.
- ISO 31000, management du risque, pour le vocabulaire de la quatrième activité : probabilité, impact, traitement.