Les coûts cachés de l’IA à grande échelle

Le 1 juin 2026, GitHub a retiré définitivement les “requêtes premium” à tarif forfaitaire pour Copilot et les a remplacées par des crédits IA basés sur l’usage. Lorsque les premières factures sous le nouveau modèle sont arrivées un mois plus tard, certains utilisateurs agentiques ont vu des factures auxquelles ils n’étaient pas préparés : Un développeur a signalé que les coûts mensuels passaient de 29 $ à 750 $ pour les flux de travail agentiques les plus lourds.

C’était un exemple visible d’un changement plus large sur le marché des outils d’IA au cours de 2026 – et qui pourrait attendre les organisations qui paient encore un tarif forfaitaire aujourd’hui.

Les organisations comptent les heures qu’elles économisent. Beaucoup d’entre elles ne comptent pas ce qu’un tarif forfaitaire rend invisible : la consommation de contexte et les nouvelles tentatives après un échec. D’autres coûts n’apparaissent jamais du tout sur la facture du fournisseur, y compris le temps passé à examiner les résultats et à entretenir les invites. Une fois la facturation passée à la consommation réelle, les organisations sans discipline budgétaire risquent une facture qui les surprend de la même manière que le nouveau modèle de Copilot a surpris certains utilisateurs.

Le contexte que personne ne tarifie

L’IA a évidemment besoin de contexte ; cela ne fait aucun doute. La question est de savoir si le contexte envoyé est pertinent, ou simplement disponible par commodité. Envoyer un document complet est le moyen le plus rapide de fournir des informations à un modèle. Ce n’est pas automatiquement le moins cher ni le meilleur moyen.

En mai 2026, le Digital Economy Lab de Stanford a publié une analyse des tâches de codage agentiques sur huit modèles de pointe et a constaté que ces tâches consomment jusqu’à mille fois plus de jetons qu’une simple discussion de code, le principal facteur n’étant pas la sortie du modèle mais le contexte d’entrée qu’il renvoie sans cesse. L’agent relit son historique complet à chaque étape suivante. La même tâche, exécutée plusieurs fois, variait la consommation de jetons jusqu’à trente fois.

La précision ne s’accroît pas non plus linéairement avec le volume de contexte : elle atteint souvent un pic à un niveau modéré, puis ne fait qu’ajouter du coût sans apporter de valeur supplémentaire.

L’aveuglement aux jetons, alors, ne concerne pas le fait que l’IA n’a pas besoin de contexte. Il s’agit du fait que, sans mesure, personne ne se demande si tout ce contexte est réellement nécessaire. Sous un tarif forfaitaire, la question est facile à ignorer. Sous une facturation basée sur la consommation, elle devient partie intégrante du coût.

Lorsque vous payez deux fois pour un échec

Les flux de travail agentiques entraînent un autre coût qui apparaît presque jamais dans les calculs de ROI. Imaginez une chaîne simplifiée de dix étapes, chacune ayant 95 % de chances, prise isolément, de fonctionner correctement. Cela semble suffisamment fiable, mais une fois enchaînées, cette chaîne n’a qu’environ 60 % de chances de traverser l’exécution complète sans aucune erreur.

Dans un flux de travail qui renvoie le contexte accumulé à chaque appel, chaque échec et la nouvelle tentative qui suit ne vous coûtent pas seulement l’étape répétée : vous payez de nouveau pour tout ce qui a été envoyé avant.

C’est une douleur courante que presque tout le monde rencontre lorsqu’il construit sa première chaîne agentique. J’ai moi-même traversé cela. Au début, avec seulement quelques agents, cela n’avait pas beaucoup d’importance. Mais à mesure que la chaîne s’est développée, chaque exécution échouée est devenue plus coûteuse, et cela m’a poussé à commencer à me demander quel contexte chaque agent nécessitait et comment le mettre en cache, plutôt que de simplement vérifier si l’exécution s’était déroulée.

La même analyse calcule qu’un agent à dix étapes avec 95 % de fiabilité par étape consomme environ 40 % de jetons supplémentaires lors des nouvelles tentatives par rapport à un système parfaitement fiable. C’est un coût que vous verrez sur la facture mais qui, probablement, ne figurera dans aucun tableau ROI.

La supervision n’est pas un bug. Elle appartient au budget

Ce point doit être formulé avec précision, car il est facile de se tromper. Examiner les résultats de l’IA n’est pas une défaillance du système ; c’est une partie légitime et attendue du travail avec l’IA, tout comme la revue de code est une partie légitime du travail avec les développeurs. Le problème n’est pas que les résultats soient examinés. Le problème est que ce travail n’est presque jamais intégré au calcul de ce que l’IA a réellement permis d’économiser.

L’Institut Work AI de Glean a interrogé 6 000 travailleurs et a constaté que l’automatisation leur fait gagner environ 11 heures par semaine, mais près de six heures et demie de ces heures sont consacrées aux tâches de maintenance : fournir du contexte aux systèmes d’IA, vérifier leur travail et corriger les erreurs. L’économie nette, alors, se rapproche de quatre heures et demie – moins de la moitié du chiffre annoncé. L’IA fait toujours gagner du temps, mais pas autant que le premier chiffre le laisse penser.

Les invites nécessitent une maintenance, pas seulement un auteur

Les invites se comportent aujourd’hui davantage comme du code de production : une mise à jour du modèle, un changement de contexte ou une modification apparemment mineure peuvent altérer leurs performances. Sans versionnage et tests, ces changements peuvent introduire silencieusement des problèmes. Les tests de régression, qui sont la norme pour le code, sont encore souvent négligés lorsqu’il s’agit de vérifier les invites. Une modification qui ressemble à une petite retouche d’une phrase unique peut atteindre la production et réduire la précision sans que personne ne le remarque, jusqu’à ce que le problème s’accumule et devienne visible.

Construire un cadre d’évaluation adéquat – incluant un jeu de tests et des tests de régression automatisés à chaque modification – représente un travail supplémentaire qui apparaît presque jamais dans le calcul “l’IA fait gagner du temps”.

Des jetons moins chers, des factures plus élevées

GitHub Copilot n’a pas fait exception. Une enquête citée par CFO Dive a révélé que près de sept entreprises américaines sur dix ont signalé au moins des dépassements partiels de budget IA au cours de l’année écoulée, principalement avant un passage complet à la facturation à l’usage, et non après.

Bain & Company, dans son analyse de juin sur l’économie des jetons, ajoute un paradoxe qui résume le mieux la situation : le prix du jeton a chuté de moitié sur l’année, tandis que la consommation sur la même période a augmenté de 4,5 fois.

Le modèle est devenu moins cher, mais la facture reste obstinément élevée. Les entreprises sont passées à des modèles plus récents, ont confié des tâches plus complexes aux agents et ont découvert davantage de flux de travail pour eux. Un jeton moins cher ne signifiait pas une dépense moindre ; cela signifiait simplement qu’il y avait plus de raisons de le consommer.

Comment se préparer avant l’arrivée de la facture

Le cadre qui découle de cela ne consiste pas à utiliser moins d’IA. Il s’agit de connaître les coûts de l’IA avant de décider de l’étendre davantage.

1. Obtenir d’abord de la visibilité

Jusqu’à ce que vous ayez la consommation ventilée par équipe, flux de travail, application et tâche terminée, chaque expansion est un pari à l’aveugle. Cette visibilité n’est pas non plus gratuite : pour les flux de travail agentiques en particulier, tracer chaque étape, consigner ce qui s’est passé et pourquoi, et surveiller les boucles incontrôlées nécessite du temps d’ingénierie et des outils dédiés. Prévoyez cela dans le coût de fonctionnement de l’IA, et non comme une réflexion après coup.

2. Recalculer le ROI sur une base nette

Soustrayez le temps passé à la révision, aux corrections et à la maintenance des prompts des heures économisées déclarées. Si le gain de temps est le but du cas d’usage et que le résultat net est négatif ou non vérifiable, il n’est pas prêt à être mis à l’échelle. Lorsque le bénéfice recherché est la qualité, la capacité, la réduction des risques ou le revenu, mesurez directement cet impact.

3. Appliquer une discipline des coûts, mais pas uniformément

Un plafond de dépenses strict a du sens lorsque l’échec est peu coûteux : outils internes, agents expérimentaux, environnements de développement. Pour les fonctionnalités critiques en contact avec les clients – par exemple un assistant de service client – un plafond strict n’est pas viable, car il crée un risque de panne. Dans ce cas, il faut des solutions de repli à un modèle moins cher et des alertes précoces, plutôt qu’une coupure à zéro.

4. Considérer les prompts et les évaluations comme des actifs d’ingénierie

Versionnez‑les, testez‑les et examinez les modifications avant le déploiement, de la même manière que vous gérez le code de production.

Abordez les renouvellements avec vos propres données

Le prix des fournisseurs est difficile à évaluer sans vos propres données d’utilisation. Avant un renouvellement ou un changement de modèle, calculez ce que vos flux de travail existants coûteraient selon les conditions proposées. L’objectif n’est pas seulement de négocier un prix plus bas. Il s’agit de savoir comment ce prix se comportera à votre niveau réel de consommation, plutôt que de le découvrir à la lecture de la facture.

Trois actions à entreprendre cette semaine : vérifier si vous pouvez ventiler la consommation d’IA par équipe et flux de travail ; choisir un cas d’usage et mettre le temps passé à la révision à côté des heures prétendument économisées ; et identifier où un plafond de dépenses strict pourrait provoquer une panne plutôt que de maîtriser un coût.

Les coûts de l’IA peuvent être maîtrisés. Mais pas lorsqu’on les découvre pour la première fois à travers la facture.