L5 — L'Architecture Métier (Phase B) : la Business Capability Map

« Capability-Based Planning shifts the focus from projects to capabilities — what the enterprise must do, not what it builds. » — The Open Group, TOGAF Series Guide — Business Capability Planning (G233e)

« Décrire ce que l’organisation fait, avant de décrire comment elle le fait. »

Vidéo d’introduction

L5 — L'Architecture Métier (Phase B)

Télécharger cette leçon en PDF

Le platane qui cache la forêt

Sophie arrive en septembre 2019 comme architecte d’entreprise senior chez GreenTech, une ETI de 1 200 salariés dans le secteur de l’énergie renouvelable. La DSI a dix-huit mois d’historique de schémas d’architecture en tout genre : trois applications de cartographie, 47 documents ArchiMate non datés, une « cartographie SI » PowerPoint qui n’a jamais été mise à jour depuis sa création. Sophie passe ses trois premières semaines à interviewer les acteurs, à collecter les documents existants, à reconstituer l’histoire.

Le huitième jour, elle découvre le pot aux roses. Lors d’une réunion avec la directrice des opérations, celle-ci lui montre un schéma qu’elle a dessiné elle-même sur un coin de tableau blanc : « Voilà comment fonctionne GreenTech. » Le schéma fait neuf boîtes. Neuf capacités métier. Elles se lisent comme suit :

Prospecter de nouveaux clients
Contractualiser avec les clients
Concevoir les installations
Construire les installations
Exploiter les installations
Maintenir les installations
Facturer les clients
Recouvrer les paiements
Innover sur les nouvelles technologies

Sophie a passé huit jours à reconstituer un puzzle d’objets techniques, de serveurs, d’applications, de processus. Il lui a suffi d’un quart d’heure avec une opérationnelle pour obtenir la véritable carte du territoire — la carte des capacités que l’organisation doit maîtriser pour exister. Neuf capacités. Pas dix-sept applications, pas trois applications de cartographie, pas quarante-sept documents. Neuf capacités.

Le choc est salutaire. Sophie comprend ce que l’Open Group appelle Capability-Based Planning (TOGAF Series Guide G233e) : la Phase B ne consiste pas à modéliser les processus, ni à dessiner des applications, ni à lister les serveurs. Elle consiste à identifier les capacités que l’organisation doit maîtriser pour remplir sa mission, puis à les organiser, les hiérarchiser, et les relier.

La Business Capability Map est l’outil qui rend cette pratique concrète. C’est une carte — un schéma — qui représente toutes les capacités métier de l’organisation, regroupées par domaines (marketing, vente, opérations, finance, RH, etc.). C’est le premier livrable canonique de la Phase B, et c’est ce que cette leçon cherche à vous apprendre à produire.

Voici à quoi ressemble une Capability Map structurée à trois niveaux (Domaine → Macro-capacité → Capacité opérationnelle) :

Capability Map à 3 niveaux : Domaine, Macro-capacité, Capacité opérationnelle

Premier principe — Capability ≠ Processus ≠ Application

L’une des confusions les plus coûteuses de la Phase B consiste à confondre trois objets très différents : les capacités, les processus, et les applications. Cette confusion produit des cartographies qui ne sont ni des capacités, ni des processus, ni des applications — des objets hybrides qui ne servent personne.

L’Open Group distingue clairement les trois dans son guide de référence (G233e). Une capacité est ce que l’organisation doit savoir faire. Elle est stable dans le temps — une mutuelle « sait facturer » depuis sa création, et continuera dans vingt ans. Elle ne se réduit pas à un processus unique (on peut facturer de plusieurs manières) ni à une application unique (on peut facturer avec plusieurs outils).

Un processus est comment l’organisation exerce ses capacités. Il décrit une séquence d’activités coordonnées par des acteurs et soutenues par des applications. Plusieurs processus peuvent contribuer à la même capacité. La capacité « facturation » peut s’exercer via un processus de facturation B2B (pour les grands clients), un processus de facturation B2C (pour les particuliers), un processus de facturation de prestations ponctuelles. Tous servent la même capacité.

Une application est ce que l’informatique fournit comme support aux processus. Une même application peut servir plusieurs processus, et donc plusieurs capacités. Un ERP peut servir la facturation, la comptabilité, la gestion des stocks — trois capacités distinctes, soutenues par un même système.

La contrefaçon la plus courante consiste à dessiner un schéma où les boîtes sont étiquetées « capacité » alors qu’elles décrivent des processus ou des applications. Le schéma « Gestion des contrats » ou « Progiciel SAP » est une capacité-écran : derrière ces mots se cachent soit des processus, soit des applications. La parade est de tester chaque boîte par la question : « cette boîte reste-t-elle valide dans cinq ans ? ». Si oui, c’est une capacité. Si non, c’est un processus ou une application.

Et toi ? Sur ta dernière « cartographie SI », combien de boîtes sont des capacités, combien des processus, combien des applications ? La distinction est-elle claire dans ton organisation ?

Deuxième principe — La hiérarchie des capacités évite le plat unique

Une Business Capability Map qui ne hiérarchise pas ses capacités produit un « plat unique » — une longue liste plate où tout est au même niveau. Cette structure perd sa valeur stratégique dès qu’on dépasse la trentaine de capacités.

L’Open Group recommande une hiérarchie à trois niveaux :

Niveau 0 — Domaine — les grandes familles (Marketing, Ventes, Opérations, Finance, RH, IT, Stratégie…)
Niveau 1 — Macro-capacité — les grandes fonctions au sein d’un domaine (Marketing → Prospection, Communication, Fidélisation)
Niveau 2 — Capacité — l’unité opérationnelle minimale (Marketing → Prospection → Génération de leads, Qualification, Conversion)

Cette hiérarchie permet plusieurs usages :

Vue macro (Niveau 0-1) — pour les discussions COMEX, les revues annuelles, les arbitrages budgétaires
Vue opérationnelle (Niveau 1-2) — pour les décisions d’investissement, les analyses de cible, la cartographie applicative
Vue de drill-down — pour analyser l’écart entre As-Is et To-Be sur une capacité précise

La contrefaçon à éviter est le plat unique. Une organisation qui a 80 capacités au même niveau produit une carte illisible, qui ne sert qu’à montrer qu’on a 80 boîtes — pas à prendre des décisions. La parade est de résister à la tentation du détail : tant qu’une capacité n’est pas l’objet d’une décision ou d’une discussion active, elle reste au niveau supérieur.

Et toi ? Combien de niveaux ta dernière cartographie a-t-elle ? Combien de capacités sont au niveau le plus fin ? Ce chiffre est-il cohérent avec le nombre de décisions prises sur la base de cette cartographie ?

Troisième principe — La Capability Map n’est pas un projet, c’est une pratique

L’un des travers les plus coûteux consiste à traiter la Business Capability Map comme un livrable de projet — un document qu’on produit en trois mois et qu’on n’actualise plus jamais. Cette approche produit des cartographies qui pourrissent sur étagères.

L’Open Group recommande que la Capability Map soit vivante :

Versionnée — un historique des versions, daté, archivé
Maintenue — une équipe (même petite) responsable des mises à jour
Consultée — utilisée dans les revues de gouvernance, les arbitrages budgétaires, les décisions d’investissement
Évolutive — révisée annuellement, avec un cycle de validation léger

Sans cette discipline, la cartographie devient un monument commémoratif d’une intention passée. Avec cette discipline, elle devient un outil de gouvernance — un référentiel commun qui structure les décisions.

Chez GreenTech, Sophie a institué une revue trimestrielle de la Capability Map — trois réunions de deux heures par an, avec les propriétaires de domaine (Directeurs Marketing, Ventes, Opérations, etc.). Chaque révision ajoute une à trois capacités, en supprime une à deux obsolètes, et raffine le libellé d’une demi-douzaine. La cartographie reste à jour sans peser sur l’équipe d’architecture.

Et toi ? À quand remonte la dernière mise à jour de ta cartographie ? Combien de fois a-t-elle été consultée pour une vraie décision cette année ? Si la réponse est « moins de trois fois », ta cartographie est probablement un monument commémoratif.

Quatrième principe — Le Capability Planning oriente l’investissement, pas l’inverse

Le piège classique consiste à déduire la cartographie des applications existantes, plutôt que d’orienter les applications par la cartographie des capacités. Cette inversion transforme la Phase B en documentation du SI, pas en architecture.

Le Capability-Based Planning (G233e) prescrit l’ordre suivant :

Identifier les capacités — ce que l’organisation doit savoir faire
Évaluer la maturité de chaque capacité — où en sommes-nous (1 à 5) sur chacune
Identifier les écarts — où la maturité est insuffisante par rapport aux objectifs
Hiérarchiser les investissements — par capacité, pas par projet applicatif

L’inverse — déduire les capacités des applications — produit des capacités « il y a SAP pour la finance », « il y a SalesForce pour le CRM ». Ces formulations masquent un problème fondamental : on ne sait pas ce que l’organisation doit faire, on sait seulement ce qu’elle fait avec ses outils actuels. Le Capability Planning sert précisément à échapper à cette myopie.

L’Open Group l’explicite ainsi dans le guide G233e : « Capability-Based Planning shifts the focus from projects to capabilities — what the enterprise must do, not what it builds ». Le glissement de « projects » vers « capabilities » est l’inversion stratégique qui distingue une AE moderne d’une simple documentation du SI existant.

La contrefaçon à éviter : se laisser tenter par un Capability Planning dont les capacités sont si vagues qu’elles n’orientent aucun investissement (« Innovation », « Excellence opérationnelle »). Ces capacités-écrans ne servent qu’à orner des slides. La parade est de tester chaque capacité par la question « quel investissement cette capacité oriente-t-elle ? ». Si la réponse est floue, la capacité est trop abstraite — il faut la décomposer.

Et toi ? Sur ton dernier plan d’investissement SI, les projets étaient-ils classés par capacité métier, ou par application ? Si par application, quelle visibilité avais-tu sur la couverture réelle des capacités ?

Cinquième principe — Les Value Streams complètent les Capabilities

La Business Capability Map montre ce que l’organisation doit savoir faire. Les Value Streams montrent comment elle crée de la valeur, de bout en bout, à travers ces capacités. Les deux sont complémentaires.

L’Open Group publie un guide dédié aux Value Streams (G178e). Un Value Stream est une séquence de bout en bout qui traverse plusieurs capacités pour créer de la valeur pour un client (interne ou externe). Pour GreenTech, le Value Stream « Acquisition d’un nouveau client B2B » traverse les capacités :

Prospecter (génération de leads)
Qualifier (scoring)
Contractualiser (négociation)
Concevoir (étude technique)
Construire (installation)
Facturer (première facture)
Recouvrer (paiement)

Sept capacités traversées. Le Value Stream rend visible le parcours complet — ce que la Capability Map seule ne montre pas. Une capacité peut être mature (note 5/5) sans que le Value Stream qui la traverse soit performant — par exemple si les transitions entre capacités sont maladroites, mal outillées, mal gouvernées.

L’articulation entre Capability Map et Value Streams est au cœur de la Phase B :

La Capability Map sert à structurer le portefeuille d’investissement : où investir pour combler les écarts de maturité
Les Value Streams servent à structurer les chantiers opérationnels : où fluidifier les transitions pour améliorer l’expérience client

La contrefaçon à éviter : se contenter de la Capability Map sans Value Streams. On investit alors pour « améliorer la capacité de facturation » sans réaliser que la vraie douleur du client est dans la transition entre « facturation » et « recouvrement ». La Capability Map seule est myope sur les frictions.

Et toi ? Combien de Value Streams as-tu identifiés pour ton organisation ? Traversent-ils les capacités critiques de bout en bout ? As-tu déjà mesuré le temps de cycle d’un Value Stream complet ?

Application — Ma Capability Map

À rédiger séance tenante. Trois livrables précis, à afficher et à confier à deux personnes de confiance.

Niveau 0 — Domaines — Les six à douze grandes familles de capacités de ton organisation. Marketing, Ventes, Opérations, Finance, RH, IT, Stratégie… Adapte au contexte.
Niveau 1 — Macro-capacités — Pour chaque domaine, les quatre à huit grandes fonctions. Marketing → Prospection, Communication, Fidélisation, Études, Pricing. Etc.
Niveau 2 — Capacités opérationnelles — Pour chaque macro-capacité, les trois à cinq unités opérationnelles minimales. Marketing → Prospection → Génération de leads, Qualification, Conversion, Suivi.

|> Cette carte est ton premier livrable de Phase B. C’est elle qui orientera tes investissements, tes analyses d’écart, et tes chantiers opérationnels.

Module complémentaire — La friction AE × Agilité au niveau métier

La Phase B produit une cartographie stable des capacités métier (L0 → L1 → L2). Les méthodes agiles produisent un flux d’événements changeants (Epics, Features, Stories). Comment ces deux visions s’articulent-elles sans se neutraliser ?

Le Capability Map n’est pas un backlog

Une erreur fréquente consiste à confondre la Capability Map (cartographie des capacités stables) avec un Product Backlog (liste de choses à faire changeante). Ces deux artefacts ont des objectifs différents :

La Capability Map décrit ce que l’organisation sait faire (ou devrait savoir faire) à un horizon de 3 à 5 ans. Elle est révisée annuellement, pas quotidiennement.
Le Product Backlog décrit ce que l’organisation va faire dans les prochaines semaines. Il change à chaque sprint.

Le Capability Map est au Product Backlog ce que la stratégie est au plan d’action tactique : la première fixe le cap, le second adapte les moyens au terrain.

Le flux de valeur métier (Value Stream Mapping)

Pour relier la Capability Map aux trains agiles, l’AE utilise le concept de flux de valeur métier (Development Value Stream, concept SAFe aligné TOGAF). Un flux de valeur est la séquence des capacités nécessaires pour délivrer un résultat métier donné.

Exemple Mutuelle Plus : le flux de valeur « Remboursement santé » traverse les capacités suivantes :

Réception de la demande (canal web, agence, courrier).
Vérification des droits (capacité « Adhésion & Éligibilité »).
Contrôle de cohérence (capacité « Détection de fraude »).
Calcul du remboursement (capacité « Gestion des prestations »).
Mise en paiement (capacité « Comptabilité »).
Notification à l’adhérent (capacité « Communication client »).

Ce flux traverse plusieurs domaines et donc plusieurs équipes agiles potentielles. C’est à l’AE de garantir que les NFR (performance, sécurité, conformité RGPD) sont respectées à chaque maillon du flux, et que les dépendances inter-équipes sont identifiées.

Le rôle de l’AE dans le PI Planning métier

Dans un PI Planning qui aligne plusieurs trains agiles sur un flux de valeur métier, l’AE intervient pour :

Vérifier que les Features planifiées s’inscrivent dans la Capability Map. Une Feature sans capacité cible est une Feature qui crée du code orphelin.
Identifier les capacités sous-tension. Une capacité mobilisée par 12 Features dans le même sprint est probablement un goulot d’étranglement à court terme. L’AE remonte l’alerte.
Tracer les dépendances inter-domaines. Si une Feature du domaine « Santé Individuelle » dépend d’une capacité du domaine « Réclamations », cette dépendance doit être visible, documentée, et priorisée dans le backlog.
Aligner la dette technique avec la cible. Si la Capability Map prévoit une cible « Détection de fraude automatisée » dans 18 mois, l’AE s’assure que les Enablers actuels construisent progressivement cette capacité, plutôt que de colmater les failles du présent.

Trois erreurs de friction AE × Agilité à éviter

L’AE qui veut imposer une Capability Map rigide. Le métier évolue, les capacités évoluent. L’AE qui refuse de réviser la cartographie tous les 12 mois devient un frein plutôt qu’un cadre.
L’équipe agile qui ignore la Capability Map. Une équipe qui développe sans regarder la cartographie crée du code qui ne s’inscrit dans aucune vision long terme. Six mois plus tard, personne ne sait pourquoi cette application existe.
La confusion entre Feature et Capacité. Une Feature (« Bouton de paiement en un clic ») n’est pas une Capacité (« Gestion des paiements »). L’AE doit maintenir cette distinction : la Capacité est stable, la Feature est ponctuelle.

Synthèse

L’AE ne s’oppose pas à l’agilité. Il l’ancre dans une vision métier stable. La Capability Map est le contrat de cohérence entre le long terme (stratégie, capacités) et le court terme (Features, sprints). Sans elle, l’agilité produit de la vitesse sans direction ; sans l’agilité, la cartographie reste théorique. Les deux se complètent.

Encadré Au lecteur / À l’animateur

Question d’ouverture : « Sur ton dernier projet d’architecture, as-tu modélisé des capacités, des processus, ou des applications ? La distinction est-elle claire ? »

Profils à observer :

Le cartographe du SI existant. Décrit ce que les outils font, pas ce que l’organisation doit faire. Question : « Cette capacité reste-t-elle valide dans cinq ans ? »
Le stratège qui pense en catégories abstraites. Produit des capacités « Excellence opérationnelle » qui n’orientent rien. Question : « Quel investissement concret cette capacité oriente-t-elle ? »
Le processeux qui modélise des processus sous le nom de capacités. Confond les niveaux d’abstraction. Question : « Cette boîte est-elle un quoi ou un comment ? »
Le rêveur qui veut 200 capacités. Vise l’exhaustivité, produit l’illisibilité. Question : « Combien de décisions sont prises sur cette capacité dans l’année ? »

Pièges d’animation :

Ne pas laisser la discussion dériver vers les outils (SAP, SalesForce, Office 365). Rappeler que la Capability Map est indépendante des outils.
Ne pas confondre Capability Map et cartographie SI. La première est stable dans le temps ; la seconde est mouvante.

Ce que la leçon 6 vous demande

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

Votre Capability Map à trois niveaux, validée par les propriétaires de domaine.
Trois Value Streams critiques, identifiés de bout en bout.
Une évaluation de maturité (1 à 5) pour chacune des macro-capacités.

Sources de cette leçon : TOGAF Series Guide to Business Capability Planning (G233e) · TOGAF Series Guide to Value Streams (G178e) · Desfray & Raymond, TOGAF en pratique (chap. 7) · Cas GreenTech (anonymisé)

Leçon suivante : L6 — La Modélisation des Processus (BPMN) : la grammaire du comment.