Posez la question à un comité de direction : « Où devons-nous investir dans notre système d’information l’an prochain ? » La réponse arrive souvent sous la forme d’une liste de projets, ou d’un inventaire de quatre cents applications dont personne ne s’accorde sur l’utilité. C’est le symptôme d’un angle mort : l’organisation raisonne en applications et en projets, pas en capacités.

La carte des capacités métier est l’outil qui corrige cet angle mort. C’est sans doute l’artefact d’architecture le plus puissant — et le plus sous-utilisé. Voici pourquoi, et comment construire la vôtre.

Le symptôme : des décisions SI prises sans carte

Sans référentiel partagé, les arbitrages SI se prennent à l’aveugle. Chaque direction défend ses projets, chaque éditeur pousse sa solution, et la priorisation se fait à la voix la plus forte plutôt qu’à la valeur. On finit par investir dans ce qui est visible (un nouveau portail) au détriment de ce qui est critique mais invisible (la gestion des identités, la qualité des données).

Le résultat est connu : des systèmes qui se dupliquent, des budgets dispersés, et une incapacité chronique à répondre simplement à « qu’est-ce qui crée vraiment de la valeur, et où sommes-nous fragiles ? ».

Qu’est-ce qu’une carte des capacités métier ?

Une capacité métier décrit ce que l’organisation sait faire — « gérer les sinistres », « accorder un crédit », « fidéliser un client » — indépendamment de comment elle le fait (le processus) ou de avec quoi (l’application). C’est une abstraction délibérément stable : vos processus changent, vos logiciels sont remplacés, mais la capacité « facturer un client » reste.

Une carte des capacités les organise par niveaux (L1 → L2 → L3), du plus général au plus détaillé, et offre une vue unique, partagée par le métier et la DSI. Elle ne dit pas comment travailler ; elle donne un langage commun pour décider.

Trois confusions à éviter :

  • Capacité ≠ processus. Le processus est une séquence d’activités ; la capacité est l’aptitude sous-jacente. Un même processus peut mobiliser plusieurs capacités.
  • Capacité ≠ application. Une application outille une ou plusieurs capacités ; elle n’est pas la capacité.
  • Capacité ≠ organigramme. Une capacité traverse souvent plusieurs services — c’est justement sa force.

Pourquoi l’inventaire applicatif ne suffit pas

Beaucoup d’organisations possèdent un inventaire applicatif (souvent dans une CMDB) et croient avoir une vision de leur SI. C’est une carte du comment, pas du quoi. Elle répond à « quels logiciels avons-nous ? » mais pas à « quelles capacités sont sous-investies, redondantes ou critiques ? ».

La carte des capacités est le chaînon manquant entre la stratégie et le SI : la stratégie s’exprime en objectifs et en capacités à renforcer ; le SI s’exprime en applications. Sans la couche capacités au milieu, les deux dialoguent dans des langues différentes — et l’alignement reste un vœu pieux.

Ce que l’absence de cette carte coûte vraiment

Les grands échecs informatiques partagent souvent une même racine : des décisions technologiques déconnectées d’une vision claire des capacités et de leur valeur.

  • Les fusions-acquisitions en sont l’illustration la plus courante. Deux banques qui fusionnent se retrouvent avec deux core banking, deux CRM, deux moteurs de crédit. Sans carte des capacités pour décider quelle brique sert le mieux chaque capacité cible, la rationalisation traîne des années et coûte une fortune en double maintenance.
  • Le National Programme for IT du système de santé britannique (NHS), souvent cité parmi les plus grands échecs informatiques publics, a englouti des milliards de livres avant d’être largement abandonné — un cas d’école d’une informatique pilotée par la technologie et le calendrier politique plutôt que par les capacités réelles du terrain et leur valeur.
  • La migration ratée du core banking de TSB en 2018 a privé pendant des jours des clients britanniques de l’accès à leurs comptes, déclenchant enquêtes réglementaires et sanctions. Au-delà de la technique, c’est l’illustration de ce qu’il en coûte de sous-estimer les dépendances entre capacités, données et systèmes.

Aucune carte de capacités n’aurait à elle seule évité ces déboires. Mais toutes ces situations traduisent la même absence : pas de vue partagée reliant ce que l’organisation doit savoir faire, ce qui le porte, et où se situent les risques.

Construire sa carte de capacités : une méthode en cinq étapes

  1. Partir du métier, pas du SI. Réunissez des responsables métier et identifiez les grandes capacités de niveau 1 (souvent 8 à 15) : ce que l’entreprise fait, pas ses départements.
  2. Décliner par niveaux. Dépliez chaque capacité L1 en L2, puis L3 là où c’est utile. Arrêtez-vous quand un niveau supplémentaire n’aide plus à décider.
  3. Rester stable et exhaustif sans être redondant. Chaque capacité apparaît une seule fois, à un seul endroit (principe MECE). Si vous hésitez à classer quelque chose à deux endroits, c’est souvent un signe de mauvais découpage.
  4. Rattacher applications, données et processus. Une fois la carte stabilisée, reliez chaque capacité aux applications qui l’outillent, aux données qu’elle manipule, aux processus qu’elle sert. C’est là que la carte devient un véritable instrument de pilotage.
  5. Valider et faire vivre. Faites valider la carte par le métier et la DSI — la co-construction fait l’adhésion. Puis maintenez-la : c’est un actif vivant, pas un livrable de fin de mission.

La heatmap : transformer la carte en outil de décision

Une carte des capacités prend toute sa puissance quand on la colorie. En superposant deux dimensions — la maturité actuelle d’une capacité et son importance stratégique (ou sa criticité) — on obtient une heatmap qui montre instantanément où investir : les capacités à la fois critiques et faiblement matures sont vos priorités évidentes.

C’est cette lecture visuelle qui transforme un débat d’opinions en décision argumentée. (Pour voir le principe en action, une carte de capacités interactive figure dans notre bibliothèque de schémas d’architecture.)

Les pièges à éviter

  • Trop de détail. Une carte à cinq niveaux que personne ne lit ne sert à rien. Le bon niveau est celui qui aide à décider.
  • La construire en silo. Une carte produite par la seule DSI sans le métier sera juste… et ignorée. L’adhésion se gagne à la co-construction.
  • La figer. Une carte qui n’évolue pas devient fausse en dix-huit mois.
  • La confondre avec un inventaire. Si votre « carte des capacités » liste des applications, ce n’est pas une carte des capacités.

En résumé

La carte des capacités métier ne remplace ni votre inventaire applicatif, ni vos processus — elle leur donne un sens commun. C’est la lentille qui permet de répondre, enfin sans ambiguïté, à la question qui compte : où investir, et où sommes-nous fragiles ? Pour une organisation qui cherche à aligner durablement sa technologie sur sa stratégie, c’est le point de départ le plus rentable — et le plus souvent négligé.