Le débit des agents de développement logiciel se mesure à travers deux chiffres indissociables : les pull requests mergées et le taux de rejet (denial rate), c'est-à-dire la part des pull requests fermées sans avoir été fusionnées. Ajoutez-y le temps de cycle de la conception du plan jusqu'au merge ainsi que le coût par pull request mergée, et vous disposez de tous les éléments pour déterminer si les agents produisent du travail accepté à un coût financièrement défendable. Le nombre de pull requests ouvertes, la métrique que la plupart des équipes mettent en avant en premier, est trompeur à lui seul : un agent peut ouvrir cinquante pull requests par jour que personne ne mergera jamais, et ce volume ressemblera faussement à du progrès. Cet article définit chaque indicateur, détaille ce qu'indique un mauvais résultat et montre comment Ivy Tendril ainsi qu'un calculateur gratuit d'Ivy permettent de les mesurer avec précision.

Les métriques

Métrique	Définition	Ce qu'indique un mauvais résultat
PR ouvertes	Pull requests créées au cours de la période	En soi, rien. Un chiffre élevé et en hausse avec des merges stagnants signifie que les agents produisent du travail dont l'équipe ne veut pas
PR mergées	Pull requests mergées au cours de la période	Stagnant ou en baisse alors que les ouvertures grimpent : la revue de code est le goulot d'étranglement, ou la qualité chute
Taux de rejet	PR fermées sans merge, divisées par le total des PR fermées (mergées plus fermées non mergées)	Élevé : les plans sont erronés, la vérification est insuffisante ou les relecteurs rejettent trop tard. Proche de zéro avec un volume faible : seul le travail sans aucun risque est tenté
Temps de cycle	Temps écoulé entre la création du plan et le merge	Long : le travail stagne à un point de contrôle humain. Découvrez lequel
Coût par PR mergée	Total des tokens ou des dollars sur la période, divisé par les PR mergées	En hausse : réexécutions (retries), plans surdimensionnés ou modèle trop cher alors qu'un modèle plus abordable réussirait la vérification
Taux de réussite de la vérification	Part des exécutions qui réussissent les tests, le lint et le build dès la première tentative	Faible : les plans sont sous-spécifiés ou l'agent manque de contexte sur le codebase

Deux définitions appellent une attention particulière. Le taux de rejet retient les PR fermées comme dénominateur — et non les PR ouvertes —, afin que les pull requests ouvertes encore en cours de relecture ne soient comptabilisées ni comme acceptées ni comme refusées. Le coût par PR mergée divise la totalité des dépenses engagées — y compris celles consacrées aux plans rejetés ou abandonnés — uniquement par les pull requests effectivement mergées. Ce choix est délibéré : le coût du travail rejeté fait partie intégrante du coût du travail mergé.

Pourquoi PR mergées et taux de rejet forment le binôme de vérité

Toute métrique isolée peut être artificiellement améliorée en dégradant une autre métrique.

Les PR ouvertes augmentent dès que l'on assouplit les critères d'exécution. Le taux de rejet augmente simultanément.
Les PR mergées augmentent lorsque les relecteurs approuvent trop vite. Les régressions détectées après le merge se multiplient, et le taux de rejet baisse pour de mauvaises raisons.
Le taux de rejet baisse si l'on ne confie aux agents que les plans les plus triviaux. Le volume de PR mergées s'effondre en conséquence.

Il s'agit du même principe qui sous-tend les métriques DORA, où débit et stabilité sont systématiquement présentés en binôme, précisément parce qu'un chiffre isolé peut être manipulé en sacrifiant l'autre. Analysés ensemble, le nombre de PR mergées et le taux de rejet résistent à cette dérive. Pour accroître les merges sans faire grimper le taux de rejet, il faut produire davantage de code que l'équipe juge acceptable. Pour faire baisser le rejet sans réduire les merges, il convient d'améliorer la formulation des plans ou la vérification automatisée, plutôt que de restreindre l'exécution. Aucun des deux indicateurs ne peut être optimisé au détriment de l'autre.

Le volume de PR ouvertes est séduisant car c'est la première production concrète d'un agent et la plus simple à comptabiliser. Pourtant, une pull request ouverte n'est qu'une sollicitation du temps d'autrui. Comptabiliser de simples demandes comme une production valorise les agents qui encombrent les relecteurs. Mesurer les merges valorise les agents qui finalisent le travail avec succès.

Ivy publie ses propres indicateurs selon cette rigueur. Le graphique des PR par jour en fonction du taux de rejet présenté sur la page Pourquoi Ivy a été établi à partir de 1 946 pull requests réparties sur les dépôts d'Ivy entre février et avril 2026. Ivy y démontre que son équipe est passée d'environ 10 à plus de 100 pull requests quotidiennes après avoir adopté le flux formalisé de planification, d'exécution, de vérification et de revue qu'elle nomme une software factory. Ce volume est affiché en vis-à-vis direct du taux de rejet, car sans lui, il ne prouverait absolument rien.

Coût par PR mergée et taux de réussite de la vérification

Une fois les merges et le taux de rejet sous contrôle, le coût par pull request mergée révèle ce que coûte réellement le travail validé. C'est l'indicateur clé attendu par un CTO, et il doit impérativement s'exprimer en dollars ou en tokens par modification mergée — et non par plan ou par exécution élémentaire —, de manière à intégrer les réessais et le code rejeté.

Le coût par pull request mergée est également l'indicateur qui matérialise les effets d'engorgement : selon la loi de Little, un backlog grandissant de pull requests ouvertes à un rythme de merge constant implique une augmentation du temps de cycle, que celle-ci soit mesurée ou non. Trois leviers influent sur le coût par PR mergée :

Les réexécutions (Retries). Chaque échec de vérification impose un nouveau cycle d'exécution. Le taux de réussite de la vérification constitue l'indicateur avancé ; lorsqu'il chute, le coût par PR mergée progresse quelques jours plus tard. L'article Portes de vérification détaille les éléments à tester et explique pourquoi la porte de plan initiale est la plus déterminante.
La taille des plans. Les plans volumineux coûtent plus cher à l'exécution et sont rejetés plus fréquemment, le relecteur y trouvant plus matière à contestation. Découper un plan en unités plus restreintes réduit généralement à la fois le taux de rejet et le coût par PR mergée, au prix d'un nombre accru de pull requests à relire.
Le choix du modèle. Un modèle plus économique qui franchit la vérification avec un taux de succès équivalent représente une économie immédiate. La seule méthode pour s'en assurer consiste à tracer les coûts et les taux de succès par plan afin de comparer les modèles sur le même code source.

Pour analyser la transition globale de la mesure de l'activité du développeur vers celle de la production acceptée, consultez In the loop, out of the loop: the KPI shift behind agentic engineering.

Comment Ivy Tendril assure le suivi de ces métriques

Ivy Tendril est une application de bureau local-first (macOS, Windows, Linux) qui orchestre les agents de code du plan initial jusqu'à la pull request validée. Elle consigne les données de chaque métrique mentionnée ci-dessus directement au fil de l'exécution, sans nécessiter la moindre instrumentation séparée.

Dashboard. Le Dashboard synthétise l'état des plans tout au long de leur cycle de vie, les KPI de coût, un graphique d'évolution dans le temps et l'activité Git pour les dépôts connectés. L'état du plan fournit les PR ouvertes, mergées et rejetées ; l'activité Git retrace l'historique complet des fusions.
Coût par plan et par tâche (job). Les tokens et les dépenses financières sont comptabilisés pour chaque plan et pour chaque tâche au sein de ce plan. Un plan ayant nécessité trois cycles d'exécution avant de satisfaire à la vérification affiche l'ensemble des trois, de sorte que le coût par PR mergée intègre structurellement les réexécutions. L'écran Jobs diffuse en continu les flux de sortie et les appels d'outils de chaque tâche en regard de ses coûts.
Comparaison par agent et par modèle. Tendril exécute Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode ou n'importe quel autre agent en ligne de commande. Le choix de l'agent et du modèle s'effectue plan par plan. Il devient ainsi trivial de comparer les coûts et la viabilité de différents modèles sur un même projet sans modifier le workflow.
Données locales. Les plans, journaux et historiques de coûts demeurent sur votre machine. Les seuls appels sortants s'adressent à l'API du modèle que vous avez configurée et à GitHub.

Pour les équipes qui n'utilisent pas encore Tendril, Ivy met à disposition un PR Cost Calculator gratuit et open source. Il analyse les données publiques GitHub d'un dépôt et calcule la moyenne mobile sur 14 jours des PR mergées et du taux de rejet, permettant d'établir une référence avant toute transformation. Lancez-le dès aujourd'hui sur votre dépôt, puis renouvelez la mesure un mois après avoir introduit les agents.

Guide de démarrage

Établissez votre point de référence : exécutez le PR Cost Calculator sur votre dépôt principal et relevez la moyenne mobile sur 14 jours des PR mergées et du taux de rejet.
Installez Tendril : curl -sSf https://cdn.ivy.app/install-tendril.sh | sh (macOS, Linux) ou irm https://cdn.ivy.app/install-tendril.ps1 | iex (Windows). Documentation accessible sur l'installation.
Exécutez des plans pendant deux semaines et analysez le Dashboard : volumes mergés, refusés, coût par plan et tendances.
Calculez manuellement le coût par PR mergée une première fois en divisant la dépense globale par le nombre de PR mergées, afin que l'équipe s'accorde sur cette définition avant qu'elle ne devienne un rapport officiel.

Tendril est gratuit et disponible en code source consultable sous licence Functional Source License. Les fonctionnalités d'équipe, l'hébergement on-premise, le SSO et l'import de résultats de CI sont proposés dans les forfaits Pro (59 $ par utilisateur et par mois) et Enterprise.

Foire aux questions

Qu'est-ce qu'un bon taux de rejet ?

Il n'existe aucun seuil standardisé, et un taux de zéro pour cent signifie généralement qu'aucune tâche comportant le moindre risque n'est entreprise. Observez l'évolution de votre propre taux au fil du temps et considérez une hausse comme une incitation à examiner la pertinence des plans et de la vérification, non comme un prétexte pour restreindre artificiellement les exécutions.

Le coût par PR mergée doit-il inclure le temps de relecture humaine ?

Ajoutez-le dès lors que vous êtes en mesure de le mesurer de façon reproductible. La plupart des équipes débutent avec la consommation de tokens et la facture des modèles d'IA, car ces valeurs sont relevées automatiquement, puis intègrent le temps d'ingénierie une fois le mode de calcul stabilisé. Concaténer les deux approches sans convention préalable rend les comparaisons mensuelles incertaines.

En quoi ces métriques diffèrent-elles des métriques DORA ?

Elles se recoupent en partie. Le temps de cycle du plan au merge est proche du délai d'exécution des modifications (Lead Time for Changes). Le taux de rejet ne possède pas d'équivalent direct dans DORA, car ce dernier présuppose qu'un développeur humain a écrit le code et s'intéresse principalement à sa mise en production. Le taux de rejet s'interroge quant à lui sur l'acceptabilité même de la modification — une question qui devient centrale dès lors que les agents génèrent les propositions.

Premiers pas avec Ivy Tendril

Prêt pour une orchestration d'agents parallèle au niveau développeur ?

Explorer le code: Découvrez Ivy Tendril sur GitHub (Open Source).
Consulter la documentation: Trouvez des guides d'intégration sur tendril.ivy.app.
Planifier une session d'architecture: Contactez renco@ivy.app pour une consultation technique de 30 minutes.

Mesurer le débit des agents de code : PR mergées, taux de rejet et coût par PR