La métrique interne d’IA d’Amazon a produit le mauvais comportement
Amazon aurait retiré un système interne de classement de l’IA après que des employés ont compris comment grimper dans le tableau en orientant les outils d’IA vers des tâches inutiles. L’épisode constitue une étude de cas utile sur la manière dont des métriques d’adoption de l’IA déployées trop rapidement peuvent fausser les incitations au sein de grandes entreprises.
Selon le texte source fourni, l’entreprise utilisait un tableau de bord appelé « Kirorank » pour évaluer les employés en fonction de leur activité sur la plateforme de développement Kiro d’Amazon. La métrique était censée encourager l’usage, mais certains salariés ont commencé à utiliser l’IA pour la note elle-même plutôt que pour produire quelque chose de pertinent. Le résultat a été une hausse des chiffres d’activité, des coûts cloud supplémentaires et peu de preuves d’une valeur correspondante.
Quand l’usage devient l’objectif
L’échec de fond est bien connu en conception organisationnelle : dès qu’une métrique devient une cible, les gens optimisent la métrique plutôt que l’objectif sous-jacent. Dans ce cas, l’objectif apparent était une adoption utile de l’IA par les développeurs. Le proxy choisi était l’activité sur une plateforme interne.
Cette distinction s’est révélée coûteuse. Si des employés peuvent améliorer leur position simplement en lançant davantage de tâches pilotées par l’IA, alors la consommation de tokens et le trafic de la plateforme peuvent augmenter même si la qualité du code, la vitesse de livraison ou l’impact client n’évoluent pas. Le texte source indique que certains salariés ont dirigé des agents d’IA vers un travail dénué de sens uniquement pour progresser dans le classement.
Le vice-président senior Dave Treadwell aurait déclaré au personnel : « Please don’t use AI just for the sake of using AI. » Cette phrase résume précisément le problème central. Dès que la direction doit le dire explicitement, le cadre de mesure a déjà dérivé de l’objectif business qu’il était censé soutenir.
La pression derrière le tableau de bord
Le timing compte. Amazon s’est fixé l’objectif de faire utiliser l’IA chaque semaine par plus de 80% de ses développeurs, selon le texte source. L’entreprise prévoit aussi de dépenser environ 200 milliards de dollars en 2026, principalement dans l’infrastructure IA. Ces chiffres expliquent en partie pourquoi les métriques internes d’adoption ont attiré autant d’attention.
Les grandes entreprises qui investissent aussi agressivement dans l’IA veulent des preuves que les outils sont utilisés, et elles veulent ces preuves rapidement. Les tableaux de bord sont une réponse managériale évidente, car ils transforment un vaste programme de transformation en un chiffre visible. Mais la visibilité n’est pas la même chose que l’utilité. En particulier dans les organisations logicielles, l’adoption réelle est difficile à saisir avec de simples statistiques d’usage.
Le texte source note que Meta a observé un schéma similaire, où des employés recherchaient des scores d’usage de l’IA. Cela suggère que le problème n’est pas propre à Amazon. Il peut être structurel dans les entreprises qui tentent d’accélérer l’adoption de l’IA avant d’avoir des moyens matures de mesurer les gains réels.
Des comptes de tokens aux déploiements utiles
La métrique de remplacement d’Amazon est révélatrice. Au lieu de suivre la consommation brute de tokens, l’entreprise mesurerait désormais les « normalized deployments », c’est-à-dire du code généré par l’IA qui s’avère réellement utile. Ce changement indique un passage des métriques d’entrée vers des métriques de sortie.
Le changement est sensé, mais pas trivial. Mesurer si le code généré par l’IA est réellement utile exige une définition du succès plus solide que le simple fait de noter qu’un modèle a été sollicité. Cela suggère un lien plus étroit avec les résultats de production, avec l’intégration dans de vrais workflows ou avec une forme de validation indiquant que le travail généré a réellement contribué à un déploiement plutôt qu’à du bruit.
Néanmoins, toute métrique de remplacement devra être soigneusement conçue. Si les employés sont récompensés uniquement au nombre de déploiements, ils peuvent optimiser des déploiements petits ou peu risqués. S’ils sont récompensés au volume de code, ils peuvent produire plus qu’ils ne relisent correctement. La leçon n’est pas que les métriques sont impossibles. C’est que les métriques d’adoption de l’IA doivent être bien plus étroitement alignées sur la valeur réelle de l’ingénierie que ne le supposent beaucoup d’organisations au départ.
Pourquoi cela compte pour l’IA en entreprise
L’expérience d’Amazon montre que les déploiements internes d’IA entrent dans une phase plus difficile. Le premier défi consistait à mettre les outils entre les mains des employés. Le suivant est de prouver que ces outils améliorent réellement le travail plutôt que de simplement gonfler les courbes d’engagement. À mesure que les dépenses en IA augmentent, la tolérance des dirigeants pour l’adoption symbolique devrait diminuer.
C’est particulièrement important dans les environnements de développement, où la puissance de calcul gaspillée se traduit directement en coûts et où des sorties générées de mauvaise qualité peuvent créer plus tard des charges de maintenance cachées. Un classement peut encourager l’expérimentation, mais il peut aussi favoriser un comportement de façade si le système de notation est trop grossier.
La conclusion générale est simple : les entreprises ne peuvent pas considérer l’usage de l’IA comme un état final. Elles doivent distinguer l’activité de l’efficacité. La décision d’Amazon de supprimer le classement suggère que l’entreprise a appris cette leçon à ses dépens. Pour les autres organisations qui poussent leurs employés vers les outils d’IA, c’est un avertissement : les campagnes d’adoption ont besoin d’incitations plus solides avant d’amplifier le mauvais comportement.
Cet article s’appuie sur un reportage de The Decoder. Lire l’article original.
Originally published on the-decoder.com

