L11 — Gouvernance de l'Implémentation (Phase G) : assurer la conformité

« Architecture governance is not about saying no. It is about ensuring that every architectural decision is informed, traceable, and reversible. » — The Open Group, TOGAF Standard — Phase G: Implementation Governance

« Un architecte qui refuse tout n’est pas un architecte. C’est un censeur. »

Vidéo d’introduction

L11 — Gouvernance de l'Implémentation (Phase G)

Télécharger cette leçon en PDF

La gouvernance qui a sauvé Mutuelle Plus — et celle qui l’aurait tuée

En 2015, Mutuelle Plus — toujours elle — entre dans la Phase G, la gouvernance de l’implémentation. Élise a passé quatre ans à produire l’architecture cible, à planifier la transition, à négocier les chantiers. Les équipes projet ont commencé à exécuter. Et là, un nouveau piège apparaît : chaque équipe projet interprète l’architecture à sa manière, certaines décisions sont contournées, et la cible se met à dériver.

Élise découvre trois symptômes typiques d’une gouvernance défaillante :

Les dispenses — les projets sollicitent des dispenses pour ne pas respecter l’architecture. Sans processus clair, les dispenses s’accumulent, deviennent un précédent, et vident l’architecture de sa substance.
Les revues de conformité — certains projets affirment qu’ils sont conformes sans avoir été testés formellement. La conformité par affirmation est une fiction.
Les contrats d’architecture — les projets ne savent pas ce qu’ils doivent livrer comme livrables architecturaux. Les architectes passent leur temps à demander des compléments.

Élise a l’intelligence de ne pas répondre par la répression. Elle instaure trois mécanismes :

Un processus de dispense explicite — toute dispense doit être demandée, justifiée, et tracée. Pas de dispense par défaut.
Des revues de conformité formelles — chaque projet passe par une revue en trois points : (a) revue de conception, (b) revue d’implémentation, (c) revue de mise en production.
Des contrats d’architecture signés — chaque projet signe avec l’architecture un contrat qui définit les engagements réciproques (ce que l’architecture fournit, ce que le projet s’engage à respecter).

Ce qui aurait pu être un casse-tête bureaucratique est devenu un cadre de confiance : les projets savent ce qu’on attend d’eux, l’architecture sait ce qu’elle doit fournir, et les litiges sont tranchés par les contrats signés.

C’est ce que cette leçon cherche à vous transmettre : comment la gouvernance de l’implémentation protège l’architecture sans paralyser les projets, en posant un cadre clair et en l’appliquant avec discernement.

Le schéma suivant résume les trois moments où l’architecture intervient dans un projet, et le processus en quatre étapes pour gérer les dispenses :

Phase G : 3 moments de revue + processus dispense en 4 étapes

Premier principe — L’architecture est un garde-fou, pas une police

Le rôle de l’architecture en Phase G n’est pas de bloquer les projets. C’est de poser un cadre qui permet aux projets d’avancer vite, sans mettre en péril la cohérence du SI.

La tentation du « garde-fou » est de tout refuser. Cette posture rend l’architecture infréquentable et les projets hostiles. La parade est d’accompagner les projets plutôt que de les bloquer. L’architecte devient un conseiller dont l’avis est sollicité en amont, pas un censeur dont l’avis est requis en aval.

L’Open Group recommande que la gouvernance s’exerce à trois moments :

Revue de conception — l’architecte valide la conception avant le démarrage du développement. C’est le moment le plus efficace : corriger un schéma est moins coûteux que corriger du code.
Revue d’implémentation — l’architecte vérifie que l’implémentation respecte la conception. C’est le moment où les écarts apparaissent.
Revue de mise en production — l’architecte valide le déploiement en production. C’est le moment où la dette technique se crée si on n’a pas fait les deux premières revues.

La contrefaçon classique consiste à ne faire que la revue de mise en production — c’est-à-dire quand il est trop tard. La parade est de planifier les trois revues dans le calendrier du projet, dès la phase de cadrage.

Et toi ? Combien de revues d’architecture sont planifiées sur chacun de tes projets ? À quels moments du cycle de vie ? Combien sont effectivement menées à terme ?

Deuxième principe — Le contrat d’architecture est un engagement récipro

Le contrat d’architecture n’est pas un document que l’architecture impose aux projets. C’est un accord entre l’architecture et le projet, qui engage les deux parties.

Un contrat d’architecture documente quatre engagements :

Ce que l’architecture fournit au projet — le périmètre architectural, les exigences non fonctionnelles, les interfaces avec les autres systèmes, les contraintes techniques.
Ce que le projet s’engage à respecter — la conformité aux exigences, les patterns techniques imposés, les contrats d’interface à respecter.
Comment les conflits sont tranchés — l’escalade vers le comité d’architecture, les dispenses, les dérogations.
Quels livrables le projet doit produire — les modèles ArchiMate, les contrats d’interface, les tests de non-régression.

La contrefaçon classique consiste à produire un contrat d’architecture que personne ne lit, ou que le projet signe sans l’avoir compris. La parade est de limiter le contrat à 2 pages, de le signer conjointement (architecte ET chef de projet), et de le relire à chaque revue.

Pour Mutuelle Plus, Élise a tenu un catalogue de contrats signés — un fichier partagé listant tous les projets en cours, avec leur contrat, leur état (signé / en cours / terminé), et leurs dispenses éventuelles. Ce catalogue permettait à tout acteur de savoir où en était chaque projet vis-à-vis de l’architecture.

Et toi ? Combien de projets en cours ont un contrat d’architecture signé ? Combien ont une dispense active ? Combien ont une revue planifiée ?

Troisième principe — La revue de conformité est formelle, pas par affirmation

La conformité « parce que le chef de projet l’a dit » n’est pas une conformité. La conformité est un état vérifié, pas un état supposé.

L’Open Group recommande que chaque revue de conformité suive un processus en trois étapes :

Préparation — le projet fournit les livrables à l’architecture (schémas, contrats d’interface, tests). L’architecture prépare la grille de revue.
Confrontation — l’architecte passe en revue les livrables, pose des questions, identifie les écarts. Le projet répond.
Décision — l’architecte émet un avis (conforme / conforme avec réserves / non conforme). L’avis est tracé, daté, signé.

La contrefaçon classique consiste à faire des revues de conformité par e-mail, sans grille de revue, sans confrontation. Ces revues sont des formalités administratives. La parade est de tenir les revues en présentiel (ou en visio), avec un déroulé strict, et de documenter les écarts.

Pour Mutuelle Plus, Élise a utilisé un template de revue d’une page, avec trois colonnes (livrable attendu, livrable reçu, écart constaté). Le template est rempli pendant la revue, signé par les deux parties, et archivé dans le catalogue des revues.

Et toi ? Combien de revues de conformité as-tu menées sur les 12 derniers mois ? Combien ont produit un avis tracé ? Combien ont identifié des écarts significatifs ?

Quatrième principe — Les dispenses sont gérées, pas interdites

Une dispense n’est pas un échec de l’architecture. C’est un acte de gestion, qui reconnaît un écart entre la cible et la réalité, et qui le trace.

L’Open Group recommande un processus de dispense explicite, en quatre étapes :

Demande — le projet soumet une demande de dispense, avec justification (pourquoi l’écart, quel impact, quelle durée).
Évaluation — l’architecture évalue la demande (impact sur la cible, risques techniques, alternatives).
Décision — le comité d’architecture accepte, refuse, ou accepte avec conditions.
Suivi — la dispense est tracée, et le projet doit revenir vers l’architecture quand la condition est levée.

La contrefaçon classique consiste à interdire les dispenses, ce qui pousse les projets à des contournements officieux. La parade est d’accepter un certain volume de dispenses, à condition qu’elles soient tracées et résolues dans un délai.

Pour Mutuelle Plus, Élise a tenu un registre des dispenses — un fichier listant toutes les dispenses actives, avec leur statut (en attente / acceptée / résolue / expirée). Le registre est revu tous les mois au comité d’architecture. Les dispenses non résolues après 6 mois déclenchent une revue prioritaire.

Et toi ? Combien de dispenses actives dans ton organisation ? Combien ont été résolues dans les 6 mois ? Combien sont restées ouvertes plus de 12 mois ?

Cinquième principe — La Phase H gère le changement continu

La Phase H (Architecture Change Management) ne signifie pas que l’architecture est terminée. Elle signifie que l’architecture entre dans un cycle de gestion continue du changement.

L’Open Group recommande que la Phase H s’organise autour de cinq activités :

Surveillance — observer les changements dans l’environnement (technologie, réglementation, marché).
Évaluation — évaluer l’impact des changements sur l’architecture.
Recommandation — recommander des mises à jour de l’architecture si nécessaire.
Implémentation — coordonner la mise en œuvre des changements architecturaux.
Communication — tenir les parties prenantes informées des changements.

La contrefaçon classique consiste à considérer l’architecture comme un livrable terminé. Une fois la cible définie, l’architecture est « fermée » et personne ne la maintient. La parade est de maintenir l’architecture comme un objet vivant — révisé annuellement, mis à jour en continu, et consulté pour toute décision structurante.

Pour Mutuelle Plus, Élise a institué une revue annuelle de l’architecture — trois jours, avec les propriétaires de domaine, les sponsors, et quelques experts externes. Cette revue a permis de réajuster la cible à trois reprises sur six ans — et de maintenir la cohérence de la transformation.

Et toi ? Combien de revues annuelles de l’architecture sont tenues dans ton organisation ? Combien de mises à jour de la cible sont décidées par an ? Combien de demandes de changement sont arbitrées par an ?

Application — Mon contrat d’architecture

À produire séance tenante. Un contrat d’architecture d’une page pour un projet réel (en cours ou à venir).

Périmètre — nom du projet, sponsor, chef de projet, dates clés.
Engagements de l’architecture — ce que l’architecture fournit (schémas, exigences, contrats d’interface).
Engagements du projet — ce que le projet respecte (patterns, normes, contrats).
Dispenses — liste des dispenses éventuelles, avec conditions.
Revues planifiées — dates des trois revues (conception, implémentation, production).
Escalade — qui tranche en cas de désaccord.

Ce contrat est ton premier livrable de Phase G. Il pose le cadre de la collaboration entre l’architecture et le projet.

Module complémentaire — L’architecte d’entreprise dans un monde agile : TOGAF × SAFe

Les organisations qui réussissent leur transformation numérique combinent deux logiques longtemps présentées comme opposées : la rigueur stratégique de TOGAF (vision long terme, cohérence globale, cycle ADM) et la vélocité d’exécution des méthodes agiles à l’échelle (SAFe, Spotify, LeSS). L’architecte d’entreprise du XXIe siècle n’a pas le choix : il doit orchestrer les deux. Ce module présente l’articulation opérationnelle entre ADM et SAFe, à travers le prisme de Mutuelle Plus confrontée à la coexistence entre son cycle de transformation et son train agile.

Mapping ADM ↔ SAFe — l’alignement stratégique

Pour qu’un cycle ADM et un train agile (ART) collaborent réellement, chaque phase ADM doit produire des artefacts consommables par le backlog agile, et inversement. Le tableau ci-dessous décrit ce flux d’informations critique :

Phase TOGAF ADM	Artefact SAFe consommé / produit	Application concrète
Phase A (Vision)	Portfolio Vision, Epic Hypothesis	L’AE transforme les objectifs de reconquête de Mutuelle Plus en Epics : passer de 72h à l’immédiateté, reconquérir les jeunes cotisants.
Phase B (Métier)	Development Value Streams	Modélisation des processus pivots (cotisations, prestations, contrats). Identification des étapes manuelles (recherches de contrats non numérisés) pour alimenter les Business Enablers.
Phases C & D (SI & Technique)	Architecture Runway	Les modèles logiques de données ciblent la résolution des doublons dans Gest+. Les architectures applicatives définissent les NFR (performance, sécurité RGPD).
Phases E & F (Transition)	PI Roadmap	Corrélation des paliers de transition (socle d’identité avant Espace Client) avec la planification des Program Increments.

Cet alignement constitue la structure porteuse de la piste d’atterrissage technique. Sans elle, l’agilité se transforme en succession de rustines tactiques sur un SI déjà rigide.

Architecture Runway vs Enabler — deux concepts distincts

L’Architecture Runway est l’état physique existant du socle technique : APIs, plateformes Cloud, intégrité des données, briques d’authentification. C’est ce qui permet aux équipes agiles de développer à pleine vitesse, sans être freinées par un mur technique.

L’Enabler est l’unité de travail dans le backlog (Epic, Feature ou Story) destinée à construire ou maintenir cette piste. L’Enabler est ce que l’AE inscrit dans le backlog pour garantir que la Runway avance au rythme des besoins métiers.

Découpage industriel des Runways pour Mutuelle Plus :

Socle de données unifié (Projet #2) — Enabler visant l’élimination des doublons Gest+ par un MDM (Master Data Management) pour restaurer la fiabilité des remboursements.
Hub CRM Transverse (Projet #6) — Mise en place d’une architecture permettant la mobilité géographique des adhérents entre agences, supprimant la dépendance aux fichiers Excel locaux.
IAM (Identity & Access Management) — Projets #3 & #10 — Architecture microservices pour l’Espace Client sécurisé, priorisant la simplicité d’authentification pour les assurés et les gestionnaires.

Ces Runways sont les livrables architecturaux que l’AE porte dans les PI Plannings successifs.

Le rôle de l’AE pendant le PI Planning

Le PI Planning est le moment où l’architecture « tour d’ivoire » se confronte à la réalité des équipes. L’AE y intervient en tant que serviteur-leader, garant de la cohérence globale.

Préparation (en amont du PI Planning) :

Rédaction des critères de succès techniques — définition stricte des NFR (ex. : scalabilité pour supporter 1 million d’adhérents).
Identification des dépendances — cartographie des liens entre le train « Front-End » et le train « Core Insurance » pour éviter les blocages sur les flux Gest+.
Estimation du WSJF (Weighted Shortest Job First) pour prioriser les Enablers. L’AE doit utiliser la donnée financière pour peser face aux demandes métier : pour Mutuelle Plus (100M€ de CA), le Coût du Délai d’un Enabler se chiffre. Exemple : retarder l’Enabler « CRM Transverse » empêche le traçage des résiliations. Si ce manque de visibilité cause une perte de 1 % des adhérents par an, le Coût du Délai est de 1 million d’euros par an. Ce chiffre permet de prioriser l’Enabler face à une Feature métier mineure.

Facilitation (Jour 1 et 2 du PI Planning) :

Éclairer : orienter les choix techniques pour éviter le développement de solutions « ad hoc » qui aggraveraient la dette technique.
Arbitrer : trancher les impasses immédiates (ex. : choix d’un protocole d’échange).
Valider les compromis : accepter une solution tactique pour tenir l’objectif du PI, à condition qu’elle soit documentée et que sa résolution soit planifiée dans la trajectoire TOGAF.

L’AE ne commande pas l’équipe ; il alimente ses décisions avec les contraintes architecturales globales. C’est ce qui le distingue du chef de projet.

System Demo, Inspect & Adapt et Contrat d’Architecture

La gouvernance agile chez Mutuelle Plus doit s’assurer que l’autonomie des équipes ne dégrade pas la solvabilité ou la conformité RGPD.

System Demo et Architecture Contract. Lors de la démonstration de fin de sprint, l’AE valide la conformité des réalisations par rapport au Contrat d’Architecture (issu de la Phase G de TOGAF). C’est ici que l’on vérifie physiquement que les NFR sont respectées et que la Runway est opérationnelle.

Inspect & Adapt (I&A). L’AE analyse les « irritants systémiques » (ex. : lenteurs récurrentes de Gest+ impactant le Centre de Services). Ces problèmes sont transformés en nouveaux Enablers pour le PI suivant. C’est la boucle d’apprentissage qui garantit que la trajectoire TOGAF absorbe le retour du terrain.

Étude de cas — Trajectoire sur trois Program Increments

Illustration de la transition vers un système d’identité client moderne chez Mutuelle Plus :

PI 1 — Les fondations. Focus sur l’Enabler d’infrastructure (OAuth2/OIDC).

Livrables TOGAF : Architecture Definition Document (partiel), Principes d’Architecture mis à jour pour inclure la sécurité « Zero Trust ».

PI 2 — La première valeur métier. Livraison de la Feature « Espace Client sécurisé » exploitant le socle du PI 1.

Livrable TOGAF : Architecture Transition v1 (état réel après migration partielle).

PI 3 — L’accélération industrielle. Livraison de « Paiement en un clic » et « Profil enrichi » sans re-conception.

Livrable TOGAF : Architecture Contract. L’AE utilise ce document pour signer la conformité des Features lors de la System Demo, clôturant ainsi le cycle de gouvernance.

Trois écueils de cohabitation AE / Agile

La transformation risque de trébucher sur trois dérives classiques :

Le goulot d’étranglement (Ivory Tower). L’AE ralentit les équipes par un excès de validation. Remède : définir des NFR claires et laisser l’autonomie de réalisation tant que les gardes-fous sont respectés. Le contrat d’architecture prime sur la présence quotidienne.

L’AE dilué ou disparu. L’absence de vision de cible génère une dette technique anarchique, mettant en péril la fiabilité des remboursements et la solvabilité à long terme. Remède : sanctuariser le rôle d’AE dans la gouvernance, même quand l’agilité semble tout résoudre.

La guerre AE vs Product Owner. Conflit entre vision long terme et livraison immédiate. Remède : instaurer des ratios budgétaires sanctuarisés. Pour Mutuelle Plus, dédier d’office 20 % de la capacité de chaque train (ART) aux Enablers d’architecture. Cela garantit l’entretien de la Runway et évite l’obsolescence du SI.

Synthèse

L’architecte moderne n’est plus un censeur. C’est un serviteur-leader : il est le garant de la pérennité du patrimoine de l’entreprise, en s’assurant que l’agilité d’aujourd’hui ne devienne pas la rigidité de demain. Le couple TOGAF × SAFe n’est pas un compromis ; c’est une complémentarité structurelle entre la stratégie de long terme et l’exécution de court terme.

Encadré Au lecteur / À l’animateur

Question d’ouverture : « Combien de projets en cours dans ton organisation ont un contrat d’architecture signé ? »

Profils à observer :

Le censeur. Refuse tout, bloque tous les projets. Question : « Combien de dispenses as-tu acceptées cette année ? »
Le laxiste. Ne fait pas de revue, accepte tout. Question : « Combien de revues as-tu menées à terme ? »
Le procédurier. Fait des revues formelles sans fond. Question : « Combien d’écarts significatifs as-tu identifiés cette année ? »
L’isolé. N’a personne avec qui signer les contrats. Question : « Combien de chefs de projet ont signé un contrat avec toi ? »

Pièges d’animation :

Ne pas laisser la discussion dériver vers les outils de ticketing (Jira, ServiceNow). Rappeler que la gouvernance est d’abord une pratique, pas un outil.
Ne pas confondre gouvernance et audit. La gouvernance est continue ; l’audit est ponctuel.

Ce que la leçon 12 vous demande

Ouvrez votre dossier d’architecte à la page suivante. Préparez :

Un contrat d’architecture signé pour un projet en cours.
Un registre des dispenses avec leur statut.
Un calendrier des revues pour les 3 mois à venir.

Sources de cette leçon : TOGAF Standard 10ᵉ (Phases G-H) · COBIT 2019 · ISACA, COBIT 2019 Framework · Cas Mutuelle Plus (anonymisé)

Leçon suivante : L12 — Durabilité numérique et éco-conception.