Coder n'a jamais été le métier

TL;DR : Le métier de "codeur" — la personne dont la valeur principale est de traduire une intention en syntaxe — est en train d'être automatisé. Mais le développement logiciel ne meurt pas. Il évolue vers ce qu'il aurait toujours dû être : concevoir des systèmes, comprendre les métiers, structurer le contexte et exercer son jugement. Les rôles de demain émergent déjà. Certaines entreprises recrutent déjà pour eux.

Dans mon article précédent, j'ai argumenté que le SDLC est mort. Que la cérémonie, le processus, les validations humaines — la majeure partie a toujours été du gaspillage. Les agents IA ont juste rendu impossible de faire semblant.

Mais tuer le processus soulève une question évidente : si l'IA écrit le code, exécute les tests, génère la doc et déploie en production — que reste-t-il aux humains ?

Les chiffres devraient vous réveiller : le recrutement de développeurs juniors en Big Tech s'est effondré de 73% en un an. Le métier de "codeur" disparaît en temps réel. Mais la réponse à ce qui reste n'est pas "rien." C'est "tout ce qui comptait vraiment depuis le début." On ne le voyait pas parce qu'on était trop occupés à taper des points-virgules.

Coder n'a jamais été le métier

Voici ce que personne ne veut dire tout haut : coder a toujours été une couche de traduction. Une couche de traduction lente, imparfaite et source d'erreurs entre ce que vous vouliez dire et ce que la machine faisait.

Vous aviez une règle métier en tête. Vous la traduisiez dans un langage de programmation. Le compilateur la traduisait en code machine. À chaque étape, de la fidélité était perdue. Chaque bug était une erreur de traduction. Chaque revue de code était une vérification de l'exactitude de cette traduction. Toute l'industrie a construit des cérémonies autour de la gestion du risque que cette traduction tourne mal.

Les agents IA court-circuitent toute la chaîne. Vous décrivez ce que vous voulez. L'agent produit du code fonctionnel. Pas du pseudo-code, pas un brouillon — du code fonctionnel, testé, déployable. La couche de traduction qui a défini une génération de carrières est compressée à quasi-zéro.

Andrej Karpathy a récemment construit un outil open-source qui note chaque métier aux États-Unis sur son exposition à l'IA, à partir des 342 professions du Bureau of Labor Statistics. Les développeurs logiciels sont notés 8-9 sur 10. C'est plus haut que les infirmiers, les médecins et les vendeurs. Le produit du travail est numérique, le poste peut s'exercer entièrement à distance, et l'activité principale — écrire du code — est exactement ce que les LLMs font le mieux.

"La profession est en train d'être profondément restructurée."
— Andrej Karpathy

Mais voici la nuance qui échappe à la plupart : ce score de 8-9 couvre toute la catégorie BLS "Software Developers" — codage et ingénierie confondus. Mon argument est que c'est la partie codage qui tire l'exposition vers le haut. La partie ingénierie — décider quoi construire, pourquoi, et comment les pièces s'assemblent — est précisément ce que l'IA ne sait pas faire. Le codeur est exposé. L'ingénieur ne l'est pas.

Enlevez le code, et ce qui reste est ce que les ingénieurs seniors ont toujours su être l'essentiel : comprendre le domaine, concevoir l'architecture, prendre des décisions produit et exercer le jugement. C'est ça que le développement logiciel aurait toujours dû être. On l'a juste enterré sous dix couches de syntaxe, de frameworks et de processus.

À quoi ressemble mon équipe aujourd'hui

Je ne théorise pas. Mon équipe est déjà en mouvement — honnêtement, pas encore au bout de la transition.

La plupart de mes développeurs maîtrisent toute la chaîne : compréhension produit, code, tests, documentation et livraison. Ils ne passent pas le relais à une équipe QA. Ils ne demandent pas au DevOps de configurer le pipeline. Ils font tout avec les agents IA.

Mais je vais être honnête : on a encore un PO dédié pour l'interopérabilité. En santé, l'interopérabilité — HL7, HPRIM, FHIR, les protocoles qui connectent les systèmes hospitaliers — est un domaine tellement profond et critique qu'il nécessite encore un spécialiste qui vit et respire ces standards. La complexité métier est massive. Nous travaillons activement à simplifier la couche d'analyse en structurant tout ce contexte métier pour que les agents puissent aider davantage. Le rôle n'a pas disparu — il évolue.

Voici comment on traite une demande de fonctionnalité aujourd'hui. Elle arrive — d'un utilisateur, d'un retour terrain, d'une anomalie repérée. Le développeur la prend en charge directement. Il comprend le besoin métier, discute des cas limites avec le PO, décrit la solution à l'agent avec le bon contexte architectural, valide le résultat, vérifie les tests, et pousse en production. Une personne. Une matinée. Même traçabilité.

Dans l'ancien monde, cette même demande passait par un PO qui écrit une story, un développeur qui implémente, un relecteur qui valide, un QA qui vérifie, et un responsable de mise en production qui livre. Cinq rôles. Trois semaines minimum. Le besoin était le même. Seule la cérémonie changeait.

Mes trois stagiaires et mon alternant — tous en dernière année d'école d'ingénieur — travaillent de la même façon. Ils ne se spécialisent pas en "Java" ou "Angular." Ils se spécialisent dans la compréhension du problème. L'agent gère le reste. Ils progressent plus vite que n'importe quel junior que j'ai vu en 14 ans parce qu'ils investissent leur énergie cognitive dans le domaine, pas dans des batailles de syntaxe.

Ce n'est pas le futur. C'est un mardi.

La grande fusion

Le signe le plus visible de cette transformation, c'est la convergence des rôles. Les murs entre développeur, product owner, designer, QA et DevOps s'effondrent. Pas parce que les compétences ne comptent plus — mais parce qu'une seule personne peut désormais couvrir tout le spectre. Cette tendance est déjà concrète aux US — et quasiment invisible en France, où les offres sur APEC et Welcome to the Jungle semblent encore dater de 2019. C'est précisément là qu'est le levier.

Product Engineer — le nouveau rôle le plus concret

Il apparaît déjà sur les sites d'emploi — environ 3-5% des offres d'ingénierie aux US, et il commence à émerger dans les scale-ups françaises. Une personne unique combinant vision produit, maîtrise technique et expertise métier — auparavant répartis entre PM, PO et développeur. Andrew Ng a noté que les équipes inversent les ratios de 1 PM pour 4 ingénieurs vers l'équivalent de 2 PMs pour 1 ingénieur, à mesure que l'IA réduit l'écart d'implémentation.

"L'utilisation réflexe de l'IA est désormais une attente de base."
— Tobi Lütke, PDG de Shopify

Shopify appelle ces profils des "spiky generalists" — profonds dans un domaine, mais naturellement tournés vers les tâches à plus forte valeur plutôt que confinés dans un rôle prescrit. Quand un agent peut générer n'importe quel composant UI ou endpoint backend, la valeur se déplace de l'implémentation vers le jugement produit — comprendre les utilisateurs, concevoir les interfaces, prendre les décisions de priorisation. La fusion designer + développeur frontend suit naturellement.

Context Engineer — le rôle qui n'existe pas encore sur les sites d'emploi français

C'est ce que je fais chaque jour, et c'est le rôle qui m'enthousiasme le plus — même si en mars 2026, vous ne trouverez pas une seule offre de "Context Engineer" sur un site d'emploi français. Le titre existe chez EY à New York. Le MIT Technology Review a nommé l'arc du "vibe coding au context engineering" comme le tournant majeur de 2025. Mais en France ? Zéro. Ce retard est exactement le problème dont cet article parle.

Un Context Engineer n'écrit pas de code — il conçoit l'architecture d'information qui rend les agents IA efficaces. Décisions architecturales, règles métier, contraintes domaine, le tout structuré pour que l'agent ait exactement ce dont il a besoin. Ce n'est pas du prompt engineering — c'est de la pensée système appliquée à l'IA. Les entreprises qui créeront ce rôle en premier auront un avantage massif.

Software Orchestrator / Agentic Engineer — le plus conceptuel, et le plus lointain

"Le titre 'Software Engineer' pourrait disparaître d'ici 2026."
— Boris Cherny, créateur de Claude Code chez Anthropic

Cherny prédit qu'il sera remplacé par "Software Orchestrator" — quelqu'un qui gère des essaims d'agents plutôt que d'écrire du code. Andrej Karpathy appelle ça l'"agentic engineering" — l'évolution au-delà du vibe coding, où l'on conçoit et gère des workflows IA plutôt que de discuter avec un modèle. C'est le cas limite de la convergence des rôles — et celui qui ressemble le plus à de la science-fiction. Mais gérer des agents vers des objectifs, valider leurs résultats, concevoir leurs workflows ? C'est ce que je fais à 9h un mardi matin.

La fin du QA en tant que rôle autonome

Si votre architecture n'est pas testable, votre équipe QA compense l'architecture. C'est la vérité inconfortable derrière le rôle de QA tel qu'il existe dans la plupart des organisations. Quand les règles métier sont bien définies et le système conçu pour la testabilité, la vérification automatisée a toujours été la bonne réponse — même avant l'IA. L'IA a juste rendu l'écart impossible à ignorer.

Les agents génèrent des suites de tests complètes en même temps que le code. Ils couvrent les cas limites systématiquement. Ils s'exécutent en secondes. Le workflow de QA manuelle scriptée — suivre un plan de test, cliquer sur des écrans, remplir des rapports de bugs — n'a pas d'avenir. Google et Meta ont déjà éliminé les rôles de QA traditionnels au profit des SDETs (Software Development Engineers in Test).

Ce qui survit — et c'est important — c'est l'expert métier qui remarque quand quelque chose ne va pas même quand tous les tests passent. Le test exploratoire, la validation de workflows cliniques, la personne qui connaît le système assez bien pour détecter les anomalies : c'est du jugement, et c'est irremplaçable. Mais c'est une compétence intégrée dans chaque membre de l'équipe, pas un rôle séparé derrière un passage de relais.

Les compétences qui comptent vraiment

Si vous êtes un professionnel du logiciel et que vous vous demandez sur quoi investir, voici mon point de vue sans détour :

L'expertise métier est le nouveau rempart. La personne qui comprend pourquoi un workflow a sept états au lieu de trois, pourquoi deux tables ne peuvent pas être fusionnées même si elles semblent identiques, ou pourquoi une règle de gestion a été implémentée de cette façon il y a dix ans — cette personne est irremplaçable. Aucun agent n'a cette connaissance. Aucun modèle n'a été entraîné dessus. Elle vit dans votre tête, et c'est ce qui fait la différence entre du code qui fonctionne et du code qui fonctionne dans le monde réel.

La pensée architecturale est le nouveau marqueur de séniorité. Clean Architecture, frontières hexagonales, inversion de dépendances, décomposition système — ce ne sont plus des concepts abstraits. C'est la structure qui rend les agents IA efficaces. Un système bien architecturé est un système où les agents peuvent opérer de manière autonome dans des frontières claires. Un système mal architecturé est un système où chaque output d'agent nécessite une revue manuelle parce que personne ne fait confiance à l'endroit où le code atterrit.

L'ingénierie de contexte est la nouvelle compétence fondamentale. La capacité à structurer la connaissance métier, les contraintes et les décisions dans un format que les agents peuvent consommer. Ce n'est pas du prompt engineering. Le prompt engineering, c'est poser la bonne question. L'ingénierie de contexte, c'est construire tout le système de connaissance qui fait que chaque question produit la bonne réponse. C'est la compétence à plus fort levier dans le développement logiciel aujourd'hui.

La vision produit est le nouveau différenciateur. Quand l'implémentation est quasi-gratuite, le goulot d'étranglement se déplace entièrement vers savoir quoi construire. Comprendre les besoins utilisateurs, les dynamiques de marché, les contraintes business — et traduire ça en intention que les agents peuvent exécuter. Le développeur qui pense aussi comme un product owner vaut dix développeurs qui "écrivent du code."

Le jugement est la dernière ligne de défense. Savoir quand l'agent a tort. Savoir quand le test couvre le cas évident mais rate le cas critique. Savoir quand livrer et quand s'arrêter. Ça vient de l'expérience, des cicatrices, d'avoir eu tort avant. Pas de raccourci. Pas de remplacement par un modèle.

Une nuance importante : rien de tout cela ne signifie que comprendre le code n'a plus de valeur. On ne peut pas superviser une IA qui écrit du code si on ne sait pas lire du code. La capacité à évaluer ce qu'on ne produit plus soi-même efficacement — c'est un avantage durable et asymétrique. Coder n'est pas le métier. Mais comprendre le code reste le socle.

Que faire concrètement

Pour les individus :

Arrêtez d'investir dans l'expertise d'un langage. "5 ans de Java" est un actif qui se déprécie. Investissez dans la connaissance métier, les patterns architecturaux et l'apprentissage du travail avec les agents IA. Cette semaine : listez trois règles métier de votre projet actuel que vous seul connaissez et qui ne sont documentées nulle part. C'est votre valeur irremplaçable. Commencez à les écrire.
Apprenez à penser en produits, pas en fonctionnalités. Comprenez toute la chaîne du besoin utilisateur à la production. N'attendez pas qu'un PO vous dise quoi construire. Cette semaine : assistez à une démo utilisateur ou un appel support et notez trois choses que le ticket ne capturait pas.
Développez vos compétences en ingénierie de contexte. Entraînez-vous à structurer la connaissance pour les agents. Commencez par un Architecture Decision Record (ADR) sur les trois plus grosses contraintes de votre projet actuel. Construisez un glossaire métier. Rédigez un document de contraintes qu'un agent peut consommer. C'est la nouvelle littératie.
Creusez un domaine. Choisissez une industrie. Apprenez-la en profondeur. L'intersection de la maîtrise technique et de l'expertise métier, c'est là que la plus haute valeur se trouve.

Pour les organisations :

Réécrivez vos fiches de poste. Remplacez "5 ans de Spring Boot" par "compréhension approfondie des workflows hospitaliers" ou "expérience dans la conception de systèmes qui évoluent sur des décennies." Au lieu de demander aux candidats d'implémenter un algorithme de tri, demandez-leur de décomposer un workflow métier réel en contextes délimités (bounded contexts).
Fusionnez les rôles délibérément. N'attendez pas que ça se fasse tout seul. Créez des postes de Product Engineer. Donnez aux développeurs la propriété produit. Laissez vos meilleurs talents opérer sur tout le spectre. En France, ça implique de travailler avec les RH, le CSE et la grille de classification syntec — c'est une transformation sur 3-5 ans, pas un OKR trimestriel. Commencez par les nouvelles embauches et les reclassifications volontaires.
Investissez dans l'architecture testable plutôt que dans la QA autonome. L'argent que vous dépensez pour une équipe QA séparée est mieux investi dans des fonctions de fitness architecturale, la vérification automatisée et des pipelines CI/CD. Intégrez le jugement qualité dans chaque membre de l'équipe plutôt que de l'isoler dans un passage de relais.
Investissez dans l'infrastructure de contexte. Documentez vos connaissances métier, décisions d'architecture et règles de gestion dans des formats consommables par les agents. C'est l'investissement au meilleur ROI en 2026.

Un mot pour le développeur expérimenté qui lit ceci avec un nœud au ventre. Si vous avez 8 ans de Java et que vous vous demandez si votre carrière est finie — elle ne l'est pas. Votre connaissance métier, votre compréhension de pourquoi les choses ont été construites ainsi, votre instinct pour ce qui va casser — c'est exactement ce qui survit. La transition ne commence pas par apprendre un nouveau titre de poste. Elle commence par nommer ce que vous savez déjà qui n'est pas du code : les règles métier, les décisions d'architecture, les particularités du domaine qui vivent dans votre tête et nulle part ailleurs. Cette connaissance est votre avantage. Commencez à la documenter.

Et un mot d'honnêteté sur la génération suivante. Mes stagiaires progressent vite. Mais si le recrutement junior s'effondre de 73%, comment les prochains stagiaires entrent-ils ? L'expertise métier se développe en travaillant dans un domaine — on ne peut pas la construire de l'extérieur. On retire l'échelle derrière eux. Je n'ai pas de solution à ça. Mais je refuse de faire semblant que ça n'arrive pas. Si vous êtes en position de recruter des juniors, faites-le. Donnez-leur de vrais problèmes, du vrai contexte, de vrais enjeux. L'industrie a plus que jamais besoin d'eux — même si les offres d'emploi n'ont pas encore évolué.

"La connaissance et la compétence d'être développeur logiciel a été banalisée. Si tout le monde peut être développeur, qu'est-ce que ça veut dire quand vous vous définissez comme développeur ?"
— Geoffrey Huntley

Conclusion

Coder n'a jamais été le métier. La personne dont la valeur principale était de traduire une intention métier en syntaxe de langage de programmation — ce rôle est en train d'être automatisé. Vite. Andrej Karpathy l'a noté 8-9 sur 10 en exposition à l'IA. Le marché est d'accord : le recrutement junior en Big Tech s'est effondré de 73% en un an.

Mais le développement logiciel ? Le développement logiciel est enfin en train de naître. Libéré du poids de la syntaxe, il devient ce qu'il aurait toujours dû être : comprendre les problèmes, concevoir des solutions, structurer le contexte et exercer le jugement. Les rôles fusionnent. Les murs tombent. La personne qui peut penser le produit, concevoir l'architecture, structurer le contexte et valider le résultat — cette personne ne se contente pas de survivre. Elle prospère.

Mon équipe fonctionne déjà comme ça. Chaque personne maîtrise toute la chaîne. Les stagiaires apprennent plus vite que n'importe quel junior que j'ai vu. La qualité est meilleure parce que l'énergie cognitive va au domaine, pas au débogage de points-virgules.

Ce n'est pas une prédiction. C'est un mardi à mon bureau.

Coder n'a jamais été le métier

Coder n'a jamais été le métier

À quoi ressemble mon équipe aujourd'hui

La grande fusion

Product Engineer — le nouveau rôle le plus concret

Context Engineer — le rôle qui n'existe pas encore sur les sites d'emploi français

Software Orchestrator / Agentic Engineer — le plus conceptuel, et le plus lointain

La fin du QA en tant que rôle autonome

Les compétences qui comptent vraiment

Que faire concrètement

Conclusion

Sources

Articles similaires

Et si on comparait notre timeline aux films de notre enfance ?

La compétence était réelle. Le poste, non.

La qualité ne se relit pas. Elle s'exécute.