IA en entreprise : mesurer l’impact, pas les tokens
Découvrez pourquoi Amazon déconseille le « tokenmaxxing » et comment mesurer l’apport réel de l’IA au travail des équipes de développement.
Amazon face au « tokenmaxxing » : l'IA ne se mesure pas au volume consommé
Un développeur qui utilise davantage d'IA est-il forcément plus productif ? La question paraît simple, mais elle piège vite le pilotage. On peut multiplier les requêtes, générer plus de code, afficher un taux d'adoption flatteur... sans livrer plus vite, sans réduire les incidents et, parfois, sans mieux répondre aux besoins des clients.
Dans une note interne diffusée en septembre puis publiée par Amazon en octobre 2026, l'entreprise met en garde ses équipes contre le « tokenmaxxing » : l'usage intensif d'outils d'IA, parfois surtout pour montrer qu'on "tourne", plutôt que pour produire un résultat vraiment utile. Amazon ne demande pas d'arrêter l'IA. Le message est plutôt : choisir les cas d'usage avec discernement et évaluer les résultats dans la durée.
Ce point de vue pose un problème plus large que les seules grandes entreprises tech : comment distinguer l'adoption d'un outil de sa valeur réelle ? Voici ce que la note d'Amazon apporte, pourquoi les indicateurs "d'usage" trompent souvent, et comment décider concrètement où l'IA mérite du temps, du budget et de la confiance.
Pourquoi le tokenmaxxing est-il un mauvais indicateur
Le « tokenmaxxing », c'est maximiser l'usage des modèles d'IA - donc le volume de données traitées ou générées - sans vérifier que cet usage améliore réellement le travail. Le terme évoque une course au compteur : plus de requêtes, plus de génération, plus de code produit. Mais consommer des ressources ne dit rien sur la valeur produite.
C'est le point central de la note d'Amazon. L'entreprise estime que l'usage de jetons, le rythme d'adoption et le volume de code généré ou examiné deviennent des mesures trop imparfaites quand on les utilise seules pour juger une équipe. Pire : elles peuvent encourager des comportements qui augmentent la consommation et la complexité, sans résoudre de problème important.
Le compteur peut changer le comportement
Quand un indicateur devient une cible, les équipes finissent par optimiser... l'indicateur. Si l'on récompense le nombre de requêtes, certains ingénieurs ont intérêt à en produire plus, même quand quelques requêtes mieux préparées suffiraient. Amazon a d'ailleurs fermé en mai un classement interne après avoir constaté que des salariés cherchaient à maximiser leur consommation pour progresser dans le palmarès.
Ce phénomène n'est pas propre à l'IA. On le retrouve dès qu'une mesure "indirecte" devient un objectif individuel. Une hausse du nombre de lignes de code, par exemple, ne garantit ni une meilleure fonctionnalité ni un logiciel plus fiable. Avec l'IA, le risque est aggravé : il devient facile de générer plus de texte ou plus de code, même si ce n'est pas forcément la bonne direction.
Le coût n'est pas le seul problème
Oui, les dépenses d'inférence comptent. Mais une génération inutile mobilise aussi du temps de vérification, peut augmenter la surface de code à maintenir et déclenche parfois des corrections supplémentaires. Au final, le coût réel inclut les jetons, le temps humain, les erreurs, la revue et les conséquences opérationnelles.
Cela ne veut pas dire que les métriques d'usage doivent disparaître. Amazon ne demande pas de les ignorer : elles doivent être interprétées avec prudence, puis croisées avec d'autres données. Elles peuvent signaler une adoption ou un coût inhabituel, mais elles ne suffisent pas, à elles seules, à dire si l'investissement est rentable.
Pourquoi les métriques d'adoption ne suffisent-elles pas
Au moment où l'on déploie un outil d'IA, les premiers chiffres sont souvent ceux qu'on récupère le plus facilement : nombre de comptes actifs, volume de requêtes, code suggéré, fréquence d'utilisation, taux d'acceptation. Ces données sont utiles pour vérifier que l'outil est accessible et effectivement utilisé.
Le problème, c'est quand on les traite comme une preuve de productivité.
Une équipe peut adopter rapidement un assistant de programmation simplement parce qu'il est bien intégré. Ça ne prouve pas que les délais de livraison baissent. De même, un développeur peut accepter une suggestion, puis passer du temps à la comprendre, la corriger ou la sécuriser. Le taux d'acceptation ne capture pas ce travail "en aval".
L'adoption mesure un comportement, pas un résultat
Pour piloter un investissement, il faut distinguer trois niveaux :
- L'activité : requêtes envoyées, outils ouverts, code proposé ou relu.
- Le flux de travail : temps passé à réaliser une tâche, à examiner les changements, à corriger les erreurs.
- Le résultat : fonctionnalité livrée, fiabilité, satisfaction client, coût de maintenance ou délai de mise en production.
Ces niveaux se recoupent parfois, mais ils ne sont pas interchangeables. Plus d'activité peut aller avec une amélioration, ne rien changer, ou même dégrader le flux de travail. Sans mesurer le résultat, on ne sait pas lequel de ces scénarios se produit.
Les comparaisons brutes sont rarement équitables
Comparer des personnes uniquement sur leur consommation d'IA, c'est souvent injuste. Les équipes ne travaillent pas nécessairement sur les mêmes produits, avec les mêmes langages, les mêmes contraintes de sécurité ou le même niveau d'incertitude. Une tâche de migration répétitive se prête mieux à l'assistance automatisée qu'une décision d'architecture liée à des exigences métier encore floues.
Le contexte compte aussi beaucoup dans les entreprises françaises et européennes. Un outil peut être pertinent pour produire des tests sur un dépôt peu sensible, et totalement inadapté pour traiter des données personnelles ou du code confidentiel. La conformité au RGPD, les règles internes de sécurité et les conditions d'hébergement doivent peser dans la décision dès le départ, pas être "rattrapées" après coup.
La vraie question n'est donc pas « qui utilise le plus l'IA ? », mais « dans quelles situations l'usage améliore-t-il un résultat sans créer d'autres problèmes ? ». Sinon, on finit par transformer un indicateur d'activité en jugement simpliste sur les individus.
Comment mesurer la contribution réelle de l'IA
Amazon met en avant des indicateurs orientés vers le résultat, notamment la « vitesse des fonctionnalités » : le nombre de lancements et de changements réussis en production. Marc Brooker, dirigeant et ingénieur chez Amazon Web Services, décrit cette approche comme un retour sur investissement : l'entreprise investit des outils, du temps, des jetons et des efforts humains seulement quand un problème client ou métier le justifie.
On peut transposer le principe, mais attention : copier un indicateur sans regarder le contexte, c'est une recette pour se tromper. Publier plus de changements ne veut pas forcément dire qu'on performe davantage, surtout si les incidents augmentent, si les fonctionnalités sont peu utilisées ou si la maintenance coûte plus cher.
Définir le résultat avant de choisir la métrique
Avant de choisir quoi mesurer, formulez d'abord le problème à résoudre. Par exemple : « réduire le délai de rédaction des tests pour des changements à faible risque, sans augmenter les régressions ». Cette phrase donne à la fois un résultat attendu et une limite claire.
Ensuite, ajoutez quelques mesures complémentaires :
- Délai : temps entre le début du travail et la mise à disposition du changement.
- Qualité : défauts après livraison, corrections, retours arrière.
- Charge de revue : temps nécessaire pour vérifier les propositions générées.
- Valeur métier : utilisation de la fonctionnalité, résolution d'un irritant client, ou réduction d'une tâche opérationnelle.
- Coût complet : dépenses d'outils, temps de vérification, effort de maintenance.
Pas besoin de construire un tableau de bord géant. Quelques indicateurs bien définis, suivis avant et après une expérimentation, valent mieux qu'une avalanche de chiffres impossibles à interpréter.
Établir une comparaison crédible
La mesure doit porter sur des tâches comparables. Une équipe peut sélectionner un ensemble de tickets récurrents, documenter leur niveau de difficulté, puis observer leur traitement avec et sans assistance. Il faut aussi tenir compte de la variabilité : disponibilité des personnes, changements de périmètre, incidents, ou différences de qualité dans les données d'entrée.
Dans la réalité, toutes les équipes ne peuvent pas conduire une expérience parfaitement contrôlée. Une comparaison prudente "avant/après" reste possible si les limites sont explicites. L'objectif n'est pas de "prouver" à tout prix que l'IA marche, mais de comprendre dans quelles conditions elle apporte un gain, pour quels types de tâches et à quel coût.
Et surtout : regardez les effets secondaires. Une livraison plus rapide qui augmente les incidents, ou qui repousse la charge sur l'équipe de maintenance, n'est pas un gain net. On juge la productivité utile sur le cycle complet, pas uniquement au moment où le code sort.
Quand faut-il utiliser l'IA dans le développement logiciel
La note d'Amazon formule une idée qui mérite d'être entendue : si le travail d'un ingénieur ne bénéficie pas des outils d'IA disponibles, c'est un constat, pas un échec. Autrement dit, pas d'obligation d'usage uniforme. Les outils actuels ne sont pas tous adaptés à chaque tâche, et le jugement professionnel consiste aussi à savoir quand il vaut mieux s'en passer.
Repérer les tâches où l'assistance est plausible
L'IA vaut souvent le coup quand la tâche est bien délimitée, que le résultat peut être contrôlé, et que l'échec reste raisonnablement peu coûteux. Cela peut concerner la génération d'une première version de tests, l'explication de code existant, la préparation d'une documentation technique, ou la transformation d'un format répétitif.
Mais ces exemples ne garantissent pas un gain. Un assistant peut accélérer une première ébauche tout en ajoutant un passage de vérification. Le bénéfice dépend de la qualité du contexte fourni, de la familiarité de l'équipe avec le domaine, et du coût d'une erreur. Dans tous les cas, il faut tester le flux complet - pas seulement la génération.
Identifier les situations où l'humain doit rester central
L'IA est moins pertinente quand le besoin est ambigu, quand les conséquences d'une erreur sont importantes, ou quand le résultat est difficile à vérifier. Les décisions d'architecture, les règles métier sensibles, et tout ce qui touche à la sécurité demandent une responsabilité claire. L'IA peut aider à explorer des options, mais elle ne doit pas brouiller la chaîne de validation.
La confidentialité impose aussi des limites. Avant d'envoyer du code, des journaux ou des données à un service, l'équipe doit savoir quelles informations peuvent partir, quel fournisseur est impliqué, et quelles règles de conservation s'appliquent. En Europe, le RGPD devient rapidement une contrainte dès qu'un traitement implique des données personnelles ; les politiques de sécurité et les obligations contractuelles peuvent aller plus loin.
Autoriser le non-usage argumenté
Une règle opérationnelle simple aide beaucoup : demander d'expliquer le choix, pas de justifier un quota. Pour une tâche donnée, l'équipe peut documenter : le résultat recherché, l'aide attendue de l'outil, le risque, la manière de vérifier, et le critère d'arrêt. Si l'outil ne produit aucun gain ou génère trop de corrections, l'équipe doit pouvoir arrêter l'usage sans être pénalisée pour "retard".
C'est aussi une condition pour obtenir des retours honnêtes. Si les salariés pensent que leur évaluation dépend du volume d'IA consommé, ils auront peu d'intérêt à signaler les usages inefficaces. Une politique qui valorise le discernement produit des informations plus fiables qu'une injonction à "utiliser l'outil partout".
Comment organiser une expérimentation utile
L'enjeu n'est pas de lancer un grand programme d'adoption à l'échelle de l'entreprise avant de savoir ce qui fonctionne. Une expérimentation bien cadrée limite les coûts, fait ressortir les risques, et permet de distinguer un gain réel de l'enthousiasme initial. Elle peut être courte, à condition de couvrir assez de tâches pour éviter de conclure sur un cas isolé.
Une méthode en cinq étapes
- Choisir un problème concret. Évitez les formulations vagues comme « utiliser davantage l'IA ». Visez un problème opérationnel identifiable : retards sur les tests, documentation obsolète, ou répétition de tâches de maintenance.
- Délimiter les tâches concernées. Dites précisément ce qui est inclus, quelles données sont autorisées et quels cas restent exclus. Cela évite que l'expérimentation dérive vers des usages risqués ou impossibles à comparer.
- Définir le résultat et les garde-fous. Fixez un indicateur principal (délai, qualité ou coût) et ajoutez quelques limites, par exemple l'absence de hausse des incidents ou de la charge de revue.
- Comparer avec une référence. Mesurez le processus actuel avant de déployer l'outil, puis suivez les mêmes types de tâches. Notez aussi les difficultés et le temps de vérification, pas seulement le temps passé à générer.
- Décider de la suite. Étendre si le bénéfice est reproductible et compatible avec les règles de sécurité ; ajuster si les résultats restent mitigés ; arrêter si le coût ou le risque dépasse la valeur observée.
Séparer le pilotage de l'évaluation individuelle
Les indicateurs d'adoption peuvent être utiles pour une équipe produit ou sécurité : comprendre où l'outil est utilisé et où naissent les coûts. Ils deviennent plus problématiques quand ils servent à classer des personnes ou à fixer des quotas individuels. Dans ce cas, ils déforment les comportements et dégradent la qualité des retours.
Les managers devraient plutôt regarder les résultats du flux de travail et les obstacles rencontrés. Cela suppose de discuter avec les développeurs : un chiffre seul ne dit pas toujours si une proposition est difficile à relire, ou si l'outil ne comprend pas les conventions du projet.
Calculer le retour sur investissement complet
Le coût d'un cas d'usage ne se limite pas à la facture du fournisseur. Il inclut la configuration, l'intégration, la formation, la revue du code, les corrections, la gouvernance et l'entretien des usages. En face, le bénéfice doit être formulé dans des termes utiles : capacité libérée pour des tâches plus importantes, délai réduit, qualité améliorée ou meilleure expérience client.
Amazon ne propose pas, dans sa note, une formule universelle de calcul. C'est logique : le retour dépend de la tâche et du contexte. La discipline consiste à rendre les hypothèses visibles, à suivre les effets dans le temps, et à accepter qu'un outil efficace pour une équipe puisse ne pas l'être ailleurs.
Conclusion : piloter les résultats, pas l'activité
La position d'Amazon ne revient pas à freiner l'adoption de l'IA. Elle rappelle simplement qu'un outil n'a de valeur que s'il améliore un travail concret, sans déplacer les coûts vers la vérification, la maintenance ou la sécurité. Consommer plus de jetons, générer plus de code ou adopter plus vite ne suffit pas à prouver qu'on progresse.
Pour les entreprises, l'approche reste pragmatique : choisir un problème précis, définir le résultat attendu, mesurer aussi les effets secondaires et laisser aux équipes la possibilité de conclure qu'un usage n'est pas pertinent. C'est comme ça que l'IA devient un investissement pilotable, plutôt qu'un objectif de consommation.