La plupart des discussions sur l’IA et le chiffrage au forfait — le modèle à prix fixe et forfaitaire qui domine encore la prestation IT en Europe — s’arrêtent au même slogan : l’IA rend les propositions moins chères. C’est vrai. Le slogan esquive juste les deux questions qui comptent vraiment : moins cher comment, et moins cher au détriment de quoi.
J’ai été des deux côtés de la table dans une négociation au forfait — comme prestataire défendant un chiffre, et plus tôt dans ma carrière, comme client en refusant un — à travers cinq organisations de delivery différentes. Ce qui suit est l’exemple le plus net que j’aie rencontré de l’écart entre décorer un ancien modèle de delivery avec de l’IA et le reconcevoir vraiment : une séquence de chiffrage réelle, menée avec AP Advisory, pour un groupe énergétique européen que j’appellerai EnergIQ. Même périmètre, trois devis, à quelques mois d’intervalle en 2026. Le client a refusé les deux premiers sur le prix. Le troisième est revenu avec un chiffre plus bas parce que le modèle de delivery qui le sous-tend avait été démonté et reconstruit. L’essentiel à retenir se trouve dans l’écart entre ces trois chiffres, pas dans l’un d’eux pris isolément.
Le brief
La plateforme d’EnergIQ — Atlas, en interne — traite des processus financiers et de conformité réglementés sur plusieurs entités juridiques du groupe. Elle fonctionne. Tout ce qui est en dessous approche de la fin de support : le système d’exploitation, le runtime Java, les serveurs web et applicatif, et un front-end construit sur ExtJS, un framework antérieur à Angular et React, dans lequel presque plus personne ne démarre de nouvelles interfaces aujourd’hui.
Une étude de faisabilité menée en 2025 avait déjà écarté l’option économique : corriger la pile existante aurait coûté à peu près le prix d’une refonte, sans en avoir les bénéfices. Atlas devait donc être reconstruite sur Java 21 / Spring Boot et Angular, migrée module par module face à un système qui ne pouvait jamais s’arrêter, tout en continuant à dialoguer avec une demi-douzaine de systèmes amont et aval.
Jusque-là, un brief de refonte applicative ordinaire — j’aurais pu écrire ce paragraphe à propos d’une demi-douzaine de clients que j’ai accompagnés depuis 2013. C’est la conversation sur le prix qui a cessé de l’être.
Partie I — Deux devis, deux refus
Premier devis : 2,4 M€ sur 24 mois
La première proposition était celle que la plupart des sociétés de delivery auraient reconnue — j’en ai moi-même signé plusieurs comme elle : un forfait Agile classique, refonte complète, équipe dédiée, phases jalonnées, gouvernance standard. Environ 2,4 M€ sur 24 mois — un chiffre défendable pour le modèle qu’il supposait.
EnergIQ a jugé cela trop cher. Point final, sans contre-offre. Dans ce modèle, il ne restait rien à activer, sinon une remise sur le même plan — ce qui n’est pas une réponse pour un client qui vous a déjà dit que le chiffre ne fonctionne pas.
Deuxième devis : 1,7 M€ sur 22 mois
La deuxième proposition a changé la forme de la delivery, pas seulement le prix. Au lieu d’une refonte complète : une migration incrémentale, Atlas et son remplaçant cohabitant derrière une couche de routage, la nouvelle plateforme reprenant la main module par module, sans interruption de service.
L’IA est apparue pour la première fois — un assistant de complétion de code dans l’IDE, posé sur un processus de delivery par ailleurs inchangé. Nous avons gardé des hypothèses de productivité modestes et vérifiables : environ 10 % de charge en moins, environ 15 % de durée en moins, à valider par un POC de démarrage avant l’engagement du reste du projet. Cela donnait environ 1,7 M€ sur 22 mois — un POC de deux mois plus vingt mois de delivery phasée.
EnergIQ a refusé celui-ci aussi, et la raison est la partie de cette histoire qui mérite d’être retenue. Le prix n’en était que la moitié. Le message reçu était de repenser la gouvernance, le processus et l’organisation des équipes autour de véritables nouvelles techniques IA — pas de conserver le modèle existant et d’y greffer l’IA pour un simple gain de productivité.
Un diagnostic juste, en fait, et pas confortable à entendre. Ajouter un outil de complétion de code à un modèle de delivery inchangé a fait bouger le prix de 10 à 15 %. C’est à peu près ce que vaut l’IA en accessoire. Nous n’avions rien reconçu ; nous avions décoré.
Partie II — Reconstruire le chiffrage
Le troisième tour est parti d’une question différente. Non pas de combien l’IA pouvait accélérer notre processus existant — mais à quoi ressemblerait ce modèle de delivery s’il avait été conçu autour de l’IA dès le premier jour.
Nous avons constitué une équipe dédiée de delivery IA, en interne l’AI Practice, et l’avons associée à l’équipe TMA qui exploitait déjà Atlas en production. Cette association a compté : l’équipe TMA portait la connaissance fonctionnelle des règles de conformité et des cas limites de la plateforme, et aucun outillage ne la remplace. Ensemble, elles ont rechiffré l’intégralité du périmètre à partir des spécifications fonctionnelles sous-jacentes, fonctionnalité par fonctionnalité, dans l’environnement technique propre d’EnergIQ : Google Cloud Platform, Vertex AI Model Garden avec Gemini Flash et les modèles Claude d’Anthropic, Google CLI, Cloud Build et Gemini Code Assist.
Travailler avec un outillage déjà validé par le client a permis d’écarter un cycle d’approbation sécurité du chemin critique — cela vaut plus sur un calendrier d’offre que ce que la plupart des gens budgètent.
Un modèle par tâche
La décision de conception la plus déterminante — celle que je conseillerais à n’importe quel DSI de reprendre telle quelle, quel que soit le prestataire — a été d’arrêter de traiter « l’IA » comme un outil unique. Les différentes étapes du pipeline n’attendent pas la même chose d’un modèle — profondeur de raisonnement, vitesse, coût par appel — nous avons donc affecté un modèle à chaque étape plutôt que de tout faire transiter par un assistant par défaut.
Du besoin métier au déploiement — un modèle ou un outil par étape, pas un assistant générique de bout en bout.
| Étape | Modèle / outil | Pourquoi celui-ci |
|---|---|---|
| Lecture des spécifications | Claude Opus | Les spécifications fonctionnelles dépassaient les cent mille mots, sur une vingtaine de documents. Extraire des exigences claires et croisées sans perdre un cas limite exige le modèle de raisonnement le plus profond disponible — utilisé avec parcimonie, car c’est aussi le plus coûteux. |
| User stories & backlog | Claude Sonnet | Une fois les exigences structurées, les transformer en user stories prêtes pour le sprint est un travail plus rapide et répétitif. L’équilibre vitesse/qualité de Sonnet convient, sans payer le prix d’Opus pour cela. |
| Génération de code | Sonnet + Gemini Code Assist | La complétion dans l’éditeur gère le flux de codage au quotidien. Sonnet prend en charge l’échafaudage plus large et la génération au niveau module, qui demande plus de contexte. |
| Revue de code | Claude Sonnet | Revoir une logique sensible à la conformité exige un modèle qui repère les erreurs subtiles, toujours associé à une validation humaine obligatoire avant que quoi que ce soit touchant un calcul réglementé ne parte en production. |
| Tests & CI/CD | Gemini Flash | Générer et exécuter de gros volumes de tests de non-régression est un travail mécanique et à haute fréquence — exactement là où un modèle rapide et peu coûteux se justifie. |
| Déploiement | Cloud Build + Gemini Flash | L’orchestration des builds, le tri des logs et la rédaction des notes de version sont des tâches fréquentes et peu exigeantes en jugement, intégrées au socle CI/CD déjà standard chez EnergIQ. |
Le principe derrière le tableau : les étapes qui exigent du jugement reçoivent les modèles les plus profonds et les plus coûteux, utilisés avec parcimonie. Les étapes à haut volume et mécaniques reçoivent les modèles rapides et bon marché. Faire correspondre l’outil à la tâche a fini par compter plus que la capacité brute d’un modèle pris isolément.
Ce qui a vraiment fait bouger le prix
Cinq choses l’ont fait bouger.
L’équipe, avant et après
Deux rôles qui étaient des lignes budgétaires séparées dans le modèle classique ne le sont plus. Les tests vivent désormais dans le pipeline — suites de non-régression générées et exécutées avec Gemini Flash, toujours vérifiées par un humain avant que quoi que ce soit de réglementaire ne parte en production. Le travail DevOps passe par Cloud Build, intégré au même flux de delivery. Les rôles qui protègent le jugement et la connaissance métier — l’expert fonctionnel, et à une allocation plus légère l’architecte et le chef de projet — sont restés.
| Rôle | Estimation initiale — modèle classique | Estimation finale — modèle nativement IA |
|---|---|---|
| Scrum Master / Chef de projet | 50 % (0,5 ETP) | 50 % (0,5 ETP) — inchangé |
| Architecte technique | 50 % (0,5 ETP) | 25 % (0,25 ETP) |
| Développeur(s) | 2 ETP (deux développeurs) | Développeur augmenté IA — 1 ETP |
| Testeur | 1 ETP | — intégré aux tests générés par IA et à la revue de code |
| Consultant fonctionnel finance | 1 ETP (100 %) | 1 ETP (100 %) — inchangé, protégé |
| Data specialist | 50 % (0,5 ETP) | 25 % (0,25 ETP) |
| DevOps | 50 % (0,5 ETP) | — intégré au pipeline Cloud Build + Gemini Flash |
Les heures libérées sur les rôles d’architecte et de data specialist n’ont pas disparu — elles se sont déplacées. Moins de temps à écrire et réécrire du code à la main ; ce qui reste va vers la revue de conception, la validation de non-régression et le séquencement de la bascule — le travail à forte valeur de jugement que l’IA ne fait pas.
Côté client, rien n’a bougé. Les deux scénarios ont besoin d’un représentant métier faisant office de Product Owner et d’un coordinateur de projet. L’IA change la façon dont l’équipe côté delivery est construite ; les rôles de gouvernance du client restent intacts.
Pourquoi nous nous sommes arrêtés à quinze mois
Un calendrier plus agressif était facile à mettre sur une slide. J’ai déjà vu ce genre de slide validé, et je l’ai regretté quelques mois plus tard — nous nous y sommes donc opposés cette fois, pour trois raisons.
Migrer module par module signifie que chaque module fait ses preuves face au système en production avant que le suivant ne démarre. Cet enchaînement a une durée calendaire minimale qu’aucune vitesse de codage ne comprime.
Chaque calcul qu’exécute Atlas est sensible à la conformité, donc les tests de non-régression face à la production — anciennes sorties contre nouvelles, sur des cas réels — sont obligatoires et validés par des humains. Une suite de tests générée par IA ne se valide pas elle-même.
Et la bascule finale doit se caler hors des périodes de pointe de déclaration et de reporting de la plateforme. Ces dates viennent du cycle métier d’EnergIQ, et aucune équipe de delivery ne les déplace.
L’IA comprime le temps d’ingénierie : écrire, refactorer et tester du code. Le temps de validation, le séquencement de bascule et le calendrier réglementaire du client restent hors de sa portée. Une proposition qui prétendrait discrètement le contraire emprunterait sur un risque que le client finirait par porter.
Partie III — Ce dont les 1,2 M€ sont faits
| Dimension | Deuxième devis — incrémental + code assist | Troisième devis — nativement IA, spec-driven |
|---|---|---|
| Usage de l’IA | Complétion de code dans l’IDE uniquement, greffée sur un processus inchangé | Un modèle affecté par étape du pipeline, de la lecture des spécifications au déploiement |
| Taille d’équipe au pic | ~9 personnes durant la phase la plus longue | ~7 personnes au pic, cœur d’équipe plus réduit hors phases de pointe |
| Charge totale | ~3 000 jours-personne | ~2 000 jours-personne |
| Durée | ~22 mois (POC de 2 mois + 20) | ~15 mois (POC de 6 semaines + delivery phasée) |
| Prix (arrondi, HT) | ~1,7 M€ | ~1,2 M€ |
Près d’un tiers de la charge et un tiers du calendrier ont disparu entre le deuxième et le troisième devis. L’IA n’est pas devenue 30 % meilleure en quelques semaines. Le deuxième devis utilisait l’IA comme accessoire d’un modèle inchangé ; le troisième s’en est servi pour reconcevoir le modèle.
La proposition finale conserve une provision de risques de 20 %. Le rechiffrage avait déjà trouvé des modules sous-estimés de 35 à 45 %, et nous avions encore peu de recul sur le pilotage de projets entièrement gérés par l’IA à cette échelle — nous avons donc intégré cette incertitude plutôt que d’espérer qu’elle disparaisse. C’est une marge interne intégrée au prix d’AP Advisory, pas une clause de partage de risque avec le client.
Les 20 %, c’est ce que me coûte un chiffre honnête — pour la moitié du périmètre que nous n’avions pas entièrement revérifié, et pour un modèle de delivery qui, à l’époque, n’avait pas encore de recul.
Environ 60 % du troisième devis reste porté par l’équipe technique cœur — architectes et développeurs augmentés par l’IA qui écrivent et revoient le code. La part de l’expert fonctionnel s’est maintenue en proportion du total, ce qui indique où ce modèle n’est pas allé chercher d’économies.
Ce qui ne change pas
La responsabilité sur ce que produit un calcul réglementé ne bouge pas. Un humain valide toujours la logique sensible à la conformité avant sa mise en production. Le même expert fonctionnel travaille sur la plateforme sous le nouveau modèle comme sous l’ancien. Les tests de non-régression face à la production restent le mécanisme qui rattrape ce qu’un relecteur IA pourrait manquer.
Sur les trois devis, le jugement humain est resté exactement aux mêmes endroits. Ce qui a bougé, c’est la quantité de travail mécanique entre une spécification et un module livrable et testé — et l’honnêteté avec laquelle l’estimation rend compte de ce que personne n’avait encore vérifié. J’enseigne une version de cet arbitrage à des étudiants d’Executive MBA presque chaque trimestre, et ça reste vrai à chaque fois : la technologie avance plus vite que le jugement qu’elle est censée servir.
Si vous rechiffrez une offre au forfait avec l’IA, voici l’essentiel : n’appliquez pas un multiplicateur de productivité à votre ancien modèle de delivery en pensant que le travail est fait. Reconcevez l’équipe, la gouvernance et la cadence autour des outils. Affectez les modèles par tâche plutôt que de tout faire transiter par un seul assistant. Gardez une provision de risques honnête sur ce que vous n’avez pas encore revérifié. C’est cette combinaison qui a fait passer cette offre d’un double refus à un chiffre qu’EnergIQ a pu négocier sur le fond.
Alin Popovici
Conseiller exécutif, dirigeant de transformation et de delivery — 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).