Phase G : contrats d'architecture, conformité et équipes agiles

L'homologation avant la mise en service

Sur Le Chemin de fer, un tronçon achevé ne roule pas. Les rails sont posés, la caténaire est sous tension, la signalisation clignote, et pourtant aucun train commercial ne passe tant que l'autorité de sécurité n'a pas signé l'homologation. Les travaux ne font pas la ligne. C'est le contrôle de conformité qui l'ouvre.

Ce contrôle ne refait pas les études. Il vérifie que ce qui a été construit correspond à ce qui a été approuvé : le tracé validé, l'écartement, les règles de signalisation. Et quand un détail s'écarte du dossier, il décide si on corrige, si on tolère pour un temps, ou si c'est le dossier qu'il faut revoir.

La phase G de l'ADM joue exactement ce rôle. C'est la seule phase du cycle où l'architecte ne produit pas d'architecture : il surveille celle que d'autres construisent. Les équipes de projet, les intégrateurs et les éditeurs livrent ; l'architecte s'assure que ce qu'ils livrent reste fidèle à la cible, et il fait remonter ce qu'on apprend en chemin.

En phase G, l'architecte change de métier : il cesse de dessiner et commence à contrôler. Trois outils lui servent à le faire sans bloquer personne : le contrat d'architecture, l'évaluation de conformité, et une manière de servir les équipes agiles plutôt que de les encadrer.

Vue d'ensemble : surveiller sans construire

Le standard TOGAF, publié par The Open Group, nomme cette phase « gouvernance de l'implémentation ». Sa finalité se lit en trois lignes. S'assurer que les projets d'implémentation sont conformes aux architectures approuvées. Guider les équipes en leur donnant la finalité, les contraintes, les écarts à combler, la spécification et le contrôle. Gérer les priorités selon les critères de succès, la valeur, l'effort et le risque.

Ce qui en sort tient moins du document que du résultat : des projets achevés, des changements réellement implémentés, et une architecture cible ajustée par ce que l'implémentation a appris.

Les deux objectifs formels découlent de là : la conformité des projets d'implémentation à l'architecture cible, et l'exercice des fonctions de gouvernance d'architecture pour la solution livrée comme pour toute demande de changement née de l'implémentation.

La phase G reçoit tout ce que les phases A à F ont produit et n'y ajoute qu'une chose : la preuve que la réalité y correspond, ou l'explication de l'écart.

Les six étapes

Sur la ligne, l'ouverture d'un tronçon suit toujours la même séquence. On confirme avec le maître d'œuvre ce qui ouvre et dans quel ordre, on vérifie que les équipes d'exploitation sont prêtes, on accompagne les derniers travaux, on contrôle, on met en exploitation, puis on tire le bilan. La phase G fait pareil, en six étapes.

Les deux premières étapes sont souvent escamotées. Confirmer la portée et les priorités avec le management du développement, c'est accepter que le plan sorti de la phase F soit confronté aux équipes réellement disponibles. Identifier les ressources et les compétences de déploiement, c'est vérifier que quelqu'un saura opérer ce qu'on va livrer.

La troisième étape, guider le développement et le déploiement, est celle où l'architecte passe le plus de temps : répondre aux questions, expliquer une contrainte, arbitrer entre deux lectures de la spécification. La quatrième, la revue de conformité, est l'acte formel. Les deux dernières ferment la boucle : mettre en place les opérations métier et IT, puis conduire la revue post-implémentation et clore.

Les revues de conformité ne sont pas toute la phase G. Elles en sont le moment visible ; le reste du temps, l'architecte guide.

Les contrats d'architecture

Une ligne nouvelle repose sur deux documents signés : la convention de financement entre l'État et la région, et le contrat de concession avec l'exploitant. Sans eux, personne ne sait qui paie, qui construit, qui exploite et qui répond de quoi. Les travaux peuvent avancer ; l'engagement, lui, n'existe pas.

Le standard définit le contrat d'architecture comme l'accord conjoint entre les partenaires de développement et les sponsors sur les livrables, leur qualité et leur adéquation à la finalité. La gouvernance d'architecture le produit et le fait vivre. Dans les versions anciennes du cadre, le contrat liait surtout le sponsor et la fonction architecture. Aujourd'hui il engage toutes les parties qui construisent et déploient : intégrateurs, éditeurs, prestataires, équipes internes.

Trois contrats pour trois moments

Le standard en distingue trois, et ils n'apparaissent pas au même moment du cycle.

Le premier a été traité avec la phase A. Les deux autres sont les instruments de la phase G.

Ce qu'on y écrit

Le contrat de conception et de développement est le plus technique : il fixe les mesures que la cible doit atteindre et le plan de travail que les deux parties partagent. Le contrat des parties prenantes métier regarde plus loin. Il porte les mesures métier et le niveau de service, et c'est lui que la phase H ressortira pour vérifier que la valeur promise est arrivée.

Pourquoi signer

Un contrat d'architecture sert à ce que chacun sache, avant de construire, ce qui sera vérifié, par qui et avec quelle autorité. La sanction est secondaire ; la prévisibilité est l'essentiel.

L'évaluation de conformité

Revenons au dossier d'homologation. L'autorité de sécurité n'inspecte pas chaque boulon. Elle lit un dossier qui dit où en sont les travaux et ce qui a été construit, puis elle coche des listes de contrôle par domaine : voie, caténaire, signalisation, exploitation. Elle le fait à des moments précis, toujours assez tôt pour qu'une correction reste possible.

L'évaluation de conformité est le livrable qui joue ce rôle en phase G. Sa finalité : s'assurer que la conception et l'implémentation suivent les objectifs stratégiques et la vision d'architecture, et que ce qu'on apprend en construisant remonte vers la cible.

Ce qu'elle contient

Quand la conduire

Le standard distingue deux temps. Pendant le développement de l'architecture elle-même, dès que les exigences et l'architecture d'entreprise sont assez fermes pour qu'une comparaison ait un sens. Puis pendant l'implémentation, à des jalons choisis.

Le mot qui compte dans ce tableau, c'est « tant qu'il est encore temps ». Une revue menée après la mise en production ne contrôle plus rien ; elle constate.

Deux listes de contrôle

Le praticien ne se pose pas les mêmes questions selon qu'il regarde la cible ou l'implémentation.

Les niveaux de conformité

Le standard donne aussi un vocabulaire pour qualifier le résultat, parce que « conforme » tout seul ne dit pas grand-chose.

Auditeur, puis architecte

L'ordre des deux listes n'est pas un hasard. Dans une revue de conformité, le praticien est d'abord auditeur : il établit les faits, cherche l'accord des experts, qualifie l'écart. Ensuite seulement il redevient architecte et décide. Trois issues sont possibles.

Imposer la cible, c'est demander au projet de se mettre en conformité, parce que l'écart est corrigible et que la cible reste la bonne. Accorder une dispense, c'est tolérer l'écart pour une durée définie, avec un plan de retour ; une dispense sans date de retour est une renonciation déguisée. Changer la cible, c'est reconnaître que l'implémentation a raison contre le plan : on rédige une demande de changement, qui sera évaluée en phase H.

La dispense est l'outil le plus utile et le plus dangereux de la phase G. Bornée dans le temps et consignée, elle absorbe la réalité sans casser la cible. Sans date, elle transforme la cible en fiction.

Servir des équipes agiles

Sur Le Chemin de fer, le tronçon ouvert le mois dernier roule pendant que le suivant est en travaux et que le troisième est encore à l'étude. Personne n'attend que la ligne entière soit finie pour faire circuler les premiers trains. Personne non plus ne laisse chaque chantier choisir son écartement de rails.

Face aux équipes agiles, la phase G doit résoudre le même problème : donner assez de contraintes pour que les morceaux s'assemblent, et pas une de plus. Le standard décrit trois niveaux d'intervention, selon ce que l'architecte sert.

Au niveau du portefeuille, l'architecte dit quels produits sont nécessaires, où passent leurs frontières et quelles contraintes s'imposent au product owner ; le backlog d'entreprise en découle. Au niveau du projet, il précise les produits, leurs frontières et les contraintes, cette fois pour le product owner et pour les équipes. Au niveau de la livraison de solution, il ne fournit plus que des contraintes, et il laisse les équipes concevoir.

Ce qu'il ne lâche à aucun niveau, c'est la raison d'être de l'ensemble : la mission, la vision, les objectifs et la feuille de route d'investissement. Autrement dit, la valeur. Les équipes décident du comment ; l'architecte garde le pourquoi et le combien.

Le piège symétrique existe. Un architecte qui descend au niveau de la livraison avec des contraintes de portefeuille étouffe les équipes et devient le goulot d'étranglement du programme. Un architecte qui reste au niveau du portefeuille sans jamais préciser les frontières de projet laisse les équipes réinventer des interfaces que personne n'a tracées.

Servir une équipe agile revient à lui donner frontières et contraintes à son niveau, ni au-dessus ni au-dessous, et à garder pour soi la responsabilité de la valeur.

L'approche : relier l'architecture à l'implémentation

Le programme pluriannuel de la ligne a été signé en phase F. En phase G, il devient une suite d'ouvertures : un tronçon, puis un autre, chaque mise en service rapportant des voyageurs réels et des leçons que le tronçon suivant intègre.

Le standard dit la même chose des architectures de transition : leur implémentation incrémentale livre de la valeur tôt et réduit le risque. Chaque transition est un état intermédiaire pleinement fonctionnel, pas un chantier à moitié ouvert.

Pour tenir ce rythme, l'approche de la phase G rassemble ce qu'il faut savoir. Le programme d'implémentation et ses projets. Un calendrier fondé sur les priorités métier. Les standards de gouvernance de l'organisation, corporate, IT et architecture, pour ne pas inventer une gouvernance parallèle. Le portefeuille et les programmes existants, dans lesquels les projets d'architecture doivent trouver leur place. Le cadre d'exploitation qui recevra la solution. Et pour chaque projet : son nom, sa description, ses objectifs, sa portée, ses livrables, ses contraintes, ses critères d'acceptation et ses mesures.

Le contrat d'architecture tient l'ensemble. Il relie l'organisation d'architecture, qui a produit la cible et la spécification, à l'organisation d'implémentation, qui construit. Sans lui, les deux travaillent côte à côte sans jamais rien se devoir.

La phase G gère moins les projets que ce que les projets doivent à l'architecture, et ce que l'architecture leur doit en retour.

Scénario B : le National Programme for IT du NHS

En 2002, le gouvernement britannique lance le National Programme for IT (NPfIT) pour le NHS anglais : un dossier de soins électronique partagé à l'échelle nationale, la prise de rendez-vous en ligne, la transmission électronique des prescriptions, un réseau dédié et une infrastructure centrale baptisée « Spine ». Le programme est piloté de manière centralisée par le Department of Health.

La procédure d'achat va vite. Fin 2003 et début 2004, des contrats nationaux pluriannuels sont signés avec de grands fournisseurs, chacun désigné prestataire de service local pour un groupe de régions : Accenture pour deux d'entre eux, CSC, Fujitsu et BT pour les autres, BT portant également le Spine. Les hôpitaux et les trusts ne choisissent pas leur système ; il leur est attribué par le contrat régional.

Le National Audit Office publie un premier rapport en juin 2006. Il décrit un programme d'une ambition rare, des contrats conçus pour ne payer les fournisseurs qu'à la livraison de systèmes qui fonctionnent, des retards déjà présents sur les systèmes de dossiers de soins, et la nécessité de gagner l'adhésion des cliniciens et des établissements. Entre-temps, Accenture se retire du programme en 2006 ; le contrat de Fujitsu sera résilié en 2008. Le deuxième rapport du NAO, en mai 2008, constate des retards qui se creusent et un périmètre qui bouge.

Le rapport de mai 2011, consacré aux systèmes de dossiers détaillés, tire le bilan. Le NAO écrit que la vision d'origine ne sera pas réalisée, que les 2,7 milliards de livres dépensés jusque-là pour ces systèmes ne représentent pas un bon usage des fonds publics, et qu'il n'a pas confiance dans le fait que les 4,3 milliards restant à dépenser fassent mieux. Le NHS reçoit beaucoup moins de systèmes que prévu alors que le Department of Health paie ses fournisseurs à peu près autant, au fil de renégociations successives des contrats. En septembre 2011, le Department of Health annonce le démantèlement du programme national au profit d'une approche locale.

Lu avec les outils de ce billet, le cas est net. Les contrats existaient, et ils étaient solides au sens juridique : portée, livrables, paiement à la livraison. La conformité existait aussi, imposée d'en haut à des établissements qui n'avaient pas été associés au choix. Ce qui manquait, c'est la troisième partie de la phase G : servir ceux qui déploient. Les frontières et les contraintes ont été fixées au niveau national sans laisser au niveau local de place pour concevoir, et les renégociations ont tenu lieu de dispenses et de changements de cible, sans la revue qui aurait dû les porter et sans date de retour.

Le NPfIT montre qu'un contrat et une conformité imposée ne suffisent pas. Sans un niveau où les équipes locales décident du comment, la gouvernance se transforme en renégociation permanente, et c'est la cible qui finit par céder.

Points clés

• La phase G est la seule phase où l'architecte ne produit pas d'architecture : il guide, contrôle et fait remonter ce que l'implémentation apprend.
• Trois contrats d'architecture couvrent le cycle : l'énoncé des travaux (phase A), le contrat de conception et de développement (phase G) et le contrat des parties prenantes métier (fin de F, utilisé en H).
• L'évaluation de conformité se mène tant qu'il est encore temps de corriger ; le praticien y est d'abord auditeur, puis architecte, avec trois issues : imposer la cible, accorder une dispense bornée dans le temps, ou changer la cible par une demande de changement.
• Face aux équipes agiles, l'architecte fournit frontières et contraintes au niveau portefeuille, projet ou livraison, et garde la mission, la vision, les objectifs et la feuille de route d'investissement.
• Le NPfIT du NHS (2002-2011) avait des contrats nationaux et une conformité imposée, mais aucun niveau où les établissements décidaient ; le NAO constate en 2011 que 2,7 milliards de livres n'ont pas représenté un bon usage des fonds publics.

Dans la série

Palier 3 : Faire rouler les trains. Domaine : Pilotage.

• Précédent : Phase F : planifier la migration et gouverner l'implémentation
• Suivant : Phase H et gestion des exigences : piloter le changement
• Vue d'ensemble : Architecture d'entreprise : par où commencer

Pour aller plus loin

• Le TOGAF Standard, 10e édition, publié par The Open Group : la phase G dans la partie Architecture Development Method, les contrats d'architecture et la conformité dans la partie Enterprise Architecture Capability and Governance
• NAO, « The National Programme for IT in the NHS: an update on the delivery of detailed care records systems » (mai 2011)
• National Audit Office, « The National Programme for IT in the NHS », juin 2006, et « The National Programme for IT in the NHS: Progress since 2006 », mai 2008
• Department of Health, annonce du démantèlement du National Programme for IT, septembre 2011
• Phase F : planifier la migration et gouverner l'implémentation, pour le modèle de gouvernance d'implémentation que la phase G exécute
• Gouvernance d'architecture : conseil, conformité et capacité, pour le conseil d'architecture qui accorde les dispenses et arbitre les changements de cible