Les agents de code écrivent 30 % de code en plus mais ne livrent pas plus : mesurez le coût par ticket résolu dans la gateway

Le chiffre que tout le monde a partagé cette semaine

Entre le 9 et le 12 octobre 2026, un graphique a circulé dans tous les Slack d'ingénierie : les agents de code font produire plus de code aux développeurs, et les entreprises ne livrent pas plus de logiciel.

La source est un working paper de Harvard signé par les économistes Fiona Chen et James Stratton, Artificial Intelligence in the Firm: Bottlenecks in Software Production. Il croise la télémétrie d'ingénierie de Jellyfish avec l'activité GitHub de plus de 700 éditeurs logiciels et environ 300 millions d'événements de travail, de 2021 à mars 2026. D'après la couverture de l'étude :

• les lignes de code augmentent d'environ 30 % après l'adoption d'agents de code
• les commits d'environ 20 %, les pull requests d'environ 23 %
• le taux de résolution des tickets Jira et des epics terminés, l'indicateur des auteurs pour les fonctionnalités livrées, ne change pas de manière statistiquement significative
• le délai entre soumission et merge d'une pull request augmente d'environ 49 %, les demandes de révision doublent presque, et les commentaires par pull request augmentent d'environ 35 %
• en mars 2026, 80 % des entreprises utilisaient des outils de revue de code IA, mais seuls 23 % des commentaires de revue étaient générés par l'IA

Certains médias y voient des relecteurs qui travaillent davantage ; d'autres, plus prudents, du travail qui attend plus longtemps en aval. Dans les deux cas, la conclusion est la même : les agents ont déplacé la contrainte. Écrire du code est devenu moins cher. Relire, intégrer et décider, non.

Pourquoi la plupart des entreprises ne le voient pas dans leurs propres données

L'étude s'appuie sur des années de télémétrie d'un fournisseur spécialisé. La plupart des organisations qui tentent de répondre à la même question pour elles-mêmes butent dès le premier jour, car le trafic des agents de code est invisible là où cela compte :

• Il part directement chez les providers. Agents en terminal, assistants d'IDE, bots de revue de PR et agents CI appellent chacun un provider de modèles, souvent avec une clé d'équipe partagée ou une carte personnelle.
• Il n'a pas de contexte métier. Une facture provider indique combien de tokens une clé a consommés. Elle ne dit ni quel dépôt, ni quel ticket, ni quel agent.
• Il n'a pas de plafond. Un agent coincé toute la nuit dans une boucle correction-test-correction dépense jusqu'à ce que quelqu'un remarque la facture.
• Il a des outils. Les agents agissent désormais sur GitHub, Jira et la CI via des serveurs MCP, avec des permissions pensées pour des humains.

Impossible de calculer un coût par ticket résolu si le coût n'est rattaché à aucun ticket. C'est un problème d'infrastructure, et il a une solution d'infrastructure.

Étape 1 : faire passer chaque agent de code par une seule gateway

Odock expose des endpoints natifs pour les formats d'API que les outils de code parlent déjà. La migration se résume à une URL de base et une clé, pas à une réécriture :

• Anthropic Messages sur https://api.odock.ai pour Claude Code et les agents fondés sur le SDK Anthropic
• OpenAI Chat Completions et Responses sur https://api.odock.ai/v1 pour les CLIs compatibles OpenAI, les extensions d'IDE et les bots de revue
• Mistral, dont le fill-in-the-middle Codestral sur /v1/mistral/fim/completions pour l'autocomplétion
• les endpoints vLLM pour les modèles de code auto-hébergés
• Gemini pour les outils fondés sur Gemini

Pour Claude Code, cela tient en trois variables d'environnement :

export ANTHROPIC_BASE_URL="https://api.odock.ai"
export ANTHROPIC_API_KEY="sk_dock_virtual_key_for_this_developer"
export ANTHROPIC_CUSTOM_HEADERS="x-repo: payments-api
x-ticket: PAY-1423"

Chaque développeur, et chaque agent autonome (le correcteur CI, le relecteur de PR, le bot de dépendances), reçoit sa propre virtual API key. Les clés portent leur propriétaire, leur équipe, leurs grants de modèles et de MCP, leurs budgets et leurs quotas. Les clés provider restent chiffrées dans Odock et n'arrivent jamais sur un poste.

Étape 2 : placer les budgets là où sont les boucles

Les agents de code sont le cas le plus net du paradoxe des coûts agentiques. Gartner a averti en août 2026 que le coût d'inférence des workflows agentiques sera multiplié par plus de cinq en deux ans, même si le prix des tokens baisse, car les agents consomment 5 à 30 fois plus de tokens qu'un chatbot pour une tâche équivalente.

Dans Odock, les budgets s'appliquent à une organisation, une équipe, un utilisateur ou une clé API, et sont appliqués avant l'appel upstream : la gateway estime le coût, le réserve sur chaque budget concerné, puis seulement appelle le provider. Quand une fenêtre est épuisée, l'agent reçoit un 402 budget_exceeded, pas une surprise sur la facture du mois suivant. Les quotas font de même pour le nombre de requêtes et de tokens.

Deux règles pratiques :

• Budgétez les équipes, pas les individus. Un budget d'équipe avec des sous-limites par clé pour les agents autonomes stoppe les boucles sans obliger les développeurs à demander la permission de travailler.
• Donnez aux agents autonomes leurs propres clés et des plafonds plus bas. Un agent CI qui relance indéfiniment un build en échec n'a pas le même profil de risque qu'un développeur qui travaille avec Claude Code.

Pour les agents qui tournent sans surveillance, ajoutez le template de flow intégré Agent identity and loop ceiling d'Odock. Il exige les headers x-odock-agent-id et x-odock-agent-iteration et arrête un agent qui dépasse un nombre de tours fixé, avant qu'il ne dépense plus de tokens.

Étape 3 : marquer chaque requête avec le travail qu'elle sert

C'est la pièce qui rend possible le coût par ticket résolu. L'outil du développeur envoie les headers x-repo et x-ticket (ou votre script d'enveloppe les déduit du nom de branche). Un petit flow Flow Studio fait le reste :

• Pre-route : un nœud Transform copie les headers dans les métadonnées de la requête, pour qu'ils voyagent avec les preuves de la requête.
• Post-response : un nœud Get Response Value lit la consommation de tokens, et un nœud Send Webhook envoie clé, équipe, modèle, tokens, statut, dépôt et ticket vers votre entrepôt. Le post-response s'exécute en asynchrone par défaut : aucune latence pour le développeur.

version: 1
name: Tag coding traffic with repo and ticket
on_error: continue
phases:
  pre_route:
    nodes:
      - {id: start, type: start}
      - id: tag
        type: transform
        config:
          target: request
          operations:
            - {op: set, path: metadata.repo, value: "{{request.headers.x-repo}}"}
            - {op: set, path: metadata.ticket, value: "{{request.headers.x-ticket}}"}
      - {id: end, type: end}
    edges:
      - {from: start, to: tag}
      - {from: tag, to: end}
  post_response:
    nodes:
      - {id: start, type: start}
      - {id: usage, type: response_get, config: {path: body.usage, var: usage}}
      - id: export
        type: webhook_send
        config:
          url: https://warehouse.example.com/hooks/ai-coding-usage
          payload:
            api_key_id: "{{request.api_key_id}}"
            model: "{{request.model}}"
            status: "{{response.status}}"
            usage: "{{vars.usage}}"
            repo: "{{request.headers.x-repo}}"
            ticket: "{{request.headers.x-ticket}}"
            at: "{{now}}"
      - {id: end, type: end}
    edges:
      - {from: start, to: usage}
      - {from: usage, to: export}
      - {from: export, to: end}

Les usage records d'Odock contiennent déjà, pour chaque appel, le principal (organisation, équipe, utilisateur, clé), le provider, le modèle, le statut, la latence, les tokens, le coût, la trace de routage et les résultats des plugins et de la sécurité, sans stocker ni prompts ni réponses. Le flow ajoute la clé métier nécessaire pour les croiser avec Jira et GitHub.

Étape 4 : mesurer les résultats, pas la production

Une fois la dépense marquée par ticket, la jointure dans l'entrepôt est simple. Les métriques qui méritent un tableau de bord sont celles qui, selon l'étude de Harvard, bougent vraiment, ou ne bougent pas :

Les lignes de code et le nombre de PR n'ont rien à faire sur ce tableau de bord. Tout l'enseignement de l'étude est qu'ils augmentent pendant que les résultats stagnent.

Étape 5 : investir les économies dans le vrai goulot

Si la revue est la contrainte, deux conséquences en découlent.

Router la génération vers le tier le moins cher qui fonctionne. Le routage Odock permet à une clé de définir des candidats, des stratégies et un failover, et un flow pre-route peut rétrograder les requêtes de type boilerplate vers un modèle plus petit. Un modèle de décision comme Jev, appelé depuis Flow Studio, peut classer une requête comme simple ou complexe en environ 100 ms. Voir notre article sur Jev et Flow Studio.

Mesurer la revue IA comme une charge à part entière. Donnez aux bots de revue de PR leurs propres virtual keys et budgets. Si 80 % des entreprises utilisent la revue IA mais que seuls 23 % des commentaires en proviennent, vous voulez savoir ce que cette dépense achète : commentaires acceptés, défauts détectés, temps de revue économisé.

Étape 6 : ne pas laisser les agents supprimer le goulot en supprimant la revue

Il existe un raccourci dangereux pour « corriger » le délai de merge : laisser les agents merger. Avec des serveurs MCP pour GitHub et la CI dans la boîte à outils de chaque agent, ce raccourci n'est qu'à un appel d'outil.

Odock gouverne le trafic MCP par clé :

• Les grants d'accès décident quelles clés peuvent appeler le serveur MCP GitHub ou CI.
• Les outils autorisés cantonnent les agents de code à leur travail : lire les tickets et les fichiers, créer des branches, ouvrir des pull requests, commenter.
• Les outils bloqués gardent les actions irréversibles chez les humains : merge, force-push, suppression de branche, modification des paramètres ou secrets du dépôt.
• Les filtres sémantiques inspectent les payloads des appels d'outils avant exécution.
• L'injection de l'auth upstream garde le token GitHub dans Odock : il n'apparaît jamais dans l'environnement d'un agent.
• Les usage records MCP attribuent chaque appel d'outil à une clé, un serveur, un outil, un statut et un coût.

Pour les actions parfois légitimes, comme un agent qui merge une mise à jour de dépendance dans un dépôt à faible risque, utilisez le template de flow intégré MCP external approval gate : il appelle votre service de policy avant les outils destructifs et échoue fermé si l'approbation est refusée ou indisponible.

Ce que les responsables techniques devraient faire ce trimestre

• Recenser chaque outil de code et chaque agent qui appelle directement un provider, y compris en CI.
• Émettre une virtual key par développeur et par agent autonome ; révoquer les clés provider partagées.
• Définir des budgets d'équipe avec des plafonds plus bas pour les agents sans surveillance ; activer le template de plafond de boucles.
• Ajouter les headers de dépôt et de ticket à la configuration des agents et déployer le flow de marquage.
• Croiser l'export avec Jira et GitHub et publier le coût par ticket résolu, pas les lignes de code.
• Restreindre le serveur MCP GitHub aux outils de lecture, de branche et d'ouverture de PR ; faire passer les merges par des humains ou une gate d'approbation.

Le résultat de Harvard n'est pas un argument contre les agents de code. C'est un argument contre leur exécution sous forme de trafic non géré et non mesuré. Dès que chaque requête porte une identité, un budget, un ticket et une trace, vous voyez où les agents créent de la valeur livrée et où ils ne créent que davantage de code à relire.

Sources

• AI Weekly, Harvard Study: AI Coding Agents Lift Code 30%, Shipped Output Flat
• Tech Insider, AI Coding Agents Add 30% More Code, Not Software
• n8nlab, AI Coding Agents Add Code, Not Software Output, Study Finds
• Superpower Daily, AI coding agents boosted code output without clear task completion gains
• Computerworld, AI inference is getting cheaper, but your agents are getting more expensive, 17 août 2026
• Endpoints natifs Odock
• Budgets Odock
• Usage records Odock
• Sécurité MCP dans Odock