Cet article se passe avant l’histoire du chiffrage au forfait que j’ai racontée ailleurs sur ce site — c’est en réalité ce programme-ci qui a construit la confiance et l’outillage partagé entre AP Advisory et EnergIQ, avant qu’on ne s’en serve pour reconstruire une offre au forfait de zéro, quelques mois plus tard. La plupart des récits d’adoption de l’IA sont racontés du point de vue de l’éditeur : une plateforme, un déploiement, un tableau de bord d’usages. Celui-ci est raconté de l’intérieur d’un engagement IT à grande échelle, où AP Advisory a mené un programme conjoint d’industrialisation de l’IA générative avec EnergIQ, sur plusieurs équipes en tierce maintenance applicative — les mêmes équipes TMA qui, plus tard, porteraient la connaissance fonctionnelle de la plateforme Atlas. Le programme est passé d’une expérimentation encadrée à un mandat d’adoption à l’échelle de l’entreprise — et, chemin faisant, est devenu le terrain de preuve d’une « AI factory » interne.
Le programme a commencé comme une expérimentation de productivité. Il est devenu un modèle de gouvernance — et c’est ce modèle de gouvernance qui a rendu la productivité crédible.
1. Un programme conjoint, pas un déploiement d’outil
L’initiative a été cadrée dès le départ comme un programme co-piloté par EnergIQ et AP Advisory, et non comme un simple déploiement de licences. Une feuille de route en quatre phases a rythmé le programme : une initialisation de quatre semaines pour aligner parties prenantes, sponsors et cadre technologique ; une phase de planification de deux semaines pour identifier les équipes pilotes et mettre en place la gouvernance ; deux à trois mois d’exécution de preuves de concept sur des chantiers réels ; puis une phase de passage à l’échelle de quatre mois couvrant licences, infrastructures et accompagnement du changement. La plateforme IA générative d’EnergIQ a été retenue comme plateforme unique du programme, avec des outils d’assistance au code et de LLM — dont Gemini Code Assist et, sur certains chantiers, Claude — venant compléter des cas d’usage spécifiques.
Quatre chantiers ont porté le pilote, chacun doté d’un nom propre pour ancrer le langage interne du programme : AI4DOC (documentation), AI4CODE (développement augmenté), AI4OPERATIONS (opérations et support), et AI4TEST (testing).
2. Un modèle de maturité à quatre niveaux, pour séquencer — pas pour vendre
Plutôt que de présenter l’adoption de l’IA de façon binaire, le programme a utilisé un modèle à quatre niveaux pour situer chaque équipe et fixer des attentes réalistes : la génération conversationnelle et les requêtes ponctuelles ; le « vibe coding », où le prompting fonctionnel accélère le prototypage mais reste risqué sur du code pérenne ; l’IA agentique, où des chaînes d’agents travaillent à partir de documents de référence partagés ; et la « team AI », où l’IA se connecte entre les métiers et alimente les chaînes CI/CD. Au moment du bilan pilote, la plupart des équipes se situaient entre les deux premiers niveaux — une lecture volontairement modeste et factuelle, plutôt qu’un effet d’annonce. J’insiste sur ce point à chaque comité de pilotage où je le présente : un modèle de maturité honnête protège plus la crédibilité d’un programme qu’un chiffre de productivité optimiste.
3. Ce que les pilotes ont réellement montré
Sur quatre équipes en tierce maintenance applicative, les gains estimés allaient de 10 % à 30 % selon le type d’activité, avec une moyenne pondérée d’environ 20 %. Cet écart comptait davantage que la moyenne : la documentation et la rétrodocumentation ont montré les gains les plus nets, le développement augmenté a montré des gains réels mais inégaux selon les langages et frameworks, et certains contextes techniques legacy ou très spécifiques ont résisté à l’assistance des outils actuels. Cette granularité — cas par cas, et non équipe par équipe — est devenue la base de toutes les décisions ultérieures de passage à l’échelle.
4. Le pivot : quand la productivité est devenue un sujet commercial
Les résultats d’un pilote ne restent pas longtemps internes. Dès qu’EnergIQ a eu de la visibilité sur les gains de productivité produits par la phase d’expérimentation, le client a traduit cette attente directement en termes commerciaux : une baisse de 10 % sur les prestations facturées en run, à partir d’une date convenue, en misant sur le fait que la productivité apportée par l’IA en absorberait l’écart. C’est une suite naturelle — et de plus en plus fréquente, je le constate sur presque tous mes comptes désormais — de tout parcours d’adoption de l’IA, dès lors que les pilotes passent du stade « intéressant » au stade « crédible » : les clients demandent que la valeur leur revienne.
AP Advisory a répondu en transformant ce qui n’était qu’un ensemble de chantiers pilotes en un programme d’adoption à l’échelle de l’entreprise, en étendant les mêmes outils, la même formation et le même modèle de gouvernance à toutes les équipes du compte, et non plus seulement à celles qui avaient participé aux pilotes initiaux — avec pour objectif explicite d’atteindre, voire de dépasser, la demande de productivité par une adoption plus large et mesurée, plutôt que par la seule réduction d’effectifs.
5. Discipline de gouvernance : séparer « adoption déclarée » et « valeur mesurée »
Le choix de conception le plus déterminant du programme n’était pas technique, mais procédural : l’adoption et la valeur étaient suivies comme deux indicateurs distincts. L’adoption était un chiffre mensuel, déclaratif, par type d’activité et par responsable — un indicateur avancé de changement de comportement. La valeur était une comparaison factuelle et rétrospective du réalisé par rapport à une référence économique figée : chiffre d’affaires, coûts, marge et effectifs, suivis par équipe, les gains de productivité n’étant reconnus qu’une fois des chiffres réalisés — et non prévisionnels — renseignés en regard de cette référence. Sur les équipes suivant ce rythme, l’adoption déclarée atteignait environ la moitié des effectifs suivis, sur une base de plus d’une centaine de collaborateurs et près d’un million d’euros de chiffre d’affaires mensuel de référence — mais le reporting du programme précisait explicitement qu’aucun gain de productivité ne pouvait encore être considéré comme acquis tant que les données réalisées n’avaient pas rattrapé le prévisionnel.
Cette discipline était portée par une gouvernance formelle à trois niveaux — ce que les documents de pilotage du programme appelaient sa comitologie : un comité de pilotage mensuel réunissant sponsors et direction delivery, un comité opérationnel hebdomadaire pour la coordination et les décisions de portefeuille, et un hub d’exécution animant les chantiers au quotidien. Une Design Authority se positionnait au-dessus des pilotes individuels puis, par la suite, au-dessus de l’initiative d’IA agentique décrite ci-dessous, en examinant périmètre, architecture et décisions de type Go/No-Go selon une cadence fixe plutôt que de les laisser à l’appréciation de chaque équipe.
6. Construire la conviction d’une AI factory interne : un pilote agentique
En parallèle du programme d’industrialisation principal, AP Advisory a mené une expérimentation d’IA agentique sur la modernisation d’une application legacy — un système reposant sur un socle technique en fin de vie, qui ne pouvait plus être maintenu de façon sûre. Plutôt qu’une réécriture classique, l’équipe a structuré le travail autour d’un pipeline d’agents spécialisés — agents de discovery, d’architecture, d’analyse, de développement, de qualité, de documentation, de performance et de conduite du changement — chacun responsable d’une étape d’un enchaînement analyse–conception–construction–validation–déploiement, avec une relecture humaine et une validation de la Design Authority intégrées à chaque étape plutôt que reléguées à une recette finale.
Résultat : une équipe minimaliste a livré 86 fonctionnalités priorisées sur quatre sprints de trois semaines — environ douze semaines entre le lancement et un périmètre prêt pour la mise en production — avec des démonstrations hebdomadaires et une revue formelle de type Go/No-Go clôturant chaque sprint. L’objectif du pilote n’était pas seulement de livrer l’application plus vite ; il s’agissait de produire un premier point de preuve défendable sur la faisabilité, à l’échelle, d’une « AI factory » interne — une capacité de delivery pérenne assistée par des agents — plutôt qu’une ambition de présentation.
L’approche de développement agentique piloté par les spécifications (« spec-driven development ») utilisée sur cette modernisation fait l’objet d’une estimation de productivité propre, suivie séparément du programme d’industrialisation principal : un gain attendu de l’ordre de 40 % (estimé, en attente d’achèvement) sur l’effort de développement lui-même — nettement supérieur à la fourchette de 10 à 30 % observée sur les chantiers documentation, assistance au code et testing, et un signal fort sur le potentiel du delivery agentique dès lors que spécifications, architecture et jalons de validation humaine sont conçus dès le départ. C’est ce même pipeline d’agents, affiné sur ce pilote, que nous avons ensuite réutilisé pour rechiffrer la migration d’Atlas.
Ce qu’un dirigeant peut en retenir
Trois enseignements dépassent largement ce seul programme. D’abord, séquencer l’adoption avec un modèle de maturité avant de promettre des gains — cela protège la crédibilité, à la fois vis-à-vis du client et des équipes de delivery. Ensuite, séparer dès le premier jour l’adoption déclarée de la valeur mesurée, et gouverner formellement cette séparation ; c’est ce qui transforme un programme IA d’un exercice de communication en une décision opérationnelle défendable. Enfin, traiter les pilotes d’IA agentique comme des exercices de construction de conviction, dotés de leur propre gouvernance, plutôt que comme un raccourci vers une décision de passage à l’échelle tranchée — le schéma de modernisation décrit ci-dessus constitue un gabarit pour construire cette preuve de façon responsable, sprint après sprint, avec une validation humaine à chaque jalon. J’enseigne une version simplifiée de cette comitologie à mes étudiants d’Executive MBA, et c’est systématiquement le point qui les surprend le plus : la partie difficile de l’adoption de l’IA n’est presque jamais la technologie.
Alin Popovici
Conseiller exécutif, dirigeant de transformation et de delivery, pilotant actuellement des initiatives d’adoption IA et de rightshoring sur un portefeuille delivery de plus de 60 M€ — et enseignant invité sur le pilotage de programmes complexes à l’Executive MBA de la Bucharest Business School (ASE Bucarest en partenariat avec le CNAM Paris).