Du cimetière des POC à la production : comment le CFO reprend la main sur les coûts IA
Plus de la moitié des projets d'IA générative sont abandonnés après le proof of concept. Derrière ce chiffre de Gartner se cachent des millions d'euros investis dans des démonstrations qui ne verront jamais la production, et des factures cloud qui continuent de courir pour des pilotes « temporaires » devenus permanents.
Pendant ce temps, les CFO reçoivent des rapports montrant que 79 % des entreprises ont connu des dépassements de coûts IA et que seulement 26 % disposent d'une visibilité en temps réel sur ce que coûte réellement l'exploitation de leurs modèles.
Cet article propose une feuille de route concrète pour sortir de cette dynamique : identifier les interlocuteurs clés, et mettre en place un cadre de décision pour tailler les POC avant qu'ils ne deviennent ingérables.
Pourquoi les POC IA deviennent si vite coûteux
Les quatre facteurs d'abandon identifiés par Gartner
Gartner a identifié quatre facteurs principaux qui poussent plus de la moitié des projets GenAI à l'abandon après le POC :
- Mauvaise qualité des données : les projets découvrent trop tard que les données ne sont pas « AI-ready » : incomplètes, non structurées, non gouvernées.
- Contrôles de risque insuffisants : absence de garde-fous sur la sécurité, la conformité et la traçabilité des décisions.
- Coûts qui s'emballent : tokens, infrastructure et intégrations dépassent largement les hypothèses initiales.
- Valeur business floue : impossible de démontrer un ROI clair ou un impact mesurable sur un indicateur métier.
Un cinquième facteur a émergé en 2026 : le déficit de conduite du changement, c'est-à-dire l'incapacité à faire adopter la solution par les équipes opérationnelles.
Le piège du POC permanent
Le schéma est récurrent. Un POC est lancé avec un budget limité, disons 10 000 à 50 000 €, sur un périmètre restreint, sans intégration profonde aux systèmes existants. La démonstration fonctionne. Mais pour passer en production, il faut industrialiser les pipelines de données, sécuriser les accès et les flux, intégrer aux ERP et CRM, mettre en place monitoring et gouvernance, et former les utilisateurs.
Le coût de production est typiquement 5 à 15 fois supérieur au coût du POC lorsque l'infrastructure MLOps, la sécurité et le monitoring sont correctement dimensionnés. Les organisations qui ne budgétisent que 2 à 3 fois le coût du POC sous-investissent systématiquement.
Résultat : le POC reste en mode pilote indéfiniment, avec une facture cloud qui tourne en continu, sans jamais atteindre la production ni générer de retour mesurable.
Les six interlocuteurs clés pour reprendre le contrôle
Le CFO ne peut pas piloter seul la maîtrise des coûts IA. Voici les rôles à impliquer, avec leurs contributions spécifiques et les questions que le CFO peut leur poser directement.
Architecte IA / Architecte Cloud
Concevoir une architecture qui aligne coûts, performance et gouvernance dès la conception.
- Routage intelligent vers les modèles les moins chers capables de faire le travail
- Caching sémantique, consolidation d'appels, limites de tokens par requête
- Choix cloud public / privé / hybride selon les workloads, mise en place du FinOps
« Quel est le coût unitaire par tâche pour chaque modèle ? A-t-on un mécanisme de routage automatique vers le modèle le moins cher qui peut faire le job ? »
Responsable Data / CDO
S'assurer que les données sont AI-ready et gouvernées avant le lancement des POC.
- Qualité et disponibilité des données : éviter les POC qui découvrent trop tard que les données sont inexploitables
- Plateforme de données mutualisée : éviter que chaque POC reconstruise ses propres pipelines
- Traçabilité et lineage pour l'audit et la conformité
« Ce POC utilise-t-il des données déjà industrialisées ou va-t-il nécessiter un chantier data spécifique ? Quel est le coût de ce chantier ? »
Responsable Sécurité / CISO
Intégrer sécurité et conformité dès la conception des projets IA.
- Authentification, gestion des secrets, protection contre les attaques de type « denial-of-wallet »
- Conformité AI Act, RGPD et politiques internes
- Monitoring des incidents pour anticiper les dérives de coûts liées à des anomalies d'usage
« Quels sont les garde-fous pour éviter qu'un agent consomme des tokens de manière incontrôlée ? A-t-on des plafonds et des alertes ? »
PMO IA / Responsable de Programme
Piloter le portefeuille de projets IA avec une vision consolidée des coûts, délais et risques.
- Vision portefeuille : consolider tous les POC pour identifier doublons et initiatives redondantes
- Suivi des dépendances transverses pour éviter les effets de bord coûteux
- Tableaux de bord coûts / valeur par projet, équipe et cas d'usage
« Combien de POC sont en cours ? Lesquels ont dépassé leur budget initial ? Lesquels ont une date de décision go / no-go claire ? »
Responsable FinOps IA
Appliquer les principes du FinOps spécifiquement aux workloads IA.
- Dashboards de consommation de tokens, par modèle, équipe et application, en temps réel
- Budgets par équipe / projet avec alertes automatiques en cas de dépassement
- Tag de chaque requête pour permettre la facturation interne et responsabiliser les équipes
« Peux-tu me montrer la consommation de tokens par équipe ce mois-ci ? Quels sont les projets qui ont dépassé leur budget ? »
Responsable Risk & Compliance IA
Évaluer et monitorer les risques réglementaires, réputationnels et opérationnels liés aux projets IA.
- Revue de risque systématique avant lancement (AI Act, usage des données, impact sur les décisions)
- Suivi des incidents : erreurs, biais, décisions contestables
- Registre des modèles, usages et décisions pour répondre aux auditeurs et régulateurs
« Quels sont les projets IA à risque réglementaire élevé ? Avons-nous documenté les décisions prises par l'IA pour pouvoir les auditer ? »
Comment tailler les POC : un cadre en 4 portes
La clé pour éviter que les POC ne deviennent des gouffres financiers est de les encadrer avec des portes de décision explicites (stage-gates) et des critères d'échec définis avant le lancement.
Faisabilité technique
Sur un échantillon représentatif de données réelles, le système atteint-il un niveau de performance prédéfini ?
90 % de tâches complétées correctement sur jeu de test held-out
Moins de 80 % après 4 à 8 semaines
Valeur business
Cette performance produit-elle un mouvement mesurable sur un indicateur métier nommé ?
L'indicateur cible s'améliore d'un seuil défini vs baseline sur une période de test
Aucun mouvement mesurable sur l'indicateur nommé
Justification économique
La valeur créée dépasse-t-elle le coût total de fonctionnement (tokens, infrastructure, maintenance, gouvernance) ?
Coût par résultat inférieur au coût de la méthode actuelle
Coût complet par outcome supérieur ou égal à la baseline manuelle
Prêt pour la production
Le système tient-il la charge, la latence, la fiabilité et les exigences de gouvernance à l'échelle de production ?
Latence, disponibilité, audit et conformité validés à pleine charge avec rollback testé
Écart de fiabilité ou conformité sans correctif, ou coût d'industrialisation disproportionné
Les règles d'or pour encadrer les POC
- 01Définir le kill threshold avant de commencer. Un seuil d'abandon est un chiffre et une date, actés par écrit avant le lancement. Exemple : « Si le taux de complétion est inférieur à 80 % après 6 semaines, le projet est arrêté. »
- 02Limiter le périmètre du POC. Un seul cas d'usage prioritaire. Un jeu de données réduit mais représentatif. Pas de développement frontend complet ni d'intégrations lourdes tant que la valeur n'est pas prouvée.
- 03Séparer validation et production. Le POC ne doit pas être construit comme une version light de la production, mais comme une expérience contrôlée pour valider des hypothèses.
- 04Imposer une date de décision go / no-go. Chaque POC doit avoir une date claire où l'on décide : soit on passe à l'étape suivante avec budget dédié, soit on arrête et on documente les apprentissages.
- 05Budgétiser la production séparément. Le budget de production, 5 à 15 fois le POC, doit être validé à la Porte 3, avec une vision claire du TCO sur 12 mois.
Tableau de bord CFO : ce qu'il faut suivre mensuellement
- Dépenses IA totales (tokens, cloud, licences, prestataires)
- Répartition par projet, équipe et cas d'usage
- Écart budget vs réel par projet et global
- Coût par outcome (par ticket résolu, par dossier traité, par lead qualifié)
- Nombre de projets en production vs nombre de POC lancés
- ROI ou gain métier mesuré par projet en production
- Taux d'adoption : utilisateurs actifs, volume de transactions IA
- Nombre d'incidents IA (erreurs, biais, décisions contestées)
- Projets sans revue de risque validée
- Projets sans kill threshold défini
Comment un CFO intervient sur un POC en dérive
Situation : un POC « assistant commercial » lancé il y a 6 mois avec un budget initial de 30 000 €. La facture cloud mensuelle est passée de 2 000 € à 12 000 €, sans passage en production ni ROI mesuré.
Actions du CFO- 01Convoquer une revue de portefeuille avec le PMO IA, l'Architecte, le Data Lead et le FinOps.
- 02Demander les chiffres clés : coût total engagé à ce jour, coût par interaction ou par lead traité, indicateur métier qui a bougé.
- 03Appliquer le cadre des 4 portes : le POC a-t-il un kill threshold défini ? La faisabilité technique est-elle validée sur des données réelles ? La valeur business est-elle démontrée sur un indicateur nommé ? Le coût par outcome est-il inférieur à la méthode actuelle ?
- 04Prendre une décision : si les portes 2 et 3 ne sont pas passées, arrêter le POC, documenter les apprentissages, réallouer le budget. Si les portes sont passées mais l'industrialisation est sous-dimensionnée, valider un budget de production réaliste, 5 à 15 fois le POC, avec un plan de montée en charge.
Transformer le CFO en pilote de la valeur IA
Les chiffres sont clairs : plus de la moitié des projets IA sont abandonnés après le POC, et la majorité des entreprises ne maîtrisent pas leurs coûts réels. Cette situation n'est pas une fatalité.
En s'appuyant sur les bons interlocuteurs (architecte, data, sécurité, PMO, FinOps, risk) et en imposant un cadre de décision rigoureux avec des portes explicites, des kill thresholds définis et des budgets séparés pour le POC et la production, le CFO peut réduire le nombre de POC zombies qui consomment du budget sans jamais produire de valeur. Il peut réallouer les économies vers les projets qui ont démontré leur faisabilité, leur valeur et leur viabilité économique. Il peut faire de l'IA un levier de performance mesurable et non un poste de dépense opaque.
« L'objectif n'est pas de freiner l'innovation. C'est de s'assurer que chaque euro investi en IA contribue à un résultat business tangible. C'est précisément le rôle du CFO. »
- Gartner, « By the end of last year, over 50 % of GenAI projects were abandoned after the proof-of-concept stage », 2026.
- Deloitte, « AI tokens : How to navigate AI's new spend dynamics », 2026.
- PwC, « Spending too much on AI ? How CIOs and CFOs can scale AI with cost discipline », 2026.
- Beri.net, « 50 % of AI Pilots Die : How to Survive the CFO Audit », 2026.
- Particula, « Killing the Pilot : An ROI Gate Framework for AI POCs », 2026.
- Reply, « From POC Graveyard to Production : What Actually Changes », 2026.
- IDC / DataRobot, « The Hidden AI Tax », 2025–2026.
- KPMG, « AI Quarterly Pulse Survey », 2025–2026.
- DoiT / Sapio Research, « AI Spending Survey », 2026.
- IBM Institute for Business Value, « AI and value creation : infrastructure, cloud and data cost benchmarks », 2024–2025.
Gaskam Consulting accompagne les directions générales et financières sur la transformation, la gouvernance et la maîtrise des coûts IA. Profil LinkedIn →