Tokenmaxxing : Amazon recadre les métriques de l’IA

Quand la mesure devient un objectif

Imaginez qu'on évalue une équipe sur la quantité de code générée par IA. Résultat : elle peut produire davantage de changements, même si une partie ajoute de la complexité ou doit être retirée après revue. Et si on impose un objectif de consommation de jetons, l'incitation pousse surtout à solliciter le modèle plus souvent - pas nécessairement à mieux servir les utilisateurs.

Le piège est classique : un indicateur pensé pour diagnostiquer devient dangereux quand il détermine une récompense ou une sanction. Les équipes finissent par optimiser la mesure. L'activité augmente, mais la valeur livrée peut stagner, voire reculer.

Amazon relie ce risque à ses principes de frugalité et de simplification : consommer plus de ressources sans résultat proportionnel est difficile à défendre, tout comme ajouter du code sans nécessité. L'entreprise aurait déjà mis fin, en mai, à un classement interne après avoir observé des comportements de tokenmaxxing, selon les informations rapportées par CNBC. Un porte-parole a précisé que l'entreprise n'avait pas plafonné la consommation de jetons des employés.

Pourquoi les métriques d'activité restent utiles

Le message n'est pas « ne mesurez rien ». Les données d'adoption peuvent révéler un vrai problème : manque d'accès aux outils, difficulté à les utiliser, ou inadéquation entre l'outil et le type de tâches. C'est informatif pour la direction - à condition de ne pas confondre faible usage et faible performance.

Amazon souligne aussi une idée simple : si le travail d'un ingénieur ne bénéficie pas des outils d'IA disponibles, ce n'est pas forcément un échec individuel. Ça peut être un constat à examiner. Par exemple, une maintenance sensible, une migration complexe ou un sujet soumis à des exigences de sécurité strictes ne se prête pas toujours à un usage massif de l'IA. Dans ce cas, une faible consommation peut être le signe d'un choix raisonné.

Et le risque existe dans l'autre sens : une adoption trop faible peut signaler un manque de formation, une intégration mal faite dans les outils de travail, ou un modèle qui ne répond pas aux besoins. Là aussi, il faut enquêter avant de demander « d'en faire plus ».

Séparer les indicateurs d'activité des résultats

Les indicateurs d'activité décrivent ce que les équipes font avec l'outil. Par exemple :

• la proportion de collaborateurs ayant accès à l'assistant de code ;
• le nombre de tâches pour lesquelles l'IA a été utilisée ;
• le volume de requêtes ou de jetons consommés ;
• la fréquence à laquelle les propositions générées sont acceptées ou modifiées.

Ces données aident à comprendre les pratiques et à repérer des écarts. Mais, seules, elles ne prouvent pas que le travail est meilleur ou plus rapide.

Les indicateurs de résultat portent sur ce qui change vraiment :

• le temps entre le début d'une tâche et sa mise en production ;
• la proportion de changements qui passent les contrôles sans reprise majeure ;
• le nombre d'incidents ou de défauts après livraison ;
• la capacité de l'équipe à livrer les fonctionnalités utiles prévues ;
• le temps consacré à des tâches répétitives, comparé à celui investi dans la revue et la correction.

Aucun de ces indicateurs n'est parfait. Le délai de livraison peut baisser parce qu'une tâche a été simplifiée, pas parce que l'IA a « fait gagner ». Et livrer plus de changements ne dit rien de leur utilité commerciale. D'où l'idée : interpréter les résultats ensemble et les comparer à un point de départ crédible.

Mesurer la vélocité sans récompenser le volume

Marc Brooker, vice-président et ingénieur distingué chez Amazon Web Services, a cité la vélocité des fonctionnalités parmi les mesures suivies par l'entreprise. Le principe : regarder ce qui arrive réellement en production (lancements et changements), plutôt que la quantité de code produite en amont. Mais même là, il faut garder un œil sur la qualité et sur l'effet réel.

Pour une équipe logicielle, une évaluation pragmatique peut combiner trois niveaux :

1. Effort et coût : temps passé, dépenses liées aux modèles, charge de revue.
2. Flux de livraison : délai de réalisation, changements effectivement déployés, reprises nécessaires.
3. Résultat produit : incidents, satisfaction des utilisateurs, progression d'un objectif métier pertinent.

La comparaison doit rester prudente. Une équipe qui travaille sur des systèmes anciens ou des données sensibles ne joue pas dans la même catégorie qu'une équipe qui développe un prototype interne. Les écarts ne prouvent pas automatiquement qu'une équipe « est moins bonne » : ils indiquent où poser des questions.

Un test simple et utile : comparer quelques tâches similaires avec et sans assistance de l'IA. Il faut inclure la préparation, les corrections, la validation, puis ce qui se passe après la mise en production. Si la génération prend deux minutes mais provoque une heure de revue en plus, le « gain » apparent ne tient pas.

Intégrer le coût total, pas seulement le coût des jetons

Le prix facturé au fournisseur n'est qu'une partie de la facture. Il faut aussi compter le temps des personnes qui évaluent les sorties, l'effort d'intégration, les erreurs à corriger, et les contraintes de sécurité ou de conformité. Dans un contexte européen, une expérimentation qui implique des données personnelles doit aussi tenir compte des obligations liées au RGPD et des règles internes de traitement des données.

Une équipe peut donc consommer peu de jetons et obtenir un vrai bénéfice - par exemple en accélérant une recherche technique. À l'inverse, elle peut consommer beaucoup sans réduire le temps total de travail. La bonne question n'est pas « combien l'IA a produit ? », mais « quel travail a vraiment été amélioré, à quel coût, et avec quel niveau de risque ? »

Partir des tâches, pas des outils

Commencez par découper le travail en tâches concrètes : écrire des tests, explorer un incident, produire de la documentation, résumer un dossier, préparer un premier brouillon. Pour chacune, définissez le niveau de risque, la fréquence, et le résultat attendu. Cette étape permet de distinguer les usages qui méritent un essai de ceux où l'IA apporte peu (ou crée un risque disproportionné).

Un test opérationnel peut tenir sur une page :

• Tâche ciblée : quel travail précis cherche-t-on à améliorer ?
• Référence actuelle : combien de temps et de reprises demande-t-il aujourd'hui ?
• Résultat attendu : quel changement justifierait de conserver l'usage ?
• Garde-fous : quelles données ne doivent pas être envoyées, et quelle validation humaine reste nécessaire ?
• Période d'essai : quand décidera-t-on de poursuivre, d'adapter ou d'arrêter ?

Cette approche évite de « généraliser » trop vite à partir d'un cas isolé. Et elle permet aussi de dire clairement : « cet usage n'est pas pertinent ici » - sans que ce soit vécu comme un échec.

Demander aux responsables d'expérimenter sur du vrai travail

Amazon demande aux responsables de pouvoir décrire une tâche où l'IA a aidé, et une autre où elle n'a pas aidé. En pratique, c'est plus instructif qu'un simple objectif d'adoption. Cela oblige le management à affronter les limites concrètes : qualité variable, contexte incomplet, nécessité de vérifier les sorties, absence de gain sur certains types de tâches.

L'expérimentation doit se faire sur du travail réel, mais dans un cadre contrôlé. Les équipes doivent connaître les règles de confidentialité, les limites d'usage, et les responsabilités de validation. Pour un développeur, une suggestion générée reste du code à relire, tester et maintenir. Pour un service client, une réponse proposée doit être vérifiée avant d'être envoyée si elle engage l'entreprise.

Et surtout : le rôle des responsables n'est pas d'imposer l'IA « au quotidien » à tout le monde. C'est d'enlever les obstacles quand un usage pertinent est identifié, de partager les apprentissages, et d'éviter les déploiements qui ne réduisent ni coût ni problème.

Lire les extrêmes comme des signaux d'enquête

Amazon suggère d'analyser les 10 % d'équipes qui adoptent le moins l'IA, puis de regarder si les 10 % qui l'adoptent le plus livrent davantage. L'approche peut être utile si elle sert à ouvrir une enquête. Moins si elle se transforme en classement automatique.

Côté faible adoption : vérifiez l'accès (c'est simple ?), la formation (manque-t-elle ?), l'adéquation des tâches, et les contraintes de sécurité. Côté forte adoption : regardez les délais, la qualité, les reprises, et le coût total. Si la consommation est forte sans amélioration mesurable, il y a probablement un usage « par habitude » ou un indicateur mal conçu.

Et bien sûr, le contexte compte : taille d'équipe, ancienneté du code, nature des projets, criticité, et type de tâches. Les données servent à poser de meilleures questions. Elles ne remplacent pas le jugement professionnel.

Construire une règle de décision simple

Avant de généraliser, une direction peut se poser quatre questions :

1. Le problème est-il assez important ? Une tâche fréquente et coûteuse mérite plus souvent un essai qu'une opération rare.
2. Le bénéfice est-il observable ? On doit pouvoir voir un impact sur le délai, la qualité, le coût ou l'expérience utilisateur.
3. Le coût complet reste-t-il acceptable ? Incluez l'abonnement, la supervision, les corrections, l'intégration.
4. Le niveau de risque est-il maîtrisé ? Vérifiez confidentialité, droits d'accès, fiabilité attendue, et obligations applicables.

Si le bénéfice est incertain, prolonger un test limité est souvent plus raisonnable que d'imposer un déploiement large. Si le gain est réel mais dépend d'une validation humaine, alors cette validation fait partie du modèle opérationnel - et du coût à assumer.

Faire de la mesure un outil de décision

Les entreprises peuvent garder des données d'usage, à condition d'être claires sur leur rôle. Les jetons peuvent aider à repérer une dérive budgétaire. Le taux d'adoption peut signaler un besoin de formation. Le nombre de suggestions acceptées peut orienter l'évaluation de l'outil. Mais aucun de ces chiffres ne devrait, seul, juger la performance d'une personne.

Cette règle protège aussi la qualité des données. Si les gens pensent que leur score dépend de la comparaison entre collègues, ils peuvent multiplier les requêtes ou chercher des façons « d'améliorer la statistique ». Un système conçu pour apprendre devient alors de la surveillance, et les données se dégradent.

Pour les entreprises françaises et européennes, la gouvernance doit aussi préciser quelles données peuvent être utilisées, dans quel but, et avec quels contrôles. C'est un sujet à la fois de conformité et de confiance. Plus les règles sont claires, plus les équipes peuvent signaler les cas où l'outil aide vraiment - et ceux où il ne marche pas.