Coder en mode feu et oubli : L'essor des agents en arrière-plan en 2026

La semaine dernière, j'ai confié un ticket à un agent, fermé l'ordinateur et suis allé déjeuner. À mon retour, une pull request m'attendait — tests au vert, résumé succinct, un diff touchant onze fichiers. Ça fonctionnait. Je l'ai mergée.

Les trois autres que j'avais lancés ce matin-là ne se sont pas aussi bien passés. L'un a silencieusement supprimé un feature flag parce qu'il « n'était pas référencé » (il l'était, depuis un fichier de configuration que l'agent n'a jamais lu). Un autre a brûlé quelques dollars à redécouvrir que notre suite de tests a besoin d'un conteneur de base de données qu'il ne pouvait pas démarrer. Le dernier a produit un diff si plausible et si faux que j'ai failli l'approuver depuis l'écran de mon téléphone.

Voilà la vraie image des agents en arrière-plan en 2026. La bonne exécution donne l'impression de tricher. Les mauvaises donnent l'impression de gérer un junior qui travaille à 3 h du matin, ne pose jamais de questions et est très sûr de lui.

En bref : les agents en arrière-plan ont fondamentalement résolu le problème « écrire du code pendant que je ne regarde pas ». Ce qu'ils n'ont pas résolu — ce qu'ils ont, pourrait-on dire, aggravé — c'est la revue. Le goulot d'étranglement a bougé. Avant, c'était la vitesse de frappe du modèle. Maintenant, c'est la vitesse à laquelle vous pouvez lire, valider et merger un travail que vous n'avez pas regardé se produire. Si vous ne construisez pas un processus pour cela, vous n'obtenez pas un multiplicateur de force ; vous obtenez une accumulation de PRs à moitié cuites.

Ce que « agent en arrière-plan » signifie vraiment aujourd'hui

Un agent en arrière-plan est un agent de codage asynchrone qui s'exécute quelque part hors de votre attention principale — généralement une VM dans le cloud — accomplit la tâche et vous remet un résultat plus tard. Vous assignez le travail et vous partez. C'est tout le discours, et à la mi-2026, chaque grand framework livre une version de cela.

Cursor a entièrement reconstruit son interface autour de cela dans la version 3.0. La note de version est directe sur le nouveau centre de gravité : vous pouvez « exécuter plusieurs agents en parallèle sur des dépôts et des environnements : localement, dans des worktrees, dans le cloud et sur SSH distant » (cursor.com/changelog/3-0). Leurs agents cloud s'exécutent dans des sandboxes, « itèrent jusqu'à ce qu'ils aient validé leur output » et convertissent les issues Linear ou Jira directement en PRs (cursor.com/cloud). La lecture de Futurum sur la suite 3.2 a qualifié l'IDE de « réencadré comme un runtime d'exécution d'agents » (futurumgroup.com) — à la limite du marketing, mais juste dans la direction.

Claude Code a suivi la même voie mais a conservé un vocabulaire précis. Sa documentation distingue quatre façons de paralléliser : les subagents (des travailleurs délégués au sein d'une session), l'agent view (claude agents — « dispatcher et surveiller des sessions s'exécutant en arrière-plan », une préversion de recherche), les agent teams (un chef coordonnant des travailleurs, « expérimental et désactivé par défaut »), et les dynamic workflows (un script qui déploie en éventail de nombreux subagents et les vérifie mutuellement) (code.claude.com/docs/en/agents). Les quatre ne sont pas interchangeables, et les noms font un vrai travail.

Devin, qui a plus ou moins créé cette catégorie, a passé 2026 à transformer un agent autonome en plusieurs. Sa version du 19 mars a ajouté « Devin Manages Devins » — une session coordinatrice qui délimite le travail et délègue à « une équipe de Devins gérés qui travaillent en parallèle », chacun sur sa propre VM isolée (docs.devin.ai/release-notes/2026).

Le fil commun : environnement isolé, transfert asynchrone, PR à la fin. Les différences résident dans la marge de manœuvre accordée et dans la façon dont la revue retombe sur vous.

Ce en quoi ils sont vraiment bons

Soyez précis sur les cas où ça vaut la peine, parce que le hype nivelle tout.

Les agents en arrière-plan sont bons sur du travail délimité, bien spécifié et vérifiable. Le point idéal est une tâche où (a) vous pouvez décrire « terminé » en une phrase, (b) un test ou un vérificateur de types peut le prouver, et (c) cela ne requiert pas de jugement esthétique. Les mises à jour de dépendances avec une suite qui passe. Ajouter un champ à travers un stack connu. Écrire les tests unitaires évidents. Des refactors mécaniques sur de nombreux fichiers — exactement le genre de chose pour lequel la compétence /batch de Claude Code est conçue, en découpant « un grand changement en 5 à 30 subagents isolés dans des worktrees qui ouvrent chacun une pull request » (code.claude.com/docs/en/agents).

Ils sont bons sur la largeur en parallèle. Le /best-of-n de Cursor exécute la même tâche sur plusieurs modèles, « chacun dans son propre worktree isolé, puis compare les résultats » (cursor.com/changelog/3-0). Pour un bug coriace où vous ne savez vraiment pas quelle est la bonne approche, lancer trois tentatives et garder la meilleure est une vraie utilisation de la capacité à exécuter des choses que vous ne regardez pas.

Et ils sont bons pour laisser une seule personne faire plus d'une chose à la fois. En tant que développeur solo, la contrainte n'a jamais été les idées — c'est que je ne peux être que dans un seul fichier à la fois. Déléguer la moitié ennuyeuse pendant que je fais la moitié intéressante, c'est le vrai gain. Pas « l'IA construit mon app » — c'est encore une fantasme. « L'IA vide mes petites tâches évidentes pendant que je réfléchis » est livrable aujourd'hui.

Ce en quoi ils sont mauvais, honnêtement

Les modes d'échec ne sont pas exotiques. Ils sont ennuyeux et se répètent.

La famine de contexte. Un agent en arrière-plan ne sait que ce qu'il a collecté avant de commencer à s'exécuter. Il ne peut pas vous poser une question de clarification en milieu de course — ou s'il le peut, vous êtes en déjeuner. Alors il devine. Mon incident du-feature-flag-supprimé était de la pure famine de contexte : l'agent a raisonné correctement sur les fichiers qu'il avait et est parvenu à une mauvaise conclusion parce que le fait pertinent se trouvait quelque part où il n'a pas regardé. La solution est en amont : un meilleur cadrage de la tâche, un AGENTS.md qui lui dit où se trouvent les choses, des liens vers l'issue. Ordures en entrée, ordures confiantes en sortie.

La dérive silencieuse. L'échec effrayant n'est pas la PR manifestement cassée — celle-là, vous la verrez. C'est celle qui est correcte à 90 % et subtilement fausse, avec un résumé propre qui décrit le bon comportement pendant que le diff fait autre chose. Le résumé est généré depuis l'intention, pas depuis ce que le code fait réellement. Faites confiance au diff, pas à la description.

Les conflits de merge et les collisions. Lancez six agents sur un seul dépôt et ils vont entrer en collision. La réponse de toute l'industrie est l'isolation par worktree — chaque agent obtient son propre checkout git pour que les sessions parallèles « ne modifient jamais les mêmes fichiers » (code.claude.com/docs/en/agents). Ça résout les agents qui se battent pendant l'exécution. Ça ne fait rien concernant six branches qui atterrissent toutes sur main le mardi après-midi, chacune légèrement obsolète. Le conflit se déplace juste au moment du merge, c'est-à-dire qu'il se déplace vers vous. Devin a livré la détection de conflits de merge dans la revue en février précisément parce que c'est là que le rêve parallèle rencontre la réalité (docs.devin.ai/release-notes/2026).

Les coûts incontrôlés. Asynchrone signifie que personne ne regarde le compteur. Les agents en arrière-plan s'appuient sur les modèles les plus chers, et une comparaison honnête a évalué une « PR facile » sur l'agent en arrière-plan de Cursor à environ $4.63 en aperçu (aitechfy.com). C'est acceptable pour un vrai ticket et absurde pour une faute de frappe. Les coûts « deviennent imprévisibles sur des travaux nouveaux », et la dépense par tâche « reste opaque sauf si vous vérifiez le tableau de bord d'utilisation » (techsy.io). La propre documentation d'Anthropic le dit clairement : exécuter plusieurs agents à la fois « multiplie l'utilisation de tokens » (code.claude.com/docs/en/agents). Fixez des limites de dépenses avant de faire feu et d'oublier, pas après la facture.

Le vrai goulot d'étranglement est la revue, et c'est maintenant le vôtre

Voici la partie que les démos omettent. Quand la génération était l'étape lente, la revue était gratuite — vous regardiez le code apparaître ligne par ligne et vous l'approuviez à mesure qu'il arrivait. Les agents en arrière-plan brisent ça. Le code apparaît pendant que vous êtes absent. Vous êtes maintenant un relecteur d'un travail que vous n'avez pas regardé, au volume des agents que vous avez déployés.

Les fournisseurs le savent clairement, car les livraisons les plus intéressantes de 2026 n'étaient pas dans la génération — elles étaient dans la revue. Devin a lancé tout un produit de revue en janvier qui regroupe les changements liés, « détecte le code copié, les bugs et les problèmes de sécurité », et a ajouté le merge automatique et un bouton « Auto-fix with Devin » en avril (docs.devin.ai/release-notes/2026). Ça vous dit où se trouve la douleur.

Mais attention à ce que vous souhaitez. La même comparaison qui a tariffé ces outils note aussi que « chaque équipe que nous connaissons exige une revue humaine avant le merge » et qualifie le merge automatique de « tir dans le pied » (techsy.io). Je suis d'accord. L'intérêt d'un agent qui examine le travail d'un autre agent est de trier votre file — signaler les trois PRs qui nécessitent vos yeux et apposer un tampon caoutchouc sur les deux ennuyeuses — pas de vous éliminer. Le jour où vous laissez un agent approuver le travail d'un autre agent dans main sans supervision, c'est le jour où vous avez automatisé la production de bugs subtils.

Donc la compétence qui compte vraiment en 2026 n'est pas le prompting. C'est gérer une file de revue sans se noyer. Concrètement :

• Triez avant de lire. Signal bon marché et mécanique d'abord : les tests sont-ils passés, le vérificateur de types est-il passé, le diff est-il petit ? Une PR qui échoue à sa propre porte n'a pas encore mérité votre attention.
• Lisez le diff, jamais le résumé. Le résumé est l'intention de l'agent. Le diff est ce qui se passe. Ils divergent silencieusement.
• Rendez « terminé » démontrable. Si vous ne pouvez pas écrire une vérification qui confirme la tâche, vous n'avez pas une tâche pour agent en arrière-plan — vous avez quelque chose que vous surveillerez de toute façon. Poussez la vérification dans l'exécution de l'agent pour qu'il s'auto-teste ; les agents cloud de Cursor « itèrent jusqu'à ce qu'ils aient validé leur output » (cursor.com/cloud), et cette porte vaut plus que n'importe quel ajustement de prompt.
• Limitez la profondeur de la file. Plus d'agents ne signifie pas plus d'output au-delà du point où vous pouvez les examiner. Si les PRs atterrissent plus vite que vous ne les traitez, vous avez construit un générateur d'arriéré, pas un multiplicateur de force.

Un quotidien qui fonctionne vraiment

Voici la boucle que j'exécute en tant que développeur solo. C'est délibérément banal.

Matin : je trie ma propre liste d'issues en deux catégories — adaptées aux agents (délimitées, testables, ennuyeuses) et adaptées à moi (jugement, architecture, tout ce qui touche à l'argent ou à l'authentification). Je déploie trois ou quatre tickets adaptés aux agents, chacun dans son propre worktree ou sandbox cloud, avec une vraie description et un lien vers l'issue. Puis je ferme cette fenêtre et vais travailler sur un problème adapté à moi-même, au premier plan, à l'ancienne.

Je ne reste pas assis à les regarder. Tout l'intérêt est dans l'asynchronisme. Regarder un agent en arrière-plan, c'est juste un agent synchrone avec des étapes supplémentaires et une vue plus mauvaise.

En milieu de matinée, les PRs commencent à arriver. Je lance la passe de tri : d'abord l'état de la porte, puis les petits diffs avant les grands. Les deux qui ont passé proprement et touchent dix lignes, je les lis et les merge en cinq minutes chacune. Celle qui a « réussi » mais réécrit plus que prévu, je la lis avec soin — c'est là que se cache la dérive. Celle qui a échoué à ses propres tests, je la recadre avec le nouveau contexte et la redéploie, ou je la tire en local et la termine à la main. Un agent qui brûle quarante minutes sur un environnement de test cassé me dit simplement que ma configuration est le problème ; je le corrige une fois et la prochaine exécution est propre.

Je merge les branches d'agents une par une, en faisant un rebase au fur et à mesure, pas en lot en fin de journée — c'est ainsi qu'on évite l'accumulation de conflits du mardi après-midi. Et je maintiens une règle stricte : rien lié à l'authentification, à la facturation ou aux migrations ne passe depuis une exécution en arrière-plan sans que j'aie lu chaque ligne. Pas parce que c'est difficile. Parce que le rayon d'explosion est grand et que l'agent ne ressent pas les conséquences.

Résultat net pour la journée : peut-être six tickets fermés là où j'en aurais fait deux. Pas parce que les agents sont intelligents — certaines de ces PRs étaient du retravail — mais parce que la moitié ennuyeuse a été nettoyée en parallèle pendant que j'ai consacré ma vraie attention à la moitié qui nécessitait un humain.

La prise de recul

Les agents en arrière-plan sont réels, ils livrent, et la boucle VM-parallèle-dans-le-cloud-vers-PR fonctionne suffisamment bien pour changer la façon dont un développeur solo passe sa journée. Ce n'est pas du hype. Ce qui est du hype, c'est le « et alors tu n'as plus rien à faire » implicite. Si, vous en avez. Le travail a juste changé de forme — passer de la frappe de code à le spécifier, le contrôler et le passer en revue.

Traitez-les comme une équipe junior rapide qui travaille pendant que vous dormez et produit une pile de PRs pour le matin : certaines excellentes, certaines silencieusement fausses, toutes confiantes. Le bénéfice est réel si vous construisez le muscle de la revue pour égaler la génération. Si vous sautez ça, vous ne vous êtes pas acheté une équipe. Vous vous êtes acheté une file d'attente.

Commencez par un agent, un ticket délimité, une définition démontrable de terminé. Faites fonctionner la boucle de tri à une profondeur avant de passer à quatre. La génération n'allait jamais être la partie difficile.