Chez Amazon, l’IA qui n’aide pas devient un constat à documenter

Chez Amazon, un ingénieur pour qui l’IA ne change rien doit désormais l’expliquer, le partager et en parler à son manager. Le texte dit que ce n’est pas un échec. Mais il fait de l’usage de l’IA le point de départ, et de son absence d’effet un écart à documenter.

La phrase vient d’une mise à jour de la direction de l’ingénierie d’Amazon, relevée par le blogueur Simon Willison. Elle fait écho à un autre signal, venu d’Anthropic, sur la façon d’évaluer les développeurs.

Une phrase qui déplace la charge de la preuve

Le texte, signé Terk Terkowitz, s’intitule « An update from Amazon engineering leadership on the role of the developer in the age of AI ». Simon Willison en cite un passage. Voici notre traduction :

« Si votre travail ne bénéficie pas des outils d’IA actuels, c’est un constat, pas un défaut. Documentez pourquoi, partagez-le avec votre communauté de pairs, apportez-le à votre manager et cherchez des solutions. Un ingénieur capable d’expliquer où l’IA n’aide pas encore son travail fait preuve du jugement que nous demandons. »

Premier point : le ton est rassurant. L’absence de gain n’est pas présentée comme une faute. Le texte parle même de « jugement », une qualité que l’entreprise dit attendre.

Second point : la logique est tout de même inversée. Avant, on demandait à quelqu’un de justifier l’adoption d’un nouvel outil. Ici, c’est le non-bénéfice qui appelle une explication écrite, un partage avec les pairs et une discussion avec la hiérarchie.

Une précision s’impose. Nous n’avons lu que cet extrait, pas le document complet. Nous ne savons donc ni comment cette demande est suivie, ni si elle est évaluée, ni quelles conséquences elle a, le cas échéant, sur un salarié.

Retour d’expérience utile ou pression douce ?

Deux lectures sont possibles. Elles ne s’excluent pas.

La lecture bienveillante. Une entreprise de la taille d’Amazon ne sait pas à l’avance où l’IA aide ses développeurs et où elle ne sert à rien. Demander aux ingénieurs de documenter les échecs est une manière de cartographier ces limites. Un code ancien, très spécifique ou fortement contraint peut résister aux assistants. Savoir pourquoi a de la valeur, et pour l’équipe, et pour les outils eux-mêmes. Le texte invite d’ailleurs à « chercher des solutions », pas à se taire.

La lecture inquiète. Quand un cas non conforme exige un dossier, la norme devient claire : l’IA est censée aider. Un salarié peut alors hésiter à signaler que l’outil ne lui sert pas, de peur de passer pour réticent. Il peut aussi se sentir poussé à trouver un usage, même marginal, pour éviter de rédiger sa justification. Rien dans l’extrait ne dit que c’est le cas. Mais la question mérite d’être posée.

Quelques points permettraient de trancher, et l’extrait n’y répond pas :

• Ces constats sont-ils lus, agrégés, suivis d’effets sur les outils ?
• Entrent-ils dans les évaluations individuelles ?
• Un manager peut-il en déduire autre chose qu’un manque de motivation ?

Chez Anthropic, le prototype remplace l’exercice de code

Côté Anthropic, le signal est différent mais va dans la même direction. Selon The Decoder, Felix Rieseberg, responsable d’ingénierie, a supprimé l’entretien de code classique. Il a dirigé le développement de Claude.ai et de Claude Code Desktop.

Son argument : Claude résout désormais mieux que les candidats les petites tâches de programmation. Donner un petit défi en React n’aurait donc plus guère plus de sens, selon lui, que d’interroger quelqu’un sur l’assembleur. Dans ses équipes, de bons scores aux tests ne prédisent plus qui sera un excellent développeur. Il observe plutôt des ingénieurs relativement récents dépasser des collègues plus expérimentés. Sa formule : « Hunger beats tenure », soit « l’appétit bat l’ancienneté ».

Son raisonnement repose sur deux idées :

• Les nouveaux voient ce que les anciens ne voient plus. Rieseberg cite le chercheur James March (1991) et le fondateur de Stripe, Patrick Collison, qui invite les nouvelles recrues à signaler ce qui leur semble étrange. Il raconte aussi un épisode chez Notion, où une architecture hors ligne jugée impossible butait surtout sur une résistance supposée du patron, que personne n’avait vérifiée.
• L’exécution coûte moins cher. Les organisations étaient bâties pour que quelques décideurs approuvent ou bloquent des idées, car construire coûtait cher. Si l’IA réduit ce coût, un prototype fait en un week-end peut remplacer les cycles de spécifications et d’approbations.

Son exemple maison : deux ingénieurs d’Anthropic alors récents, Anthony Morris et Alice Zhao, ont construit l’interface graphique de Claude Code en un week-end. La première version publique est sortie environ huit jours plus tard. Rieseberg cherche désormais, dans les candidatures, de petits prototypes qui montrent du goût, de l’empathie et une pensée fondée sur des principes. L’entretien de code classique ne reviendra pas, dit-il.

Le revers : l’appétit n’est pas donné à tous

The Decoder ne se contente pas de relayer. Le média note que ce discours peut se lire comme une émancipation : l’IA égalise les chances et permet aux nouveaux de contourner des gardiens devenus aveugles aux problèmes de leur entreprise.

Mais il relève aussi que la barre d’entrée se déplace. On passe de l’application et du savoir-faire vers l’esprit d’entreprise, le sens du produit et le goût. Ces compétences sont peu enseignées à l’université, et les entreprises les attendaient plutôt de chefs de produit expérimentés ou de fondateurs. Les ingénieurs cités en modèles construisent en outre des prototypes le week-end, sans qu’on le leur demande. « Hunger beats tenure » motive, mais suppose une mentalité de débrouille que tous les développeurs débutants ne peuvent pas ou ne veulent pas offrir.

On retrouve ici le même mouvement que chez Amazon. Dans les deux cas, l’IA ne se contente pas d’être un outil : elle redéfinit ce qu’on attend d’une personne. Chez Anthropic, on demande de l’initiative visible. Chez Amazon, du jugement explicite sur l’outil.

Ce que cela change pour un salarié ou un indépendant

Ces deux textes viennent de grandes entreprises technologiques américaines. Les transposer tels quels à une PME belge ou à un indépendant québécois serait imprudent. Ils indiquent pourtant une direction.

La compétence qui ressort n’est ni « savoir utiliser l’IA » ni « la refuser ». C’est savoir évaluer, tâche par tâche, quand elle aide vraiment, et pouvoir le dire avec des faits. Concrètement, on peut s’y exercer :

• noter, sur une ou deux semaines, les tâches où l’IA fait gagner du temps et celles où elle en fait perdre, par exemple à cause de vérifications ou de corrections ;
• préciser pourquoi : contexte trop spécifique, données sensibles, exigence de fiabilité, outil mal adapté ;
• garder une trace montrable à un manager, à un client ou à des pairs.

Cette trace sert dans les deux sens. Elle peut justifier un usage, mais aussi protéger un refus raisonné, comme le suggère le texte d’Amazon lui-même.

Reste la vigilance sur le contexte. Un « constat à documenter » est une chance si l’entreprise l’écoute, un risque si elle ne l’entend que comme de la réticence. À vous de regarder, chez vous, qui lit ces retours et ce qu’il en fait.

Sources

• A quote from Terk Terkowitz (Simon Willison)
• With AI writing the code, entrepreneurial thinking is now what counts most for newcomers at Anthropic (The Decoder)