Un vol pour Seattle, et 100 000 lignes après 25 ans de pause
Beth Galetti, vice-présidente senior d'Amazon en charge de People Experience and Technology, a passé 25 ans à diriger les équipes qui encadrent les ingénieures et ingénieurs logiciel sans écrire elle-même une ligne de code, et cette semaine le blog d'entreprise d'Amazon a annoncé qu'elle en avait désormais écrit plus de 100 000 avec un outil interne d'IA appelé Kiro. Galetti a décrit ce retour en termes personnels : "Savez-vous à quel point il est libérateur de réaliser qu'après 25 ans sans coder, on peut encore construire quelque chose ?" Son premier projet a été une application de calendrier familial, pensée pour son propre foyer et non pour l'activité d'Amazon.
L'histoire la plus importante est celle qu'Amazon a choisi de publier autour d'elle. Galetti a écrit sa proposition pour un concours interne appelé Everyone Can Build pendant un vol vers Seattle, et le concours a attiré plus de 1 500 employés en quelques semaines. La publication d'Amazon a mis en avant d'autres propositions dans le même esprit : une personne a automatisé un processus manuel de quatre heures pour le ramener à une seconde, une autre a construit pour le plaisir un animal de compagnie numérique appelé Momo, sans aucune finalité professionnelle.
Amazon ne cache pas à quoi cela sert. La publication relie le retour de Galetti au code à Future Ready 2030, l'engagement de 2,5 milliards de dollars tout juste annoncé par lequel Amazon veut préparer plus de 50 millions de personnes à l'avenir du travail, dont 1 milliard de dollars destiné au dispositif éducatif existant Career Choice, ainsi qu'une formation gratuite à l'IA et une certification AWS pour chaque employé d'Amazon. L'application personnelle d'une dirigeante senior est devenue le visage humain d'un budget de formation considérable.
Cinq mois plus tôt, les ingénieurs d'Amazon avaient reçu l'instruction inverse
Lu à côté de la note interne que l'organisation d'ingénierie d'Amazon a diffusée en mars 2026, cette célébration ne ressemble qu'à la moitié de l'histoire. Cinq mois avant la publication sur Galetti, Amazon avait exigé de ses ingénieures et ingénieurs logiciel formés, et non de personnes codant pour la première fois, l'accord d'une personne senior avant de livrer tout code auquel un outil d'IA avait contribué.
Le déclencheur fut une série de pannes liées à ce que les communications internes d'Amazon appelaient des modifications assistées par IA générative à rayon d'impact élevé, un schéma que la note faisait remonter au troisième trimestre 2025. En décembre 2025, une panne AWS a duré 13 heures après que l'outil Kiro a été autorisé à modifier l'infrastructure sans contrôle humain et a décidé seul de supprimer puis recréer un environnement. Début mars 2026, deux autres incidents ont suivi en trois jours : l'un a coûté environ 120 000 commandes et généré 1,6 million d'erreurs sur le site, l'autre a fait chuter le volume de commandes en Amérique du Nord de 99 %, avec 6,3 millions de commandes perdues selon les informations rapportées. Le vice-président senior d'Amazon Dave Treadwell a dit sans détour aux équipes que la disponibilité du site et de l'infrastructure associée n'avait pas été bonne récemment.
TechRadar a rapporté la politique qui en a résulté, en citant une note interne obtenue par le Financial Times : les ingénieures et ingénieurs juniors et de niveau intermédiaire doivent désormais obtenir l'accord d'une personne senior avant qu'un changement de code assisté par IA soit livré, dans le cadre d'une remise à plat de la sécurité du code sur 90 jours couvrant environ 335 systèmes critiques du commerce de détail, avec une revue à deux personnes et des contrôles automatisés plus stricts. Amazon a contesté une partie de cette présentation, qualifiant au moins un incident d'erreur humaine de contrôle d'accès, mais a maintenu l'exigence d'accord elle-même.
Un calendrier familial et une caisse n'exposent pas au même risque
La différence entre l'application de Galetti et le code à l'origine des pannes d'Amazon n'a jamais tenu à qui avait rédigé l'instruction donnée à l'IA, mais à ce que le code produit pouvait toucher. Une application de calendrier familial et une proposition pour un concours interne ne lisent ni n'écrivent rien qui appartienne à un client, et rien de ce qu'elles font n'atteint le public payant d'Amazon.
La politique de mars visait une catégorie plus étroite : du code écrit avec l'IA fonctionnant à l'intérieur de systèmes de production qui traitent de vraies commandes, de vrais prix et de vrais comptes clients, à une échelle où un seul déploiement défectueux supprime des millions de transactions en quelques heures. Cette catégorie a besoin qu'une deuxième personne formée la vérifie avant sa mise en production, peu importe qui, ou quoi, a écrit la première version.
Le seuil qu'Amazon a fixé pour elle-même est la partie de cette histoire qui se transpose ailleurs. L'entreprise a continué à utiliser Kiro et à encourager les non-ingénieurs à construire. Elle n'a ajouté un contrôle humain qu'une fois le code arrivé en production, touchant des données clients, ou porteur d'un rayon d'impact assez large pour compter.
La décision que tout dirigeant a désormais devant lui
Pour une dirigeante ou un dirigeant qui voit une responsable marketing ou un responsable financier construire ses propres outils avec un assistant de programmation IA, la question n'est pas de savoir s'il faut l'autoriser, la propre année d'Amazon a déjà répondu à cette question. La décision porte sur l'endroit où placer la ligne qu'Amazon a fixée à 335 systèmes de production et un accord senior obligatoire.
En dessous de cette ligne, laissez les équipes construire. Une automatisation de tableur, un tableau de bord interne alimenté par des données auxquelles la personne qui le construit a déjà légitimement accès, un outil personnel d'agenda comme celui de Galetti, rien de tout cela n'a besoin d'un processus formel de revue, et l'imposer quand même n'apprend aux équipes qu'à construire en silence plutôt qu'à demander.
Au-dessus de cette ligne, appliquez directement la règle d'Amazon. Dès qu'un outil créé avec l'IA par une personne sans profil technique est destiné à lire ou écrire dans une base de données de production, à toucher de vraies données clients, ou à devenir accessible depuis l'extérieur de l'entreprise, exigez l'accord d'une personne technique qualifiée avant sa mise en service, selon le même critère qu'Amazon vient d'appliquer en interne en 2026. Si personne dans l'équipe ne peut réellement effectuer cette revue, mettez le lancement en pause jusqu'à ce qu'une personne qualifiée soit disponible.
Ce qu'il faut vérifier avant qu'un nouvel outil créé avec l'IA soit mis en ligne
Commencez cette semaine par lister chaque outil créé avec l'IA en dehors de l'équipe d'ingénierie au cours du dernier trimestre, et posez-vous une question pour chacun : touche-t-il des données de production, un client payant, ou un système accessible depuis l'extérieur de l'entreprise. Un oui à l'un de ces points exige le même accord qu'Amazon impose désormais à ses propres ingénieurs, quelle que soit la personne de l'entreprise qui l'a construit.
Mettez un nom derrière l'accord, pas seulement un document de politique. La solution d'Amazon fonctionne parce qu'une personne senior précise doit attacher son nom à une modification précise avant qu'elle soit livrée, et une règle sans personne relectrice nommée n'est qu'une note, pas une barrière.
À lire ensuite: Le nouveau chiffrement par défaut de Ring n'en est pas un | L'équipe européenne de DuckDB rejoint AWS
