Aligner Business et IT : ce que le BIZBOK® v3 change vraiment dans nos missions

On parle d'alignement Business-IT depuis trente ans. Et pourtant, selon Genpact Research, près de 400 milliards de dollars dépensés dans des projets digitaux sur 600 milliards aboutissent à des résultats décevants. Deux tiers des programmes sont soit abandonnés, soit en deçà des attentes. Quand on lit ce chiffre en mission, on ne le trouve pas exagéré : on le retrouve dans les comités où personne ne sait dire quelle capacité métier supporte quelle application — ni l'inverse.

Le whitepaper du Business Architecture Guild publié en septembre 2025, « Business and IT Architecture Metamodel Alignment », tombe à pic. Il ne réinvente pas l'architecture d'entreprise. Il fait quelque chose de plus utile : il pose noir sur blanc comment le métamodèle BIZBOK® v3 (capacités, chaînes de valeur, organisation, information) se connecte formellement au métamodèle IT (applications, services logiciels, données). C'est cette connexion-là qui manque dans 80% des organisations que je croise.

Ce que j'aime dans le cadrage du document, c'est l'angle « current → target ». L'architecture métier décrit l'écosystème actuel, le même métamodèle décrit la cible, et la transformation devient l'arbitrage entre les deux. La couche IT (application + données) est l'écho fidèle de cette transformation. Tout le reste — shadow systems, technical architecture — est volontairement mis en hors-scope. C'est sain : on arrête de prétendre tout cartographier pour enfin pouvoir décider.

Le pivot du document, et c'est aussi le pivot de mes missions, c'est la capacité métier. Pas le processus, pas l'application, pas l'org chart. La capacité, parce qu'elle est stable dans le temps, parce qu'elle est neutre vis-à-vis de la techno, et parce qu'elle est le seul concept qu'un DG, un DSI et un développeur peuvent partager sans malentendu. Le whitepaper en fait explicitement le « central focal point » de l'alignement Business-IT.

Concrètement, voilà comment je traduis ça en mission. D'abord, je construis ou j'audite la capability map de niveau 1-2. Ensuite, je trace la matrice capacités × applications. Pas dans Excel. Dans HOPEX, BizzDesign ou LeanIX, en exploitant les relations natives « automatise » entre Application et Capability. C'est ce mapping qui révèle les vraies décisions : capacité critique mal supportée = investir, capacité non stratégique sur-supportée = simplifier.

Le whitepaper formalise ensuite les relations entre Software Service, Software Feature, Capability Behavior et Capability Instance. Ça paraît théorique, mais c'est exactement ce qui permet, au moment du chiffrage d'un projet, de répondre à la question que personne ne sait trancher : « si on automatise cette capacité, combien de services impactés, combien de features à livrer, combien d'objets de données touchés ? » Sans cette grammaire, on chiffre à la louche. Avec, on chiffre sur des faits.

Le volet données est tout aussi puissant. Le document fait du Business Object le pivot entre information métier et data architecture. Sur mes missions, c'est ce qui résout le débat éternel entre les architectes data et les architectes métier : tout le monde modélise le même « Client », le même « Contrat », le même « Produit ». Quand l'objet métier est commun, les data lakes arrêtent d'être des silos parallèles à l'IS opérationnel.

Mon retour sur le whitepaper, sans détour : il ne révolutionne rien, mais il met de l'ordre dans une discipline qu'on a laissée se diluer dans les buzzwords « digital ». Pour un architecte d'entreprise sur le terrain, c'est une caisse à outils sérieuse. À utiliser pas pour produire des slides supplémentaires — mais pour pouvoir enfin dire en comité, fact-based : voilà ce qui doit changer, voilà combien ça coûte, voilà l'impact métier.