Le futur du développement : à quoi ressemblera le métier d'ici 2035

« La plupart d'entre nous sont des dinosaures qui attendent la météorite. » La phrase est de Matt Welsh, dans « The End of Programming », publié en janvier 2023 par Communications of the ACM. Deux ans plus tard, Tim O'Reilly lui répond point par point : chaque saut d'abstraction depuis le compilateur devait tuer le métier, et chacun a multiplié le nombre de développeurs. Le même débat a eu lieu à la télévision chinoise, entre Robin Li, le patron de Baidu, pour qui il ne restera bientôt que deux langages de programmation, « l'anglais et le chinois », et Zhou Hongyi, le fondateur de 360, qui lui a répondu le lendemain.

Quelques chiffres sont moins discutables : chez Meituan, le géant chinois de la livraison, 52 % du nouveau code est généré par l'IA, chez Epic Games plus de la moitié de l'usage de Claude Code vient de salariés qui ne sont pas développeurs, et Gartner prévoit qu'en 2029, 60 % des organisations auront basculé vers des équipes de développement réduites, contre 15 % aujourd'hui. Plutôt que la question du remplacement, qui se prête surtout aux débats de plateau, j'en pose deux autres : où se déplace le goulot d'étranglement, et qui, dans une équipe qui rétrécit, garde la vision d'ensemble. Cet article y répond en quatre parties, à partir de ce qui s’écrit de plus sérieux sur le sujet en anglais, en chinois et en japonais, et à partir de ce que je vis dans une équipe de deux personnes qui délègue l'essentiel de son code à des agents. Il se termine par des jalons datés, pour qu’on puisse me donner tort dans deux ans.

1. La loi du goulot déplacé

Kent Beck a inventé l'Extreme Programming et popularisé le TDD, et il programme depuis un demi-siècle. Interrogé en 2025 sur ce que l'IA change pour lui : « 90 % de mes compétences viennent de perdre toute valeur. Les 10 % restants ont été multipliés par mille. » Le phénomène a des précédents, des compilateurs au no-code, et chaque fois l'abondance nouvelle a créé plus de demande qu'elle ne détruisait d'emplois, parce que ce qui coûte moins cher se consomme davantage. Cet argument des optimistes est solide, mais il a un angle mort : il décrit ce qui devient abondant et ne dit rien de l'endroit où la rareté se déplace. À chaque étape, le métier a survécu en déménageant.

Mises bout à bout, les analyses les plus solides dessinent la trajectoire suivante : l'écriture du code cesse d'être rare (c'est fait), puis la vérification devient le goulot (c'est la phase en cours), puis l'intention devient la source (cela commence). Un mouvement de fond, moins commenté, accompagne les trois étapes : à chaque cran, la part du travail qui reste humaine se concentre sur moins de personnes. C'est lui qui explique les équipes de deux de la section 4.

2. Acte I (2023-2026) : l'écriture cesse d'être rare

À l'été 2025, le laboratoire METR publie une étude contrôlée randomisée sur seize mainteneurs open source expérimentés et 246 tâches réelles de leurs propres projets : avec les outils IA, ils sont 19 % plus lents, et eux-mêmes s'estimaient 20 % plus rapides. Puis la génération des agents qui testent et itèrent seuls est arrivée, et la bascule s'est mesurée : le suivi de février 2026 du même laboratoire constate une accélération réelle, et le think tank de Tencent parle désormais d'« ère d'abondance » du code.

La prophétie de Welsh, le modèle qui exécute la tâche directement, sans code, ne s'est pas réalisée non plus : une exécution par modèle coûte des ordres de grandeur de plus qu'un code compilé, sans déterminisme ni piste d'audit, et les modèles écrivent au contraire plus de code que l'humanité n'en a jamais produit. « Le code est soudain devenu gratuit, éphémère, malléable, jetable après un seul usage », résume Andrej Karpathy dans son bilan de l'année 2025. Le code reste le meilleur substrat d'exécution que l'on connaisse, et ce sont désormais des agents qui l'écrivent.

3. Acte II (2026-2029) : la vérification devient le métier

Quand la production de code ne coûte presque plus rien, l'engorgement se déplace vers la relecture. À Stanford, Yegor Denisov-Blanch suit 100 000 développeurs, et une de ses études de cas porte un titre limpide, « l'IA écrit plus vite que les humains ne peuvent relire ». Simon Willison pointe le problème de fond : un agent fabrique en trente minutes tous les signaux extérieurs du sérieux, tests verts, commits propres, README soigné, et ces signaux ne prouvent plus rien.

J'en ai fait l'expérience : une migration d'architecture confiée aux agents de l'équipe est passée en revue sans une remarque, tests verts et patterns respectés, avant que les régressions n'apparaissent une à une, parce qu'elle avait réécrit à neuf des fichiers qui concentraient six mois d'ajustements. Il a fallu décortiquer près de 1 700 lignes dans l'historique git et trois commits de restauration pour recoller les morceaux.

La profession répond de trois façons, et toutes déplacent le métier vers le contrôle. La première est l'orchestration : le développeur pilote des agents de codage en parallèle et arbitre, et les données d'Annie Vella montrent que 77 % des ingénieurs interrogés passent moins de temps qu'avant à écrire du code et se découvrent « quelque chose qui ressemble étrangement à des managers ».

La deuxième passe par la spécification. Sean Grove, chez OpenAI, tient le raisonnement le plus net : le code n'est qu'une projection avec perte de l'intention, et jeter ses prompts en ne versionnant que le code généré revient à « détruire la source pour versionner soigneusement le binaire ». Le Spec-Driven Development décrit sur ce blog en est la version outillée, et Bertrand Meyer y voit le retour de l'ingénierie des exigences, la discipline la plus difficile du métier.

Reste le harnais technique. Le TDD redevient stratégique, pour une raison que Kent Beck explique : ses agents essaient de supprimer les tests qui les gênent, et tout ce qui borne mécaniquement un code qu'on ne lit plus prend de la valeur, jusqu'à la preuve formelle, que Martin Kleppmann prédit courante dès que l'agent rédige la preuve et qu'un vérificateur rejette les fausses.

La relecture elle-même change de nature. Tant qu'un humain lisait chaque ligne, le contrôle coûtait cher et on en faisait peu, or les agents écrivent aussi les tests, y compris les tests de bout en bout que personne n'avait le temps d'écrire, et le contrôle devient bon marché au moment où il devient indispensable. L'outillage suit : SonarQube applique depuis sa version 2026.1 une barrière qualité dédiée au code généré par l'IA, le mutation testing vérifie que les tests testent quelque chose, et une revue IA en CI peut lire les mêmes AGENTS.md que l'agent qui a écrit le code, un dispositif que j'ai détaillé dans mon précédent article. Le relecteur humain lit la spécification, les tests et le diff de la configuration de l'outillage, et il échantillonne le code au lieu de le parcourir ligne à ligne. De nouveaux standards vont s'imposer par ce chemin, un score de mutation minimal, une couverture qui ne peut que monter, un ADR par décision d'architecture, et c'est sur ce contrôle automatique de la qualité que j'attends le plus de R&D d'ici 2029, davantage que sur la génération.

Willison décrit sur lui-même une « normalisation de la déviance » : chaque code d'agent mis en production sans relecture complète, et sans incident, rend la relecture suivante moins probable. Cette pente mènera probablement à un accident, et à mon avis, avant fin 2028, un incident majeur et médiatisé sera attribué à du code d'agent non relu, et il déclenchera un resserrement des pratiques plutôt qu'un retour en arrière. Les outils et les pratiques liés au contrôle des IA, et en particulier à l'automatisation de ce contrôle, vont nécessairement devoir se développer, par anticipation ou par réaction suite à des incidents graves, afin d'accompagner la prise d'autonomie de ces systèmes.

4. Des équipes de deux

L'acte II a une conséquence que peu d'analyses poussent jusqu'au bout. Si le travail humain qui reste consiste à garder la vision d'ensemble et la cohérence du système pendant que des agents écrivent, ce travail se fait mieux à un ou deux qu'à douze. L'équipe de deux personnes dont j'ai décrit les garde-fous sur ce blog a produit quelque 350 commits en quinze mois, très majoritairement générés, et l'essentiel du travail humain a consisté à maintenir l'architecture cohérente pendant que les agents la faisaient dériver. Gartner a chiffré le mouvement en juillet 2026, ce sont les 60 % de l'introduction : des équipes de quatre ou cinq personnes aujourd'hui, « parfois deux ou trois ».

L'idée a cinquante ans. Dans The Mythical Man-Month, en 1975, Fred Brooks défendait déjà l'« équipe chirurgicale », un chirurgien entouré de rôles de soutien, parce que l'intégrité conceptuelle d'un système exige qu'il paraisse sorti d'un seul esprit. Wes McKinney a relu le livre en mars 2026 à la lumière de ses propres agents : ils sont l'outil le plus puissant jamais créé contre la complexité accidentelle, mais ils laissent intacte la complexité essentielle, savoir quoi construire et quoi refuser, et au-delà de 100 000 lignes ils tournent en rond dans leur propre fouillis. Les rôles de soutien de Brooks sont tenus par des agents, et le chirurgien reste un humain, parce que c'est lui qui tient le modèle conceptuel du projet.

Meta vient de montrer ce qui arrive quand on réduit les équipes avant d'avoir l'outillage. Une enquête de Reuters publiée fin août 2026 raconte le projet OT, lancé en janvier : remplacer les équipes produit de dix à vingt personnes par des « pods » de trois à cinq « builders » épaulés d'agents. En juin, les modifications de code sur les plateformes internes avaient bondi de 220 % sur un an, les fonctionnalités arrivées jusqu'aux utilisateurs de 36 % seulement, les incidents majeurs de 40 % et le temps passé à les éteindre de 70 %. Mark Zuckerberg a annulé la deuxième vague de restructuration et reconnu que les agents n'avaient pas « accéléré » aussi vite que prévu. La leçon que Peter Bell en tire pour LeadDev tient en une phrase, le rétrécissement des équipes vient à la fin de la transformation, une fois l'outillage en place, et Gartner dit la même chose autrement, les tiny teams ne tiennent que sur une équipe plateforme solide.

Le revers de ces petites équipes se calcule facilement. Une équipe de deux qui perd une personne perd la moitié de ce qu'elle sait du système, et une équipe d'une personne qui la perd est un projet gelé, ou abandonné. La communauté agile appelle ça le « truck factor », le nombre de personnes qu'un camion doit renverser pour que le projet s'arrête (certains préfèrent « lottery factor », gagner au Loto étant plus agréable à souhaiter à ses collègues). Sur l'open source, les mesures n'ont rien de rassurant : sur 133 projets populaires de GitHub, 65 % avaient un truck factor inférieur ou égal à deux, et sur 1 932 projets suivis dans le temps, 16 % ont été abandonnés par leurs développeurs principaux, dont 41 % seulement ont survécu grâce à un repreneur. Un projet interne n'a pas de communauté pour le reprendre. La spécification versionnée, les tests et les décisions d'architecture écrites deviennent donc la mémoire externe de l'équipe, l'assurance-vie du projet. Pour les DSI comme pour les sociétés de services comme la mienne, la question du remplacement doit se poser dès le départ, en imposant dans les process la production de tous les artefacts qui faciliteront ultérieurement le transfert de compétence, lui-même assisté par IA. Le « key person risk » est une vieille rubrique des audits, ce qui change est qu'il concernera la majorité des projets.

5. Acte III (2029-2033) : l'intention devient la source

Tant que l'écriture coûtait cher, la vraie difficulté du logiciel, savoir ce qu'on veut, restait masquée derrière elle. L'acte III la rend visible. Quand la spécification est ce qui reste, celui qui écrit la spécification est le programmeur, quelle que soit sa carte de visite : product manager, juriste, expert métier. Le logiciel se stratifie alors, un substrat garanti en bas, territoire des professionnels, une couche floue en haut, exécutée par les modèles, et entre les deux une couche d'usage générée au point d'utilisation, celle qui va donner du travail aux DSI.

Le retour des bricoleurs

Hier, les plus téméraires des équipes métier bricolaient leurs outils de gestion avec Excel ou Access, et les DSI savent ce que ça donne à l'échelle : en octobre 2020, Public Health England a perdu près de 16 000 cas de Covid-19 en une semaine parce que les résultats de tests étaient agrégés dans un fichier au vieux format .xls, limité à 65 536 lignes, qui tronquait silencieusement au-delà. Demain, n'importe qui pourra se générer une petite application pour le moindre de ses besoins. Gartner en fait une prédiction : d'ici 2028, les approches « prompt-to-app » adoptées par les développeurs citoyens augmenteront les défauts logiciels de 2 500 %. La version gouvernée existe pourtant déjà, chez Meituan, où plus de 3 000 applications internes ont été construites par des employés non informaticiens sur une plateforme encadrée, des « développeurs à 60 points » à qui les 4C de ce blog s'appliquent autant qu'aux professionnels.

On parle moins du trajet de retour. Une partie de ces mini-projets finira sur le bureau de la DSI, parce que l'outil qu'un contrôleur de gestion s'est fabriqué est devenu indispensable à trois autres services, ou parce que son auteur a changé de poste. Reprendre, sécuriser et étendre du code que personne dans l'équipe n'a écrit, produit par un agent sans spécification ni tests, deviendra un travail courant. C'est une compétence à part entière. Je l'ai déjà vécu, avec une application générée par un commercial permettant de faciliter l'analyse et la réponse aux appels d'offres, devant être reprise pour être généralisée à l'ensemble des équipes commerciales. Bien évidemment, j'ai encore une fois pu constater combien la distance est grande entre un prototype fonctionnant pour une personne, et son industrialisation à destination de tout un service ! Brooks estimait qu'un programme qui marche représente un neuvième du chemin vers un produit maintenable par un autre que son auteur, et les applications à ce stade-là seront produite plus facilement que jamais, avec un truck factor de un par construction. Les DSI qui sauront les accueillir auront un avantage sur celles qui les interdisent, parce que l'interdiction déplace le fichier .xls vers un dépôt Git personnel que la DSI ne voit pas.

Le grand public, lui, ne suivra pas le contrôleur de gestion. Le bilan chinois de l'année du vibe coding est cruel, le trafic de Lovable étant passé de 35 à moins de 20 millions de visites, et la raison est anthropologique : fabriquer du logiciel ne correspond pas à un désir de masse, contrairement à photographier. Les gens commanderont des résultats, sans développer. Robin Li avait donc raison à moitié : plus besoin d'être programmeur pour obtenir du logiciel, mais cela ne fabrique pas de programmeurs.

6. Acte IV (2033 et après) : ce qui ne se génère pas

Trois choses résistent à l'abondance. La responsabilité : « Claude Code n'a pas de réputation professionnelle à défendre », note Willison, et quelqu'un devra répondre du système devant le client, l'auditeur ou le juge. Vient ensuite la confiance, la garantie qu'un système se comporte comme promis : Nicholas Zakas, le créateur d'ESLint, prédit pour 2030 des assureurs refusant de couvrir le code écrit à la main dans les systèmes critiques. Et le jugement, savoir dire ce qui est correct et ce qui expose l'organisation.

Architecte, product owner, ou autre chose

Le portrait du développeur de 2033 se dessine en creux : quelqu'un qui garde la vision d'ensemble d'un système que des agents écrivent, qui sait dire ce qu'il doit faire et qui en répond, souvent à deux, parfois seul. Il peut pencher vers l'architecte logiciel puis l'architecte de solution, qui garde la maîtrise technique, ou à l'inverse vers le product owner, qui tient la vision fonctionnelle et délègue le comment aux agents. Les premiers indices vont vers un profil qui n'existe pas encore et qui ferait la synthèse des deux : Meta a introduit fin 2025 un titre générique, « builder », à la place des titres d'ingénieur et de designer, Gartner décrit des tiny teams où chacun va « de la compréhension des objectifs métier à la supervision des agents », et Peter Bell voit monter l'ingénieur produit, qui comprend le client et le domaine. Il n’est pas tout à fait clair pour moi si ce profil viendra majoritairement d'un architecte qui a appris le métier, ou d'un product owner qui a appris la technique, cela dépendra peut-être du niveau de technicité et de complexité métier de l’environnement.

Le problème est que ce profil exige malgré tout une combinaison de trois qualités, une technicité suffisante pour juger du code qu'on ne lit plus, une capacité d'abstraction pour tenir l'ensemble, et une capacité de vulgarisation pour rester proche des métiers. Chacune se trouve sur le marché. La combinaison des trois beaucoup moins, et une compétence rare est chère et concentre encore un peu plus la valeur du projet dans une tête, ce qui ramène au truck factor de la section 4 : moins de personnes par projet, chacune plus difficile à remplacer et plus longue à former.

La formation est le point faible. Yukihiro Matsumoto, l'auteur de Ruby, raconte avoir livré un logiciel « sans écrire ni toucher une seule ligne de code », mais il alerte sur la « terre brûlée » : si l'industrie cesse d'embaucher des juniors, elle détruit la chaîne de transmission qui fabrique les seniors. Le jugement dont l'acte IV a besoin s'acquiert dans les tâches d'exécution que l'acte II confie aux agents. La chose est déjà mesurable. À Stanford, Erik Brynjolfsson et ses coauteurs suivent les données de paie d'ADP, et dans la version révisée d'août 2026, l'emploi des 22-25 ans dans les métiers exposés à l'IA se situe 19 % en dessous de ce qu'il serait s'il avait suivi celui de leurs pairs moins exposés, un écart qui passe par les embauches, pas par les licenciements. Gartner prévient de son côté que les organisations qui s'appuient sur l'IA pour supprimer les postes juniors auront vidé leur propre vivier d'ici 2028.

Si la trajectoire tient, le portrait de 2035 ressemble à ceci. Des équipes de deux à cinq personnes qui négocient et versionnent des spécifications avec le métier, tiennent le harnais et répondent du résultat, adossées à une équipe plateforme. Autour d'elles, des opérationnels qui fabriquent leur propre outillage et le rapportent parfois à la DSI, et des flottes d'agents qui écrivent un code que plus grand monde ne lit. L'écriture humaine de code demeurera dans les noyaux, dans la pédagogie et pour le plaisir, comme on pratique aujourd'hui l'assembleur.

7. Ce qu'il faut préparer dès maintenant

Chaque acte désigne un actif à construire dès maintenant. D'abord des exigences testables : les organisations qui savent déjà écrire des exigences précises, versionnées et vérifiables auront une longueur d'avance sur celles dont les besoins vivent dans des tickets de deux lignes. Le harnais de vérification vient juste derrière, tests, jeux d'évaluation, propriétés formalisées là où l'enjeu le justifie, et il se construit en années. Il faudra aussi des plateformes internes gouvernées pour accueillir le développement spontané sans le subir, avec une filière de reprise pour les applications qui remontent, un truck factor mesuré sur chaque dépôt qui compte, et des gens entraînés à reprendre du code que personne chez eux n'a écrit. Un dernier actif, contre-intuitif : des juniors. Continuer à en recruter et à les former, alors que leur rendement immédiat baisse, c'est investir dans la seule ressource dont la pénurie est déjà mesurable.

Pour finir, les jalons promis en introduction, de quoi relire cet article dans deux ans.

Si, en 2028, la relecture ligne à ligne se porte bien, que les équipes de dix restent la norme et que les juniors s'embauchent comme en 2022, cet article aura eu tort, et je le reconnaîtrai volontiers.

Conclusion

Ce que cinquante ans d'informatique ont appelé « développer », traduire une intention en code, s'automatise, et ce que le génie logiciel a toujours eu du mal à obtenir, spécifier, vérifier, répondre de, devient le travail. Un travail qui se fera dans des équipes plus petites, avec des profils plus rares et plus difficiles à remplacer, au milieu d'applications que les métiers auront générées eux-mêmes. En 2035, la question qui comptera sera de savoir qui, dans une équipe de deux, saura dire qu'un système mérite la confiance qu'on lui accorde, et qui le saura encore quand cette personne sera partie. Ce jugement ne se génère pas, il se transmet, et la transmission dépend des juniors qu'on embauche, ou pas, d'ici 2030.

Pour aller plus loin sur ce blog

• TechReady 2026 : l'IA rebat les cartes du software engineering : le panorama collectif Ippon.
• La seule règle qu'une IA respecte vraiment, c'est une erreur ESLint : le retour d'expérience de l'équipe de deux de la section 4.
• Spec-Driven Development (SDD) : de la spécification au code avec l'IA : l'acte III en pratique.
• La seconde vie de votre patrimoine applicatif : la dette technique traitée par des agents, en écho à la section 5.