Pourquoi l’IA n’a pas remplacé les ingénieurs logiciels, et pourquoi elle ne le pourra probablement pas non plus à l’avenir

• L’ingénierie logicielle est l’un des métiers qui adoptent l’IA le plus rapidement, mais le récit selon lequel des licenciements massifs surviendraient dès que l’IA atteindrait un certain niveau de compétence n’est pas étayé par les preuves actuelles
• Dans les cas de Block, Snap et Intuit, l’IA a été invoquée comme justification des licenciements, mais le contexte réel est plus directement lié à des pressions financières, à des exigences de réduction des coûts et à l’allègement des couches managériales
• Le développement logiciel repose sur une structure en sandwich décision-exécution-livraison, et l’IA comprime la couche d’exécution, mais les couches qui décident quoi construire et qui valident les résultats tout en en assumant la responsabilité résistent fortement à l’automatisation
• Le « vibe coding » consiste à confier le travail à un agent sans supervision ni relecture, alors qu’en pratique les ingénieurs utilisent les agents dans une logique d’agentic engineering où l’humain conserve le contrôle et la responsabilité
• Si l’IA réduit le coût de production du logiciel, elle peut aussi faire naître une demande plus forte de logiciels ; même si la carrière de chaque ingénieur peut être déstabilisée, la demande globale a des chances de rester solide

---

Pourquoi l’IA n’a pas remplacé les ingénieurs logiciels, et pourquoi elle ne le pourra probablement pas non plus à l’avenir

• Coding agents as normal technology

  • L’anxiété et l’incertitude autour de la question de savoir si l’IA va remplacer des emplois sont fortes, mais pour examiner le sujet, il faut regarder le métier de l’ingénierie logicielle, où les capacités de l’IA et son adoption progressent rapidement
  • Le récit selon lequel des licenciements massifs surviendraient dès que l’IA atteindrait un certain seuil de compétence peut être écarté faute de preuves suffisantes
  • Si ce récit ne tient pas dans un secteur où les barrières réglementaires sont presque inexistantes, alors d’autres professions disposent probablement de mécanismes d’amortissement encore plus importants
  • Le travail intellectuel et le développement logiciel peuvent être vus comme un decide-execute-deliver sandwich ; l’IA compresse la couche d’exécution, mais les couches de décision et de livraison ne s’automatisent pas simplement parce que les capacités progressent
  • On peut rester prudemment optimiste quant à l’avenir de la demande en ingénierie logicielle, mais même si la demande globale reste saine, la carrière de chaque ingénieur peut demeurer instable

Les cas de licenciements massifs attribués à l’IA dans le logiciel relèvent surtout d’un « AI washing » typique

• Cas de Block

  • En février, Block a annoncé le licenciement de 4 000 employés, et Jack Dorsey a déclaré que l’IA rendait possibles des « équipes plus petites et plus plates », en évoquant aussi les progrès attendus des modèles d’ici fin 2025
  • Des reportages ultérieurs ont toutefois montré une autre réalité : après avoir plus que triplé ses effectifs pendant la pandémie, Block faisait face à de fortes pressions financières
  • Naoko Takeda, data scientist au sein de l’équipe Cash App, a écrit que Block imposait l’IA à tout le monde mais que les gains de productivité étaient très limités ; elle a refusé une proposition d’augmentation de rétention de 75 % puis a quitté l’entreprise
  • D’autres employés interrogés avaient une perception très différente de ce que l’IA pouvait réellement faire chez Block et de la bonne compréhension du sujet par Dorsey
  • Aaron Levie a souligné que les CEO peuvent réussir à produire rapidement des prototypes, mais tomber dans l’illusion de l’utilité de l’IA parce qu’ils ne voient pas les 90 % de travail nécessaires pour en faire un produit fini

• Cas de Snap

  • En avril, Snap a licencié environ 1 000 personnes, et Evan Spiegel a cité l’IA comme raison principale dans son mémo de licenciement
  • Spiegel a affirmé que 65 % du nouveau code était généré par l’IA
  • En réalité, les licenciements sont intervenus après une campagne d’un investisseur activiste réclamant des réductions de coûts
  • Snap enregistre une perte nette chaque année depuis son IPO de 2017, et son action avait chuté de plus de 30 % en 2026
  • La réduction d’effectifs a surtout consisté à supprimer 150 postes variés dans l’activité de réalité augmentée, ce qui ne correspond pas au type de coupes à l’échelle de l’entreprise dans les postes de programmation ou les fonctions exposées à l’IA auxquelles on s’attendrait si l’IA en était vraiment la cause

• Cas d’Intuit

  • En mai, Intuit a annoncé une réduction de 3 000 postes, en même temps que des contrats avec Anthropic et OpenAI
  • Les médias y ont vu une restructuration centrée sur l’IA, mais le CEO a répliqué que ces suppressions de postes n’avaient rien à voir avec l’IA
  • Il a expliqué que les postes supprimés concernaient des « rôles nécessitant beaucoup de coordination » et un excès de couches managériales
  • Les cas de Block, Snap et Intuit montrent que l’IA sert souvent de justification de façade aux licenciements, alors que le contexte organisationnel réel et la structure de coûts en sont des causes plus directes

• L’AI washing est un phénomène à l’échelle de l’économie

  • Dans tous les récits de licenciements d’ingénieurs logiciels attribués à l’IA examinés ici, on retrouve le même décalage narratif
  • 59 % des responsables du recrutement aux États-Unis reconnaissent qu’au moment d’expliquer un gel des embauches ou des licenciements, il est mieux accepté par les parties prenantes de mettre l’accent sur l’IA plutôt que sur les contraintes financières
  • J. P. Gownder, de Forrester, explique que lorsqu’il demande aux entreprises qui se préparent à des licenciements liés à l’IA si elles disposent déjà d’applications d’IA matures et validées, neuf fois sur dix la réponse est non, et elles n’ont même pas commencé
  • Dans une enquête de HBR auprès de plus de 1 000 dirigeants dans le monde, 21 % ont procédé à de fortes réductions d’effectifs « en prévision » de l’IA, et 39 % à des réductions préventives faibles ou modérées
  • La part de ceux qui avaient déjà effectué de fortes réductions d’effectifs en lien avec une mise en œuvre réelle de l’IA n’était que de 2 %, ce qui montre l’ampleur de l’écart entre les coupes fondées sur l’anticipation et celles liées à une implémentation effective

• Données du WARN Act

  • Le WARN Act impose certaines déclarations en cas de fermeture de site ou de licenciements massifs affectant plus de 100 salariés
  • En mars 2025, l’État de New York est devenu le premier État américain à ajouter une case de déclaration liée à l’IA dans le formulaire de dépôt du WARN Act
  • Au cours de la première année, plus de 160 entreprises ont déposé un avis WARN, mais aucune n’a coché la case IA
  • À la fin mai, selon la confirmation du département du Travail de l’État de New York, seule Nespresso avait coché cette case
  • Si les documents déposés sont exacts, alors sur cette période, sur environ 25 000 licenciements dans l’État de New York, seules 46 personnes étaient concernées par un impact de l’IA, soit environ 0,2 %

• Les licenciements sont un mauvais signal pour mesurer l’effet de productivité de l’IA

  • Des travaux montrent que l’effet de productivité de l’IA se traduit davantage par un ralentissement des embauches que par davantage de licenciements parmi les salariés déjà en poste
  • Licencier des employés existants fait perdre le savoir tacite et le capital organisationnel nécessaires pour utiliser efficacement l’IA
  • Les licenciements sont aussi coûteux en indemnités, en perte de moral et en risque de devoir réembaucher plus tard
  • Le même résultat peut souvent être obtenu en quelques années par attrition naturelle, ce qui rend généralement les licenciements massifs inutiles

• Données sur les tendances de l’emploi

  • Un article d’économistes de la Federal Reserve compile les preuves pertinentes dans le contexte américain
  • L’emploi continue d’augmenter, mais depuis ChatGPT, il progresse d’environ 3 points de pourcentage par an de moins que sur la trajectoire contrefactuelle sans IA
  • Cette méthodologie ne capte pas le travail indépendant, si bien qu’une partie du ralentissement de la croissance a pu être absorbée par la création d’entreprise
  • D’autres études apportent des éléments montrant que l’IA facilite davantage l’entrepreneuriat
  • L’image réelle pourrait être plus saine encore que celle décrite dans l’étude de la Federal Reserve

• Un autre type de destruction d’emplois liée à l’IA existe bel et bien

  • Des pertes d’emplois en ingénierie logicielle peuvent survenir lorsque l’IA réduit la demande pour un produit
  • Chegg et Stack Overflow sont cités comme exemples où l’IA a réduit la demande de produits d’aide aux devoirs ou d’assistance technique, et les deux entreprises ont procédé à des licenciements
  • Dans ce cas, l’IA n’a pas directement exécuté le travail des salariés ; elle a réduit le besoin de ce travail
  • Parmi les 270 professions du recensement américain de 1950, le seul métier disparu à cause de l’automatisation était celui d’opérateur d’ascenseur, mais plusieurs métiers, comme télégraphiste, sont devenus inutiles à cause de nouvelles technologies
  • Chez des entreprises qui vendent l’IA plutôt que de l’acheter, comme IBM ou SAP, les licenciements relèvent davantage d’une restructuration classique consistant à réallouer les effectifs de fonctions existantes vers des lignes de produits en forte croissance que d’un remplacement direct des travailleurs

Pourquoi les coding agents n’ont pas conduit à un remplacement du travail : le decide-execute-deliver sandwich

• La part de code écrite par l’IA n’a quasiment aucun lien avec le remplacement du travail

  • Certains dirigeants de la tech présentent la part de code écrite par l’IA en parallèle de licenciements ou de prévisions de baisse future de l’emploi
  • Cette manière de faire renforce l’idée simpliste que si l’IA écrit tout le code, les développeurs ne sont plus nécessaires
  • Or, la part de code générée par l’IA n’a quasiment aucun rapport avec les indicateurs centraux permettant d’évaluer un remplacement du travail
  • Écrire du code n’était pas le goulet d’étranglement, et ne l’a jamais vraiment été

• Écrire du code n’était pas le goulet d’étranglement

  • Un article de 2019, synthétisant des travaux antérieurs, concluait que le temps consacré au codage par les développeurs était étonnamment faible, entre 9 % et 61 % selon les études
  • Ce résultat concorde aussi avec les données internes de Microsoft sur 6 000 développeurs
  • Après le début du déploiement des coding agents, plusieurs textes publiés fin 2025 ont également souligné que l’écriture de code n’était pas le goulet d’étranglement
  • Les développeurs reconnaissent que même si les agents écrivent la majeure partie du code, l’impact sur la productivité globale reste limité

• Les trois véritables goulets d’étranglement

  • Le véritable goulet d’étranglement est la décision sur ce qu’il faut construire et la manière de le spécifier
  • La validation du résultat livré et la responsabilité qui l’accompagne constituent aussi un goulet d’étranglement essentiel
  • Une compréhension humaine profonde de la base de code, du métier et de l’environnement est nécessaire aussi bien pour la décision que pour la livraison
  • Le travail d’un ingénieur logiciel est un sandwich décision-exécution-livraison, et cette compréhension est la condition préalable des trois couches
  • L’IA a comprimé le milieu du sandwich, mais les deux extrémités sont restées en grande partie inchangées

• Preuve de « Writing Code vs. Shipping Code »

  • Writing Code vs. Shipping Code analyse l’effet de productivité de l’IA sur 100 000 développeurs GitHub
  • Les agents d’IA ont multiplié par 8 le nombre de lignes de code écrites, ce qui correspond à l’idée d’une forte compression de la couche d’exécution
  • Les mises en production n’ont augmenté que de 30 %, ce qui suggère fortement que les goulets d’étranglement humains dans les couches de décision et de livraison sont toujours là

• La couche de décision peut difficilement devenir beaucoup plus mince

  • Les équipes de développement doivent décider quoi construire
  • L’une des leçons importantes qu’apprennent les ingénieurs logiciels juniors est que la spécification des exigences prend plus de temps qu’ils ne l’imaginent
  • Comprimer cette phase entraîne davantage de douleur dans les étapes suivantes
  • Cette couche est difficile à automatiser car elle doit prendre en compte les besoins des utilisateurs, les signaux du marché, les priorités de l’organisation et, dans certains cas, les contraintes réglementaires
  • À mesure que les capacités de l’IA progressent, les types de décisions qu’on peut lui déléguer augmentent, mais les décisions délégables cessent alors d’être une source d’avantage concurrentiel
  • La valeur de la décision humaine remonte vers des niveaux plus élevés, et comme la complexité logicielle augmente avec le temps, ce processus n’a pas de plafond clair

• La couche de livraison subsiste à cause de la responsabilité et de la validation

  • Les équipes humaines doivent assumer la responsabilité des résultats qu’elles livrent
  • À l’avenir, il est possible qu’une équipe déploie du code critique sans l’avoir suffisamment testé ni compris
  • Aujourd’hui, l’IA est trop instable pour que cette manière chaotique de faire ne constitue pas une menace existentielle pour les équipes logicielles et leurs clients
  • Même si les barrières techniques disparaissent, rien n’oblige les humains à céder le contrôle à l’IA
  • Il est possible de maintenir la responsabilité humaine via des normes partagées, le droit et les politiques publiques
  • Le droit de la responsabilité et les réglementations sectorielles jouent déjà un rôle de frein, et peuvent encore être renforcés

• L’ingénieur logiciel du futur ressemblera davantage à un grutier

  • Plus la couche d’exécution est déléguée à l’IA, plus le rôle de l’ingénieur logiciel se rapproche de celui d’un grutier
  • Les agents d’IA réalisent l’essentiel du travail cognitif lourd, et la tâche centrale de l’humain devient la supervision et le contrôle des agents
  • Certains soutiennent qu’un futur où l’humain garde le contrôle n’est pas viable pour des raisons de coût
  • Des cas où des coding agents insuffisamment supervisés ont supprimé des bases de données de production ou provoqué d’autres dégâts font déjà le buzz
  • Ces cas sont moins l’annonce d’une nouvelle norme que des exceptions spectaculaires qui se diffusent justement parce qu’elles choquent, tout en servant de leçon contre une dépendance excessive à l’IA
  • Détecter si l’usage d’une IA insuffisamment supervisée augmente dans les tâches à haut risque constitue une lacune importante dans les données, non seulement pour l’ingénierie logicielle mais pour l’ensemble de l’économie

• Le déclin de la programmation n’est pas un phénomène propre à l’IA

  • La tendance au sandwich qui s’aplatit est nouvelle, mais elle n’est pas propre à l’IA
  • Depuis plus de vingt ans, le Bureau of Labor Statistics suit séparément la programmation et l’ingénierie logicielle
  • En gros, les programmeurs s’occupent surtout de l’exécution, tandis que les ingénieurs logiciels gèrent une part plus large du sandwich
  • La programmation a reculé, est perçue comme une tâche de simple exécution et est bien moins rémunérée
  • L’IA accélère une tendance ancienne en diminuant encore la valeur des compétences d’exécution purement techniques
  • Le schéma dans lequel l’humain reste profondément impliqué dans la décision et la livraison tandis que l’IA automatise la couche d’exécution intermédiaire pourrait s’appliquer largement à l’ensemble du travail intellectuel

Le vibe coding n’est pas l’agentic engineering

• Confusion terminologique

  • Le terme « vibe coding » est utilisé de manière imprécise pour désigner un large éventail de pratiques, ce qui entretient la confusion sur les évolutions de l’ingénierie logicielle
  • Dans le vibe coding au sens strict, l’utilisateur dit à l’agent quoi faire, puis ne le supervise pas pendant l’exécution et ne relit pas le code
  • Cet utilisateur peut ne pas avoir les compétences nécessaires pour revoir le code, et peut ne pas évaluer le résultat sauf s’il est visiblement cassé
  • Cela diffère de la manière dont la plupart des ingénieurs logiciels utilisent les agents

• Agentic engineering

  • La plupart des ingénieurs logiciels utilisent les agents comme des outils tout en conservant, en tant qu’humains, le contrôle et la responsabilité du résultat
  • Le terme agentic engineering se diffuse pour désigner cette pratique
  • À mesure que l’agentic engineering devient la norme, les ingénieurs découvrent que la supervision des coding agents prend plus de temps que prévu
  • Simon Willison dit qu’il se sent mentalement épuisé vers 11 heures du matin après avoir supervisé des agents, ce qui correspond aussi à l’expérience réelle de terrain

• Données SWE-chat

  • SWE-chat est un jeu de données sur les interactions avec des coding agents provenant de développeurs open source ayant volontairement participé à un outil de journalisation
  • Dans cette étude, 44 % du code produit par les agents a survécu jusqu’au commit de l’utilisateur
  • Les commits issus du vibe coding introduisaient des vulnérabilités à un taux 9 fois plus élevé que les commits entièrement écrits par des humains
  • L’intention utilisateur la plus fréquente n’était pas de générer du nouveau code, mais de comprendre du code existant, à hauteur de 19 % contre 13 %
  • Comme le jeu de données est basé sur un échantillon auto-sélectionné, cette étude seule ne permet pas de tirer des conclusions fortes
  • Elle renforce néanmoins d’autres éléments montrant que le vibe coding et l’agentic engineering relèvent de modèles différents

• Différence essentielle

  • Le vibe coding et l’agentic engineering ne sont pas deux catégories totalement séparées, mais les deux extrémités d’un spectre
  • Tous les projets ne se divisent pas entre projet ponctuel et projet critique
  • Tous les workflows ne correspondent pas parfaitement à la colonne de gauche ou de droite d’un tableau
  • Pour la question de l’emploi, l’implication importante est qu’une entreprise ne peut pas embaucher un vibe coder non validé à la place d’un ingénieur logiciel pour déployer du logiciel de production

Que peut-il se passer ensuite ?

• Pourquoi le scénario des licenciements massifs a peu de chances de se concrétiser

  • Les défenseurs de l’IA peuvent affirmer que les licenciements massifs ne sont simplement pas encore arrivés
  • Mais si le modèle du sandwich est juste, cette prédiction ne se réalisera pas
  • L’IA a déjà fortement comprimé la couche intermédiaire du sandwich, et cette compression a en réalité commencé il y a des décennies
  • Même si la couche d’exécution devenait instantanée et parfaite, le changement par rapport à la situation actuelle serait limité
  • Les couches de décision et de livraison résistent à l’IA pour des raisons qui ne tiennent pas à de simples limites de capacité

• La demande d’ingénieurs logiciels pourrait augmenter

  • Non seulement l’IA pourrait ne pas détruire les emplois en ingénierie logicielle, mais la demande pourrait même croître
  • Si les gains de productivité technologique font baisser le coût de production du logiciel, les gens achètent davantage de logiciels
  • Le logiciel est, en termes économiques, fortement élastique au prix
  • Si l’IA ne remplace pas les ingénieurs logiciels, alors une demande accrue de logiciels entraîne une demande dérivée accrue d’ingénieurs logiciels
  • Le « Jevons’ paradox » est le terme économique souvent utilisé dans les discussions sur l’IA pour expliquer cette idée

• Schéma historique

  • L’emploi de programmeur aux États-Unis était proche de zéro vers 1950, alors qu’il atteint aujourd’hui plusieurs millions de personnes
  • C’est très différent de professions comme l’agriculture, où la mécanisation et l’automatisation ont fortement réduit la demande de travail
  • La quantité de calories consommées par une personne est relativement fixe, mais le volume de logiciel produit a été multiplié par un facteur d’un million
  • Une voiture moderne embarque environ 100 millions de lignes de code exécutées sur plusieurs ordinateurs de bord
  • Même s’il existe un plafond à la demande de code, nous n’en sommes manifestement pas proches aujourd’hui
  • Presque tout travail cognitif bénéficie du logiciel, et la baisse du coût du codage grâce à l’IA permet déjà la création d’utilitaires ponctuels à usage professionnel comme personnel

• Cela ne signifie pas forcément que la Big Tech deviendra encore plus dominante

  • Il est possible que l’avenir contienne beaucoup plus de logiciels et davantage d’ingénieurs logiciels, sans pour autant signifier que les grandes entreprises technologiques vont encore grossir
  • Aujourd’hui déjà, la majorité des ingénieurs logiciels travaillent dans des organisations internes d’entreprises qui ne sont pas des sociétés de logiciel
  • Cette part pourrait encore augmenter à l’avenir
  • Les « AI rollups » désignent l’idée selon laquelle des fonds de venture capital ou de private equity rachèteraient des activités de proximité comme des cabinets dentaires ou des cabinets comptables, puis y injecteraient des ingénieurs logiciels ou IA pour les reconstruire en mode AI-native
  • Cette idée peut tout aussi bien finir comme une simple surenchère marketing ; il est encore trop tôt pour trancher

• Réponse aux prédictions de démocratisation

  • Certains prédisent que l’IA va démocratiser l’ingénierie logicielle et donc réduire la demande d’ingénierie logicielle
  • Selon eux, à la fois le volume de logiciel produit et le temps humain consacré à sa production augmenteraient, mais ce travail serait réalisé par des personnes qui ne sont pas ingénieurs logiciels
  • Par exemple, ils imaginent qu’un logiciel juridique pourrait être plus facilement créé par une personne formée au droit que par une personne formée à l’ingénierie logicielle
  • Ce raisonnement tombe dans le piège de confondre vibe coding et agentic engineering, ainsi que la couche d’exécution avec l’ensemble du sandwich
  • Des langages plus anciens comme FORTRAN, COBOL ou SQL étaient eux aussi accompagnés, lors de leur apparition, de promesses de démocratisation de la programmation, qui ne se sont pas concrétisées
  • La véritable barrière n’est pas l’apprentissage de la syntaxe, mais le jugement expert nécessaire pour prendre de bonnes décisions tout en conservant la responsabilité

• Les carrières individuelles pourraient connaître une profonde recomposition

  • Avec le temps, il est probable que les gens consacrent davantage d’heures à faire faire de nouvelles choses aux ordinateurs
  • Cette activité pourra prendre la forme de construction logicielle, de gestion de workflows complexes à l’aide d’agents, ou d’autres formes encore
  • Les compétences nécessaires seront une combinaison de compétences logicielles, de compétences IA et d’expertise métier
  • On ne sait pas encore si les ingénieurs logiciels d’aujourd’hui seront les mieux placés pour s’adapter à ces nouveaux rôles
  • Même si la demande globale de travail logiciel reste forte, cela ne signifie pas que les travailleurs individuellement ne seront pas affectés
  • L’IA provoque une profonde transformation structurelle de la manière de produire du logiciel, et les ingénieurs qui en bénéficieront ou en souffriront dépendront du type d’entreprise où ils travaillent, de leur région, de leur niveau de carrière et de leur vitesse d’adaptation

[GN⁺]

Avis sur Hacker News

• Tout au long de l’histoire de l’industrie informatique, nous avons poursuivi de manière agressive et enthousiaste l’automatisation de l’ingénierie logicielle, et chaque fois cela nous a permis de créer des choses plus grandes et meilleures, plus rapidement
  À mesure que la productivité augmentait, la valeur du travail augmentait aussi et les attentes montaient en parallèle, et jusqu’ici la demande mondiale en logiciels a semblé sans fin
  Si l’IA n’a pas remplacé les ingénieurs logiciel, c’est parce qu’à chaque hausse de productivité, l’objectif s’est déplacé lui aussi
  Il n’y a que deux façons pour que cette dynamique prenne fin : la première, c’est que la productivité devienne enfin assez élevée pour satisfaire toute la demande mondiale en logiciels
  On n’en voit encore aucun signe, et il faudrait expliquer clairement en quoi cette fois serait différente de toute l’histoire de l’industrie informatique
  La seconde, c’est que l’IA, lorsqu’elle agit de façon autonome, devienne un ingénieur logiciel supérieur à l’humain
  Autrement dit, un état où une équipe IA+humain ne ferait pas mieux que l’IA seule ; jusqu’ici, les éléments disponibles suggèrent plutôt que l’IA est un amplificateur pour les développeurs, et que pour obtenir de bons résultats il faut un expert pour donner la direction pendant que l’IA effectue jusqu’à 90 % du travail
  Il n’existe pas de preuve solide qu’un de ces deux scénarios se produira dans un avenir proche, donc les ingénieurs logiciel semblent à l’abri pour le moment
  En revanche, si votre éventail de compétences est étroit et centré sur un domaine précis, par exemple le développement web frontend, il y a davantage lieu de s’inquiéter
  Même si l’IA ne remplace pas l’ensemble des ingénieurs logiciel, il est tout à fait plausible qu’elle absorbe complètement certains domaines spécifiques, sous la direction de profils généralistes

  • Je pense que la fin de parcours du logiciel n’est plus si loin
    Dans l’ensemble, nous produisons déjà plus de logiciels que ce que les gens veulent réellement, et une bonne partie relève du déchet, de l’arnaque flagrante, voire du carrément malveillant
    À terme, pour les petits besoins logiciels du grand public — gestion de listes de tâches, synchronisation de fichiers, etc. — chacun aura probablement son IA pour écrire du sur-mesure, et les ingénieurs logiciel ne resteront plus que sur les grands projets d’entreprise
    Depuis des décennies, la tendance écrasante du logiciel commercial a été une standardisation extrême contre l’utilisateur et sans personnalisation
    On a fini avec un unique happy path, et si cela ne correspond pas à vos besoins, débrouillez-vous
    Il n’existe presque plus de logiciel commercial pour les gens ordinaires, et même l’open source s’éloigne de plus en plus des utilisateurs non techniques
    Bientôt, les gens ordinaires pourront créer eux-mêmes des logiciels qui résolvent leurs problèmes à leur manière
    Dans la plupart des cas, la qualité et la précision importeront peu ; ce qui comptera davantage, c’est que ce soit personnalisé, gratuit, et non une plateforme intrusive de surveillance et de publicité
  • L’exemple du développement web frontend me paraît un peu drôle
    En tant que développeur frontend, je trouve que les modèles de pointe actuels gèrent bien les travaux de plomberie à l’arrière-plan ennuyeux dont je n’ai rien à faire, mais restent encore mauvais pour le vrai travail de design sur mesure que les clients veulent réellement
    Je ne dis pas que quelqu’un a clairement raison ou tort, et je suis d’accord sur le fait qu’un éventail de compétences plus large est probablement la meilleure façon de réussir dans cette nouvelle époque
    Cela dit, on n’en est pas encore au point où les LLM domineraient complètement une partie de la stack au point de faire disparaître les spécialistes du domaine
  • Contrairement à l’idée qu’« on ne voit aucune preuve que cela se produise », on observe déjà au moins un phénomène similaire dans les stores d’applications mobiles
    D’après une analyse récente, le nombre d’applications lancées a fortement augmenté, mais le nombre total d’avis et de téléchargements stagne
    En d’autres termes, il y a beaucoup plus d’applications, mais pas vraiment — voire presque pas — plus d’utilisateurs
    Il suffit de regarder la p.40 / figure 12 de "WRITING CODE VS. SHIPPING CODE: PRODUCTIVITY EFFECTS ACROSS GENERATIONS OF AI CODING TOOLS" : https://www.nber.org/system/files/working_papers/w35275/w352...
    L’analyse se trouve aux pages 42 à 43
    On ne peut pas prouver que la taille du marché est fixe, mais on ne peut pas non plus prouver qu’elle est infinie
    Ce que les gens oublient souvent dans le récit de la croissance économique du logiciel, c’est que l’argent doit venir de quelque part
    Pour continuer à croître, il faut que quelqu’un qui ne paie pas aujourd’hui pour du logiciel se mette à payer, et il faut alors se demander qui sont ces gens, de combien ils disposent, et avec quelles autres dépenses cela entre en concurrence
  • Dire que « la demande mondiale en logiciels a été sans fin » ne signifie pas que tout le monde recherche les technologies les plus récentes et les plus avancées
    Beaucoup d’entreprises s’appuient encore sur des tableurs sur mesure ou sur des technologies comme Microsoft Access
    Parce que cela fait exactement ce qu’elles veulent, avec un coût fixe, et presque aucun besoin de modifications supplémentaires ou de maintenance
    Quand on sort de la bulle dans laquelle on vit, on se rend compte que beaucoup de gens ne s’intéressent pas aux mises à niveau ; ils veulent simplement que les vieilleries qu’ils connaissent déjà continuent de fonctionner
  • Si l’IA peut effectuer 90 % du travail sous la direction d’un expert, cela veut dire qu’elle pousse 90 % des développeurs hors de l’emploi
    Et je vois mal pourquoi cette proportion ne pourrait pas monter à 99 %

• L’IA va clairement remplacer les ingénieurs logiciels
  Ce qui manque, comme le dit le texte, c’est la livraison et l’exploitation, et c’est davantage le domaine du DevOps/SRE/des ingénieurs cloud que celui des ingénieurs logiciels
  Je travaille comme ingénieur cloud, et plusieurs amis non ingénieurs m’ont contacté pour me dire qu’ils pouvaient désormais créer chacun leur side project de zéro, en plusieurs langages, et l’exécuter en local, en web app ou en application native
  Ce qui leur manque, c’est une plateforme pour déployer et maintenir cela aussi facilement qu’un « développeur ordinaire »
  Aujourd’hui, construire cette base reste assez fastidieux, mais avec AGENTS.md, des skills et des tests d’intégration stricts, c’est tout à fait possible
  Une fois cela en place, un utilisateur non technique peut continuer à développer sans embaucher d’ingénieur logiciel, simplement en disant à claude/codex ce qu’il veut
  claude/codex peut raisonner à partir d’une architecture définie à l’avance et guider l’utilisateur non technique
  Dans les cas anecdotiques que j’ai vus, l’IA a déjà remplacé plusieurs ingénieurs logiciels
  Si ce type de base devient un produit, je pense que les projets greenfield pourront être gérés uniquement du point de vue produit, via des agents codeurs et de la platform engineering
  C’est la situation actuelle ; il suffit d’imaginer où on en sera dans 5 ans

  • Ce raisonnement, bien que difficile à comprendre, est très répandu
    Le fait que des non-ingénieurs arrivent avec des applications qu’ils ont créées ne signifie pas que l’IA a remplacé ou remplacera les ingénieurs logiciels
    On peut chercher ses symptômes avec Dr. Google, essayer des changements d’habitudes de vie, des remèdes à base de plantes ou des médicaments en vente libre, et obtenir de vrais résultats ; cela ne veut absolument pas dire que les médecins vont disparaître
    On peut créer de la musique avec l’IA générative sans théorie musicale, sans sens musical et sans créativité ; cela ne signifie pas non plus que les personnes ayant un talent musical vont disparaître
    Même si l’IA peut aider pour du DIY à la maison, cela ne fait pas disparaître les ingénieurs
    Qui aidera les experts métier à clarifier ce dont ils ont réellement besoin par itérations prototype-amélioration ?
    Qui écrira et maintiendra les systèmes d’exploitation, langages, systèmes de gestion de versions, éditeurs et émulateurs de terminal, systèmes de gestion des connaissances et de la documentation, plateformes PaaS, etc., sur lesquels s’appuient les amateurs qui fabriquent du logiciel ?
    Ont-ils testé ce qu’ils ont construit de manière suffisamment rigoureuse pour pouvoir garantir sa robustesse ?
    Comprennent-ils les cas limites qui peuvent se présenter ?
    La sécurité est-elle correcte ?
    Produire rapidement quelque chose avec un prompt n’est pas la même chose que faire de l’ingénierie
    Si on ne le voit pas, c’est peut-être à cause de l’erreur qui consiste à croire que la valeur du software engineering réside surtout dans le code produit, c’est-à-dire dans le simple tableau de bits
    La valeur principale d’un projet réside dans le processus de construction de théorie et d’abstractions : https://pages.cs.wisc.edu/~remzi/Naur.pdf
  • La génération et la maintenance sont deux bêtes totalement différentes
    Il existe peut-être des ingénieurs qui créent une app en deux semaines puis n’y retouchent plus jamais, mais je ne connais pas grand monde qui en vive
    Des choses comme « un site WordPress pour votre entreprise » sont peut-être possibles
    Le problème apparaît quand il y a 432 fonctionnalités et qu’il faut ajouter la 433e sans toucher aux autres
    Dans certains cas, on n’a pas le droit à l’erreur ; dans d’autres, une seule fonctionnalité augmente la complexité plus vite que ce qu’un ingénieur peut absorber, jusqu’à ce que le projet devienne avec le temps ingérable
  • Dans notre entreprise, des équipes non techniques ont commencé à créer elles-mêmes des outils parce que les équipes techniques étaient surchargées
    C’était l’idée d’une petite application connectée à un gros système, et une preuve de concept a été réalisée en 2 à 3 jours avec 3 ou 4 commits
    C’était impressionnant, mais la personne qui l’a créée a ajouté 400 commits de plus sur ce projet au cours des 3 derniers mois, et à force de correctifs, construire et maintenir cette app est en pratique devenu un travail à temps partiel, voire à temps plein
    Cette personne est devenue un développeur logiciel non formé, sans comprendre la sécurité ni les bonnes pratiques
    Si Claude s’améliore, la charge diminuera peut-être et cela ne lui prendra peut-être plus ses journées, mais dans notre entreprise, toutes ces premières « vibe apps » sont devenues du travail de maintenance qui consomme de plus en plus de temps
    Il est clair que les gens ne veulent pas moins de logiciel, mais davantage
    Même si l’ingénierie logicielle traditionnelle peut disparaître, la gestion de plateformes en expansion, la sécurité, la complexité, la documentation et la logique métier restent toujours devant nous dans l’entreprise
    Il est vrai qu’on peut créer un projet avec du texte, mais dès qu’on dépasse le logiciel le plus simple, je n’ai jamais vu de vrai « configurez et oubliez »
    Il faut toujours quelqu’un pour piloter l’ensemble
    Que cette personne ait reçu ou non une formation en ingénierie logicielle
    Un développeur expérimenté a encore de fortes chances de mieux s’en sortir qu’une personne non formée
    Bien sûr, les builders curieux rattraperont vite leur retard, mais les développeurs traditionnels gardent un énorme avantage
    Parce que nous avons toujours voulu savoir comment les choses fonctionnent à l’intérieur
    Leur vibe app actuelle, qu’ils ont mise plusieurs mois à construire, j’aurais pu la faire en une heure avec l’IA
  • Le déploiement logiciel est déjà descendu au niveau d’un simple vercel lancé dans le terminal, et un agent peut lui aussi le faire sans aucun problème dès qu’on le lui demande
    Déployer un logiciel desktop reste un peu plus difficile selon la plateforme
    Malgré cela, l’écart entre un side project et un excellent logiciel reste très large, et j’ai du mal à croire qu’il sera un jour comblé
    Je ne vois pas pourquoi ce qui était déjà un problème résolu avant l’IA ne serait pas remplacé en premier
    J’ai aussi du mal à croire qu’un projet personnel ait besoin d’une infrastructure complexe
  • Le coding assisté par l’IA est formidable, mais à mon avis le vibe coding n’est bon que pour des prototypes jetables
    Je ne construirais pas une application financière à maintenir indéfiniment en vibe coding
    Je ne toucherais pas non plus à un système legacy
    L’IA a clairement remplacé certains ingénieurs, mais les exemples d’amis non ingénieurs qui créent des side projects sont peu pertinents
    Ils les ont construits parce que c’est devenu possible, pas forcément parce qu’ils prévoyaient au départ d’embaucher quelqu’un pour les réaliser
    Comme ils ne l’avaient jamais fait jusqu’ici

• Je travaille dans une agence de développement, et la plupart de nos clients sont des startups qui doivent arriver vite sur le marché.
  Nous utilisons le développement fondé sur des agents depuis environ un an et demi, et pendant ce temps notre rôle a beaucoup changé.
  Il m’est difficile de parler du volume de projets entrants sans chiffres précis, mais je peux au moins dire qu’il y a eu un changement visible dans les attentes quant à ce qu’il est possible de livrer.
  Des projets qui nécessitaient autrefois 5 personnes sont désormais généralement réalisés par 1 ou 2 personnes.
  En pratique, les projets greenfield sont désormais largement automatisés.
  Beaucoup de tâches manuelles — itérations de design UX/UI, itérations d’architecture système, essais de plusieurs approches sur des problèmes difficiles sans métriques claires — se font maintenant instantanément.
  Si vous pouvez le comprendre dans votre tête, vous pouvez en quelque sorte le mettre au monde en un centième du temps.
  Pendant cette période, ma manière de travailler et de penser les systèmes a elle aussi beaucoup changé.
  Je suis entré en symbiose avec les LLM, et il est désormais vraiment difficile de s’en passer.
  Cela ne veut pas dire que je ne comprends pas le code qu’un LLM écrit, et je suis tous les changements tout en comprenant la base de code bien plus largement que le LLM.
  En revanche, ma capacité à écrire du code manuellement s’est nettement atrophiée, et je pense que ce n’est pas grave.
  Aujourd’hui, j’ai l’impression d’être une sorte de couche de traduction entre les objectifs business et la technologie qui les soutient le mieux.
  Cela reste de la résolution de problèmes, mais à un niveau bien plus élevé, et c’est toujours intéressant et amusant.
  La meilleure stratégie pour les développeurs à cette époque semble être de conserver un esprit critique et d’utiliser les outils à leur avantage.
  Désormais, tout le monde a obtenu des superpouvoirs.
  Il n’est même pas nécessaire de travailler dans une entreprise, et un développeur solo peut créer des choses incroyables, donc il n’y a plus autant besoin de dépendre des autres qu’avant.
  Peut-être que l’avenir sera une économie de produits macro où chacun apporte au monde quelque chose d’unique.

  • Je pense que des lectures du type « désormais, tout le monde a des superpouvoirs » montrent que les enthousiastes de l’IA comprennent bizarrement mal la situation.
    Si le code par agents devient assez bon pour créer des projets greenfield, cela affectera non seulement les développeurs, mais aussi l’entreprise entière et des secteurs industriels entiers.
    Le modèle économique des agences de développement existe parce que des entreprises peu à l’aise avec la technique ne savent pas gérer le logiciel, et dans certains cas il y a aussi un opportunisme consistant à externaliser un travail initial très intensif en main-d’œuvre.
    Mais maintenant que cette technologie est déjà au bout des doigts des clients des agences, ce n’est qu’une question de temps avant que des CEO et managers se mettent au vibe coding et réalisent qu’ils n’ont besoin que d’« un développeur un peu à l’aise avec la technique ».
    Cela peut aussi s’étendre à beaucoup d’activités SaaS.
    Beaucoup de petites entreprises veulent toujours un logiciel sur mesure pour éliminer du travail manuel, mais les développeurs logiciels sérieux ont toujours été trop chers.
    Elles ont donc souvent fini avec le code bancal du neveu de quelqu’un ou avec un SaaS qui fonctionne à peine.
    Désormais, elles peuvent créer leur propre solution sur mesure — encore assez bancale, certes — et en tirer davantage.
    Ce que fait la big tech ressemble davantage à un réajustement lié au ralentissement économique, et ce qui m’inquiète davantage, c’est la perturbation du secteur technologique des PME.
  • Si l’on travaille dans une entreprise, ce n’est pas seulement parce qu’un développeur ne peut pas livrer seul.
    C’est aussi parce qu’il n’a pas le réseau nécessaire pour gagner des clients.
    La plupart des développeurs ont besoin que l’entreprise prenne au moins en charge le marketing pour qu’ils puissent se concentrer sur ce qu’ils font bien.
  • Je ressens déjà l’atrophie de la capacité à écrire du code.
    Générer du code et juger du code mobilisent des capacités différentes dans le cerveau.
    Comme la programmation comporte surtout beaucoup de petits détails syntaxiques, on peut avoir du mal à écrire du code tout en restant bon en revue de code.
    https://xcancel.com/karpathy/status/2015883857489522876
  • Il ne faut pas confondre ce qui est théoriquement possible et ce qui est réalistement possible.
    Dans le monde réel, les entreprises qui réussissent disposent de douves défensives fondées sur les données, les brevets et la propriété intellectuelle, les effets de réseau, etc.
    Ce n’est pas parce que le temps de développement est réduit au centième qu’on peut aussitôt créer une nouvelle activité.
    Quand on regarde aujourd’hui le secteur tech, on voit beaucoup d’entreprises qui semblent pouvoir être bouleversées par des builders agiles dopés à l’IA, mais en pratique cela n’arrive pas à cause des effets de verrouillage.

• L’affirmation selon laquelle « parmi les 270 professions du recensement américain de 1950, une seule a disparu à cause de l’automatisation, celle d’opérateur d’ascenseur » est trompeuse.
  Sur la même période, les emplois agricoles sont passés de 15 % de la population active à 2 %.

  • Le texte semble aussi aborder ce point.
    Il dit que c’est différent des métiers comme l’agriculture, où la mécanisation et l’automatisation ont fortement réduit la demande de travail.
    La différence, c’est que la quantité de calories consommées par les gens est relativement fixe, et qu’une hausse de 25 % suffit à provoquer une épidémie d’obésité, alors que la quantité de logiciel produite a été multipliée par un million.
  • L’emploi agricole lui-même a diminué d’un quart par rapport à 1950.
    Le chiffre en pourcentage exagère la baisse parce que l’ensemble de la population active a augmenté.
    Mais si l’on regarde l’emploi dans l’industrie alimentaire au sens large, il a considérablement augmenté.
    Donc l’emploi des « codeurs » peut baisser alors que l’emploi dans l’industrie plus large du « logiciel / de la tech » peut augmenter.
  • Il suffit de regarder l’industrie forestière.
    Environ 95 % de ces emplois ont déjà été automatisés, mais ils accusent souvent les chouettes.
  • C’est une manière typique d’utiliser les statistiques de façon sélective.
    Même chose pour les usines et les tapis roulants.
    À chaque arrivée de l’automatisation, des gens perdent effectivement leur emploi, et nous ne faisons qu’« espérer » qu’ils trouvent autre chose, ou bien nous leur servons un optimisme extrême et incohérent du genre « devenez généraliste », « devenez expert », « allez dans les services », « apprenez à coder », « extrayez du charbon ».
    Il suffit d’écouter @pmarca pour voir à quel point le leadership technologique est perdu et incohérent.
    Le dernier livre de Stripe Press sur l’automatisation industrielle vaut aussi le détour : https://press.stripe.com/origins-of-efficiency

• Les personnes qui ont cru le plus naïvement en l’IA étaient en général des bricoleurs.
  C’est compréhensible, puisque le code assisté par LLM a accéléré de façon étonnante la vitesse à laquelle on peut bidouiller quelque chose.
  Le bricolage est un processus, et les gens tirent un grand plaisir de l’acte même de construire et d’ajuster.
  Le résultat n’est qu’une considération secondaire ou tertiaire.
  L’IA a considérablement élargi notre capacité d’agir et donc de bricoler, mais elle ne produit pas à elle seule un impact significatif, c’est-à-dire de « l’ingénierie ».
  L’impact compte plus que l’activité.

  • Le bricolage ressemble souvent à de l’ingénierie avant qu’une organisation ne construise des processus autour.
    Le prototypage, le débogage, les tests, etc., ne sont pas du faux travail sous prétexte qu’ils vont vite.
    Un compilateur non plus ne produit pas d’impact par lui-même.
    Il en va de même pour la CI, les IDE, les frameworks et l’infrastructure cloud.
    Ces outils augmentent le levier de la personne qui les utilise.

• Mon épouse a été remplacée par une IA
  Elle était programmeuse, et l’entreprise a créé un agent avec pour objectif affiché de remplacer mon épouse et quelques autres personnes, puis l’a licenciée environ un mois après qu’il a commencé à fonctionner.

  • Le moral des collègues qui sont encore là doit être mauvais
    Notre équipe a eu un nouveau manager il y a 18 mois, et il y avait un favoritisme flagrant ; la seule personne qu’il appréciait était aussi la seule à ne pas être un joueur d’équipe.
    Pendant 18 mois, il a trouvé des moyens de licencier tous les télétravailleurs, indépendamment de leurs performances passées.
    L’un d’eux avait même reçu à plusieurs reprises des récompenses d’un niveau supérieur à celui du manager, mais le manager ne reconnaissait toujours que cette personne toxique.
    Ce n’était pas un remplacement par l’IA, mais l’ambiance où les gens ont l’impression de n’avoir aucune valeur doit ressembler à ce qu’on ressent quand on est remplacé par une IA.
    Tout le monde dans cette équipe, y compris mon superviseur, est en train de postuler ailleurs.
    Mon superviseur est autiste à haut niveau de fonctionnement et est souvent tourné en ridicule par le manager.
    J’espère vraiment qu’ils y arriveront, pour leur santé mentale.
    J’ai signalé le problème plusieurs fois aux RH, et j’ai même trouvé des clauses du règlement de travail que le manager enfreignait, mais j’ai appris qu’au moins ici, ces règles ne sont que des mots sur le papier.
    En fait, cela revenait surtout à me mettre une cible dans le dos, donc j’ai dû partir.
    Plusieurs autres personnes ont aussi exprimé leurs inquiétudes, et la plupart d’entre elles ont depuis trouvé un autre emploi.
    Heureusement, j’ai moi aussi trouvé un nouveau poste où aller bientôt, et j’ai hâte d’y être.
  • Ça a l’air dur
    J’espère que ça ira.
    Je me demande ce qui s’est passé ensuite, si elle a trouvé un nouveau poste, et si c’est toujours dans le logiciel.

• Le fait que la communication des entreprises sur les licenciements liés à l’IA soit mensongère n’annule pas le risque
  Même si le discours des entreprises est faux, l’impact de la technologie peut être réel ; dans ce contexte, ce n’est que du bruit.
  L’hypothèse, comme dans le diagramme du burger de l’article, selon laquelle la phase d’exécution rétrécit tandis que toutes les autres grossissent au point que la taille totale du burger reste la même, ne me paraît pas très plausible non plus.
  Cela dit, certaines parties du génie logiciel semblent encore très loin d’être menacées.
  En particulier les domaines où la précision est essentielle.
  Le développement web laisse beaucoup plus de place à l’à-peu-près, mais le code de guidage d’une fusée, c’est autre chose.
  Les LLM pourront peut-être faire les deux, mais je ne pense pas que qui que ce soit fera du vibe coding sur le second de sitôt.

• L’IA a littéralement déjà remplacé une partie du travail, et cela continuera
  Elle ne remplacera pas tous les ingénieurs logiciels, mais maintenant que la boîte de Pandore est ouverte, les tâches à faible effort et faible risque seront faites par l’IA.
  Il y a énormément de projets réellement en production sur des services comme Lovable, et l’alternative aurait été qu’un humain les développe.

  • Peux-tu montrer un projet “excellent”, écrit ou prompté dans Lovable par un non-spécialiste du logiciel, qui soit réellement utile comme outil SaaS complet ?
  • L’alternative n’était peut-être pas qu’un humain le construise, mais qu’il n’existe tout simplement pas.

• Ce sont toujours les employeurs qui remplacent les emplois
  Il ne faut pas anthropomorphiser un amas de cartes graphiques.

  • Si cet amas de cartes graphiques devient réellement plus efficace, les employeurs qui voudraient embaucher des humains ne pourront plus rivaliser.

• Je ne suis pas convaincu par cette partie de l’article
  L’affirmation est que « les vrais goulots d’étranglement sont (1) décider quoi construire et le spécifier, (2) valider ce qui est livré et en assumer la responsabilité, (3) avoir une compréhension humaine profonde de la base de code, du métier et de l’environnement ».
  Il se peut qu’on ait consacré beaucoup d’efforts en amont et en aval précisément parce que le codage était considéré comme coûteux et comme un goulot d’étranglement, afin de s’assurer que les entrées étaient correctes et de ne pas jeter les livrables.
  Si le codage est perçu comme une étape rapide et peu coûteuse, on n’aura peut-être plus besoin du même niveau de supervision en amont, puisqu’on pourra simplement jeter la sortie.

  • Le coût de jeter du mauvais code n’est pas le principal coût de construire la mauvaise chose
    Les conséquences quand un logiciel dysfonctionne, ainsi que le maintien de la rétrocompatibilité, sont bien pires.