L10 — Opportunités et Solutions (Phase E & F) : planifier la transition

« A roadmap without priorities is a wish list. A roadmap without transition architectures is a fantasy. » — The Open Group, TOGAF Standard — Phase E: Opportunities and Solutions

« La transition est un chemin, pas un bond. »

Vidéo d’introduction

L10 — Opportunités et Solutions (Phase E & F)

Télécharger cette leçon en PDF

Les dix projets qui ont failli ne jamais voir le jour

En 2014, Mutuelle Plus — la mutuelle dont nous avons parlé en L1 — entame la troisième année de sa transformation. Les deux premières années ont été consacrées à l’audit, à la cartographie, à la Phase Préliminaire, aux Phases A et B (Vision et Architecture Métier). Le diagnostic est posé, la cible est dessinée. Reste à planifier comment y aller.

C’est à ce moment qu’Élise, l’architecte d’entreprise, fait face à un piège classique : transformer une cible architecturale en une liste de projets qu’on peut confier aux équipes opérationnelles. Cette transformation n’est pas mécanique. Elle suppose de répondre à plusieurs questions structurantes :

Quels écarts sont les plus coûteux ? L’analyse As-Is vs To-Be fait apparaître des dizaines d’écarts. Lesquels sont prioritaires ?
Quelles solutions couvrent plusieurs écarts ? Un même projet peut répondre à trois écarts en même temps — ou trois projets peuvent répondre au même écart en se concurrençant.
Comment séquencer ? Les projets ne sont pas indépendants. Certains sont des prérequis d’autres. Le séquencement est un problème d’optimisation, pas un problème de tri.
Comment gérer la transition ? On ne peut pas basculer d’un coup d’un SI à un autre. Il faut des architectures de transition qui décrivent les états intermédiaires.

Élise passe trois mois à résoudre ces questions. Elle produit :

Une analyse d’écarts structurée par couche (métier, données, applications, technique) avec une note de coût et de complexité pour chaque écart.
Une liste de Solution Building Blocks (SBB) — des briques de solution qui couvrent les écarts, avec leur périmètre fonctionnel et leurs dépendances.
Sept architectures de transition — des états intermédiaires qui maintiennent la cohérence du SI pendant la transformation.
Une roadmap 24 mois avec trois vagues de chantiers, organisées par valeur métier et risques.

Ce travail a permis à Mutuelle Plus de passer d’une cible séduisante sur papier à un plan d’action exécutable — et de tenir la trajectoire pendant les six années suivantes.

C’est ce que cette leçon cherche à vous transmettre : comment transformer une architecture cible en un plan de transition réaliste, sans céder à la tentation du grand soir.

Le schéma suivant montre les sept architectures de transition qui ont permet à Mutuelle Plus de passer du SI legacy au SI cible sur 24 mois :

7 architectures de transition de Mutuelle Plus

Premier principe — L’analyse d’écarts est As-Is vs To-Be, couche par couche

L’analyse d’écarts consiste à comparer l’architecture actuelle (As-Is) et l’architecture cible (To-Be) pour identifier les différences. Cette comparaison doit être faite couche par couche, pas comme une masse indistincte.

L’Open Group recommande une analyse d’écarts structurée en quatre couches :

Couche métier — quelles capacités sont absententes, sous-maturées, ou en sureffectif ?
Couche données — quelles données sont mal qualifiées, mal governées, mal distribées ?
Couche applicative — quelles applications manquent, sont obsolètes, ou font double emploi ?
Couche technique — quels composants techniques sont à risque, mal outillés, ou à renouveler ?

Chaque écart reçoit trois notes : coût (combien ça coûte à combler), complexité (combien c’est difficile techniquement), valeur métier (combien ça rapporte). Ces trois notes permettent de prioriser les écarts à traiter.

La contrefaçon classique consiste à produire une liste à plat de 200 écarts sans hiérarchie. Cette liste ne sert à rien — elle ne permet ni de décider, ni de budgéter, ni de planifier. La parade est de classer les écarts par criticité et de regrouper les écarts similaires en projets cohérents.

Et toi ? Combien d’écarts As-Is vs To-Be as-tu identifiés sur ton dernier projet ? Combien sont documentés avec une note de coût, complexité, et valeur ? Combien ont été transformés en projets ?

Deuxième principe — Le Solution Building Block est la brique élémentaire

Le SBB (Solution Building Block) est une brique de solution qui couvre un ou plusieurs écarts. C’est l’unité élémentaire de la transition — plus fine que le projet, plus consistante que la tâche.

L’Open Group distingue deux types de briques :

ABB — Architecture Building Block — la description cible d’un composant (métier, données, application, technique). C’est ce que l’architecture prédit.
SBB — Solution Building Block — l’implémentation choisie pour réaliser un ABB. C’est ce que l’architecture décide.

Le SBB est l’unité qui sert à budgéter, à planifier, à contractualiser. Un SBB peut être :

Une application packagée (un ERP, un CRM, un ETL)
Un développement spécifique (un service, une API, un module)
Un composant SaaS (un service cloud souscrit)
Une prestation (du conseil, de la formation, de l’intégration)

La contrefaçon classique consiste à confondre SBB et projet. Un projet peut contenir plusieurs SBB ; un SBB peut s’étendre sur plusieurs projets. La parade est de maintenir une bibliothèque de SBB avec leur description, leur coût, leur délai, leur fournisseur, et leur état (à l’étude, choisi, en cours, livré, décommissionné).

Et toi ? Combien de SBB as-tu identifiés sur ton dernier projet ? Combien ont une bibliothèque tenue à jour ? Combien ont un fournisseur identifié ?

Troisième principe — Les architectures de transition évitent les bonds

On ne passe jamais d’un coup d’un SI à un autre. Les architectures de transition décrivent les états intermédiaires qui maintiennent la cohérence pendant la transformation.

Une architecture de transition est un état cible intermédiaire du SI, qui coexiste avec des éléments anciens et des éléments nouveaux. Elle répond à trois questions :

Quelles applications anciennes restent actives pendant la transition ? (et pour combien de temps)
Comment les nouvelles applications cohabitent-elles avec les anciennes ? (interfaces, synchronisation, bascule progressive)
Quand et comment chaque composant ancien est-il décommissionné ? (critères de bascule, plan de retrait)

La contrefaçon classique consiste à croire qu’on peut basculer en un week-end d’un système à un autre. Cette illusion est mortelle : elle sous-estime la complexité de la cohabitation, ignore les régressions, néglige la formation des utilisateurs. La parade est de privilégier les bascules progressives — un utilisateur, un service, une région à la fois — avec des architectures de transition explicites.

Pour Mutuelle Plus, Élise a défini sept architectures de transition sur 24 mois (voir schéma ci-dessus) :

T0 — état initial (le SI legacy)
T1 — MDM client en place (la donnée client est unifiée)
T2 — CRM en place (les processus front-office migrent)
T3 — ERP intégré (les processus back-office migrent)
T4 — BI en place (le reporting est unifié)
T5 — applications décommissionnées (la dette se résorbe)
T6 — état cible (le SI est stabilisé)

Chaque transition Tn → Tn+1 a ses propres critères de bascule, ses propres tests de non-régression, ses propres KPIs de succès.

Et toi ? Combien d’architectures de transition as-tu définies sur ton dernier projet ? Combien sont documentées avec des critères de bascule explicites ? Combien de bascule ont été effectivement réalisées en une seule fois ?

Quatrième principe — La roadmap est priorisée par valeur et risque

Une roadmap qui classe les chantiers par ordre chronologique sans logique de valeur et de risque est un calendrier, pas une stratégie.

L’Open Group recommande que la roadmap soit structurée en trois vagues :

Vague 1 — Quick wins — chantiers à fort impact, faible complexité, court terme. Ils démontrent la valeur de l’architecture.
Vague 2 — Fondations — chantiers structurants qui débloquent les chantiers suivants. Investissement lourd, valeur différée.
Vague 3 — Rayonnement — chantiers d’optimisation, d’innovation, d’extension. Ils valorisent les fondations.

Chaque vague contient 5 à 10 chantiers. Chaque chantier a un sponsor identifié, un indicateur de succès chiffré, un budget estimé, et un délai cible.

La contrefaçon classique consiste à présenter la roadmap comme un Gantt de 24 mois sans hiérarchie. Cette vision plate ne permet pas de prendre des décisions de priorisation. La parade est de maintenir la roadmap par valeur — chaque chantier peut être reclassé si sa valeur se révèle plus ou moins importante que prévu.

Et toi ? Combien de vagues structurent ta roadmap ? Combien de quick wins ont été identifiés pour la Vague 1 ? Quel est le sponsor de chaque vague ?

Cinquième principe — Le Work Package est l’unité budgétable

Le Work Package (WP) est un lot de travaux qui peut être budgété, planifié et exécuté par une équipe. C’est l’unité qui relie l’architecture à l’opérationnel.

Un WP contient typiquement :

Un périmètre fonctionnel — ce qui est livré
Des critères d’acceptation — comment on sait que c’est terminé
Un budget — estimé ou engagé
Un délai — estimé ou engagé
Une équipe — interne, externe, ou mixte
Des dépendances — amont et aval dans la roadmap

La contrefaçon classique consiste à confondre WP et chantier, WP et SBB, WP et projet. La parade est de maintenir un référentiel des WP qui permet de suivre l’avancement, de détecter les dérives, et de communiquer avec le sponsor.

Pour Mutuelle Plus, Élise a tenu un tableau de bord des WP pendant 24 mois, avec un WP par chantier, une mise à jour hebdomadaire, et une revue mensuelle avec le COMEX. Ce suivi a permis de détecter tôt les dérives (chantier A en retard de 6 semaines → arbitrage sur le périmètre) et de célébrer les quick wins (chantier B livré en avance → communication positive).

Et toi ? Combien de WP as-tu définis sur ton dernier projet ? Combien ont un budget engagé ? Combien ont un sponsor identifié ? Quel est ton taux de livraison à l’heure ?

Application — Ma roadmap 90 jours

À produire séance tenante. Cinq sections précises.

Analyse d’écarts — 5 à 10 écarts prioritaires (As-Is vs To-Be), notés coût / complexité / valeur.
SBB — 2 à 3 Solution Building Blocks, chacun avec son périmètre et son fournisseur envisagé.
Architectures de transition — 2 à 3 états intermédiaires, avec critères de bascule.
Roadmap — 3 vagues (quick wins / fondations / rayonnement), 5 à 10 chantiers par vague.
Work Packages — 1 WP par chantier prioritaire, avec budget, délai, sponsor, équipe.

Cette roadmap est ton premier livrable de Phases E-F. Elle rend l’architecture actionnable.

Module complémentaire — Le langage financier de l’architecte : TCO, Business Case et pitch COMEX

Une roadmap de transition ne vaut rien si elle n’est pas traduite dans le vocabulaire du décideur. L’architecte d’entreprise qui présente un schéma de capacités à un COMEX passe pour un technicien ; celui qui présente un TCO sur cinq ans, un Coût de l’Inaction chiffré et trois options comparées passe pour un partenaire stratégique. Ce module donne à l’architecte les outils financiers nécessaires pour transformer une trajectoire technique en décision exécutive.

La structure du TCO sur cinq ans

Le TCO (Total Cost of Ownership) remplace la vision « coût projet » par une vision de possession sur cinq ans. Pour Mutuelle Plus, dont le chiffre d’affaires plafonne à 100 M€ face à des géants pesant des milliards, chaque décision d’architecture doit être un arbitrage sur la préservation des fonds propres (1 Md€) et le maintien de la marge de solvabilité.

Décomposition CAPEX / OPEX :

Composante	Nature	Éléments inclus pour Mutuelle Plus
CAPEX (Investissement)	Immobilisations	Licences, infrastructures Cloud (IaaS), coûts de conception (ADM Phases A-D), migration des données clients
OPEX (Exploitation)	Charges courantes	Abonnements SaaS, maintenance corrective et évolutive (Phase H), support N1/N2/N3, formation des 800 collaborateurs

Coûts cachés à quantifier explicitement :

Vendor Lock-in subi : la rigidité de Gest+ empêche toute négociation tarifaire et bloque l’agilité métier. C’est un coût invisible mais réel.
Passifs de non-conformité : le retard sur le RGPD constitue une provision pour risque juridique et financier au bilan.
Dette d’intégration : le coût de maintenance du Shadow IT (tableurs par agence) représente un surcoût opérationnel direct.

Formule du TCO sur 5 ans :

TCO₅ₐₙₛ = Σ CAPEX_initiaux + Σ (OPEX_annuels / (1+i)^n)

où i représente le taux d’actualisation financier. L’actualisation reflète la valeur temps de l’argent : un euro dépensé dans trois ans coûte moins qu’un euro dépensé aujourd’hui.

Le Coût de l’Inaction (COI) — la traduction financière de la dette technique

Le DAF ne raisonne pas en « bugs » mais en « érosion de la marge de solvabilité ». L’architecte doit traduire le ressenti technique en Coût de l’Inaction (COI), c’est-à-dire ce que l’organisation perd chaque année à ne pas transformer.

Exemple chiffré — Mutuelle Plus :

Source d’inefficacité	Calcul	Total annuel
Coût de la non-qualité (incidents)	500 erreurs de remboursement × 200 €/incident	100 000 €/an
Coût du ralentissement (productivité)	10 000 tickets × 5h supplémentaires × 50 €/h	250 000 €/an
Perte de vitesse portefeuille (résiliations faute de réactivité)	1 % d’adhérents perdus × ~300 € de cotisation moyenne	3 000 000 €/an
Total COI estimé		~3 350 000 €/an

Pour le COMEX, ce chiffre n’est pas une dépense informatique mais une perte sèche de 3 % du chiffre d’affaires annuel, menaçant directement les fonds propres. C’est cette traduction qui fait basculer le débat du « luxe qu’on ne peut pas se permettre » vers l’« urgence économique à traiter ».

Le template de Business Case simplifié (une page)

Le Business Case est le support d’arbitrage ultime pour débloquer les budgets de transformation. Il tient en une page et présente trois options chiffrées.

Structure type :

Section	Contenu
Contexte stratégique	Nécessité de restaurer la « solidarité intergénérationnelle » en attirant des cotisants jeunes. Alignement du SI pour servir les agents territoriaux.
Options étudiées	1. Do Minimum — maintenance Gest+ (COI ~3 M€/an). 2. Cible intermédiaire — réhabilitation partielle. 3. Cible idéale — CRM SaaS moderne.
KPIs financiers	ROI sur 3 ans, période de payback, TCO à 5 ans.
Risques résiduels	Adoption utilisateur (l’âge moyen de 43 ans nécessite un plan de formation massif).

Le pitch COMEX en trois slides (dix minutes)

L’objectif est d’obtenir un arbitrage en dix minutes en parlant « valeur métier ».

Slide 1 — L’effet ciseau financier. Message : Notre SI est le goulot d’étranglement qui nous empêche de créer des produits spécifiques. Visuel : graphique en « ciseau » montrant la hausse des coûts de couverture (vieillissement) croisant la baisse des cotisations (perte de jeunes adhérents).

Slide 2 — Trajectoires de valeur. Message : L’inaction nous coûte 15 M€ sur 5 ans. L’investissement de 2,5 M€ est amorti en 14 mois. Visuel : comparaison des courbes de TCO (Statu Quo vs CRM SaaS).

Slide 3 — Recommandation de l’architecte. Message : Lancer le projet CRM pour protéger notre milliard d’euros de fonds propres et automatiser la gestion des réclamations. Visuel : tableau de bord prospectif liant la technologie à la marge de solvabilité.

Trois pièges fatals à éviter :

Le jargon technique. Évitez « Micro-services », dites « Capacité d’évolution modulaire ».
L’absence de chiffres. Ne parlez jamais de « besoin », parlez de « perte sèche ».
Le manque d’alternative. Quantifiez toujours l’option « Inaction » pour souligner le danger.

Étude de cas chiffrée — Refonte du CRM de Mutuelle Plus

Mutuelle Plus (800 collaborateurs, 1 million d’assurés) souffre d’une fragmentation de la donnée client, chaque agence gérant ses propres tableurs.

Critère	Statu Quo (Gest+)	Réhabilitation partielle	CRM SaaS moderne
Investissement (CAPEX)	0 €	1,2 M€	2,5 M€
Dette technique (COI/an)	3 M€	1,5 M€	0,2 M€
TCO sur 5 ans	15 M€	8,7 M€	3,5 M€
Payback Period	N/A	30 mois	14 mois
ROI sur 3 ans	Négatif	~25 %	~45 %

Lecture : l’option CRM SaaS divise le TCO par quatre par rapport au statu quo. C’est le levier indispensable pour attirer les cotisants jeunes et stabiliser la base client. L’architecte dispose ici d’un argument financier béton pour défendre la cible.

Le « Shift Left Finance » — intégrer la gouvernance FinOps dans le cycle ADM

Pour garantir la pérennité financière, l’AE pratique le Shift Left Finance : intégrer le contrôle des coûts dès la conception.

Cartographie ADM ↔ FinOps :

Phase C (SI) : distinction entre ABB et SBB. Sélection des briques de solution selon leur efficience énergétique et financière.
Phase E (Opportunités) : arbitrage financier. Choix des solutions Cloud basé sur la consommation réelle plutôt que sur le sur-provisionnement historique.
Phase F (Planning) : utilisation de l’Architecture de Transition. On définit des paliers incrémentaux qui délivrent une valeur métier immédiate (ex. : numérisation des contrats d’abord) pour autofinancer la suite de la transformation.
Phase G (Gouvernance) : boucle FinOps (Inform → Optimize → Operate). Suivi en temps réel de la dérive budgétaire.

Cette gouvernance garantit que l’architecture reste un moteur de rentabilité, pas un poste de coût.

Synthèse

Maîtriser les chiffres n’est pas optionnel pour l’architecte d’entreprise. C’est ce qui transforme un schéma directeur en un dossier d’investissement, et un dossier d’investissement en une décision exécutive. Le COMEX ne raisonne pas en « conformité aux principes TOGAF » ; il raisonne en marge de solvabilité, ROI, payback, risque de non-conformité. L’architecte qui parle ce langage devient un partenaire stratégique ; celui qui ne le parle pas reste un prestataire technique.

Encadré Au lecteur / À l’animateur

Question d’ouverture : « Combien d’écarts As-Is vs To-Be as-tu identifiés sur ton dernier projet ? »

Profils à observer :

Le sauteur. Voudrait basculer en un week-end d’un SI à un autre. Question : « Combien d’architectures de transition as-tu définies ? »
Le collectionneur d’écarts. Produit une liste de 200 écarts sans hiérarchie. Question : « Combien d’écarts sont notés coût / complexité / valeur ? »
Le projet par chantier. Confond WP et SBB, WP et projet. Question : « Combien de WP ont un budget engagé ? »
Le planneur plat. Présente la roadmap comme un Gantt sans hiérarchie. Question : « Combien de vagues structurent ta roadmap ? »

Pièges d’animation :

Ne pas laisser la discussion dériver vers les outils (MS Project, Jira, etc.). Rappeler que la roadmap est d’abord un document stratégique.
Ne pas confondre architecture de transition et architecture cible. La transition décrit un état intermédiaire, la cible décrit l’état final.

Ce que la leçon 11 vous demande

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

Une analyse d’écarts structurée par couche, avec 5 à 10 écarts prioritaires.
Une bibliothèque de 2 à 3 SBB avec leurs caractéristiques.
Une roadmap 3 vagues avec 5 à 10 chantiers par vague.

Sources de cette leçon : TOGAF Standard 10ᵉ (Phases E-F) · TOGAF Series Guide to Business Capability Planning (G233e) · Cas Mutuelle Plus (anonymisé)

Leçon suivante : L11 — Gouvernance de l’Implémentation (Phase G) : assurer la conformité.