Le catastrophisme n'est pas de la science : anatomie d'un article

Le 28 septembre, Science et Vie publie un article intitulé : « Cet ex-ingénieur de Google et d'Amazon prévient… l'IA serait sur le point de remplacer la moitié des développeurs humains ». Une ligne entre crochets signale qu'il a « déjà été publié le 16 février 2026 ». Le conditionnel du titre est là pour la forme : le lecteur retient « la moitié des développeurs ».

J'enseigne l'informatique à des étudiants qui vont chercher un emploi dans deux ou trois ans, et parmi mes cours il y a l'initiation à la recherche, qui n'a de sens qu'avec un esprit critique bien affûté. Ce genre de titre arrive dans leur fil, puis dans mes cours, sous la forme d'une question inquiète. Je vais donc faire ce que je leur demande de faire avec n'importe quel texte : remonter à la source, séparer ce qui est établi de ce qui est affirmé, et regarder qui parle.

Je n'ai pas trouvé de faux à proprement parler. Les citations existent, les liens mènent quelque part. J'ai trouvé un récit qui a perdu en route presque tout ce qui permettait de le pondérer, et c'est cette perte que je veux détailler, parce qu'elle sépare le sensationnalisme du journalisme scientifique plus sûrement qu'une erreur de fait.

Pour mes étudiants : ce billet est aussi un exercice. Chaque passage en italique est une consigne que je vous donne, à appliquer à ce texte et à tous ceux que vous lirez ensuite, y compris les miens. La première : avant de réagir à un article, demandez-vous ce qu'il affirme, ce qu'il prouve, et si les deux coïncident. Ce sont presque toujours deux listes différentes.

De l'entretien au titre

La source primaire est un entretien de Steve Yegge avec Gergely Orosz, publié le 10 février 2026 dans la newsletter The Pragmatic Engineer. Yegge y décrit un cadran imaginaire, gradué de 0 à 100, qui indiquerait la part des ingénieurs qu'une entreprise peut licencier, et estime que les grandes entreprises le règlent en moyenne vers 50 : « You're going to have to get rid of half of them to make the other half maximally productive. » La prédiction est bien la sienne, et il ne la met pas au conditionnel. Il lui donne une raison (l'argent dépensé en jetons, en licences et en GPU doit venir de quelque part), mais pas d'horizon, pas de chiffre d'appui, pas d'entreprise nommée. Dans le même entretien, il parle de développeurs cent fois plus productifs, puis précise qu'à ce régime on ne tire d'eux que trois heures utiles par jour, et décrit un épuisement qu'il appelle l'« effet Dracula ».

Voici ce que devient cet entretien en trois reprises :

  1. Le 11 février, Business Insider titre : « He's worked decades in tech and wrote a book on vibe coding. He predicts 50% of Big Tech engineers will be laid off. » Le livre est dans le titre. Le corps de l'article rappelle qu'il est « souvent impossible » d'attribuer des pertes d'emplois à une seule cause, et cite un ingénieur qui décrit la fatigue que lui causent ces outils.
  2. Le 16 février, Science et Vie en fait « un ex-ingénieur de Google et d'Amazon » fort de « plus de quarante ans de carrière ». Le livre a disparu, la réserve sur les causes aussi, la fatigue aussi. Le « environ 50 % » est resté.
  3. Le 28 septembre, le texte est republié sept mois plus tard, avec une date neuve. Il a été retouché entre-temps, puisqu'il contient un lien vers un article du 30 juillet ; la mention entre crochets dit quand il a été écrit, rien ne dit ce qui s'est passé depuis.

Personne ne ment dans cette chaîne. Chaque reprise enlève un peu de contexte, et ce qu'elle enlève est chaque fois ce qui aurait aidé le lecteur à peser le chiffre : qui le donne, avec quelle réserve, à quel prix pour ceux qui sont censés produire cent fois plus. Le chiffre, lui, traverse les trois étapes sans une égratignure.

En journalisme scientifique, on cite la source primaire, on conserve son degré de certitude, et on précise la nature de l'énoncé : hypothèse, résultat mesuré, opinion. Science et Vie donne bien le lien vers l'entretien, et il faut le lui reconnaître. Un lien ne remplace pas ce qu'on choisit d'en rapporter, cependant : le lecteur qui ne clique pas (c'est-à-dire presque tout le monde) repart avec un « ex-ingénieur » et un chiffre.

Consigne n° 2 : remontez toujours à la source primaire. Pas au site qui cite le site qui cite le podcast ; au podcast. Ça prend dix minutes, et c'est là que vous verrez ce qui est tombé en route : ici, les trois heures par jour et l'épuisement, qui sont dans l'entretien et nulle part dans l'article. En recherche, on appelle ça vérifier la citation, et c'est la première chose qu'un relecteur fait sur votre mémoire. Un texte que vous ne pouvez pas remonter jusqu'à sa source ne vaut pas plus qu'une rumeur bien écrite.

Les sources citées

L'article cite trois sources, avec un lien pour chacune. C'est plus que beaucoup d'articles du même genre, et c'est justement ce qui permet de vérifier ce qu'il en a fait.

Source invoquéeCe qu'elle est censée prouverCe qu'on trouve en suivant le lien
« Selon Business Insider, le dirigeant de Meta a souligné ces gains »L'IA multiplie la productivité individuelleUn article sur Yegge, qui mentionne en une phrase que Mark Zuckerberg a dit, lors d'une présentation de résultats, qu'un ingénieur pouvait désormais faire le travail d'une équipe. Un patron qui explique à ses actionnaires ce que rapportent ses investissements en IA : c'est de la communication financière, pas une mesure
« The Pragmatic Engineer »Yegge prédit 50 % de coupesL'entretien existe et la prédiction y figure. On y trouve aussi les trois heures productives par jour et l'« effet Dracula », que l'article ne mentionne pas
« Selon les analyses présentées par TWIT »Des équipes réduites fonctionnent comme des ateliers automatisésUn billet de blog d'un réseau de podcasts, signalé comme « AI-generated, human-reviewed », consacré à Gas Town, l'outil de Yegge. Il le décrit comme expérimental, « not consumer-ready », et demandant une supervision manuelle importante

Les trois liens ramènent au même homme : l'entretien, un article sur l'entretien, et un billet généré par IA sur l'outil que cet homme a écrit. La troisième source parle donc du produit de la personne interrogée pour appuyer ce que dit la personne interrogée, et elle-même était plus prudente que l'usage qu'on en fait.

Le texte compte aussi trois liens vers Science et Vie lui-même, posés sur des expressions générales. Dans la phrase qui affirme que les coûts des entreprises « explosent, portés par les centres de calcul », « centres de calcul » mène à un article du 30 juillet sur « l'enfer des voisins des data centers dédiés à l'IA » : les factures dont il parle sont celles des riverains. « Agents capables de générer des fonctions entières en quelques secondes » mène à « Ce réseau social peuplé d'1,5 million d'IA est interdit aux humains… et inquiète les chercheurs ». « Outils autonomes » mène à « La France veut se libérer des outils US avec sa propre solution de visioconférence ». Aucun des trois n'appuie la phrase qui le porte. Ces liens servent à garder le lecteur sur le site, ce qui est une pratique courante, et ils ont un effet de bord : à l'œil, le texte paraît deux fois plus sourcé qu'il ne l'est.

Ce qui manque en dit autant. Aucune étude sur la productivité réelle des outils de code assisté. Aucun chiffre d'emploi, alors que les statistiques de recrutement en informatique sont publiques et suivies mensuellement. Aucune entreprise nommée ayant annoncé une réduction de postes de développeurs motivée par l'IA. Aucune date pour le « environ 50 % » : dans deux ans, dans dix ans ?

Un article de journalisme scientifique sur le même sujet aurait au minimum : la source primaire, une donnée quantitative indépendante de cette source (une série d'emploi, un essai contrôlé), et un contradicteur.

Consigne n° 3 : classez chaque source par ce qu'elle peut établir. Un dirigeant qui parle à ses actionnaires, un billet de blog, un article de presse et un essai contrôlé n'ont pas le même poids, et une phrase qui commence par « selon » ne prouve rien tant que vous n'avez pas lu ce qui suit le « selon ». Suivez le lien, et demandez-vous si ce qu'il contient dit bien ce qu'on lui fait dire. Dans vos propres rapports : une source, un lien, une phrase exacte. Si vous ne pouvez pas citer précisément, ne citez pas.

Les raisonnements

Une fois les sources examinées, il reste l'argumentation. Elle repose sur quatre enchaînements, tous présentés comme évidents, aucun démontré.

Les licenciements prouvent l'effet de l'IA. L'article le concède lui-même : les coupes ne sont « pas uniquement » liées à la fin du cycle post-Covid. Les grandes vagues de licenciements dans la tech ont commencé fin 2022, quand les agents de code n'existaient pas en production, et les entreprises ont invoqué la sur-embauche de 2020-2022 et la hausse des taux d'intérêt. Ajouter que « la montée en puissance de l'automatisation » pèse aussi dans la balance, sans un seul cas documenté, c'est prendre une coïncidence de calendrier pour une cause. Business Insider, sa propre source, prenait la précaution que l'article n'a pas reprise. Le récit arrange beaucoup de monde : un dirigeant préfère annoncer une transformation technologique qu'une erreur de gestion, et un journaliste préfère une rupture à un ajustement comptable.

Consigne n° 4 : deux choses qui arrivent en même temps ne sont pas liées parce qu'elles arrivent en même temps. Vous connaissez la phrase, mais regardez comme elle est facile à oublier quand le récit est plaisant. Le test à faire : quelle autre explication couvre les mêmes faits ? Ici, la sur-embauche et les taux d'intérêt expliquent les licenciements sans l'IA. Tant que vous n'avez pas éliminé cette explication, vous n'avez pas le droit à la vôtre.

Il faut choisir entre les GPU et les humains. C'est le raisonnement de Yegge lui-même : les jetons, les licences et le calcul coûtent cher, et l'argent doit venir de quelque part. Il vaut pour une entreprise qui entraîne des modèles, et peut-être pour les équipes qui font tourner des dizaines d'agents en parallèle toute la journée, comme celles que Yegge décrit. Pour une entreprise qui équipe ses développeurs d'un assistant de code, la licence se compte en dizaines ou en centaines d'euros par mois et par poste, face à un salaire chargé qui se compte en milliers ; l'outil s'ajoute aux frais sans obliger à trancher. L'article généralise le cas extrême à « la tech » et ne dit jamais duquel il parle.

Plus de productivité, donc moins d'emplois. C'est le saut le plus lourd et le moins interrogé. L'histoire du logiciel montre l'inverse à chaque génération d'outils : compilateurs, environnements de développement, bibliothèques, cloud. Chaque fois, le coût de production a baissé, la demande de logiciel s'est élargie, et l'emploi total a augmenté. Rien ne dit que cette fois est différente, rien ne dit non plus que c'est pareil, et c'est précisément la question ouverte qu'un article sérieux poserait. Celui-ci la tranche dans le titre et la contredit dans sa dernière partie en annonçant « une explosion de petites équipes innovantes ». Si quelques ingénieurs en startup rivalisent avec des géants, le nombre de développeurs ne baisse pas forcément ; il se redistribue.

Les gains de productivité sont acquis. L'article parle d'un développeur qui « peut désormais accomplir ce qui demandait, hier encore, tout un groupe ». Dans l'entretien d'origine, Yegge parle d'un facteur 100, mais ajoute qu'on ne tire de ces développeurs que trois heures productives par jour et décrit l'« effet Dracula » : l'outil prend les tâches faciles et laisse la réflexion intense toute la journée. L'article a gardé le multiplicateur et laissé la contrepartie dans la source. Les mesures indépendantes disponibles racontent autre chose : l'essai randomisé de METR publié en juillet 2025, sur des développeurs expérimentés travaillant sur leurs propres bases de code, a mesuré qu'ils mettaient 19 % de temps en plus avec les outils d'IA, alors qu'ils s'estimaient 20 % plus rapides. L'écart entre la productivité perçue et la productivité mesurée est le résultat le plus solide du domaine, et l'article n'en dit pas un mot.

Consigne n° 5 : méfiez-vous de ce que vous ressentez sur votre propre productivité, la vôtre comme celle des autres. L'essai METR est important pour ça : les développeurs étaient sincèrement convaincus d'aller plus vite, et le chronomètre disait l'inverse. Un essai contrôlé ne demande pas votre avis. Quand vous évaluerez un outil, un langage ou une méthode, cherchez qui a mesuré, avec quel protocole, et sur quel type de tâche. Un témoignage enthousiaste, même de quarante ans de carrière, ne remplace pas une mesure.

Qui est Steve Yegge

L'article présente Steve Yegge comme un vétéran de quarante ans de carrière, passé par Amazon et Google. C'est exact, et incomplet au point d'être trompeur.

Yegge a publié à l'automne 2025 un livre intitulé Vibe Coding, coécrit avec Gene Kim, dont la thèse est que la programmation par agents change tout. Il a construit Gas Town, un orchestrateur d'agents IA open source, et anime la communauté qui l'entoure. Il intervient dans ce podcast, et dans plusieurs autres la même semaine, pour en parler. Il dit lui-même, dans un autre épisode, qu'être « anti-IA aujourd'hui, c'est être anti-soleil ».

Rien de tout cela n'est un reproche. Yegge a le droit d'être convaincu et de vendre sa conviction. Mais un lecteur qui ne sait pas que le vétéran est aussi l'auteur d'un livre et d'un outil sur le sujet ne peut pas pondérer ce qu'il lit. Le journalisme scientifique a une règle simple pour cela : on déclare les intérêts. Business Insider l'avait fait, dans son titre même : « wrote a book on vibe coding ». Science et Vie avait ce titre sous les yeux, puisqu'il le cite en lien, et a préféré « ex-ingénieur de Google et d'Amazon ».

Consigne n° 6 : à qui profite l'énoncé ? Ce n'est pas une accusation, c'est une pondération. Quelqu'un qui vend un livre sur le vibe coding et qui vous dit que le vibe coding change tout peut avoir raison ; mais son avis pèse moins que celui de quelqu'un qui n'a rien à vendre et qui dit la même chose. Appliquez-le partout, y compris aux enseignants qui vous parlent de leur domaine de recherche. Moi compris.

Le même article, fait correctement

La question « l'IA va-t-elle réduire l'emploi des développeurs ? » mérite un article. Pour relever du journalisme scientifique plutôt que de l'alerte, il devrait contenir :

Aucun de ces points ne demande une compétence particulière. Ils demandent du temps, et l'acceptation qu'un article correctement sourcé fera moins de clics qu'un titre qui annonce la fin d'un métier.

Consigne n° 7 : cette liste est aussi une grille pour vos propres écrits, rapport de stage compris. Source primaire, statut de chaque énoncé, une donnée indépendante, un contradicteur, intérêts déclarés, horizon temporel. Relisez votre dernier document avec ces six points. Si vous en cochez moins de quatre, vous venez d'écrire l'article que ce billet démonte.

Ce que je concède

Je ne défends pas la thèse inverse. Le métier change. Les outils de génération de code existent, je les utilise, et je vois mes étudiants les utiliser. L'entrée dans la profession est plus dure pour les juniors qu'il y a cinq ans, et la part du travail consacrée à relire, tester et cadrer du code qu'on n'a pas écrit augmente. Tout cela mérite d'être dit.

Mais « le travail change de nature » et « la moitié des postes disparaissent » sont deux propositions différentes. La première s'observe. La seconde est une prédiction, faite par une personne intéressée, sans horizon ni donnée, et devenue un titre à force de reprises qui ont chacune laissé tomber une réserve. Personne ne l'a mesurée, et personne, dans cet article, n'a essayé.

Sensationnalisme et journalisme scientifique peuvent traiter le même sujet, sur le même ton ; ils se séparent sur ce qu'ils font de l'incertitude. Le premier l'enlève, parce qu'elle se vend mal, et le second la garde, parce qu'elle fait partie de l'information. Un article qui ne vous laisse aucun moyen de savoir à quel point ce qu'il affirme est établi vous raconte une histoire, et vous laisse avec l'inquiétude.

Dernière consigne, et la plus importante : apprenez à dire « je ne sais pas » et « personne ne sait encore ». C'est la phrase que cet article ne prononce jamais, et c'est celle qui distingue un scientifique d'un commentateur. Sur l'avenir de votre métier, la réponse honnête aujourd'hui est : il change, on ne sait pas encore vers quoi, et ceux qui vous annoncent un chiffre ne le savent pas non plus. C'est moins rassurant, et plus exact.

Références