L'ownership métier de l'IA : le meilleur conseil de l'année, et le plus mal appliqué
L'ownership métier de l'IA : le meilleur conseil de l'année, et le plus mal appliqué
Série Revolution Summit 2026 - article 3/3
Au Revolution Summit Onepoint, les intervenants venant de secteurs très différents, BTP, luxe, services financiers, portaient tous la même conviction : les projets d'IA doivent appartenir aux métiers, pas à l'IT. C'est juste. Mais c'est souvent là que la réflexion s'arrête : comme si nommer qui devait piloter suffisait à résoudre la question de comment.
Une étiquette n'est pas une gouvernance
Le silotage entre métiers et IT était déjà un anti-pattern bien identifié avant l'IA. Les transformations agiles ont travaillé sérieusement à le réduire, avec des résultats réels dans beaucoup d'organisations : des rituels partagés, des équipes mixtes, des rôles à l'interface comme le product owner, censé incarner la collaboration plutôt que la médiation.
- Là où ces approches ont tenu leurs promesses, elles ont rapproché les deux mondes.
- Là où elles ont atteint leurs limites, le product owner est resté en position de relais entre ces deux mondes qui ne se parlaient pas directement, souvent réduit à prioriser et transmettre des besoins : propriétaire du backlog, rarement de la décision. Le silotage de fond avait survécu au changement de méthode.
« Les métiers pilotent l'IA » risque de suivre la même trajectoire. Non parce que la direction est fausse, mais parce que nommer qui doit porter les projets IA ne résout pas la question sous-jacente : comment se gouverne la collaboration entre ceux qui connaissent les processus métier, ceux qui maîtrisent les capacités techniques, et ceux qui détiennent la connaissance de la donnée dans son contexte d'usage ? Sans réponse structurelle à cette question, « les métiers pilotent l'IA » risque d'être réduit à une simple reformulation : le métier exprimait des besoins fonctionnels, il exprime désormais des cas d'usage ; l'IT livrait des systèmes, elle livre des briques IA. Les étiquettes ont changé ; la dynamique, non.
Il y a une autre dimension que ce consensus tend à laisser dans l'ombre. Quand on dit « les métiers pilotent l'IA », on suppose souvent que le travail consiste à identifier des cas d'usage et à les confier à l'IT pour implémentation. Or dans l'ère agentique, l'enjeu dépasse largement les cas d'usage : il s'étend à la conception de nouvelles modalités d'organisation du travail, où humains et agents collaborent selon des logiques que nos organigrammes n'ont pas encore intégrées. C'est une question que je développerai dans une prochaine série d'articles.
C'est d'ailleurs la condition pour que les rôles évoqués dans les deux articles précédents, le « process designer agentique » et le « référent sémantique métier », aient un mandat réel plutôt qu'un titre sans pouvoir.
Ce que ce mandat implique concrètement
Avant tout chantier IA, je pose systématiquement la même question : dans votre organisation, qui a aujourd'hui la légitimité de stopper un déploiement, non pour des raisons techniques ou budgétaires, mais parce que les conditions organisationnelles ne sont pas réunies ? Parce que les modalités de travail n'ont pas été repensées pour y intégrer des personas agentiques ? Si la réponse est personne, vous n'avez pas de gouvernance : vous avez un portefeuille de projets.
Cette question révèle ce que recouvre réellement l'ownership dans votre organisation. Quand les métiers se limitent à identifier des cas d'usage que l'IT implémente, il existe un point de transfert : le moment où le besoin passe d'un côté à l'autre. C'est ce point de transfert qui reproduit la dynamique client/fournisseur. Ce qui la rompt véritablement, c'est un ownership qui va jusqu'au comment : non pas « voici ce que je veux que l'IA fasse » mais « voici comment mon organisation va tirer le meilleur des agents ». La première posture peut se déléguer comme une spécification. La seconde ne peut pas : elle implique que les métiers restent dans la boucle de conception, non comme validateurs en bout de chaîne, mais comme co-auteurs des nouveaux modes de travail. C'est là que l'IT cesse d'être fournisseur.
L'IA ne crée pas le défaut de gouvernance entre métiers et IT : elle le rend incontournable.
Pour que cette boucle de conception existe réellement, et pas seulement dans les intentions, elle a besoin d'un sponsor. Dire go, débloquer le budget, afficher son engagement : c'est ce que font tous les sponsors. Ce qui est beaucoup plus rare, c'est la capacité de dire stop parce qu'un déploiement cherche à court-circuiter la phase où les modes de travail doivent être repensés. Sans ce pouvoir de blocage, la co-conception reste une intention : au premier arbitrage, les délais l'emportent sur le redesign.
Cette série de trois articles est tirée des enseignements du Revolution Summit Onepoint 2026. Les articles précédents :
Continuer votre exploration
Découvrez d'autres articles du cluster operating-models-excellence dans l'univers Organization