L'agentic coding ne coûte pas cher — jusqu'au jour où la facture atterrit sur le bureau du CFO

Un ingénieur senior d'une scale-up française partage son expérience début 2026 : son équipe de huit développeurs a adopté Cursor en septembre, les sprints sont 40 % plus courts, les démos impressionnent le board. Puis arrive la facture de Q1 : 180 000 euros d'inférence, contre un budget prévisionnel de 40 000. Rien n'est cassé. Les agents tournent. Le compteur, lui, n'a jamais arrêté de tourner. C'est exactement ce que Jaya Gupta, investisseuse (probablement Foundation Capital), formule dans son essai viral du 28 mai 2026 — 230 500 vues en quelques heures : « SaaS usage told you the software had been adopted. AI usage tells you the meter is running. It doesn't tell you whether your company is cooking. »¹

La question n'est plus de savoir si l'agentic coding produit de la valeur. Elle est de savoir combien cette valeur coûte — et si quelqu'un dans votre organisation est en mesure de calculer le rapport. Cet article prolonge notre pilier sur l'agentic coding en entreprise sous l'angle du coût.

La fin des assistants bon marché : un changement structurel, pas conjoncturel

Pendant deux ans, les équipes de développement ont vécu dans une économie de l'abondance artificielle. Les assistants de codage IA étaient subventionnés, les plans d'entrée bradés pour accélérer l'adoption, et les budgets de quelques milliers d'euros par développeur semblaient dérisoires face aux gains de productivité annoncés.

Ce temps est révolu. Cursor, Claude Code et Kiro ont harmonisé leurs tarifs à la hausse au cours de l'automne 2025². Dion Hinchcliffe, du cabinet The Futurum Group, explique que cette normalisation tarifaire reflète des contraintes réelles et durables : la tension sur l'approvisionnement en GPU, les coûts de licence des modèles de fondation, et les frais d'infrastructure d'inférence. Wei Zhou, de SemiAnalysis, est encore plus direct : il ne voit pas de mécanisme susceptible d'inverser cette tendance sans innovation majeure sur les modèles ou l'efficacité du KVCache².

Simultanément, la pression sur les budgets IT globaux s'est accentuée indépendamment de l'IA. Guillaume Geudin, directeur de la performance achats chez Elee, chiffre la hausse annuelle des factures DSI à 12-14 %, bien au-dessus de l'inflation, avec des pointes spectaculaires : Microsoft Copilot AI a augmenté de 85 % entre 2020 et 2024, Google Gemini de 20 à 45 %³. La stratégie désormais systématique consiste à embarquer des fonctionnalités IA par défaut dans les suites existantes, sans option de refus, gonflant le revenu moyen par utilisateur de 30 à 80 %. Sans correction de trajectoire, Geudin projette une augmentation des dépenses IT de 50 à 60 % d'ici 2028³.

L'agentic coding ne crée pas ce problème de toutes pièces — il l'amplifie de manière non linéaire.

De l'adoption à l'allocation : le vrai changement de phase

Il y a une formule qui circule dans les salles de conseil depuis le printemps 2026 et qui résume ce basculement mieux que n'importe quel tableau Excel : « Enterprise AI has moved from adoption to allocation. » (Jaya Gupta)¹.

La phase 1 était simple : prouver que les agents savent coder, reviewer, tester. Cette preuve est faite. Stack Overflow mesure 84 % d'adoption ou de planification des outils IA chez les développeurs en 2025, GitHub dépasse 97 % d'utilisation sur ses propres plateformes². La phase 2 est différente : elle exige de décider combien de ce travail vaut la peine, à quel coût, pour quels workflows.

La chronologie de la bascule est précise. Les modèles les plus capables ont été déployés en production en novembre 2025, après le lock des budgets annuels 2026. Dès le premier trimestre, de nombreuses organisations se sont retrouvées « running multiples ahead of plan » sur leur consommation d'inférence¹. En dessous d'une centaine de milliers d'euros annuels, l'inférence reste de l'expérimentation — une ligne de R&D que l'on accepte sans trop questionner. Au-delà du million d'euros, elle devient de l'infrastructure opérationnelle, avec des swings de P&L matériels. Et c'est là que Gupta formule l'observation la plus inconfortable : « two runs of the same workflow on the same input can differ in token cost by 5-10x without anything visibly going wrong » — un chiffre que, selon elle, le CFO doit expliquer au CEO¹.

La marginal token utility : le chiffre que personne ne peut voir

Pour nommer ce problème avec précision, Gupta introduit le concept de marginal token utility : « the business value created by each additional dollar of inference. It's the number that matters at scale, and the number most companies cannot see. »¹.

Ce n'est pas le coût total de l'IA — c'est le dérivé du ROI, la valeur du dollar marginal d'inférence. Une facture de tokens ne dit pas si la dépense a remplacé du travail humain, généré du revenu, réduit du risque, ou financé des agents en boucles inutiles. Le problème est que la plupart des organisations ne disposent pas de l'instrumentation pour voir cette différence.

Cette invisibilité n'est pas anodine. Elle résulte de trois mécanismes bien identifiés qui s'accumulent silencieusement dans la facture mensuelle.

Le premier est ce que Gupta appelle les retry tails. Le coût par workflow résolu suit la formule T/p, où T est le nombre total de tokens et p le taux de complétion au premier passage. Passer d'un taux de réussite de 90 % à 70 % ne coûte pas 20 % de plus — il coûte environ 28 % de plus, parce que les échecs composent et génèrent des retries qui consomment eux-mêmes du contexte. Les agents qui semblent fonctionner, mais qui échouent régulièrement sur des cas limites, détruisent silencieusement la marge.

Le deuxième mécanisme est la context inflation. Le coût d'inférence par appel évolue en O(n²) en longueur de contexte — c'est la mécanique de l'attention. Doubler la taille du contexte quadruple le coût de raisonnement. Et les agents ingèrent facilement 50 documents quand 5 suffiraient, ou maintiennent un historique périmé que personne n'a pensé à élaguer.

Le troisième est le routing : par défaut, les organisations envoient toutes leurs requêtes au modèle frontier le plus puissant. Classifier un ticket de support avec un modèle de raisonnement complexe, c'est louer un avion de chasse pour livrer une pizza. Sur des millions d'appels, la différence entre router intelligemment les tâches simples vers des modèles plus légers et tout envoyer au frontier est, selon Gupta, « the difference between a manageable bill and a board-level problem »¹.

La deep research AI4* de novembre 2025 nomme ce même enjeu sous l'angle du DSI : le FinOps pour l'IA exige de nouvelles métriques (le coût par token remplace le coût par instance/heure), de nouvelles contraintes (la rareté GPU), et un nouveau modèle mental — le coût devient un « signal de conception » qui oblige les équipes à adopter une « architecture frugale »⁴.

Le ROI reste fort — sauf quand il ne l'est pas

Charlie Dai, VP et analyste principal chez Forrester, apporte la nuance nécessaire : le ROI des outils d'agentic coding reste globalement favorable. Le coût annuel d'un assistant (quelques milliers d'euros par poste) demeure très inférieur au salaire d'un développeur senior². La livraison est plus rapide, le taux d'erreur plus faible, la productivité mesurée à la hausse.

Mais Dai ajoute une condition : « pour les projets complexes et à grande échelle, le coût cumulé des outils et de la supervision senior pourrait égaler ou dépasser l'embauche d'un développeur. »². Cette asymétrie est au cœur du problème. Le ROI de l'agentic coding est fort sur les tâches bien bornées — génération de tests unitaires, migration de code répétitif, documentation automatique, revue de PR standardisée. Il devient questionnable, voire négatif, sur les tâches ambiguës où les agents s'engagent dans des boucles de retry coûteuses et nécessitent une supervision senior intensive pour rattraper les erreurs.

Gupta formule la même logique en termes d'arbitrage budgétaire : « a claim that requires three retries, human correction, and a frontier model may be more expensive than the outsourced labor it was supposed to replace. »¹. L'IA ne concurrence plus le SaaS dans les budgets — elle concurrence directement le coût du travail. Et contrairement au BPO (déjà tarifé en unités de travail complétées, donc facilement comparable), le travail interne est beaucoup plus difficile à benchmarker : les employés sont polyvalents, les gains sont diffus, et la résistance organisationnelle à réduire des effectifs en réponse à des gains d'efficacité diffus est réelle.

Le piège du compteur SaaS appliqué à l'IA

Il y a un réflexe acquis pendant dix ans de transformation cloud qu'il faut désapprendre : celui de traiter l'usage comme un proxy de valeur. Quand une organisation mesurait l'adoption d'un CRM au nombre de connexions quotidiennes, elle avait une heuristique raisonnable — si les commerciaux s'y connectent, ils l'utilisent. Ce proxy s'effondre avec l'IA agentique.

« The signal and the noise share the same unit », écrit Gupta¹. Le token est à la fois l'unité de facturation et l'unité de travail — mais la valeur produite par un token varie de manière radicale selon qu'il correspond à un raisonnement utile ou à du thrashing (boucles sans issue, retries inutiles, récupération de contexte superflu). Un dashboard de consommation de tokens ne dit pas si votre entreprise produit de la valeur ou simplement paie le compteur.

Deux organisations peuvent afficher la même facture mensuelle d'inférence. L'une a automatisé 30 % de ses revues de code et réduit son cycle de release de deux semaines. L'autre a déployé des agents qui tournent, consomment, et produisent une output que personne n'a instrumentée pour mesurer. La facture est identique. L'outcome, non.

Les leviers d'action : du bon modèle par tâche au context engineering

La bonne nouvelle, c'est que les trois sources d'inefficacité décrites par Gupta sont actionnables. Ce sont exactement les leviers que SFEIR observe et instrumente dans ses missions, dans le cadre de son approche Context Engineering et Harness Engineering.

Le premier levier est le routage modèle. L'équation n'est pas de toujours utiliser le meilleur modèle, mais le modèle juste-suffisant pour chaque tâche. Un modèle léger (classe Haiku) pour la classification, le résumé ou la génération de boilerplate. Un modèle intermédiaire (classe Sonnet) pour la refactorisation ou la revue de code contextuelle. Un modèle frontier uniquement pour les raisonnements complexes ou multi-étapes qui le justifient réellement. Sur des millions d'appels, ce routage différencie une facture maîtrisable d'un problème de board. Bradley Shimmin, de The Futurum Group, avertit d'ailleurs que les coûts croissent avec l'expansion de la base de code de l'entreprise — sans routage explicite, la trajectoire est divergente².

Le deuxième levier est l'hygiène du contexte. Nourrir un agent de 50 documents quand 5 suffisent ne produit pas un meilleur résultat — il produit une facture quadruplée. Le Context Engineering de SFEIR adresse précisément ce point : l'architecture mémoire en trois tiers (Hot / Warm / Cold, d'après Vasilopoulos) permet de n'injecter dans le contexte actif que l'information pertinente à l'instant t, et d'externaliser le reste en mémoire froide récupérable à la demande. « Chaque session est un nouvel employé qui repart de zéro » — Patrick Debois — mais un nouvel employé bien briefé ne consulte pas les 50 derniers rapports annuels pour répondre à une question simple. C'est sur les grandes bases de code que ce levier pèse le plus lourd.

Le troisième levier est la fiabilisation du premier passage. Réduire les retry tails exige de comprendre pourquoi les agents échouent. Est-ce un problème de prompt, de contexte insuffisant, de task too complex décomposée en un seul appel ? Le Harness Engineering de SFEIR pose l'équation comme suit : un agent = un modèle + un harnais. Le harnais (guides feedforward + sensors feedback) peut faire gagner 20 points de performance à modèle constant. Instrumenter les traces d'exécution — ce que l'agent a vu, récupéré, où il a retenté, quand un humain a corrigé — permet d'identifier les patterns d'échec et de les éliminer avant qu'ils ne composent.

Le quatrième levier est la sélection du workflow. Tous les workflows ne méritent pas des agents frontier. La règle d'or : déployer l'agentic coding en priorité sur les tâches à fort volume, bien bornées, où la vérification automatique du résultat est possible. La génération de tests sur du code existant, la migration vers un nouveau framework avec des règles explicites, la synchronisation de documentation sur une base de code instrumentée : ces workflows ont un ROI fort et un profil de retry prévisible. En revanche, la conception d'une architecture from scratch, la résolution de bugs dans un système mal documenté, ou la négociation de spécifications ambiguës avec des agents autonomes : ces cas produisent des boucles coûteuses et nécessitent une supervision humaine qui annule les gains.

Vers le coût par résultat complété : le nouveau KPI de la DSI

La couche qui manque dans la plupart des organisations est ce que Gupta appelle le token-to-outcome attribution : un mécanisme reliant la dépense d'inférence au travail effectué, puis à l'outcome business. Trois questions doivent trouver une réponse : quel est le coût réel incluant les retries et corrections ? Quelles parties de la trace d'exécution ont produit de la valeur versus du thrashing ? Le workflow a-t-il changé l'operating model (moins de tickets par agent, cycles plus courts, lignes de coût réduites) ?¹

L'unité pertinente n'est plus le token — c'est le coût par résultat complété (cost per completed outcome) : coût par PR mergée, par bug résolu au premier passage, par feature livrée en production, par heure de développeur libérée de tâches répétitives. Cette conversion est triviale pour les processus comparables à du BPO (déjà tarifés en unités de travail) ; elle est plus difficile mais fondamentale pour le travail de développement, où les gains sont souvent diffus et multi-dimensionnels.

Ce glissement de KPI modifie la posture de la DSI. Le suivi de l'adoption des outils — « combien de développeurs ont activé le plugin ? » — ne suffit plus. Ce qu'il faut mesurer, c'est l'impact sur les indicateurs DORA : cycle time, change failure rate, mean time to restore. L'IA est productive quand elle déplace ces métriques, pas quand elle est utilisée. La formule de Gupta est implacable : « Show me the incentive and I will show you the outcome » — si vos développeurs sont évalués sur leur vitesse d'adoption des outils, ils adopteont les outils ; si vous les évaluez sur la réduction du cycle time, ils optimiseront pour ça.

Points clés

• La fin des assistants bon marché est structurelle : tensions GPU, coûts de licence des modèles, et infrastructure d'inférence ont mis fin aux tarifs subventionnés de 2023-2024. Cursor, Claude Code et Kiro ont aligné leurs prix à la hausse à l'automne 2025². Sans action, les dépenses IT globales pourraient augmenter de 50-60 % d'ici 2028³.
• L'IA d'entreprise est passée de l'adoption à l'allocation : la bascule expérimentation (quelques centaines de milliers d'euros) vers infrastructure (7 chiffres) s'est produite au Q1 2026. À cette échelle, deux exécutions du même workflow peuvent différer de 5 à 10× en coût de tokens sans que rien ne soit visiblement cassé¹.
• La marginal token utility — la valeur business créée par chaque dollar marginal d'inférence — est le chiffre qui compte à l'échelle, et que la plupart des organisations ne savent pas calculer. Le token est une unité de facture stable dont la valeur produite est instable : usage ne signifie plus valeur.
• Trois sources d'inefficacité actionnables : les retry tails (passer de 90 % à 70 % de complétion coûte 28 % de plus, pas 20 %), la context inflation (doubler le contexte quadruple le coût), et l'absence de routing modèle (tout envoyer au frontier modèle est l'équivalent budgétaire d'un problème de board).
• Le ROI reste fort sur les workflows bornés : les tâches à fort volume, vérifiables automatiquement, avec des spécifications stables (génération de tests, migration de code, documentation). Il devient questionnable sur les tâches complexes, ambiguës ou sous-documentées, où les retries et la supervision senior annulent les gains².
• Quatre leviers de maîtrise : routage modèle (bon modèle par tâche), hygiène du contexte (Context Engineering, architecture mémoire 3 tiers), fiabilisation du premier passage (Harness Engineering, instrumentation des traces), sélection des workflows à fort ROI.
• Le nouveau KPI : le coût par résultat complété — coût par PR mergée, par bug résolu, par feature livrée — supplante le coût par token comme unité de mesure pertinente. La DSI qui construit cette attribution aujourd'hui fait les allocation calls de demain.

Sources

1. Jaya Gupta, essai sur l'allocation de l'IA en entreprise — x.com, 28 mai 2026.
2. Paul Krill, The era of cheap AI coding assistants may be over — infoworld.com, 15 septembre 2025.
3. CIO Online, Logiciels et cloud : l'ère des prédateurs pour vos budgets IT — cio-online.com, 26 janvier 2026.
4. Deep research AI4*, IA Production Logicielle : Six Domaines Clés — github.com, novembre 2025.