Le budget de tokens du contexte : un actif, pas une dépense

Un grand groupe de protection sociale décide de déployer des agents IA pour accélérer la production de ses équipes de développement. Les premiers résultats sont encourageants : les sprints s'accélèrent, la couverture de tests s'améliore, les développeurs signalent moins de friction sur les tâches répétitives. Puis arrive la réunion budgétaire de fin de trimestre. La ligne « inférence IA » a doublé. Le DSI demande pourquoi. Personne ne peut vraiment répondre. Les agents tournent. La valeur est là, quelque part. Mais la facture non plus n'a pas de décomposition utile.

Ce scénario est devenu banal en 2026. Il révèle un angle mort structurel : la plupart des organisations pilotent leur budget IA à l'aveugle, parce qu'elles traitent les tokens comme une dépense de fonctionnement qu'elles ne cherchent pas à comprendre. Ce que cet article défend, c'est l'exact opposé : le contexte est un actif capitalisable. L'appréhender comme tel transforme non seulement la lecture de la facture, mais aussi la trajectoire du ROI.

Le paradoxe du contexte : la partie invisible de la facture IA

Il y a un fait contre-intuitif qui structure tout ce qui suit : dans un cycle de développement piloté par agents, le coût n'est pas dans la génération — il est dans l'ingestion. Ce que l'agent lit pèse infiniment plus lourd que ce qu'il écrit.

Une étude de 283 sessions de développement agentique le quantifie précisément : l'infrastructure contextuelle représente désormais 24,2 % de la documentation totale. Et si l'on remonte au niveau de la session elle-même, les lectures de fichiers concentrent environ 96 % du contexte — l'agent relit sans cesse ce qu'il a déjà ingéré (Didier Girard / SFEIR, « Context Engineering », 2026-03, basé sur les travaux de Vasilopoulos, Debois, Shipper & Klaassen 2025-2026).

Le ratio entrée/sortie en codage agentique atteint 153:1. Pour un simple chat de code, ce ratio est de 1,33:1. Cet écart de deux ordres de grandeur explique pourquoi la facture IA surprend systématiquement les équipes : on mesure et on perçoit la sortie (le code produit, les tests générés, la documentation mise à jour), mais on paie l'entrée, invisible et continue.

La formule de Patrick Debois, inventeur du DevOps, résume le paradoxe : « Chaque session est un nouvel employé — un employé qui repart de zéro, sans mémoire musculaire ni conversations de couloir. » Un agent sans contexte structuré ne cherche pas dans sa mémoire — il relit tout depuis le début. À chaque fois. C'est là que les tokens disparaissent.

Bai et al. (arXiv 2604.22750, 2026) ont mesuré sur SWE-bench Verified qu'un cycle agentique consomme en moyenne 4,17 millions de tokens par tâche — soit environ 1 000 fois plus qu'un chat. La dépense n'est pas répartie uniformément entre les phases : quelques-unes concentrent l'essentiel de la facture. Les identifier est le premier levier de maîtrise.

Comprendre la mécanique : où partent vraiment les tokens ?

Quatre moteurs brûlent les tokens dans un cycle agentique. Les connaître transforme une facture opaque en budget pilotable.

Le premier moteur est l'ingestion de contexte. Rechargement de mémoire, relectures de fichiers, rechargement des leçons apprises — dans une session type, ces opérations représentent l'essentiel de la consommation. L'agent relit sans cesse ce qu'il a déjà traité, faute d'une architecture qui lui permette de distinguer ce qui est pertinent à l'instant t de ce qui peut rester en mémoire froide.

Le second moteur est le parallélisme multi-agents. Chaque sous-agent maintient sa propre fenêtre de contexte indépendante. N agents en parallèle génèrent de 7 à 15 × les tokens d'une session simple. Un système multi-agents de recherche d'Anthropic consomme 15 fois plus de tokens qu'un chat ; une équipe d'agents Claude Code en mode planification atteint 7 fois. Ce n'est pas du gaspillage — les sous-agents Sonnet ont surpassé un agent Opus unique de plus de 90 % en évaluation interne, en réduisant le temps réel de 50 à 80 %. Mais le multiplicateur doit être anticipé et budgété.

Le troisième moteur est la boucle de debug. Reproduire, localiser, corriger, recommencer. Deux exécutions de la même tâche peuvent varier d'un facteur 30 en tokens. C'est la source de variance la plus difficile à maîtriser, et celle qui rend les projections budgétaires si difficiles.

Le quatrième moteur est la recherche web. Une page web pèse des dizaines de milliers de tokens d'entrée. Activer l'outil de recherche seul ajoute déjà environ 4 300 tokens de contexte.

Ces quatre moteurs ne pèsent pas de façon uniforme dans le cycle. L'analyse du SDLC v3 (Didier Girard / SFEIR, 2026) montre que quatre phases concentrent environ 78 % de la facture totale : BUILD (≈ 30 %), REVIEW (≈ 19 %), PLAN (≈ 17 %) et VERIFY (≈ 12 %). À l'opposé, la phase OPS — la plus longue en durée — ne représente qu'environ 1 % de la consommation totale en tokens. Durée et coût sont découplés : Long ≠ coûteux. C'est ce découplage qui rend le pilotage intuitif impossible.

Réserve méthodologique : ces pourcentages sont des ordres de grandeur dérivés, pas des mesures directes. Aucune source publique ne ventile les tokens sur un SDLC à onze phases. L'enjeu est de les instrumenter par projet pour passer de l'estimation au chiffre maison.

De la dépense à l'actif : le changement de cadre mental

Voici le renversement que cet article propose : le contexte n'est pas une dépense — c'est un actif. Et comme tout actif, il peut être capitalisé, déprécié, mis à jour, partagé.

« Le contexte est un actif, pas une dépense. » Cette formule de Didier Girard / SFEIR (« Context Engineering », 2026-03) n'est pas un slogan — c'est un changement de comptabilité. Une dépense se consomme. Un actif produit de la valeur sur plusieurs cycles. Un contexte bien structuré — une spec précise, une convention d'équipe documentée, un historique de décisions accessible — ne sert pas qu'une seule session. Il sert toutes les sessions suivantes, à coût marginal décroissant.

C'est la différence fondamentale entre le prompt engineering et le context engineering. Le premier optimise une interaction isolée : mémoire éphémère, retour sur investissement linéaire. Le second optimise l'environnement global : mémoire persistante cross-sessions, ROI composé. Chaque session bien contextualisée enrichit la suivante. C'est la mécanique de la boucle compound (Shipper & Klaassen, 2025-12) : planifier, exécuter et évaluer, puis composer les leçons pour les cycles futurs. L'étape « composer » est décrite par ses auteurs comme l'étape magique — et la plus souvent négligée.

Mais un actif se déprécie s'il n'est pas maintenu. C'est le problème du contexte qui pourrit. Comme le code, le contexte entre en conflit avec la réalité et devient obsolète. Une spec périmée n'est pas neutre — elle induit l'agent en erreur activement. Elle est pire que l'absence de spec, parce qu'elle produit une confiance erronée.

La réponse s'inspire du DevOps : traiter le contexte comme une dépendance logicielle. Packageage versionné, distribution contrôlée (comme npm ou maven), cycle de revue, dépréciation explicite. Le CDLC — Context Development Lifecycle (Debois / Tessl, 2026-02) — formalise ce cycle en quatre phases : GÉNÉRER (rendre l'implicite explicite), ÉVALUER (le TDD du contexte), DISTRIBUER (package versionné) et OBSERVER (boucle de feedback en production).

Pour un DSI, la question n'est pas seulement « combien coûtent nos tokens » mais « quelle est la valeur de notre actif contextuel et combien investissons-nous pour le maintenir ».

Le ROI du context engineering : la vélocité ×5 décomposée

Passons aux chiffres. Le décideur a besoin d'un business case, pas d'un manifeste.

La mesure la plus directe est celle de Didier Girard / SFEIR (« Context Engineering », 2026-03) : « Vélocité ×5 — Un développeur bien outillé équivaut à cinq développeurs traditionnels. » Ce multiplicateur est le résultat de la boucle compound appliquée sur la durée : chaque cycle enrichit le suivant, la complexité décroît là où elle croissait dans l'ingénierie traditionnelle. Le coût de maintenance pour obtenir ce résultat est remarquablement faible : 1 à 2 heures par semaine pour un système qui s'améliore seul.

Pour construire un business case défendable devant un CFO, le rapport DORA × Google Cloud (2026-04-21) offre le plancher de référence : sur un sample de 500 développeurs, avec un salaire chargé de 176 000 $ et 12,5 % de temps économisé par développeur, le modèle donne un ROI de 39 % la première année et un payback de 8 mois. C'est délibérément conservateur — mais c'est précisément ce conservatisme qui le rend crédible devant une direction financière.

Sur le terrain, les retours d'expérience sont plus élevés. Un grand éditeur SaaS a décidé de supprimer tous les token limits pour ses ingénieurs — au motif que le token limit était une friction, pas un garde-fou de coût — et constaté les résultats suivants sur un an glissant : work items complétés par développeur en hausse de +50,8 %, PRs mergées de +79 %, et surtout leur indicateur de valeur réelle du code livré en hausse de +151,3 % en glissement annuel. Résultat notable : les incidents totaux ont baissé de 5 % en parallèle de la hausse des livraisons. Vitesse et qualité ne sont pas en tension — elles se renforcent quand le contexte est bien structuré (dirigeant exécutif d'un hyperscaler SaaS américain, 2026-05-27).

Le changement de KPI est ici décisif. Jaya Gupta (investisseuse, thread X, 2026-05-28, 230 500 vues) introduit le concept de marginal token utility : « la valeur business créée par chaque dollar marginal d'inférence. C'est le chiffre qui compte à l'échelle, et que la plupart des entreprises ne peuvent pas voir. »

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. Deux organisations peuvent afficher la même facture mensuelle d'inférence : l'une a automatisé 30 % de ses revues de code, l'autre a des agents qui tournent sans que personne n'ait instrumenté leur output. La facture est identique. L'outcome, non.

L'unité pertinente à construire : le coût par résultat complété — coût par PR mergée, par bug résolu au premier passage, par feature livrée, par heure de développeur libérée de tâches répétitives. C'est ce déplacement de KPI qui permet de piloter un budget contextuel avec rigueur.

L'architecture Hot / Warm / Cold : le cadre de décision du DSI

Comment décider quoi mettre où ? L'architecture 3 tiers de Vasilopoulos (Codified Context Infrastructure, 2026-02) offre un cadre opérationnel — détaillé dans notre article dédié : Architecture mémoire 3 tiers pour les agents IA.

Tier 1 — Hot Memory (la Constitution) : ce qui est toujours chargé, à chaque session, sans exception. Les conventions d'équipe, les standards de code, les décisions d'architecture structurantes, les règles de sécurité non négociables. Volume faible, fréquence maximale, criticité absolue. L'investissement ici est un coût de fonctionnement minimal avec un levier maximal : chaque session bénéficie de cette base sans qu'on ait à la recharger manuellement.

Tier 2 — Warm Memory (les Experts) : les agents spécialisés invoqués à la demande. Environ 50 % de faits, peu de directives. Ce tier est le plus coûteux par usage mais le plus frugal par design : on n'invoque l'expert que quand on en a besoin. Une équipe qui a structuré ses spécialités métier, ses patterns de test ou ses contraintes réglementaires dans ce tier dispose d'experts disponibles immédiatement.

Tier 3 — Cold Memory (la Knowledge Base) : l'ensemble de la documentation de référence — specs fonctionnelles, historique de décisions, documentation technique, résultats d'audits. Ce tier est massif, mais il est tiré uniquement au besoin. L'anti-pattern à éviter absolument est l'over-retrieval : injecter 50 documents quand 5 suffisent. Le coût d'inférence évolue en O(n²) en longueur de contexte — doubler la taille du contexte quadruple le coût de raisonnement. La Cold Memory doit être précisément indexée et récupérée de façon chirurgicale.

Un contexte bien architecturé dans ces trois tiers réduit mécaniquement la consommation de tokens : l'agent cesse de relire tout depuis le début à chaque session. Il s'appuie sur ce qui est déjà structuré. C'est le passage du salarié qui arrive sans briefing chaque lundi matin au collaborateur qui retrouve son contexte de travail intact.

Trois pièges FinOps que chaque DSI doit connaître

Le discours sur le ROI du contexte serait incomplet sans les risques. Voici les trois pièges les plus fréquents.

Piège 1 — L'over-retrieval ou context inflation. C'est le driver invisible le plus commun de la facture. On récupère 50 documents parce que c'est ce que le système fait par défaut, alors que 5 suffiraient. On maintient un historique de conversation de 80 échanges alors que les 10 derniers seraient suffisants. Chaque doublement du contexte quadruple le coût de raisonnement. Jaya Gupta identifie cette sur-récupération comme l'une des trois causes principales d'invisibilité de la valeur IA (2026-05-28).

Piège 2 — L'absence de routing modèle. 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 allouer une ressource rare à une tâche qui n'en a pas besoin. Sur des millions d'appels, la différence entre router intelligemment et ne pas router est, selon Gupta, « the difference between a manageable bill and a board-level problem ». Le pattern opusplan (Didier Girard / SFEIR) articule cette logique : Opus pour PLAN et le raisonnement complexe, Sonnet pour BUILD, Haiku pour les scouts d'exploration et les tâches de classification.

Piège 3 — Le contexte qui pourrit sans maintenance. Une infrastructure contextuelle non maintenue ne reste pas neutre — elle se dégrade. Les specs évoluent, les conventions changent, les contraintes se modifient. Un agent qui reçoit un contexte périmé ne sait pas qu'il est périmé : il l'utilise. La bonne nouvelle est que le coût de maintenance est faible : 1 à 2 heures par semaine pour un système correctement architecturé. Les hésitations de l'agent en production sont d'ailleurs le signal le plus fiable des lacunes du contexte — les observer fait partie du cycle CDLC.

Un dernier point contre-intuitif sur ce troisième piège : le partage de la connaissance sert désormais l'intérêt égoïste du développeur, pas seulement l'équipe. Un contexte bien documenté aide d'abord son auteur à l'itération suivante. Cette convergence d'incentives est un levier organisationnel que peu de DSI exploitent consciemment.

Leviers d'action : construire le budget contextuel

Cinq actions concrètes permettent de passer d'un budget contextuel subi à un budget contextuel piloté.

1. Activer le prompt caching en priorité. C'est le levier le plus puissant et le plus immédiat. Les relectures en cache reviennent à environ 10 % du tarif d'entrée standard — soit une réduction allant jusqu'à −90 % sur le premier poste de coût (tokens-sdlc-v3, Didier Girard / SFEIR, 2026). Dans un cycle agentique où l'ingestion représente l'essentiel de la facture, ce levier seul peut transformer l'économie du projet.

2. Instrumenter par phase. La variance entre sessions est la principale source d'imprévisibilité budgétaire. L'instrumentation (ccusage, /cost) permet de passer des estimations au chiffre maison, par phase, par workflow, par équipe. Cette donnée est le prérequis à toute conversation sérieuse avec la direction financière.

3. Définir un modèle de gouvernance Hot/Warm/Cold par équipe. Ce travail de classification n'est pas technique — il est stratégique. Décider ce qui mérite d'être en Hot Memory force à expliciter ce que l'équipe considère comme ses invariants. Ce travail de structuration prend quelques heures initialement ; il économise des tokens et du temps à chaque session suivante.

4. Cadrer le scope en amont. La phase DEFINE est la moins coûteuse du cycle (environ 6 % de la facture totale) et c'est là que se joue l'essentiel de l'hygiène contextuelle. Un scope précis réduit mécaniquement le volume de contexte à traiter dans les phases coûteuses (BUILD, REVIEW). Chaque heure investie en DEFINE économise des tokens en BUILD.

5. Traiter le contexte comme une dépendance logicielle. Packageage versionné, revue régulière, dépréciation explicite. Le contexte est une dépendance au même titre qu'une librairie : il doit avoir un owner, un cycle de mise à jour, et une politique de dépréciation. Cette discipline — légère à maintenir, lourde à reconstruire une fois perdue — est ce qui différencie une organisation dont le contexte s'améliore de celle dont il se dégrade.

Pour aller plus loin sur la maintenance du contexte : Maintenir le contexte avec TDD et évaluations. Pour sécuriser votre infrastructure contextuelle : Sécuriser le contexte des agents IA.

L'ingénierie du contexte comme investissement structurant

Il y a une formule que l'on retrouve dans les organisations qui ont le plus progressé sur ce sujet : « l'ingénieur de demain ne sera pas celui qui écrit le meilleur code, mais celui qui structure le meilleur contexte. » (Didier Girard / SFEIR, « Context Engineering », 2026-03).

Ce glissement n'est pas rhétorique. Il reflète un changement économique réel : écrire du code est devenu un anti-pattern. Ce qui crée de la valeur dans un cycle de développement augmenté, c'est la qualité du contexte fourni aux agents — la précision des specs, la clarté des conventions, la richesse de la mémoire structurée. Le code est un sous-produit. Le contexte est la facture, et potentiellement le moat.

Pour un DSI, l'enjeu stratégique est clair. L'organisation qui traite ses tokens comme une dépense qu'elle subit paie le coût d'un « nouvel employé qui repart de zéro » à chaque session. Elle consomme sans capitaliser. À l'inverse, l'organisation qui investit dans son infrastructure contextuelle — qui structure son Hot Memory, qui maintient son Warm Memory, qui indexe intelligemment sa Cold Memory — transforme chaque session en point de départ enrichi plutôt qu'en recommencement.

Le coût de cet investissement est faible : quelques heures initiales de structuration, une à deux heures de maintenance hebdomadaire. Le ROI est composé : chaque cycle améliore le suivant. La vélocité ×5 documentée par SFEIR n'est pas un point d'arrivée — c'est un multiplicateur qui s'améliore avec le temps si l'actif contextuel est maintenu.

La vraie question pour un DSI en 2026 n'est pas « combien nous coûtent nos tokens » mais « quel est le rendement de notre actif contextuel — et que faisons-nous pour qu'il s'apprécie ? »

SFEIR accompagne ses clients dans la structuration de ce capital contextuel, via le Context Engineering (architecture 3 tiers, CDLC) et le Harness Engineering (équation Agent = Modèle + Harnais, gains de 20+ points de performance à modèle constant).

Pour aller plus loin :

• Context Engineering — Le guide complet
• Architecture mémoire 3 tiers
• Compound Engineering : le cycle cumulatif
• Coût de l'agentic coding : le guide FinOps
• Sécuriser le contexte des agents IA

Sources

1. SFEIR — Context Engineering, matière first-party, mars 2026.
2. SFEIR — Tokens & SDLC v3, matière first-party, 2026.
3. Bai et al., How Do AI Agents Spend Your Money? — arxiv.org, 2026.
4. Vasilopoulos, Codified Context Infrastructure — arxiv.org, février 2026.
5. Patrick Debois (Tessl), Context Development Lifecycle — tessl.io, 19 février 2026.
6. DORA × Google Cloud, The ROI of AI-assisted Software Development — cloud.google.com, 21 avril 2026.
7. Jaya Gupta, Token Budget Wars — x.com, 28 mai 2026.