Mesurer l'IA dans une équipe tech : usages, dépenses et résultats

L'adoption des assistants de code est désormais quasi générale. Le rapport DORA 2025 de Google indique que 90 % des professionnels interrogés utilisent l'IA dans leur travail et que plus de 80 % estiment qu'elle a accru leur productivité. La mesure, elle, ne suit pas : selon l'AI Impact Report de LeadDev, réalisé avec DX auprès de plus de 880 responsables engineering et publié en août 2025, seules 18 % des organisations mesurent l'impact des outils d'IA sur leurs équipes de développement.

Cet écart tient en partie à une confusion. Les premiers chiffres disponibles sont ceux que fournissent les outils eux-mêmes : comptes actifs, suggestions acceptées, tokens consommés. Faciles à obtenir, ils décrivent pourtant une diffusion et une consommation, pas un effet sur la livraison ou sur le produit.

DORA 2025 explique pourquoi l'effet ne se déduit pas de l'usage : l'IA agit comme un amplificateur. Elle renforce les équipes solides et accentue les difficultés des autres, et son adoption est associée à un débit plus élevé mais aussi à une stabilité de livraison plus faible. Sans indicateurs propres aux résultats, une organisation ne sait pas dans quel cas elle se trouve.

De nos échanges avec la direction technique d'un grand groupe et celle d'une scale-up, une conclusion s'est dégagée : usages, dépenses et résultats doivent rester trois objets distincts. Chacun répond à une question différente et appelle ses propres indicateurs.

• Les usages : qui se sert de l'IA, pour quelles tâches, avec quel niveau de pratique. Ils servent à cartographier et à accompagner les équipes.
• Les dépenses : ce que coûtent les licences, les tokens et les configurations. Elles servent à repérer les inefficacités et à arbitrer entre modèles.
• Les résultats : ce qui change dans la livraison, la qualité et le produit. Ce sont les seuls indicateurs qui disent si l'effort en vaut la peine.

Cette séparation rejoint les cadres publics. L'AI Measurement Framework de DX, signé par Abi Noda et Laura Tacho, organise la mesure autour de trois dimensions : utilisation, impact et coût. Pour l'impact, il s'appuie sur des mesures de productivité plus générales, comme DX Core 4, qui équilibre quatre dimensions (vitesse, efficacité, qualité, impact sur l'activité), ou le framework SPACE, publié en 2021 dans ACM Queue par Nicole Forsgren et ses coauteurs, selon lequel la productivité des développeurs ne peut pas être mesurée par un indicateur unique.

Ces dirigeants en tirent une règle simple : ne jamais lire une courbe d'adoption comme une courbe de valeur, car un nombre d'utilisateurs mesure une diffusion, pas un effet.

Chaque indicateur a un usage légitime et une limite. Le tableau suivant reprend la grille discutée avec ces directions techniques.

La dernière ligne appelle une précision. Un coût par tâche ne se compare qu'à charge de travail comparable, donc à niveau de compétence comparable : une même tâche confiée à un profil qui maîtrise ses outils et à un profil qui les découvre ne consomme pas la même chose.

Des dirigeants avec qui nous avons échangé ont abandonné certaines de leurs premières mesures à cause de leurs effets sur les comportements : une activité mesurée attirait l'effort au détriment d'autres dimensions du travail. C'est le mécanisme résumé par la loi de Goodhart : lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure.

Les cadres publics font la même mise en garde. DX déconseille explicitement d'utiliser ses métriques pour évaluer la performance individuelle et note que des indicateurs comme le volume de code généré sont particulièrement faciles à manipuler. Pour DX Core 4, les mesures de vitesse et de débit, prises isolément, suscitent souvent de la crainte et des comportements contre-productifs ; elles doivent être contrebalancées par des mesures d'expérience développeur et ne jamais être liées à des objectifs ou à des récompenses.

Mesurer le dispositif consiste à suivre ce qui dépend de l'organisation : la configuration des outils, le choix des modèles selon l'usage, le temps de cycle d'une équipe, la stabilité des livraisons, le ressenti des développeurs.

Le prix affiché par million de tokens dit peu de chose de la dépense finale. Nos échanges ont mis en évidence un écart de dépense d'un facteur 3 entre deux modèles au prix proche par million de tokens. L'explication avancée tient au comportement des modèles : leur volume de raisonnement, leurs boucles et leurs appels d'outils.

La documentation officielle des fournisseurs éclaire ce mécanisme. Chez Anthropic, les tokens qu'un modèle consomme en réfléchissant sont facturés comme des tokens de sortie, et la facturation porte sur la totalité du raisonnement, même lorsque seul un résumé est affiché : le nombre de tokens facturés ne correspond donc pas à ce que l'utilisateur voit. Les blocs de raisonnement des tours précédents, conservés dans le contexte, sont en outre facturés comme des tokens d'entrée. Un agent qui enchaîne les appels d'outils paie ainsi, à chaque tour, un contexte qui grossit.

Le coût dépend aussi de la configuration. Un travail FinOps évoqué lors de nos échanges a montré qu'un grand nombre d'outils pouvaient être chargés dès le début d'une requête, avant même que le modèle ne commence à travailler. Chaque définition d'outil occupe du contexte, donc des tokens, à chaque appel.

• Le coût total d'une tâche représentative, du premier appel à la réponse finale, plutôt que le prix unitaire du token.
• La part des tokens de raisonnement dans la sortie, que les API exposent dans leurs données d'usage.
• Le nombre d'itérations et d'appels d'outils nécessaires pour terminer la tâche.
• Le niveau d'effort ou de raisonnement configuré, qui se règle usage par usage.

Un grand groupe avec qui nous avons échangé attribue un quota mensuel par défaut de 150 dollars par utilisateur. Ce montant est jugé suffisant pour encourager l'adoption, mais insuffisant pour les usages intensifs comme le développement guidé par les spécifications. Des plafonds étendus, validés selon le projet, atteignent 850 dollars par mois. Il s'agit de limites autorisées, pas de consommations constatées.

Le quota produit un effet utile : il incite chacun à examiner ses pratiques. Un dépassement révèle souvent un modèle trop coûteux pour la tâche, une skill d'agent à améliorer ou un traitement qui boucle. Ces dirigeants proposent donc de traiter le quota comme un signal FinOps plutôt que comme une limite. Le risque inverse existe : une personne bloquée peut poursuivre son travail sur un outil extérieur et y transférer des données de l'entreprise. Un plafond trop serré déplace alors la dépense hors du périmètre visible.

Pour ne dépendre ni d'un seul modèle ni d'une seule offre, ces directions techniques décrivent plusieurs leviers, à des stades différents :

• Une passerelle IA multimodèle, qui permet de changer de modèle sans changer d'outil.
• Des restrictions par clé et par usage, qui réservent les modèles les plus coûteux aux tâches qui les justifient.
• Des forfaits avec limites par plages horaires, moins coûteux, mais au prix d'une visibilité détaillée perdue sur les usages.
• La prudence face aux offres fournisseur engageantes, pour préserver la liberté d'expérimentation.

Certains dirigeants s'attendent à une hausse des prix, raison de plus pour garder des alternatives.

La gouvernance de l'IA recouvre deux sujets que nos interlocuteurs ont pris soin de distinguer : les données confiées aux modèles et les traces d'usage laissées par les collaborateurs.

Les données confiées aux modèles relèvent d'abord des exigences des clients. Les grands comptes demandent des garanties sur la localisation des données et sur leur non-utilisation pour l'entraînement. Les directions techniques y répondent par une plateforme d'accès aux modèles correctement configurée, par des accès à certains modèles réservés aux tests et par des outils d'entreprise accompagnés de sensibilisation, pour limiter les services personnels, sans garantie technique. Les exigences de l'AI Act restent à réévaluer pour certains de ces accès.

Les traces d'usage posent une autre question : jusqu'où regarder ce que font les collaborateurs ? La collecte de logs peut aller jusqu'aux prompts, pour analyser des usages techniques, tandis qu'un dirigeant a exprimé une réserve sur la possibilité de lire les prompts des salariés. Mieux vaut donc préciser le cadre d'accès aux prompts (périmètre, droits, conservation) avant d'élargir la collecte.

Ces questions concernent aussi les profils externes. Lorsque nous évaluons un freelance, nous regardons comment il pilote sa propre consommation : choix du modèle selon la tâche, niveau de raisonnement, gestion du contexte et respect des outils autorisés par le client.