Amazon rapporte le métier de développeur au résultat, pas au nombre de tokens

Le mémo a été diffusé en interne en septembre, puis posté sur aboutamazon.com le 27 octobre 2026. Il est signé Terk Terkowitz, vice-président et distinguished engineer chez Worldwide Amazon Stores. Son objet officiel : réviser la façon dont Amazon définit le rôle des software development engineers et de leurs managers à l'heure où une partie du code s'écrit avec des assistants génératifs.

La formule mise en avant est celle de la « Renaissance Developer ». « We're now in the era of the Renaissance Developer, blending AI tools with human judgment and domain expertise to build entirely new things », écrit Terkowitz, qui renvoie aux prédictions 2026 de Werner Vogels. Le développeur idéal décrit par le mémo comprend le produit et les clients, apprend les outils directement, relie les entrées aux sorties, et sait dire où l'IA n'a pas sa place.

C'est cette dernière partie qui constitue le cœur du document. « If your work does not benefit from current AI tooling, that is a finding, not a failing », écrit Terkowitz, demandant aux ingénieurs de documenter pourquoi, de partager avec leurs pairs et de remonter l'information au management. Un ingénieur capable d'expliquer où l'IA ne l'aide pas encore démontre, selon le mémo, exactement le jugement qu'on attend de lui.

Le terme employé en interne pour désigner le travers à éviter est « tokenmaxxing » : accumuler de la consommation de tokens comme preuve d'adoption. Terkowitz écrit que compter les tokens et mesurer les lignes de code sont des façons « deeply flawed » de juger la productivité, parce qu'elles ne reflètent pas la qualité. Transformer ces métriques en objectifs ferait grimper les coûts — « tokenmaxxing is at odds with frugality » — et ajouterait de la complexité inutile, à rebours du principe « invent and simplify » de la maison.

Deeply flawed, mais conservées

Le même mémo qui qualifie ces chiffres de « deeply flawed » explique, quelques paragraphes plus loin, qu'ils suivent la performance assez bien pour être utilisés « with care and judgement ». Amazon reconnaît s'être appuyé sur des métriques d'entrée — usage de tokens, taux d'adoption des outils — et des métriques de débit — nombre de changements de code et de revues — parce que les vrais résultats sont lents et difficiles à isoler. Un porte-parole a indiqué qu'aucun plafond de consommation de tokens n'a été instauré pour les employés.

La tension est explicite dans le texte. Dire qu'une relation existe à l'échelle de l'entreprise entre usage d'IA et performance ne prouve pas que chaque ingénieur doive avoir un objectif personnel de tokens, de changements de code ou d'usage d'outil. Dès qu'un manager exige un chiffre hebdomadaire, la mesure devient la cible — et le travail se plie à la cible.

Le mémo ne sort pas de nulle part. Amazon avait mis en place un classement interne, KiroRank, qui a servi de leaderboard d'adoption de l'IA. Les équipes se sont mises à le jouer. L'entreprise l'a fermé en mai 2026. Le document publié en octobre est la rationalisation a posteriori d'un dispositif qu'Amazon avait déjà retiré quatre mois plus tôt.

Le périmètre couvre les ingénieurs logiciels de tout Amazon. Le mémo a été posté sur le site corporate comme un modèle qu'Amazon dit que ses clients pourraient suivre — ce qui place le document quelque part entre la note RH interne et l'argumentaire commercial pour les outils maison, Kiro en tête, l'IDE agentique spec-driven lancé par AWS.

Le contexte dans lequel arrive ce mémo n'est pas celui d'une entreprise sereine sur l'emploi de ses développeurs. Amazon a supprimé environ 14 000 postes corporate en octobre 2025, puis 16 000 de plus confirmés fin janvier 2026, soit environ 30 000 depuis octobre selon le décompte de la presse — davantage que les 27 000 éliminés en 2023. Jassy a soutenu que ces coupes visaient la bureaucratie et le surdimensionnement post-pandémie, pas l'automatisation par l'IA. Il avait par ailleurs prévenu les salariés que l'IA réduirait à terme les effectifs corporate. Un courrier ouvert signé par plus de 1 200 employés a critiqué la stratégie IA de l'entreprise et réclamé plus de voix sur son déploiement.

Pour un DSI qui lit le mémo sans le logo Amazon dessus, la leçon opérationnelle est antérieure à l'IA : une métrique devient un mauvais indicateur dès qu'elle devient un objectif. Les tableaux de bord qui comptent les suggestions Copilot acceptées, les lignes générées ou les requêtes envoyées à un modèle mesurent l'activité, pas la livraison. Doubler le volume de code généré par IA en une semaine peut ne produire aucun logiciel utile en plus.

Ce que le mémo ne contient pas : un chiffre de gain de productivité attribué à l'IA, un taux de défauts comparé avant/après, un nom de métrique de remplacement qui tiendrait au niveau de l'ingénieur individuel. Amazon dit mesurer l'impact sur les clients, les entreprises et les équipes — sans préciser comment on observe cet impact à l'échelle d'une personne et d'un sprint, le niveau exact où le tokenmaxxing est né.

« An engineer who can explain where AI does not yet help their work is demonstrating the judgement we are asking for », dit le mémo.