L'IA et le remplacement des développeurs

On répète partout que l'IA va remplacer les développeurs. Mon expérience dit l'inverse.

Le récit du remplacement, vu de près

Depuis trois ans, je construis des agents IA en production. Sur des projets clients, sur des projets perso, sur des chantiers où l'IA passe de l'expérimentation à la mise en ligne. J'observe, je pilote, je code, je forme.

Ce que je n'ai pas vu : des développeurs remplacés par l'IA. Pas une seule équipe qui a réduit ses effectifs parce qu'un agent faisait le travail. Pas un seul recrutement annulé pour la même raison.

Ce que j'ai vu : les mêmes développeurs livrer plus vite, sur plus de fronts, avec plus de polyvalence. Un dev back qui se met sérieusement au front parce que l'agent l'aide. Un dev front qui touche à l'infra parce que l'agent l'aide. Une équipe de quatre qui livre ce qu'une équipe de huit livrait il y a deux ans. Mais l'équipe de quatre est toujours là — souvent débordée, parce que les ambitions ont suivi.

Le bottleneck n'est plus la production de code. Et c'est précisément ça qui change tout — mais pas du côté que la presse pointe.

Le vrai déplacement se joue ailleurs

Quand un agent IA peut produire 80 % du code d'un projet en une semaine, le goulot d'étranglement n'est plus la vitesse de frappe. Ce n'est plus combien de fonctionnalités tiennent dans un sprint. Ce n'est plus combien de bugs un dev peut corriger en une journée.

Le goulot d'étranglement, c'est la qualité de la décision en amont.

Quel ticket. Dans quel ordre. Avec quel critère d'acceptation. Quel arbitrage entre rapidité et dette. Quelle fonctionnalité va vraiment être utilisée. Quelle règle métier ne souffre aucune approximation. Quelle exception est acceptable.

Ces décisions, l'agent ne les prend pas. Il exécute ce qu'on lui demande. À une vitesse qui révèle, sans pitié, les zones où la commande n'était pas claire. Un brief flou hier prenait deux semaines à révéler son flou — le temps que le dev s'enlise. Un brief flou aujourd'hui, ça met deux heures : l'agent produit du code qui ne correspond à rien, et il faut tout reprendre.

La vitesse de l'agent amplifie la qualité du cadrage. Bien cadré : gain colossal. Mal cadré : perte colossale. Il n'y a plus de zone grise où on s'en sortait par la débrouille.

Trois compétences qui deviennent critiques

Pour un PO, un chef de projet, un tech lead — toute personne qui pilote une livraison —, trois choses comptent maintenant infiniment plus qu'avant :

01 · Cadrer assez précisément pour qu'un agent puisse livrer sans dériver

Cadrer, ça n'a jamais été un cahier des charges de cinquante pages. C'est un effort de clarté. Quel utilisateur. Quelle action. Quel résultat attendu. Quel cas-limite. Quel critère d'arrêt.

Avec un humain, on pouvait faire l'impasse : le dev posait des questions, complétait, comblait. Avec un agent, l'impasse devient un trou. L'agent ne pose pas les bonnes questions — il propose une réponse qui colle à ce qu'on lui a dit, ou il invente une interprétation qui ressemble à du sens. Si la spec dit « envoyer une notification quand un client est inactif », l'agent va décider tout seul ce qu'inactif veut dire. Souvent mal.

Cadrer pour un agent, c'est cadrer pour quelqu'un qui n'a aucun bon sens du métier. Mais qui exécute très vite. Cette discipline-là est exactement le cœur du métier de PO. C'est ce qu'un bon PO faisait déjà, en mieux. Sauf qu'avant, un mauvais PO pouvait survivre. Maintenant, non.

02 · Découper le travail en morceaux exécutables et revus

Un ticket trop gros, l'agent dérive. Un ticket trop petit, l'agent perd le contexte d'ensemble. Un ticket dépendant d'un autre ticket non terminé, l'agent invente l'interface manquante.

Le découpage devient un savoir-faire à part entière. Quelle taille. Dans quel ordre. Avec quelles dépendances explicites. Quelle granularité de revue à la fin.

Un PO qui sait découper un projet en tickets agent-ready livre dix fois plus en un mois qu'un PO qui produit le même backlog format « humain-ready » d'il y a deux ans. Pas parce qu'il travaille plus. Parce que chacun de ses tickets passe en mode autonome dans la machine.

03 · Versionner le contexte du projet

C'est probablement le plus nouveau, et le plus sous-estimé.

Un projet a un contexte : les règles métier, l'historique des décisions, les choix d'architecture, les conventions de code, les contraintes du client. Ce contexte vivait jusqu'ici dans la tête des développeurs et dans des conversations. Une partie dans Notion ou Confluence, mais avec un coût d'accès tel que personne ne l'utilisait vraiment.

Un agent, lui, lit. Vite. Tout. À condition que ce soit dans un fichier qu'il peut consulter. Le PO qui sait écrire et maintenir un fichier de contexte projet — appelez-le CLAUDE.md, AGENTS.md, CONTEXT.md — donne à l'agent une mémoire qui dépasse celle de n'importe quelle équipe humaine. Et chaque décision archivée là devient un acquis pour la prochaine itération.

Le PO devient le gardien du contexte. C'est un nouveau rôle. Il n'existait pas vraiment avant.

Le PO qui maîtrise vs celui qui ne change pas

Un PO qui maîtrise ces trois compétences — cadrer pour l'agent, découper agent-ready, versionner le contexte — vaut littéralement dix fois ce qu'il valait il y a deux ans. Parce que sa décision libère une chaîne d'exécution dix fois plus rapide.

Un PO qui continue à faire des roadmaps Excel, des réunions hebdo de deux heures pour aligner les humains, des tickets format prose vague, va être désintermédié. Pas par l'IA. Par les autres PO qui ont changé. Et par les développeurs eux-mêmes, qui auront pris l'habitude d'écrire leurs propres specs avec l'agent — parce que c'est plus rapide que d'attendre une spec floue.

Le métier de PO ne disparaît pas. Le mauvais PO disparaît. Le bon PO devient indispensable.

Le plus grand renversement depuis Agile

Agile a déplacé la valeur du process vers la collaboration. Du document figé vers la conversation continue. C'était un changement de paradigme, qui a pris dix ans à être absorbé, et qui a tué les chefs de projet à l'ancienne au profit des PO et scrum masters.

L'IA agentique déplace la valeur de la production vers la décision. Du temps passé à coder vers le temps passé à arbitrer. Du nombre de devs vers la qualité du cadrage. Ce changement-là est en train de se passer en deux ans, pas dix.

Ce n'est pas un upgrade outil. C'est un changement de régime. Ceux qui s'y mettent maintenant prennent une avance qui ne se rattrape pas en six mois. Pas parce que l'outil est compliqué — il ne l'est pas — mais parce que la posture qu'il exige se construit par la pratique. Et que cette pratique prend du temps.

Concrètement, par où commencer

Si vous pilotez un projet, voici la checklist minimale pour basculer :

• Avez-vous un fichier de contexte projet que l'agent peut consulter en début de session ? Si non, c'est la première chose à écrire. Une page suffit pour démarrer.
• Vos tickets sont-ils écrits pour qu'un agent puisse les exécuter sans poser de question ? Critères d'acceptation explicites, dépendances listées, format de sortie attendu.
• Tenez-vous un journal des décisions ? Pas un compte-rendu de réunion. Un fichier court qui dit « telle date, telle décision, telle raison ». Lisible par l'humain et par l'agent.
• Mesurez-vous quelque chose de différent qu'il y a deux ans ? Le bon indicateur, ce n'est plus le temps de livraison : c'est la quantité de décisions tranchées par jour. Plus elle est haute, plus vous êtes en avance.

Aucun de ces points n'est une révolution outil. Tous ces points sont des changements de discipline. C'est précisément ce qui les rend difficiles. Et c'est précisément ce qui rend l'écart entre les pilotes qui ont changé et ceux qui n'ont pas changé impossible à combler vite.

L'IA ne va pas remplacer les développeurs. Elle est en train de redéfinir ce que veut dire piloter un projet logiciel. Le métier de PO et de chef de projet est, sans doute, celui qui change le plus vite et le plus profondément en 2026. Pas le métier de dev.