🦉
Le Veilleur
Builders vs keepers : la vraie guerre de l'ingénierie logicielle a commencé

Builders vs keepers : la vraie guerre de l'ingénierie logicielle a commencé

Aurélien Allienne

Aurélien Allienne

Publié le • 5 min de lecture

Builders vs keepers : la vraie guerre de l’ingénierie logicielle a commencé

Et si la question n’était pas « est-ce que l’IA va remplacer les développeurs », mais « quel type de développeur va survivre » ? Chez Microsoft, les ingénieurs qui ont adopté les agents en ligne de commande mergent 24 % de pull requests en plus [5]. Pourtant, au même moment, une fracture se creuse dans les équipes. Et elle n’a rien à voir avec la productivité.

Deux camps, une même équipe

Anton Zaides le raconte crûment : sa startup a explosé en vol en sept mois. Son associé voulait pousser des features en prod depuis son téléphone, sans lire une ligne de code — « s’il y a un bug, je dirai aux agents de le corriger » [1]. Lui sentait qu’ils construisaient un château de cartes.

C’est la guerre que traverse toute l’industrie. D’un côté les builders : le code est obsolète, seule l’idée compte, un dev sans orientation produit est condamné. De l’autre les keepers : ceux qui aiment les systèmes bien construits, qui refactorent par principe, qui détestent le code sale [1].

« Il était un builder, j’étais un keeper. C’est le même combat que mène toute notre industrie en ce moment. »

Le piège, c’est de croire qu’un camp a raison.

Le manager qui a arrêté de coder

Il y a une figure qui incarne cette dérive : le manager hands-on qui meurt à petit feu. 95 % des engineering managers aimeraient coder davantage mais s’en sentent incapables [2]. Un sprint sans code devient deux, puis dix, puis une année entière sans ouvrir son IDE. Ce n’est plus une question de temps — c’est une habitude perdue.

À l’ère des agents, cette déconnexion devient dangereuse. On demande à ces managers de faire adopter l’IA à leurs équipes… alors qu’ils ne l’utilisent plus eux-mêmes.

Comprendre : le nouveau goulot d’étranglement

Car voilà le vrai basculement. Geoffrey Litt (Notion) le formule d’une phrase : comprendre est devenu le goulot d’étranglement [3]. Les agents écrivent de plus en plus de code, et on peine à suivre. On croit qu’on comprend « pour vérifier » — mais les agents deviennent bons à vérifier eux-mêmes. La vraie raison de comprendre, c’est pour participer : concevoir, décider, orienter.

Ce n’est pas qu’un enjeu individuel. C’est un enjeu d’équipe. Le modèle des 8 niveaux de maturité de contexte le montre bien : l’IA touche 60 % du travail d’ingénierie, mais seul un cinquième peut être délégué sans supervision [4]. Ce n’est pas un problème de modèle. C’est un problème de contexte. Et la plupart des équipes stagnent au niveau du CLAUDE.md qui pourrit plus vite qu’on ne le met à jour.

Les chiffres qui dérangent les deux camps

Alors qui a raison ? Les données envoient des signaux contradictoires — et c’est tout l’intérêt.

Contre les prophètes du remplacement : les entreprises qui investissent massivement dans l’IA font croître leurs effectifs de 10 % sur deux ans, et de 12 % pour les postes juniors [6]. L’IA ne détruit pas l’emploi tech, elle l’amplifie — chez ceux qui l’adoptent sérieusement.

Contre les prophètes du « tout automatique » : chez Microsoft, un nouveau modèle « moins cher » (Sonnet 5, -33 % au token) a consommé jusqu’à 12x plus de tokens et produit du code moins idiomatique que son prédécesseur [7]. Toute mise à jour n’est pas un progrès. Il faut mesurer, comprendre, arbitrer.

Autrement dit : la vélocité augmente, mais le jugement reste humain.

Ni builder, ni keeper : les deux

La vérité, c’est qu’aucun camp ne gagne cette guerre. Le builder pur construit un château de cartes. Le keeper pur se fait dépasser par la vélocité. Le métier qui survit, c’est celui qui garde une main dans le code et une vision produit — qui sait quand déléguer à l’agent et quand comprendre en profondeur.

La vraie compétence de 2026 n’est plus d’écrire du code. C’est de savoir lequel mérite d’être compris.

Et vous, dans votre équipe, qui sont les builders et qui sont les keepers — et est-ce qu’ils se parlent encore ?


Sources

  1. The software engineering war
  2. The slow death of the hands-on engineering manager
  3. Understanding is the new bottleneck
  4. 8 levels of context maturity in AI-native engineering
  5. Adoption and Impact of Command-Line AI Coding Agents: A Study of Microsoft’s Early 2026 Rollout of Claude Code and GitHub Copilot CLI
  6. Companies hire more after AI adoption
  7. Not all model upgrades are upgrades

Pour aller plus loin

Cet article a été rédigé en m’appuyant sur une IA pour m’aider à synthétiser et structurer ma veille. Les idées, le choix des sources et la relecture restent les miens.

Pour aller plus loin

Forward Deployed Engineering Is About To Get Diluted

— pourquoi la ruée des Microsoft, AWS & co sur les FDE va banaliser le rôle comme jadis les SI.

GLM 5.2 and the coming AI margin collapse (part 1)

— un open weights au niveau d'Opus qui pourrait faire s'effondrer les marges de l'inference.

The 13 software engineering laws

— 13 lois intemporelles (Conway, Hyrum, Goodhart…) pour garder la tête froide quand tout accélère.

Cet article a été rédigé en m'appuyant sur une IA pour m'aider à synthétiser et structurer ma veille. Les idées, le choix des sources et la relecture restent les miens.