La lettre de mission arrive
Sur Le Chemin de fer, tout commence par une lettre. Le ministère écrit à l'autorité d'infrastructure : étudiez une liaison entre ces deux métropoles, voici l'enveloppe d'études, voici l'horizon, voici ce que l'État en attend. La lettre tient en quelques pages et ne dessine aucun tracé.
La direction de la planification ne répond pas par un plan. Elle répond par un autre document : ce qu'elle va étudier exactement, pour qui, jusqu'où, avec quelles équipes, et à quoi on reconnaîtra que l'étude est terminée. Tant que ce cahier des charges n'est pas signé, aucun géomètre ne part sur le terrain.
La phase A de l'ADM fait la même chose. Elle reçoit une demande de travaux, cadre le problème et le projet, identifie qui est concerné et par quoi, puis fait approuver un énoncé des travaux. Entre les deux, elle écrit la pièce la plus lue de tout le cycle : la vision d'architecture.
La phase A ne conçoit rien. Elle écrit ce qu'on va concevoir, pour qui, et obtient la signature qui autorise la suite.
Vue d'ensemble : la phase qui ouvre chaque cycle
Dans le TOGAF Standard, publié par The Open Group, la phase A est la phase initiale d'un cycle de développement d'architecture. La phase préliminaire a installé la capacité : l'équipe, le cadre adapté, les principes. La phase A met cette capacité au travail sur une demande précise.
Sa finalité tient en quatre mouvements. Fixer la portée, celle du problème à résoudre et celle du projet qui va s'y attaquer. Identifier les parties prenantes et leurs préoccupations. Formuler une vision qui résume la réponse envisagée. Obtenir une approbation formelle avant d'engager l'effort des phases B, C et D.
Le standard lui assigne deux objectifs. Le premier : développer une vision de haut niveau, volontairement ambitieuse, des capacités et de la valeur métier que l'architecture proposée va livrer. Le second : obtenir l'approbation d'un énoncé des travaux d'architecture, qui définit le programme de travaux pour développer puis déployer l'architecture esquissée dans la vision.
Ce billet suit les livrables dans l'ordre où ils apparaissent. La demande de travaux, en entrée. Le plan de communication, la vision et l'énoncé des travaux, en sortie. Puis les deux documents que la phase A ouvre en brouillon et que le cycle entier remplira : le document de définition d'architecture et la spécification des exigences d'architecture.
Une phase A réussie se reconnaît à un seul signe : le sponsor a signé un texte qu'il a lu en entier.
Les onze étapes, en deux temps
Le planificateur qui reçoit la lettre ne dessine pas. Il fait le tour : la région qui réclame la ligne, les exploitants qui y feront rouler leurs trains, les chargeurs, les maires des communes traversées. Il regarde ce que le réseau sait faire aujourd'hui, et si la région a les équipes et l'argent pour suivre. Il n'écrit son schéma directeur qu'après.
Le standard découpe la phase A en onze étapes. Elles se lisent mieux en deux temps : six étapes pour cadrer, cinq pour formuler et faire approuver.
Le premier temps commence par établir le projet d'architecture lui-même : le rattacher au portefeuille de projets de l'entreprise, le conduire avec la méthode de gestion de projet maison, lui donner un responsable et l'appui de la direction. Viennent ensuite les parties prenantes et leurs préoccupations, dont on dérive les exigences métier de haut niveau. Puis les objectifs, moteurs et contraintes métier, qu'on confirme ou qu'on précise s'ils ont bougé depuis la phase préliminaire.
Les étapes 4 et 5 mesurent. L'évaluation des capacités regarde ce que l'entreprise et son IT savent faire ; la maturité à la transformation regarde si l'organisation supportera le changement. Ces deux techniques ont leur propre billet.
L'étape 6 pose la portée : étendue de l'entreprise couverte, niveau de détail, domaines concernés, horizon de temps. C'est ici qu'on écrit ce qui est dedans et ce qui est dehors.
Le second temps écrit. On confirme les principes, métier et architecture, hérités du préliminaire, puis on développe la vision. On lui attache des propositions de valeur et des indicateurs, pour que la cible soit mesurable et pas seulement désirable. Viennent les risques de transformation et leurs atténuations. Enfin on rédige l'énoncé des travaux et on obtient sa signature.
Les six premières étapes écoutent et mesurent, les cinq suivantes écrivent et négocient. Inverser l'ordre produit une vision que personne ne reconnaît.
La demande de travaux d'architecture
La lettre de mission du ministère ne dit pas où passera la ligne. Elle dit pourquoi l'État veut une liaison, combien il met sur la table pour l'étudier, et quand il veut une réponse. C'est un document politique, et c'est très bien ainsi.
La demande de travaux d'architecture (Request for Architecture Work) est son équivalent : un document de haut niveau envoyé par l'organisation sponsor à l'organisation d'architecture pour déclencher un cycle. Les architectes aident souvent à la formuler, mais ils ne la signent pas.
Elle a trois origines possibles. La phase préliminaire, quand une capacité fraîchement installée reçoit son premier travail. Une demande de changement approuvée en phase H, quand une évolution dépasse ce qu'une simple mise à jour peut absorber. Ou la planification de migration de phase F, quand une architecture de transition révèle un travail d'architecture complémentaire.
| Finalité | Contenu type |
|---|---|
| Identifier qui demande | Sponsors de l'organisation, description de l'organisation qui va développer l'architecture |
| Dire pourquoi | Mission de l'organisation, objectifs métier et leurs évolutions, plans stratégiques |
| Poser le cadre | Changements de l'environnement métier, contraintes organisationnelles, contraintes externes |
| Donner les moyens | Information budgétaire et contraintes financières, ressources disponibles, délais |
| Décrire le point de départ | Description du système métier actuel, description de l'architecture et des systèmes IT actuels |
| Phase | Ce qu'elle en fait |
|---|---|
| Préliminaire | Peut la produire, pour un premier cycle |
| A | La reçoit : c'est l'entrée qui déclenche la phase et la source du contexte de l'énoncé des travaux |
| F | Peut en produire une nouvelle, quand une transition appelle un travail d'architecture complémentaire |
| H | Peut en produire une nouvelle à partir d'une demande de changement approuvée |
La demande ne dit pas quelle architecture construire. Elle dit pourquoi quelqu'un paie pour qu'on y réfléchisse.
Le plan de communication
Avant qu'une ligne nouvelle sorte des cartons, il y a la concertation. Réunions en mairie pour les riverains, dossiers techniques pour l'autorité de sécurité, note de deux pages pour le cabinet du ministre. Même projet, trois discours, trois calendriers. Le planificateur qui improvise cette communication perd l'enquête publique.
Une architecture d'entreprise charrie un gros volume d'informations complexes et interdépendantes. Le standard considère la communication ciblée, la bonne information aux bonnes parties prenantes au bon moment, comme un facteur critique de succès. Le plan de communication sert à la mener dans un processus planifié et géré, plutôt qu'au fil des couloirs.
Il se construit directement sur la liste des parties prenantes de l'étape 2. On les groupe par besoins de communication. Pour chaque groupe, on identifie les messages clés en rapport avec la vision, les risques de communication et les facteurs de succès. On choisit les mécanismes : revues, réunions, lettres d'information, dépôt partagé. On fixe un calendrier qui dit quelle communication a lieu avec quel groupe, à quel moment, à quel endroit.
| Finalité | Contenu type |
|---|---|
| Savoir à qui parler | Parties prenantes identifiées et groupées par besoins de communication |
| Savoir quoi dire | Besoins d'information, messages clés liés à la vision, risques de communication, facteurs critiques de succès |
| Savoir comment | Mécanismes de communication : réunions, revues, lettres d'information, dépôt partagé |
| Savoir quand | Calendrier des communications par groupe de parties prenantes, avec lieu et moment |
| Phase | Ce qu'elle en fait |
|---|---|
| A | Le crée, à partir de la carte des parties prenantes |
| B, C, D | L'applique pour présenter et valider chaque architecture de domaine auprès de ses parties prenantes |
| E, F | L'applique pour faire accepter la feuille de route et le plan de migration |
Le plan de communication est la liste de ceux qui peuvent faire échouer l'architecture s'ils apprennent les choses trop tard, et la date à laquelle on leur parle.
La vision d'architecture
Le schéma directeur de la ligne tient en vingt pages. Le ministre le lit, l'élu le cite, les bureaux d'études le reçoivent avant tout autre document. Il ne contient aucun plan de voie. Il dit ce que la ligne changera pour les voyageurs, les chargeurs et les territoires traversés, de façon qu'on puisse encore le relire le jour de l'ouverture.
La vision d'architecture est créée tôt dans le cycle. C'est un résumé des changements que l'entreprise connaîtra une fois la cible déployée. Son but : s'accorder dès le départ sur le résultat attendu, pour que les architectes concentrent ensuite leur effort sur les zones critiques, celles où la faisabilité reste à prouver. Elle sert aussi de résumé exécutif du document de définition, pour les parties prenantes qui ne liront jamais ce dernier.
Le standard insiste sur un point : la vision est un résultat formellement accepté, tôt. Pas une intention, pas une présentation. Elle devient la base sur laquelle les architectures de domaine des phases B, C et D sont développées, et le texte auquel on les compare.
| Finalité | Contenu type |
|---|---|
| Poser le problème | Description du problème : parties prenantes et préoccupations, liste des enjeux ou des scénarios à traiter |
| Relier au contrat | Objectif de l'énoncé des travaux d'architecture |
| Montrer la cible | Vues résumées nécessaires à la demande de travaux ; architectures métier, données, applications et technologie en version 0.1 |
| Tenir la trace | Exigences rattachées, renvoi vers le brouillon du document de définition d'architecture |
| Phase | Ce qu'elle en fait |
|---|---|
| A | La crée et la fait accepter formellement |
| B, C, D | La prennent pour base ; chaque architecture de domaine la détaille et la vérifie |
| E, F | La relisent pour choisir les lots de travail et prioriser la migration |
| G | La citent dans les contrats d'architecture et les revues de conformité |
Un résumé de vingt pages formellement accepté vaut mieux qu'un dossier de quatre cents pages que personne n'a approuvé.
L'énoncé des travaux d'architecture
Le cahier des charges de l'étude de ligne est le document que signent les deux parties : l'autorité qui commande l'étude et la direction qui la réalise. Il fixe le périmètre, les livrables, le calendrier, qui fait quoi, et comment on décide qu'un tronçon entre ou sort du périmètre quand le ministère change d'avis.
L'énoncé des travaux d'architecture (Statement of Architecture Work) définit la portée et l'approche qui seront utilisées pour mener le projet d'architecture à bien. Le standard précise son statut : c'est typiquement le document contre lequel l'exécution réussie du projet est mesurée, et il peut servir de base contractuelle entre le fournisseur et le consommateur de services d'architecture. Dans une entreprise, lis : entre l'équipe d'architecture et le sponsor.
Son contenu est précis. Un titre. La demande d'origine et son contexte. La description du projet et sa portée. Un aperçu de la vision. Les rôles, les responsabilités et les livrables. Les critères et procédures d'acceptation. Le plan et le calendrier. Une procédure de changement de portée, parce qu'il y en aura. Et les approbations.
Un squelette suffit pour voir comment ces rubriques s'articulent :
enonce_des_travaux:
titre: "Architecture cible du parcours commande à encaissement"
demande: "Demande de travaux du 12 mars, direction financière"
contexte: "Trois systèmes de facturation hérités de fusions successives"
portee:
dedans: ["Prise de commande", "Facturation", "Encaissement"]
dehors: ["Logistique", "Paie"]
apercu_vision: "Un seul référentiel client, une facture par commande"
roles:
sponsor: "Direction financière"
responsable: "Équipe architecture d'entreprise"
livrables: ["Vision", "Document de définition", "Spécification des exigences", "Feuille de route"]
criteres_acceptation: ["Revue par le conseil d'architecture", "Signature du sponsor"]
calendrier: "Phases B à F sur seize semaines"
changement_de_portee: "Toute modification passe par le conseil d'architecture"
approbations: []
| Finalité | Contenu type |
|---|---|
| Identifier | Titre, demande d'origine et contexte du projet |
| Délimiter | Description du projet, portée, aperçu de la vision d'architecture |
| Organiser | Rôles, responsabilités, livrables, plan et calendrier du projet |
| Mesurer | Critères et procédures d'acceptation |
| Protéger | Procédure de changement de portée, approbations |
| Phase | Ce qu'elle en fait |
|---|---|
| A | Le rédige et obtient l'approbation du sponsor |
| B, C, D | S'y réfèrent pour rester dans la portée et livrer ce qui est listé |
| E, F | Le mettent à jour si la feuille de route révèle un écart de périmètre ou de calendrier |
| G | Mesure l'exécution du projet contre lui |
| H | Le rouvre quand une demande de changement en modifie la portée |
L'énoncé des travaux est le seul livrable de la phase A qu'on relit quand ça va mal. Écris-le pour ce jour-là.
Deux documents que le cycle va remplir
Sur la ligne, deux dossiers grossissent pendant toute l'étude. Le dossier d'études complet, plans et notices, qui explique le tracé, les ouvrages, les choix et leurs raisons. Et le cahier des charges fonctionnel chiffré, qui dit ce que la ligne doit tenir : vitesse de ligne, charge à l'essieu, intervalle minimal entre deux trains. Le premier se lit, le second se vérifie.
La phase A ouvre leurs équivalents en version 0.1, et les phases suivantes les remplissent.
Le document de définition d'architecture (Architecture Definition Document) est le conteneur des artefacts d'architecture créés pendant le projet, et des informations qui s'y rattachent. Il couvre les quatre domaines, métier, données, applications et technologie, et tous les états pertinents : référence, transition, cible. Il porte une vue qualitative de la solution et vise à communiquer l'intention des architectes.
La spécification des exigences d'architecture (Architecture Requirements Specification) rassemble des énoncés quantitatifs : ce qu'un projet d'implémentation doit faire pour être conforme à l'architecture. Elle forme typiquement une composante majeure d'un contrat d'implémentation, ou d'un contrat pour une définition d'architecture plus détaillée.
Le standard les présente comme compagnons l'un de l'autre, avec des objectifs complémentaires. Le premier explique pourquoi et comment on a dessiné cela. Le second dit ce qu'il faudra démontrer pour avoir le droit de livrer.
| Document de définition d'architecture | Spécification des exigences d'architecture | |
|---|---|---|
| Nature | Qualitative : intention, choix, justifications | Quantitative : critères mesurables à satisfaire |
| Contenu | Artefacts par domaine et par état, principes appliqués, écarts, architectures de transition | Exigences fonctionnelles et non fonctionnelles, critères de succès, mesures, contraintes |
| Lecteur | Parties prenantes, architectes des phases suivantes | Projets d'implémentation, acheteurs, revues de conformité |
| Rôle contractuel | Explique ce qu'on veut obtenir | Fait partie du contrat qui dit ce qu'il faut prouver |
| Cycle de vie | Brouillon en A, enrichi en B, C, D, finalisé en F | Brouillon en A, enrichi en B, C, D, finalisé en F |
La filiation entre tous ces documents se dessine en une ligne : la demande déclenche, l'énoncé encadre, la vision résume, les deux compagnons détaillent.
La définition dit « voici ce qu'on veut et pourquoi ». La spécification dit « voici ce que tu devras prouver ». Un cycle qui n'a que l'un des deux finit en litige ou en diaporama.
L'approche en bref
Le planificateur trace deux traits sur sa carte avant tout le reste. Celui qui sépare ce que l'étude couvre de ce qu'elle laisse de côté. Et celui entre le réseau d'aujourd'hui et le réseau à l'horizon visé. Toute l'étude vit entre ces deux traits.
Le standard décrit l'approche de la phase A en quelques gestes, dans cet ordre :
- recevoir la demande de travaux, et clarifier avec le sponsor la finalité réelle de l'effort ;
- définir ce qui est dedans et ce qui est dehors, pour l'architecture de référence comme pour la cible ;
- vérifier les principes d'architecture et les objectifs métier qui s'appliquent, les compléter si besoin ;
- décrire la référence et la cible de haut niveau pour les quatre domaines, sans descendre dans le détail ;
- documenter la vision dans l'énoncé des travaux ;
- communiquer les bénéfices aux parties prenantes, en suivant le plan de communication ;
- faire signer le sponsor.
Pour construire la vision, le standard renvoie aux scénarios métier : une technique qui part d'un problème métier, de son environnement, des résultats attendus et des acteurs, et en dérive les exigences. C'est l'objet du billet suivant. Ici, retiens seulement sa position dans le cycle : elle nourrit l'étape 2 et l'étape 8.
Dedans, dehors, aujourd'hui, demain : quatre mots qui, écrits noir sur blanc en phase A, évitent six mois de dérive de périmètre.
Scénario B : la Government Digital Strategy du Royaume-Uni (2012)
Pas de train ici. Le cas est un programme de transformation numérique d'un État, et sa particularité tient en une phrase : les documents de sa phase A sont publics, et le sont restés.
La demande de travaux arrive en 2010. Martha Lane Fox, alors « UK Digital Champion », remet au ministre du Cabinet Office, Francis Maude, un rapport court intitulé « Directgov 2010 and beyond: revolution not evolution ». Il recommande un domaine unique pour les services en ligne du gouvernement et une équipe centrale dotée d'une autorité réelle sur l'expérience utilisateur de ces services. Le ministre répond publiquement qu'il accepte les recommandations. Sponsor identifié, mission énoncée, contexte posé.
La réponse structurée suit deux ans plus tard. Le Government Digital Service, créé en 2011 au sein du Cabinet Office, met en ligne GOV.UK en octobre 2012. Le 6 novembre 2012, le Cabinet Office publie la Government Digital Strategy.
La vision y est écrite en clair, sous le nom de « digital by default » : des services numériques si simples et si pratiques que tous ceux qui peuvent les utiliser choisiront de le faire, tandis que ceux qui ne le peuvent pas ne sont pas exclus. Une phrase, portée par le ministre, que n'importe quel fonctionnaire ou citoyen peut relire et opposer à ce qui a été livré.
L'énoncé des travaux prend la forme de quatorze actions numérotées. Chacune nomme un responsable, un ministère ou le Cabinet Office lui-même, et une échéance. Parmi elles : un responsable numérique actif au conseil de chaque ministère ; un responsable de service, doté des compétences et de l'autorité nécessaires, pour tout service dépassant 100 000 transactions par an ; le choix par les ministères transactionnels de services exemplaires à refondre, vingt-cinq au total ; le transfert de la publication institutionnelle des ministères sur GOV.UK ; et, à partir d'avril 2014, l'obligation pour tout service transactionnel nouveau ou refondu de satisfaire un standard de service. Chaque ministère devait publier sa propre stratégie numérique avant la fin 2012, ce qu'ils ont fait en décembre.
Le plan de communication est assumé, et c'est le dispositif le plus original du cas. La stratégie est publiée en pages web consultables, pas seulement en PDF. Les stratégies ministérielles le sont aussi. Le GDS tient un blog où il explique ses décisions au fil de l'eau. La stratégie est révisée et republiée en décembre 2013, et des rapports d'avancement publics suivent les actions. Deux études d'accompagnement, un « Digital Efficiency Report » et une « Digital Landscape Research », sortent en même temps pour étayer le diagnostic.
Reste la spécification des exigences. Le Digital by Default Service Standard, publié en 2013, liste des critères numérotés qu'un service doit satisfaire, et des évaluations sont menées aux passages de phase, avant la bêta publique puis avant la mise en service. Des énoncés vérifiables, utilisés comme condition de livraison. Le Service Manual qui l'accompagne joue le rôle du document qualitatif : il explique comment et pourquoi.
Ce que ce cas montre, et seulement cela : une vision, un énoncé des travaux et un plan de communication peuvent être lisibles par n'importe qui, avec des responsables nommés et des dates. Le bilan économique du programme n'est pas le sujet de ce billet ; le dispositif documentaire, si.
Quand la vision, l'énoncé et le plan de communication sont publics, la gouvernance n'a plus besoin d'être expliquée : elle se lit.
Points clés
- La phase A reçoit une demande de travaux, cadre le problème et le projet, identifie les parties prenantes et leurs préoccupations, et se termine par un énoncé des travaux signé par le sponsor.
- Onze étapes en deux temps : six pour écouter et mesurer (projet, parties prenantes, objectifs, capacités, maturité, portée), cinq pour écrire et négocier (principes, vision, valeur et indicateurs, risques, énoncé).
- Quatre livrables, chacun avec un cycle de vie : la demande en entrée, le plan de communication utilisé de B à F, la vision utilisée jusqu'en G, l'énoncé des travaux relu jusqu'en H.
- Le document de définition (qualitatif) et la spécification des exigences (quantitatif) sont compagnons : ouverts en version 0.1 en A, enrichis en B, C, D, finalisés en F.
- La Government Digital Strategy britannique de 2012 montre une vision en une phrase, quatorze actions avec responsables et échéances, une communication ouverte et un standard de service vérifiable, tous publics.
Dans la série
Palier 1 : Tracer la ligne. Domaine : Cadrage.
- Précédent : Phase préliminaire : la capacité d'architecture et ses principes
- Suivant : Scénarios métier, capacités et maturité : outiller la phase A
- Vue d'ensemble : Architecture d'entreprise : par où commencer
Pour aller plus loin
- Le TOGAF Standard, 10e édition, publié par The Open Group : la partie Architecture Development Method pour la phase A, la partie Architecture Content pour la description des livrables
- ISO/IEC/IEEE 42010, pour les définitions de partie prenante, préoccupation, point de vue et vue reprises par le standard
- Government Digital Strategy (2012), gov.uk, le texte complet avec ses actions numérotées et sa révision de décembre 2013
- Le Service Standard du Royaume-Uni, héritier du Digital by Default Service Standard de 2013
- Martha Lane Fox, « Directgov 2010 and beyond: revolution not evolution », rapport au ministre du Cabinet Office, octobre 2010, publié avec la réponse ministérielle
- Scénarios métier, capacités et maturité : outiller la phase A, pour les techniques qui alimentent les étapes 2, 4, 5 et 8
- Phase B : architecture métier et analyse d'écarts, la première phase qui développe ce que la vision a résumé