- Le PDG d’AWS, Matt Garman, a déclaré que l’idée selon laquelle l’IA pourrait remplacer les employés juniors est « l’une des choses les plus stupides que j’aie jamais entendues »
- Il souligne que les employés juniors sont les moins coûteux et parmi les plus enclins à utiliser activement les outils d’IA, et qu’il est indispensable de leur offrir des opportunités de formation et d’apprentissage
- Il a également affirmé que mesurer les performances de l’IA à la quantité de code produite est un indicateur dénué de sens, en rappelant qu’un code plus court mais de meilleure qualité est préférable à une grande quantité de code inutile
- Chez AWS, plus de 80 % des développeurs utilisent déjà l’IA en interne, sous diverses formes : tests unitaires, rédaction de documentation, assistance au code, workflows fondés sur des agents, etc.
- Garman estime que, dans un environnement technologique en mutation rapide, les qualités nécessaires à long terme sont l’esprit critique, la créativité et la capacité d’apprentissage, et que les personnes dotées de ces compétences réussiront à l’ère de l’IA
Position sur la polémique autour du remplacement des employés juniors
- Garman a vivement contesté l’idée défendue par certains dirigeants selon laquelle l’IA pourrait remplacer tous les employés juniors
- Il insiste sur le fait que les employés juniors sont « ceux qui coûtent le moins cher et qui sont les plus enclins à adopter l’IA »
- « Que se passera-t-il dans dix ans si plus personne n’accumule d’expérience ? », a-t-il lancé pour souligner la nécessité de former les talents
- Selon lui, il reste essentiel de recruter des diplômés de l’université et de les former à la résolution de problèmes
Critique des usages de l’IA et des indicateurs
- Il a qualifié de « métrique inutile » la pratique consistant à mesurer la performance de l’IA sur la base du volume de code produit
- Il est possible de générer une quantité de code illimitée, sans pour autant garantir sa qualité
- Il a rappelé que « moins de code est souvent préférable », critiquant l’obsession pour les indicateurs quantitatifs
- D’après les données internes d’AWS, plus de 80 % des développeurs utilisent déjà l’IA
- Pour automatiser les tests unitaires, aider à la rédaction de documentation, écrire certaines parties du code ou encore travailler via une collaboration fondée sur des agents
- Le taux d’usage de ces outils d’IA augmente chaque semaine
Conseils sur l’éducation et la carrière à l’ère de l’IA
- Garman cite parmi les compétences essentielles à l’ère de l’IA l’esprit critique, la créativité et la volonté d’apprendre
- Non pas l’acquisition d’une technologie précise, mais bien la capacité à apprendre elle-même
- Il insiste sur « la capacité à penser par soi-même, à décomposer un problème pour le résoudre et à vouloir apprendre de nouvelles choses »
- Il estime que, compte tenu de la rapidité des évolutions technologiques, se limiter à l’apprentissage d’une technologie spécifique permet difficilement de soutenir une carrière de 30 ans
- Les enseignants devraient donc apprendre aux étudiants à décomposer les problèmes, raisonner et continuer à apprendre, car ce sont ces profils qui prospéreront à l’ère de l’IA
11 commentaires
Je pense qu’il faut vraiment réfléchir sérieusement aux deux aspects.
Pour faire fonctionner une entreprise, il faut des développeurs, et nous traversons actuellement une période où il est difficile pour les développeurs juniors de trouver un emploi.
Officiellement, on met cela sur le dos de l’IA, mais après les recrutements massifs pendant la période du Covid, les entreprises ont surtout vu leur masse salariale augmenter davantage que leurs succès proportionnels. Elles réduisent donc leurs embauches en raison de cette charge. Dans ce contexte, comme l’usage des LLM commence à montrer une efficacité au moins équivalente au fait de confier certaines tâches à des développeurs juniors, je pense que le marché de l’emploi s’est encore davantage contracté.
Mais, comme c’est aussi écrit dans l’article, il faut des développeurs juniors pour qu’ils puissent ensuite devenir des développeurs seniors.
Si on ne recrute pas au niveau junior, on ne peut tout simplement pas faire émerger de développeurs seniors.
Malgré tout, je pense qu’il faut un important travail d’ajustement dans ce processus.
Dans les grandes entreprises, c’est sans doute moins problématique parce que les processus sont mieux structurés, mais lorsqu’un développeur junior arrive, on le forme généralement en lui confiant non pas le cœur de l’activité, mais plutôt des tâches annexes (des tâches internes pour lesquelles l’échec reste acceptable).
En revanche, du point de vue d’un développeur senior, moins l’organisation est structurée, plus il est difficile d’accompagner un développeur junior.
Et, ironiquement, pour bien utiliser un LLM, il est plus avantageux d’avoir déjà des connaissances dans le domaine ; ce n’est pas parce qu’on est développeur débutant qu’on obtiendra la même efficacité.
En réalité, il est impossible de remplacer tout le travail de développement par des employés juniors. Des personnes exceptionnellement brillantes pourraient peut-être s’en sortir d’une manière ou d’une autre, même sans développeur senior. Mais si tout le travail commence alors à se concentrer sur cette personne, pourra-t-elle vraiment tenir le rythme ?
Autrement dit, il faut recruter à la fois des développeurs seniors et juniors, avec une politique d’embauche flexible qui tienne compte à la fois de la productivité et de la masse salariale de l’entreprise.
Ceux qui nient ce texte,
ce sont seulement des seniors de faible niveau qui n’ont travaillé qu’avec des juniors médiocres lol
À l’ère de l’IA, quelle que soit l’expérience, les gens intelligents sont écrasamment avantagés.
Un nouveau très doué qui se donne à fond pendant 1 à 2 ans peut largement bouffer un profil ordinaire avec 10 ans d’expérience
Même sans IA, un jeune diplômé brillant pouvait déjà, en se donnant à fond pendant un ou deux ans, manger sans problème un profil moyen avec dix ans d'expérience...
On a un peu l’impression qu’il dit : « Les juniors ne coûtent pas cher et utilisent bien l’IA, alors pourquoi les remplacer ? Remplaçons plutôt les seniors ! »
Oh, on peut aussi le comprendre comme ça.
Putain, mdr
Pff...
Merci d’éviter ce genre de commentaires. Ici, ce n’est pas DC Inside.
Ici, ce n'est pas DC Inside..
Quelle façon de parler.
Avis Hacker News
Tout à fait d’accord. Cela dit, j’ai vraiment l’impression qu’il faut devenir un véritable magicien du prompt pour utiliser du code généré par des LLM en conditions réelles. Je ne m’en sers qu’occasionnellement pour du débogage ou pour esquisser rapidement une UI. Dès qu’il s’agit de vrai code, ce que produisent les LLM est souvent un véritable plat de spaghettis, verbeux, avec de sérieux risques en matière de performances et de sécurité, et une incompréhension totale de presque tous les design patterns que je leur ai fournis.
Chaque fois que je vois sur Hacker News ou Reddit des messages sceptiques sur le coding avec l’IA, je suis de plus en plus surpris. On dirait vraiment qu’on vit tous dans des mondes complètement différents. Je pense aussi que la diversité des outils y est pour beaucoup. À mon avis, « utiliser du code LLM » ne veut pas dire la même chose pour tout le monde. Le LLM précis utilisé, le contexte fourni et l’IDE employé ont tous une grande influence sur le résultat. J’ai moi-même écrit 200 000 lignes de code B2B SaaS avant l’arrivée de l’agentic coding. En mode Agent de Sonnet 4, je n’écris maintenant qu’environ 20 % du code que je produis chaque jour, et les 80 % restants sont écrits par le Sonnet interactif de VS Code et les GitHub Copilot Agents. Plus je documente en Markdown, plus cette proportion augmente. Je relis et teste les résultats avec beaucoup de soin.
Je serais curieux de savoir quels outils tu utilises. J’utilise aider, et même avec des modèles réputés mauvais pour coder comme gpt-5, je n’ai jamais eu l’expérience que tu décris. Ça écrit effectivement du « bon » code, et ça respecte bien le style du code existant. La rédaction du prompt est vraiment cruciale, et sur une base de code existante, le taux de réussite grimpe nettement quand on peut donner des indications d’implémentation précises. C’est justement le genre de chose qu’un senior connaissant bien la codebase peut faire facilement, mais qui peut être difficile pour un junior. Je pense qu’il faut voir tous les aspects de manière claire. Pour l’instant, il m’arrive encore souvent d’être légèrement plus rapide en le faisant moi-même qu’en passant par aider, mais l’écart est faible et ça continue de s’améliorer. Les LLM peuvent remplacer certaines tâches qu’un développeur junior peut faire, mais pas le remplacer complètement. Un junior va aussi en réunion, anime des discussions, et suit au final une trajectoire de progression pour devenir senior. Mais du point de vue du management, il se peut qu’on s’en moque.
L’IA est un outil fantastique pour consulter de grandes masses d’information de manière approximative. Ces derniers temps, j’utilise de plus en plus souvent l’Assistant de Kagi avant une recherche classique. Il me donne le mot qui me manque, puis en recherchant ce mot dans les pages, je finis par trouver ce que je voulais. En revanche, je n’ai jamais vraiment obtenu de valeur durable du vibe coding. Pour des tâches one-off, c’est excellent. Par exemple, quand je fais un graphique matplotlib, si je lui explique ce que je veux et que je lui montre seulement le schéma des données, il tape juste à 90 %. Il me fait aussi facilement des shell scripts simples. Récemment, je lui ai demandé un petit outil CLI pour ranger des photos RAW dans des dossiers selon les informations EXIF, et pour ce genre de choses j’en suis très satisfait. Mais dès qu’on lui demande quelque chose d’un peu plus complexe, il se met à faire beaucoup de choses inutiles. Il régénère en doublon des modèles déjà présents dans le projet, fait des modifications sans rapport, ou invente de toutes pièces des fonctions d’API qui n’existent pas. Au lieu de vérifier ses résultats, autant écrire le code moi-même. Et pour moi, la partie la plus plaisante reste justement le fait de coder directement. Je n’ai pas encore trouvé de cas convaincant où les LLM conviendraient au véritable flux de travail humain consistant à obtenir un résultat via un prompt, puis à l’enregistrer, l’intégrer et le transmettre aussitôt.
L’IA est en revanche très utile pour filtrer rapidement la réponse que je cherche parmi des centaines de sites catastrophiques remplis de pub. J’utilise souvent Duck Duck Go AI pour les questions-réponses. Je ne lui fais confiance qu’à portée de jet de datacenter, mais pour des informations faciles à vérifier rapidement, comme la syntaxe d’un programme ou les options d’une commande, c’est utile.
En matière d’IA, la formule « on récolte ce qu’on y met » colle parfaitement. Si on prend le temps d’expliquer le fonctionnement interne, les edge cases, l’architecture, le choix des bibliothèques, etc., et qu’on rédige soigneusement tout cela en Markdown, alors après quelques itérations il y a de bonnes chances d’obtenir un code exploitable. Il y a une énorme différence avec un prompt court du type « fais-moi la fonctionnalité X ». Mais si tu es capable d’écrire un prompt aussi bon, c’est qu’en réalité tu as déjà presque résolu le problème, et le LLM ne fait plus que jouer le rôle d’une machine à taper rapide. Seule la frappe s’accélère, l’essentiel de la réflexion a déjà été fait par l’humain.
Je pense qu’au moins un CEO comprend cet aspect. L’idée de sauter la main-d’œuvre junior pour ne remplir qu’avec de l’IA nuira aux entreprises sur le long terme. Si les seniors deviennent indépendants et s’en vont, il ne reste plus rien. Honnêtement, je ne sais même pas si l’IA est réellement bénéfique pour quelque ingénieur que ce soit, y compris les juniors. Le software engineering est un parcours d’exploration et d’apprentissage. Chaque fois que j’utilise l’IA, je repense à mon prof de maths qui disait : « si tu utilises une calculatrice, il ne t’en restera rien dans la tête ». Globalement, j’ai aussi l’impression que l’IA est le résultat naturel des politiques économiques américaines des 45 dernières années. Une quête de résultats à court terme uniquement pour le 1 %, au détriment d’un écosystème d’entreprise sain et du développement de long terme de l’économie. Quand on voit ça, on se dit que Jack Welch serait très fier.
Ces derniers mois, en travaillant avec des startups, j’ai vu de nombreux cas de gens tellement plongés dans le LLM vibe coding qu’ils n’arrivent plus à en sortir. Souvent, ils n’ont pas réussi à recruter correctement ou ont raté des profils techniques. Ils prennent le code produit par l’IA, surtout Claude, pour un ingénieur interne x10, et en attendent des itérations plus rapides et un meilleur code. J’ai vu des fondateurs pourtant assez avisés devenir accros à la dopamine procurée par du code Claude qui donne l’impression d’avoir accompli plusieurs semaines, voire plusieurs années, de travail de software engineering. Croire que l’IA peut « penser » ou « comprendre » des problèmes complexes, c’est lui faire beaucoup trop de crédit. À mon avis, nous devrions mesurer non pas une véritable capacité de réflexion, mais une « réduction du temps de frappe ». [1] vibebusters.com
Tout à fait d’accord avec l’idée d’enseigner « comment penser » et « comment décomposer un problème ». Les meilleurs professeurs de mon école d’ingénierie donnaient toujours des examens en open book. Dans la réalité, tout le monde évolue dans un environnement où toutes les données et informations sont accessibles. On ne paie pas des gens pour aller simplement chercher des données, mais pour leur capacité à analyser ces données, à les comprendre et à les appliquer logiquement. C’est justement cela qu’on appelle l’ingénierie, et c’est précisément ce que ce professeur enseignait.
À l’université, j’ai suivi un cours d’algèbre abstraite. Tous les examens consistaient soit à réciter des démonstrations célèbres, soit à en créer de nouvelles. L’aspect mémorisation me paraissait artificiel, mais j’ai fini par comprendre qu’on ne peut pas mémoriser une preuve sans la comprendre. Et quand il fallait inventer soi-même une nouvelle démonstration, on avait déjà des modules mentaux en place, ce qui rendait l’approche beaucoup plus intuitive. La vraie mémorisation n’a rien à voir avec l’apprentissage par cœur de code façon problèmes algorithmiques ; le codage d’applications réelles ressemble bien davantage à une improvisation humaine, fondée sur l’état courant, proche d’une exploration de graphe à la volée. Les problèmes du monde réel n’ont pas toujours un ordre inédit bien défini ; au final, les heuristiques sont essentielles.
Je pense que c’est le problème central auquel le recrutement dans ce domaine fait face. Les développeurs vraiment compétents sont fondamentalement des généralistes. L’expertise a évidemment de la valeur, mais sauf dans des situations du type ancien enfer de code legacy ou percée au-delà des limites, un spécialiste n’est pas forcément indispensable. Au contraire, quelqu’un ayant touché à une stack inconnue peut combler des faiblesses ou apporter un regard neuf. Un bon développeur généraliste s’adapte vite à n’importe quelle stack. Parce que chaque entreprise utilise un ensemble de technologies différent et souvent assez chaotique. Tu peux bien exiger « 15 ans d’expérience en React », de toute façon, quelle que soit la personne recrutée, elle n’atteindra pas immédiatement une productivité maximale. Il faut forcément du temps d’onboarding. Mais les recruteurs opérationnels comprennent souvent mal cela. Les grandes entreprises assurent encore un minimum de formation, mais même cet état d’esprit n’est plus ce qu’il était. On dépense des centaines de milliers de dollars dans la compétition du recrutement, sans vraiment penser au coût réel de former quelqu’un sur la durée. À l’échelle du secteur, il faudrait même une association professionnelle pour éviter que toute la structure du recrutement et de la formation des talents ne devienne complètement dysfonctionnelle, mais comme elle n’existe pas, le problème est encore pire. (Je pense que l’attention actuelle portée aux syndicats, avec les restructurations, l’externalisation, etc., s’inscrit dans le même contexte.)
J’ai l’impression que ce changement est déjà en train d’avoir lieu. La moitié du cursus traditionnel de CS, c’est des maths, et l’autre moitié, c’est essentiellement encore des maths sous un autre nom. On critique beaucoup le monde académique, mais quand quelqu’un dit « le monde académique est idiot, il faudrait enseigner ceci », soit c’est déjà enseigné, soit c’est le genre de chose qu’on peut acquérir rapidement au besoin. La plupart des nouvelles tendances sont en fait déjà couvertes.
À l’université, le département de philosophie avait pour slogan marketing « la filière qui apprend à penser, faites des études de pensée ». D’après mon expérience comme recruteur, les gens issus des humanités sont bien meilleurs sur les tâches fondamentales comme l’analyse ou la compréhension. J’ai sans doute un biais puisque j’ai moi-même fait une double spécialisation CS/philosophie, mais un junior doté d’une vraie capacité de raisonnement analytique est bien plus précieux que quelqu’un qui sait seulement écrire beaucoup de code. La pensée analytique est bien plus difficile à enseigner que le codage.
En première année, j’avais un professeur qui appelait « crazy finger syndrome » le fait, pour les élites en informatique, de vouloir coder immédiatement sans d’abord décomposer le problème du point de vue business ou utilisateur. Ses blagues sur les « étudiants anxieux qui veulent juste coder » me manquent. J’ai l’impression que les bootcamps récents ne sont pas toujours alignés avec des standards éthiques élevés.
J’ai entendu la question suivante : « que se passe-t-il si, à l’avenir, plus personne n’est correctement formé ? » Beaucoup de gens considèrent probablement déjà cette conclusion comme allant de soi. Et pourtant, il est difficile d’échapper à une structure où la plupart des entreprises privilégient la rentabilité à court terme plutôt que la soutenabilité de long terme. Les stages et programmes coop restent malgré tout mis en avant comme moyen de maintenir le pipeline de talents. Je m’attends aussi à voir une tendance consistant à se concentrer encore davantage sur les stages pour éviter les difficultés du recrutement de développeurs juniors.
Si je résume mon expérience, ça donne à peu près ça : notre patron a voulu se donner une image de leader de l’IA avec une communication très déclarative du type « on va se séparer massivement de gens à cause de l’IA », mais en pratique ça s’est avéré complètement catastrophique, et maintenant c’est moi qui dois gérer les excuses et les explications.
Patron -> VP : « il faut réduire les effectifs à cause de l’IA » VP -> public : « d’ici deux ans, on remplacera tous les ingénieurs par l’IA » Patron -> VP : « il faut aussi réduire les VP à cause de l’IA » VP -> public : « remplacer des gens par l’IA est une idée stupide »
On ne recrute toujours pas de développeurs juniors.
Le CEO d’AWS semble lui aussi avoir changé de position. Il y a un an, il disait que « l’IA ferait tout le code d’ici deux ans » [1]. On dirait enfin que le c-suite commence à accepter la réalité. [1] https://news.ycombinator.com/item?id=41462545
Le CEO n’a pas réellement dit cela. Il a seulement dit que d’ici deux ans, les développeurs pourraient ne presque plus écrire de code eux-mêmes. Et il a ensuite ajouté : « il faudra désormais davantage se concentrer sur ce qu’on construit, sur la manière de le construire et sur ce dont les vrais clients ont besoin ». Lien vers l’article Il y a une continuité cohérente entre la prémisse et sa déclaration actuelle. Écrire du code en soi pourrait devenir moins important ; c’est justement pourquoi il faut recruter des juniors, leur apprendre à apprendre, et développer des compétences réellement utiles.
En théorie, l’essentiel de la valeur d’Amazon vient des capacités de ses talents. Certains considèrent les salariés comme un simple coût et estiment que toute la valeur revient aux actionnaires. Mais si les actifs humains ont réellement de la valeur, alors prétendre que n’importe qui peut obtenir cette valeur uniquement avec l’IA est au contraire mauvais pour le cours de l’action. Il y a même un risque de baisse du PE, donc il est étrange d’interpréter cela positivement. Si l’on croit vraiment qu’avec l’IA seule on peut tout faire, alors du point de vue des actionnaires, le capital ne peut plus rester immobilisé de manière sûre dans une entreprise comme un FAANG, et il faut en permanence courir après de nouveaux « relais de croissance ».
Quand on fait partie de la direction, il est indispensable de toujours sentir le sens du vent.
Ce n’est pas du tout contradictoire. Pour donner des instructions à une IA autonome, il faut absolument un pipeline de talents, depuis les juniors jusqu’aux seniors. Les grandes entreprises s’inquiètent de ce pipeline, tandis que les petites peuvent en profiter pour recruter uniquement des seniors à court terme sans prendre d’internes.
Il n’y a aucune contradiction logique entre les deux déclarations. On peut continuer à recruter des juniors même si leur travail s’éloigne du codage pur.
Si cela semble en désaccord avec le patron, je recommanderais d’aller vérifier directement. Il n’est pas souhaitable de citer un article de presse hors contexte. Personne ne peut réellement prédire l’avenir. [1]: https://www.shrm.org/topics-tools/news/technology/ai-will-shrink-corporate-workforce--amazon-ceo-warns
Je ne pense pas que les propos des deux CEO soient en contradiction. « Il faut continuer à recruter des diplômés et leur enseigner la bonne manière de créer du logiciel » - Matt Garman « Il y aura moins besoin d’humains pour plusieurs des tâches effectuées aujourd’hui » - Andy Jassy Ce sont surtout des nuances de ton ; sur le fond, c’est très proche.
Quand on cite quelqu’un, je pense qu’il est éthique de reprendre les paroles originales de manière aussi fidèle que possible, avec leur contexte. Le choix de la personne citée et du contexte construit détermine la tonalité de l’actualité.
Les deux déclarations sont très cohérentes sur le plan logique.
Pour avoir travaillé chez AWS, je ne fais pas entièrement confiance aux déclarations officielles d’AWS. Je savais déjà quel type d’entreprise c’était, et j’y suis allé comme huitième poste à 46 ans. Il y a même eu des cas où des postes annoncés comme « full remote permanent » ont ensuite reçu un ordre de retour au bureau, après mon départ d’ailleurs.
Le pipeline de talents dans la recherche académique ressemble à ceci : étudiant de premier cycle -> graduate student -> postdoc -> titulaire/chercheur senior À quelques rares exceptions près, on ne saute pas les deux premières étapes pour devenir directement chercheur senior. C’est pareil dans n’importe quel secteur. Sans juniors, on ne peut pas produire de seniors ; si on veut que les « bots » fassent tout, il faut aussi se préparer au risque que cela implique.
Je suis convaincu que tous ceux qui travaillent avec ces modèles depuis longtemps seront d’accord. Les posts de sama sur l’AGI avant la sortie de o3, ainsi que les posts doomer de l’époque dans la tech, paraissent aujourd’hui franchement absurdes avec le recul.
Le doomerism AGI n’était qu’une stratégie marketing. Maintenant, tout le monde comprend la nature réelle de l’IA, et on assiste simplement à une nouvelle itération du marché de la recherche où l’IA lit tous les documents à votre place.
C’était un bruit idiot depuis le départ, mais personne n’est totalement à l’abri du « hype ». Surtout quand d’énormes sommes sont injectées dans l’astroturfing afin de gonfler la technologie au-delà de sa réalité.
Je considère que ChatGPT est meilleur que n’importe quel développeur junior avec lequel j’ai travaillé. Un junior est un poids net pour l’équipe pendant presque un an. Quand on est responsable de vrais projets, on ne se dit jamais « j’aimerais vraiment avoir plus de juniors ». Il vaut largement mieux payer 20 % de plus et débaucher un profil intermédiaire.