ROI de Claude Code et Codex : les indicateurs à suivre dans une ESN

Mesurer le ROI de l'IA générative en développement logiciel consiste à comparer le coût total d'un résultat accepté, pas le nombre de lignes générées. Dans une ESN, Claude Code et Codex peuvent déplacer l'effort entre développement, revue et correction. Il faut donc observer toute la chaîne de livraison, puis distinguer capacité libérée et économie réellement réalisable.

Un développeur qui termine une tâche plus vite ne crée pas automatiquement du chiffre d'affaires supplémentaire. Le résultat dépend du contrat, du travail disponible et des goulets d'étranglement. La mesure doit être utile à la décision opérationnelle, sans transformer une estimation en résultat commercial.

Méthode et exemple chiffré pédagogiques, préparés avec assistance IA le 17 septembre 2026. Les chiffres ci-dessous sont fictifs et ne représentent pas des résultats clients. Illustration générée par IA.

Définir d'abord ce que signifie « accepté »

Une tâche acceptée respecte les critères métier et les contrôles du projet. Selon son risque, cela peut inclure une revue, des tests unitaires, une intégration et une validation fonctionnelle. Le statut doit être défini avant la mesure.

Le temps jusqu'à acceptation inclut les reprises. Si l'agent produit rapidement un correctif qui exige plusieurs cycles de revue, ces cycles font partie du résultat. Ne mesurez pas seulement la durée de génération.

Conservez aussi les tâches abandonnées ou revenues au traitement manuel. Les exclure donnerait une vision artificiellement favorable des agents et masquerait les types de missions où ils sont moins adaptés.

Les indicateurs à relever sur un pilote

Ajoutez des mesures qualitatives : facilité à comprendre le diff, capacité à reprendre le travail et fréquence des informations manquantes. Elles aident à expliquer les chiffres sans prétendre remplacer la mesure.

Évitez d'utiliser le nombre de prompts comme classement individuel. Un volume élevé peut indiquer une forte adoption, mais aussi un problème mal formulé ou des corrections répétées. La mesure vise à améliorer le processus, pas à récompenser une activité superficielle.

Construire une comparaison avant/après exploitable

Sélectionnez une famille de tâches assez homogène : correctifs d'un module, documentation technique ou tests d'une API. Relevez une période ou un échantillon de référence sans agent, puis appliquez les mêmes critères avec l'agent.

Notez les changements qui peuvent expliquer une différence : développeur plus expérimenté, dépendances réparées, tests ajoutés, sprint moins chargé ou meilleure spécification. Une amélioration observée en même temps que l'introduction de Codex ou Claude Code n'en prouve pas automatiquement la causalité.

Si possible, alternez les approches sur des tâches comparables. Pour comparer les produits entre eux, évitez de donner au second le résultat du premier. Le protocole comparatif pour ESN décrit cette séparation.

Présentez le nombre d'observations et leur dispersion. Avec quelques tickets, une médiane accompagnée des cas extrêmes est plus honnête qu'un pourcentage général appliqué à toute l'entreprise.

Exemple fictif : le gain apparent et le gain net

Supposons un lot de 20 tâches comparables. Sans agent, l'équipe consacre 100 heures au développement, à la revue et aux reprises. Avec agent, elle consacre 65 heures au développement, 20 heures à la revue et 10 heures aux reprises, soit 95 heures au total.

Le gain de capacité est de cinq heures sur ce lot, pas de 35 heures. La baisse du temps de développement a été partiellement absorbée par les autres étapes. Au taux interne hypothétique de 250 MAD par heure, la capacité libérée représente 1 250 MAD.

Si les coûts additionnels attribuables au lot sont de 2 000 MAD, le solde économique est de moins 750 MAD. Le ROI calculé sur cette hypothèse vaut (1 250 − 2 000) / 2 000, soit −37,5 %. Cet exemple volontairement défavorable montre pourquoi il faut compter l'ensemble du processus.

Le calcul reste une valorisation de capacité, pas une économie bancaire. Si les cinq heures sont simplement disponibles sans réduction de dépense ni travail utile supplémentaire, le gain financier réalisé est nul. À l'inverse, elles peuvent contribuer à réduire un retard si le reste de la chaîne permet de les exploiter.

Missions au forfait : protéger la marge et la qualité

Au forfait, une réduction réelle de l'effort total peut améliorer la marge, à condition de préserver la qualité et de ne pas augmenter les coûts de garantie ou de maintenance. Il faut donc suivre les défauts et retours après livraison.

Distinguez les heures économisées sur le périmètre contractuel des nouvelles fonctionnalités ajoutées sans facturation. Produire davantage de code non demandé n'améliore pas nécessairement la rentabilité. Cela peut au contraire augmenter les obligations de support.

La décision d'extension peut porter sur un type de ticket précis : par exemple, rédaction de tests sur un module bien documenté. Il n'est pas nécessaire de conclure que l'agent est rentable pour toutes les missions.

Missions en régie : ne pas confondre vitesse et revenu

En régie, une accélération ne se traduit pas mécaniquement par une hausse des montants facturés. Elle peut améliorer la qualité, la capacité de livraison ou la satisfaction du client, mais son effet commercial dépend du contrat et de la relation.

Respectez les règles de déclaration du temps et les engagements de transparence. Les outils utilisés ne justifient pas une déclaration fictive d'effort. Si le modèle économique évolue vers des livrables ou des objectifs, cette évolution doit être discutée et contractualisée.

Le bon indicateur peut alors être le délai de résolution ou la diminution des reprises, plutôt qu'une économie de jours vendus. Décidez avec le responsable de mission ce qui constitue de la valeur pour le client et pour l'ESN.

Intégrer le coût de lancement sans fausser l'exploitation

La formation et la configuration peuvent peser fortement sur le premier mois. Présentez-les séparément du coût récurrent, puis indiquez l'horizon d'amortissement retenu. Évitez de faire disparaître ces dépenses du calcul final.

Les simulations de budget pour 10, 30 et 100 développeurs donnent une structure de calcul. Remplacez les hypothèses par des factures et relevés réels ; ne mélangez pas crédits, dollars et dirhams sans règle de conversion datée.

Pour collecter l'usage, consultez les outils de suivi décrits dans la documentation Claude Code et les règles de consommation OpenAI. Les chiffres d'activité ne remplacent pas les données de livraison de votre projet.

La décision à la fin du pilote

Poursuivez lorsque la qualité reste acceptable, les risques sont maîtrisés et la valeur observée justifie les coûts. Ajustez lorsque le bénéfice se concentre sur certains usages. Arrêtez lorsque les reprises, incidents ou contraintes contractuelles rendent le dispositif inadapté.

Une synthèse doit montrer les résultats positifs et négatifs, les limites de l'échantillon et les conditions nécessaires pour reproduire l'expérience. Elle doit aussi préciser une date de réexamen, car outil, modèle et organisation peuvent évoluer.

Questions fréquentes

Peut-on promettre un pourcentage de productivité avant le test ?

Pas sur la base de cette méthode. Le résultat dépend des tâches, des personnes et des contrôles. Fixez une hypothèse à évaluer, pas un gain garanti.

Faut-il mesurer chaque développeur séparément ?

La mesure par type de tâche et par équipe est souvent plus utile pour décider du déploiement. Toute collecte nominative doit être justifiée et encadrée selon les règles de l'organisation.

Une augmentation du temps de revue signifie-t-elle un échec ?

Pas toujours. Elle peut être compensée par une meilleure qualité ou une baisse d'autres coûts. Il faut examiner l'effort total et les défauts, pas isoler un indicateur.

Lancer un pilote avec mesure avant/après

Hunter BI propose de définir avec votre ESN les tâches, la référence, les critères d'acceptation et le tableau de suivi. Le livrable est un dossier de décision fondé sur vos observations.

Demander un pilote Claude Code ou Codex avec mesure du ROI. Préparez également les conditions de sécurité et gouvernance avant de démarrer.