Le rôle méconnu des goulots d'étranglement dans les déploiements d'IA

22.05.2026

10 min de lecture

La Deloitte Tech Leadership Study répertorie 71 % des entreprises disposant de cinq ou plus dirigeants techniques au niveau C. Le responsable devient l’orchestrateur, indique la diapositive. Ceux qui assument effectivement le rôle d’orchestration dans les grands groupes sont généralement pas des cadres C-Level, mais plutôt un PMO. Et précisément cette nomination déterminera si les déploiements d’IA en 2026 réussissent.

Les points clés en bref

Les PMO sont le rôle silencieux limitant dans les déploiements d’IA. Alors que la direction technique au niveau C apparaît sur les présentations du conseil d’administration, les déploiements échouent souvent à l’étape où périmètre, fournisseurs et parties prenantes internes se croisent. Ce n’est pas l’agenda du CIO, c’est la réalité du PMO.
Trois configurations bloquent fatalement le déploiement. Un PMO centré sur la conformité, un PMO prolongement du CIO sans mandat propre, un PMO privé de pouvoir pour fixer les méthodes. Quiconque possède une de ces trois configurations ne construira pas un déploiement d’IA fonctionnel.
La méthode n’est pas le principal problème, c’est le mandat. Un PMO sans mandat clair pour définir le périmètre court après chaque partie prenante. Les cadres et outils sont ici juste des calmants, ils ne remplacent pas la décision fondamentale : savoir qui a le droit de dire non dans le programme.

ReliéLe talent tech senior devient rare/Mandats tech au conseil de surveillance

Pourquoi les modèles d’orchestrateur s’établissent dans le PMO

L’étude Deloitte 2026 touche juste. La direction technique au niveau C est plus fragmentée qu’il y a cinq ans. Aujourd’hui, le CIO, le CDO, le CISO, le CAIO, le Chief Digital Officer et le Head of Data siègent parfois en parallèle au comité exécutif ou au directoire. Ce que l’étude ne précise pas : ces cinq fonctions ne se rencontrent pas opérationnellement au niveau C. Elles interagissent dans les grands programmes, et là, le PMO est l’endroit où la coordination entre elles réussit ou échoue.

J’ai accompagné, au cours des 18 derniers mois, trois déploiements d’IA dans des grands groupes allemands ayant démarré comme sujet du comité exécutif. Tous trois avaient une structure de parrainage au niveau C qui semblait solide dans les présentations aux dirigeants. Deux d’entre eux ont stagné lors des neuf derniers mois dans la phase de programme. Le point de blocage était à chaque fois le PMO. Pas parce que les personnes en poste étaient mauvaises. Mais parce que le mandat manquait.

Un Daily Standup dure dans la plupart des équipes trois minutes de trop. Pas seize de trop, trois. C’est exactement cette marge qui détermine la maturité du PMO. Trois minutes font la différence entre une réunion qui produit des décisions et une autre qui n’échange que des rapports d’avancement. Dans un déploiement d’IA, cela peut rapidement s’accumuler en semaines.

Configuration 1 : PMO en tant que service de conformité

Cette configuration est la plus fréquente. Le PMO est positionné au sein de l’organisation comme un bras allongé des fonctions de conformité et de gestion des risques. Son mandat se limite à la production de rapports, pas à la prise de décisions. Les registres de risques sont entretenus, les logs RAID mis à jour, les réunions Stage-Gate préparées. Si un stakeholder formule une nouvelle demande, elle est ajoutée au backlog. Si un fournisseur décale un délai de livraison, l’entrée de risque est mise à jour.

Les registres de risques sont inutiles lorsqu’ils sont gérés uniquement pour des raisons de conformité. Ils deviennent alors des dossiers classés sans qu’aucune décision ne soit prise. Dans une transformation classique, une telle configuration peut encore fonctionner pendant plus de deux ans. Pas dans le déploiement KI de 2026. La vitesse d’itération est si élevée qu’un PMO qui ne fait que classer reste en retard sur chaque sprint.

Exemple concret tiré d’un groupe industriel moyen, anonymisé : Le PMO d’un fournisseur d’énergie a enregistré 47 entrées de risques au cours des premiers neuf mois d’un déploiement KI et clos quatre d’entre elles avec une escalade vers la direction du programme. Les autres 43 ont été réévaluées trimestriellement. Au neuvième mois, un auditeur financier a visité le programme et s’est demandé qui prenait finalement les décisions concernant ces 43 entrées. Personne n’a su répondre. La direction du programme a quitté l’entreprise deux mois plus tard.

Un poste de travail typique au sein d’un PMO, avec un registre de risques ouvert et des dossiers de projets affichés sur deux écrans. — Un PMO en tant que service de conformité surveille les risques et documente les processus via des outils standardisés.

Configuration 2 : PMO sans mandat propre

Le PMO est placé directement sous le CIO ou le CAIO et exécute ce que ces fonctions lui indiquent. D’un point de vue méthodologique, cela semble raisonnable : chemins courts, reporting clair, un sponsor. En pratique, il manque toutefois un levier lorsque le déploiement dépasse les limites de l’organisation du CIO. Et c’est toujours le cas lors des déploiements KI. Les données proviennent des départements métier, la conformité de la direction juridique, le management du changement du service RH, le budget de la finance.

Dans cette configuration, si le PMO demande à un responsable métier des données, ce dernier interroge d’abord son propre supérieur hiérarchique. Ce supérieur a rarement envie de multiplier les efforts, et le PMO ne dispose d’aucun chemin d’escalade direct. La demande tombe dans l’oubli. Le PMO alerte le CIO. Le CIO contacte le conseil d’administration. Le conseil d’administration renvoie à la structure d’encadrement du programme. Trois semaines perdues, une demande restée sans réponse.

Si personne ne peut dire non à un périmètre donné, tu n’as pas besoin d’un outil de gestion de projet. Tu as besoin d’une discussion. Or, cette discussion ne se produit pas dans un PMO sans mandat, car le PMO n’est pas le lieu où la question est tranchée.

Configuration 3 : PMO sans pouvoir de fixation des méthodes

Cette configuration est la plus insidieuse, car elle semble saine au premier abord. Le PMO dispose d’un mandat, d’un budget, d’un accès direct au CFO ou au COO. Ce qu’il lui manque, c’est la capacité à imposer des méthodes dans l’organisation. Chaque sous-projet choisit sa propre approche. L’un suit SAFe, un autre Disciplined Agile, un troisième utilise la méthode classique en cascade, un quatrième applique un modèle hybride défini internement.

Méthodologiquement, cela n’est pas faux, au contraire, c’est même moderne selon les manuels. En pratique, cela empêche toute coordination transversale entre les flux de travail. Un déploiement KI nécessitant simultanément des pipelines de données provenant de trois départements métier, une plateforme MLOps, une couche de gouvernance et une gestion des risques liés aux modèles ne peut être orchestré efficacement avec quatre méthodologies différentes. Pas parce que les méthodes seraient erronées, mais parce que les interfaces entre elles deviennent trop coûteuses.

La transformation la plus courante que j’ai observée est celle qui, après deux ans, ressemble à l’ancienne organisation, mais avec de nouveaux titres de rôles. C’est exactement ce que produit fiablement la configuration 3 : une grande diversité de méthodes, peu de coordination, et à la fin, un déploiement qui existe sur le papier, mais qui est porté concrètement par des flux de travail individuels.

Ce que les dirigeants doivent clarifier avant le lancement du prochain programme d’IA

Qui dans le PMO a le droit de dire non. Si cette question ne peut pas être clairement répondue avant le début du premier sprint, le PMO devient un organe d’escalade. Les organes d’escalade ne décident pas, ils transmettent. Définissez avant le démarrage quelles décisions relatives à la portée et au budget peuvent être prises dans le PMO et lesquelles doivent être soumises au comité exécutif.
Qui impose définitivement la méthode pour le programme. Pas chaque sous-projet n’a le choix. Une approche claire avec des marges d’adaptation précises pour les sous-flux de travail. Sans pouvoir d’imposer une méthode dans le PMO, vous ne coordonnez pas, vous faites des demandes.
Comment sera composé le PMO : opérationnels expérimentés ou passionnés de méthodes. Un PMO composé de trois formateurs SAFe certifiés mais sans personne ayant déjà sauvé un programme échoué constitue un risque. La profondeur d’expérience prime sur la largeur des certifications.

Foire aux questions

Le PMO dans le déploiement de l’IA devrait-il rendre compte directement au comité exécutif ou au CIO ?

Dans les déploiements d’IA à portée transversale, il devrait rendre compte à un sponsor de programme qui agit en parallèle du CIO. Le CFO ou le COO sont souvent les postes suffisamment puissants pour cela. Les voies de reporting directes vers le CIO ne fonctionnent que si ce dernier a lui-même un levier transversal au sein du comité exécutif. Ce n’est plus la norme en 2026 dans de nombreux grands groupes.

Quelle méthode soutient le mieux un déploiement d’IA : SAFe, Disciplined Agile ou Stage-Gate classique ?

Aucune des trois pleinement. Des déploiements d’IA efficaces combinent généralement un cadre stable Stage-Gate pour gérer les passages réglementaires sensibles avec des cycles itératifs agiles dans les flux de travail liés aux modèles et aux données. Celui qui applique une méthode pure paiera tôt ou tard, notamment lors de la gestion des risques liés aux modèles ou lors d’un audit de conformité.

Quand est-il temps de remplacer le PMO au cours d’un programme en cours ?

Lorsque le taux des décisions prises au niveau du PMO tombe en dessous de 30 % et reste stable sur plusieurs sprints. Ce n’est pas normal en phase de maturité, mais plutôt un indicateur que le PMO a perdu son rôle de pilotage. À ce stade, il faut se demander si c’est le PMO ou le mandat qui pose problème. Remplacer les deux ensemble est souvent moins coûteux que de laisser les deux souffrir.

Quelle taille doit avoir un PMO pour un déploiement d’IA au sein d’un grand groupe ?

Plus petite que prévu dans la plupart des programmes. Dans les trois déploiements que j’ai observés, la taille minimale fonctionnelle était de cinq équivalents-temps plein : un manager de programme, un responsable méthodologique, un coordinateur des parties prenantes, un responsable reporting et un responsable qualité. Un PMO ne devient pertinent qu’à partir du moment où chaque flux de travail dispose de ses propres sous-PMO et que l’instance centrale ne fait que coordonner.

Quel rôle joue le CAIO en parallèle du PMO ?

Le CAIO définit la stratégie IA et prend les décisions concernant le portefeuille de modèles, la politique de données et la priorisation des cas d’utilisation. Le PMO pilote la mise en œuvre du programme. Si ces deux fonctions se mélangent, l’une d’elles finit par s’effondrer. Quand cela fonctionne, le CAIO dispose dans le PMO d’un corridor clairement défini pour les escalades et les décisions, sans jouer un rôle opérationnel quotidien.

Plus du réseau MBF Media