Il y a quelques jours, un post publié sur Hacker News a collecté 948 points et déclenché 914 commentaires. Le titre est sobre, presque clinique : « LLMs are eroding my software engineering career and I don’t know what to do. » L’auteur n’est pas un junior paniqué — c’est un développeur expérimenté qui décrit en temps réel la compression de sa valeur perçue. Moins d’entretiens. Des postes supprimés. Des équipes qui rétrécissent sans annonce officielle. L’érosion silencieuse.
Ce qui frappe dans la réaction de la communauté, c’est l’absence de consensus mais la présence unanime d’une chose : personne ne remet en question la légitimité de l’inquiétude. Certains disent « moi aussi », d’autres « tu exagères », d’autres encore « voilà ce qu’il faut faire ». Mais l’inconfort est partagé. Et ça, c’est déjà révélateur de quelque chose de plus profond qu’une simple angoisse passagère.
Alors plutôt que de te sortir une liste de « 10 compétences dev indispensables à l’ère de l’IA » (il y en a déjà trop), je préfère regarder ce qui se passe vraiment — pour qui, à quel rythme, et ce qu’on peut concrètement en faire.
TL;DR — Les LLMs ne remplacent pas les développeurs au sens spectaculaire du terme : ils permettent à des équipes plus petites de produire autant. L’impact se fait surtout sentir sur le flux de recrutement, pas sur les postes existants. Certains profils sont clairement plus exposés que d’autres — et savoir où tu te situes change tout à la stratégie à adopter.
Ce que les LLMs ont rendu trivial — honnêtement
Soyons directs : les LLMs sont excellents sur un périmètre précis. Écrire du code CRUD. Générer du boilerplate. Convertir une fonction Python en TypeScript. Expliquer une stack trace. Produire des tests unitaires sur du code simple. Ces tâches ne sont pas marginales — elles représentent une portion significative du travail quotidien de nombreux développeurs, en particulier en début de carrière.
En 2019, un junior passait une bonne partie de son temps sur ces tâches. C’est ainsi qu’on apprenait les patterns, qu’on se formait la main sur de vrais projets. Aujourd’hui, un dev senior avec un bon setup Cursor ou Copilot génère ce même code en quelques prompts. La productivité augmente — mais ça veut aussi dire qu’on a besoin de moins de mains pour produire la même quantité de code.
La question n’est donc pas « est-ce que les LLMs codent aussi bien qu’un dev expérimenté ? » La réponse est non. La question est « est-ce qu’ils permettent à une équipe de 4 de faire le travail d’une équipe de 6 ? » Là, souvent, la réponse est oui. Et c’est là que l’érosion commence.
Les LLMs ne remplacent pas les développeurs. Ils permettent à moins de développeurs de produire autant. Ce n’est pas la même chose — mais pour le marché de l’emploi, l’effet sur la demande est très similaire.
Les profils les plus exposés (sans filtre)
Certains profils sont objectivement plus touchés. Les développeurs qui travaillaient principalement sur des tâches standardisées — intégrations d’API bien documentées, maintenance de petits sites, fonctionnalités CRUD dans des applications existantes — voient leur valeur perçue baisser. Pas parce qu’ils sont mauvais, mais parce que ces tâches sont précisément celles que les LLMs gèrent le mieux. La concurrence n’est plus uniquement humaine.
Les freelances sur des missions courtes de « quick fix » sont aussi sous pression. Un client qui a besoin de corriger un bug dans son site ou d’ajouter un formulaire va de plus en plus essayer de le faire lui-même avec un outil IA avant de penser à embaucher quelqu’un. Parfois ça marche. Parfois non. Mais la barrière à l’entrée pour « essayer soi-même » a radicalement baissé ces dix-huit derniers mois.
À l’opposé, les devs qui travaillent sur de la conception d’architecture, de la sécurité applicative, des systèmes distribués, ou du développement d’applications métier complexes sur mesure sont beaucoup moins exposés. Ces problèmes nécessitent de la compréhension du contexte, du jugement, et une capacité à naviguer dans l’ambiguïté — trois choses que les LLMs actuels gèrent très mal dès qu’on sort des sentiers balisés.
DÉCOUVREZ NOS RÉALISATIONS
My Nounou
Application PWA de mise en relation parents / assistantes maternelles. Planning, cahier de liaison, generation de contrats et fiches de…
Voir le projet →La vraie menace : la compression d’équipes, pas le remplacement
Le scénario « le robot prend ton bureau » est bien plus discret que dans les films. Ce qu’on observe réellement, c’est différent : les équipes recrutent moins. Les startups qui auraient embauché huit développeurs en 2022 en embauchent quatre en 2025 et produisent autant. Les offres d’emploi restent ouvertes moins longtemps. Les missions freelance se raccourcissent ou disparaissent sans vraiment qu’on sache pourquoi.
C’est sur le flux d’entrée que l’impact se fait le plus sentir, pas sur les postes existants. Les devs en poste avec de l’ancienneté et une légitimité établie sont généralement protégés à court terme. Ceux qui cherchent à entrer sur le marché, à changer de poste, ou à progresser dans leur carrière — eux voient la pression monter de façon très concrète, avec moins d’opportunités pour les mêmes compétences.
Ce mécanisme est difficile à nommer parce qu’il n’y a pas de méchant visible, pas de communiqué de presse. Juste une lente normalisation d’équipes plus petites et l’intégration tacite des LLMs comme « multiplicateurs de productivité » dans les critères de recrutement. Certaines offres d’emploi mentionnent déjà explicitement l’usage de Cursor ou GitHub Copilot comme compétence attendue — au même titre que Git ou Docker il y a dix ans.
La vraie question n’est pas « les LLMs codent-ils aussi bien qu’un dev ? » — c’est « de combien de devs ai-je besoin si j’utilise des LLMs ? »
Ce que les LLMs ne savent vraiment pas faire
Autant être honnête sur les deux tableaux. Les LLMs sont très mauvais à plusieurs choses qui comptent énormément dans le vrai travail d’ingénierie logicielle. La première : comprendre un système legacy avec des années de dette technique, des décisions prises pour des raisons oubliées, et des contraintes qu’aucune documentation n’explique. Un LLM ne sait pas que cette fonction bizarre existe parce qu’un client avait un edge case en 2017 et que le corriger coûterait trois semaines de tests de régression.
La deuxième : les trade-offs. Faut-il optimiser cette requête maintenant ou attendre d’avoir plus de données sur les patterns d’usage réels ? Est-ce qu’on sort un MVP fragile pour valider le marché ou on prend le temps de faire les choses proprement ? Ces décisions impliquent du contexte business, une compréhension des risques, et parfois du courage pour dire « non, c’est trop tôt ». Les LLMs produisent des réponses qui satisfont la forme de la question sans jamais vraiment comprendre l’enjeu sous-jacent.
La troisième, moins évidente : la relation avec les autres. Comprendre ce qu’un client veut vraiment dire quand il dit « je veux un truc simple ». Détecter qu’un collègue est au bord du burnout et que ce n’est pas le moment d’empiler une fonctionnalité urgente. Négocier un périmètre sans que tout le monde en ressorte frustré. Ce sont des compétences qui n’ont rien de trivial, et que les LLMs ne peuvent tout simplement pas exercer.
Bonne nouvelle : les compétences qui résistent le mieux aux LLMs sont aussi celles qui font les développeurs les plus appréciés dans une équipe. La technique pure n’a jamais suffi à faire un bon ingénieur logiciel.
Ce qu’on peut concrètement faire (sans bullshit)
Le conseil le plus inutile serait « apprends à utiliser les LLMs ». Tout le monde les utilise déjà. Ce qui compte davantage, c’est de développer les compétences qui restent hors de portée des modèles actuels — et probablement des prochains aussi. La compréhension profonde des systèmes : comment fonctionne vraiment ton runtime, ta base de données, ton réseau. Pas pour snober les abstractions, mais pour savoir exactement quand elles te trahissent.
WESTCODE BY LEB
Studio web en Mayenne — On crée des outils numériques qui transforment
Développer une expertise de domaine est une protection sérieuse et chroniquement sous-estimée. Un dev qui comprend vraiment la logistique, la finance, ou la santé est infiniment plus utile qu’un généraliste capable de générer du CRUD dans n’importe quel langage. Les LLMs sont généralistes par nature. La spécialisation crée de la valeur différenciante que les modèles ne peuvent pas combler par de la complétion de token.
Il y a aussi la capacité à travailler avec les LLMs de manière critique plutôt que de les suivre aveuglément. Savoir évaluer si le code généré est correct, sécurisé, maintenable. Savoir que le modèle peut halluciner une API inexistante ou produire du code qui compile sans faire ce qu’on attendait. Cette compétence de supervision intelligente — ce que certains appellent « engineering judgment » — devient centrale dans les équipes qui utilisent ces outils sérieusement, et elle ne s’acquiert qu’avec de l’expérience réelle.
Mon avis, sans détour
L’inquiétude de l’auteur du post Hacker News est légitime. Pas dramatisée, pas exagérée. Il se passe bien quelque chose de structurel. Mais ce n’est pas une condamnation à mort du métier — c’est une requalification forcée. Ceux qui s’en sortiront le mieux seront ceux qui auront compris ce qu’ils valent au-delà de leur capacité à produire du code propre rapidement.
La valeur d’un bon ingénieur logiciel n’a jamais été dans la vitesse de frappe ni dans la capacité à mémoriser la syntaxe de vingt frameworks. Elle était dans le jugement, la compréhension des systèmes, et la capacité à résoudre des problèmes flous avec des contraintes réelles et souvent contradictoires. Si les LLMs accélèrent la partie mécanique, tant mieux — ça libère du temps pour ce qui compte vraiment.
La vraie question à se poser maintenant : est-ce que tu sais faire des choses qu’un LLM ne peut pas faire, et est-ce que quelqu’un est prêt à payer pour ça ? Si la réponse est oui aux deux, tu es probablement dans une position correcte. Sinon, c’est maintenant qu’il faut bouger — pas dans deux ans quand le marché aura déjà recalibré en silence, comme il le fait toujours.
