Confier une tâche de code à un agent en arrière-plan

OUTILS IA — L'AGENT QUI AGIT · UNE TÂCHE DE CODE, PENDANT VOTRE ABSENCE

Capacités et limites relevées le 25 juillet 2026 sur la documentation officielle des trois plateformes citées. Aucune tâche n'a été exécutée pour cet article : le protocole de vérification, en fin de page, est à dérouler dans votre propre dépôt.

Le premier assistant de code répondait pendant que vous regardiez l'écran. Vous voyiez la suggestion apparaître, vous l'acceptiez ou vous la rejetiez, et la boucle se refermait en quelques secondes. Le rapport de force était clair : la machine proposait, vous disposiez, et le coût d'une mauvaise proposition se limitait à une touche.

Une deuxième génération d'outils a rompu cette boucle. On leur confie une tâche décrite en français, on ferme l'onglet, et on revient plus tard chercher un résultat. Ce n'est pas la même activité. Ce n'est pas non plus la même prise de risque, et surtout, ce n'est plus le même goulot d'étranglement.

Le sujet de cet article n'est pas de savoir si ces agents écrivent du bon code. C'est de comprendre ce que vous recevez à la fin, dans quelles limites ce résultat a été produit, et qui paie la facture cognitive du retour. Sur le choix d'un assistant interactif, notre article sur le choix d'un assistant de code traite l'autre métier — celui où vous êtes devant l'écran.

Le rendu n'est pas du code, c'est une demande de fusion

C'est le déplacement le plus mal mesuré. Un assistant interactif produit des lignes que vous intégrez au fil de l'eau, en connaissance de cause, puisque vous étiez là quand elles ont été écrites. Un agent de fond produit un objet fermé : une branche, un ensemble de commits, une demande de fusion, et un résumé de ce qu'il prétend avoir fait.

La documentation d'une des plateformes le formule sans détour : l'agent travaille en arrière-plan, puis le développeur « choisit de créer une demande de fusion quand elle est prête » — « Developers let the agents work in the background and then chooses to create a pull request when ready ». Le point important est la place du verbe : le développeur ne code pas, il décide. Son travail commence là où celui de l'agent s'arrête.

Une autre plateforme insère une étape de validation avant l'exécution : « Once you submit a task, Jules will generate a plan. You can review and approve it before any code changes are made » — un plan est produit, vous l'approuvez, et alors seulement le code est touché. C'est une réponse directe au problème du mandat : approuver une intention est plus facile qu'auditer un diff de six cents lignes après coup. On retrouve exactement le raisonnement des mandats signés que nous décrivions à propos des paiements par agent, dans le premier article de cette série : la signature ne dit pas si l'achat était pertinent, elle dit qui l'a autorisé.

Ce n'est pas un détail d'ergonomie. Un agent qui rend une demande de fusion s'insère dans un circuit de relecture qui existait déjà, avec ses règles de protection de branche, ses vérifications automatiques et ses relecteurs désignés. C'est un avantage — rien à réinventer — et un piège : le circuit a été calibré pour un débit humain.

Trois murs que la documentation pose noir sur blanc

Les contraintes d'exécution ne relèvent pas du folklore : elles sont écrites, et elles déterminent quelles tâches sont confiables à ces outils. Trois d'entre elles reviennent, formulées de manière remarquablement explicite.

Un plafond de temps dur. Sur l'une des plateformes, la documentation de l'agent de code l'écrit ainsi : « Each Copilot cloud agent session has a maximum execution time of 59 minutes. This is a hard limit that cannot be extended or bypassed » — cinquante-neuf minutes, limite dure, ni prolongeable ni contournable. Toute tâche dont l'exécution, l'installation des dépendances et la suite de tests dépassent cette enveloppe est structurellement hors de portée. Ce n'est pas une question de qualité du modèle.

Un périmètre d'écriture réduit à sa plus simple expression. Même source : « Copilot can only work on one branch at a time and can open exactly one pull request to address each task », et « Copilot can only make changes in the repository specified when you start a task ». Une branche, une demande de fusion, un dépôt. Toute évolution qui traverse plusieurs dépôts — un changement de contrat d'interface entre deux services, par exemple — se décompose à la main avant d'être confiée.

Un environnement jetable. Toujours la même documentation : l'agent dispose de « its own ephemeral development environment », adossé au moteur d'intégration continue de la plateforme. Chez un concurrent, la formulation est équivalente : « Jules runs in a virtual machine where it clones your code, installs dependencies, and modifies files ». Rien ne survit à la tâche. C'est une bonne nouvelle pour la sécurité, et une contrainte réelle pour tout ce qui suppose un état persistant — une base de données de référence, un cache de compilation, un jeu de données volumineux.

Fig. 1 — Ce que déplace vraiment l'exécution en arrière-plan. Le travail de production sort de votre journée, mais le travail de vérification y entre en bloc, sous une forme plus difficile : un diff fermé, produit hors de votre regard, dont il faut reconstituer l'intention. Les trois murs de gauche déterminent quelles tâches franchissent la porte ; le goulot de droite détermine combien vous pouvez en absorber.

Les quotas disent quel usage l'éditeur anticipe

Les limites d'usage publiées valent lecture attentive : elles révèlent le régime d'utilisation que l'éditeur juge normal. Sur l'une des plateformes, le compteur publié est explicite — quinze tâches par tranche glissante de vingt-quatre heures dans la formule d'entrée, cent dans la formule intermédiaire, trois cents dans la plus haute ; et respectivement trois, quinze puis soixante tâches simultanées.

Soixante tâches simultanées, ce n'est pas un chiffre de développeur. C'est un chiffre d'équipe, et il pose la question que personne ne pose : qui relit soixante demandes de fusion ? Sur la structure de coût de ces usages, notre article sur le coût réel d'un agent IA donne la méthode de calcul ; elle s'applique telle quelle ici, à condition d'ajouter au calcul le temps humain de relecture, qui est le poste le plus lourd et le seul qui ne baisse pas.

Le réseau coupé par défaut, et pourquoi

Voici le point que la plupart des présentations commerciales passent sous silence, et qui est pourtant le plus instructif sur la maturité réelle de ces outils. Sur l'une des plateformes, la page consacrée à l'accès réseau de l'agent est catégorique : « By default, Codex blocks internet access during the agent phase » — l'accès à Internet est bloqué pendant la phase d'exécution de l'agent. Les scripts d'installation, eux, conservent l'accès nécessaire aux dépendances.

Lisez cette liste comme un aveu utile plutôt que comme un aveu d'échec. Un agent qui lit le web pendant qu'il code lit aussi ce que le web lui dit de faire — c'est exactement l'injection de prompt, cette faille sans correctif, transposée dans un contexte où l'agent a la main sur un dépôt. Lorsque l'accès est ouvert, deux garde-fous sont proposés : une liste blanche de domaines, et une restriction des méthodes HTTP à GET, HEAD et OPTIONS, ce qui bloque POST, PUT, PATCH et DELETE.

Cette seconde mesure mérite qu'on s'y arrête, car elle dit tout du modèle de menace retenu : on autorise l'agent à lire le web, jamais à y écrire. C'est une reconnaissance implicite que le risque principal n'est pas ce que l'agent télécharge, mais ce qu'il pourrait envoyer. Le même raisonnement gouverne les permissions que vous accordez à un agent sur vos propres systèmes, sujet que nous traitions dans notre article sur les accès à consentir à un agent.

Le vrai goulot n'est pas la production, c'est la vérification

Réunissons les pièces. Le temps de production d'un correctif tend vers zéro et peut être parallélisé jusqu'à des dizaines de tâches simultanées. Le temps de vérification, lui, ne bouge pas : relire un diff de trois cents lignes que l'on n'a pas écrit demande le même effort qu'en 2019, et probablement davantage, puisqu'on ne dispose pas du fil de raisonnement qui l'a produit.

Une équipe qui adopte ces outils sans y penser observe une séquence prévisible. D'abord une accélération réelle et grisante sur les tâches périphériques — mises à jour de dépendances, corrections de tests instables, documentation. Puis une accumulation de demandes de fusion en attente. Puis, presque toujours, une dégradation silencieuse de la qualité de relecture : quand douze demandes attendent, la treizième est approuvée sur la foi du résumé.

Reste la question du périmètre. Toutes les tâches ne se valent pas devant un agent de fond. Celles qui passent bien partagent trois traits : un critère de réussite mécanique (une suite de tests qui passe ou ne passe pas), un périmètre contenu dans un dépôt, et une exécution qui tient largement sous l'enveloppe de temps imposée. Celles qui passent mal partagent le trait inverse : le succès y est une affaire de jugement, et le jugement ne se délègue pas à un processus dont vous ne verrez que la sortie. Sur ce partage entre ce qu'un agent peut porter et ce qui doit rester sous votre contrôle, notre article sur la confiance que l'on peut placer dans un agent pose le cadre général.

🔬 Comment le vérifier vous-même

Les chiffres ci-dessus sont ceux des éditeurs. Les seuls qui comptent pour votre décision sont les vôtres, et ils s'obtiennent en deux semaines sans engagement.

Il y a une ironie dans tout cela. Ces agents ont été vendus comme un moyen de rendre du temps aux développeurs, et ils en rendent réellement — mais pas à ceux que l'on croit, et pas sous la forme annoncée. Ils déplacent l'effort de l'écriture vers la lecture, et la lecture attentive de code écrit par un autre est, de longue date, l'activité la plus coûteuse et la moins valorisée d'une équipe. Les organisations qui tireront quelque chose de ces outils sont celles qui traiteront la relecture comme un poste à financer, pas comme une formalité à expédier.

Cet article est le troisième de la série Outils IA — l'agent qui agit. Le suivant descend d'un étage : si l'agent exécute du code que personne n'a relu, la question devient où ce code s'exécute, et ce qui le sépare du reste de vos systèmes — c'est le sujet de notre article sur les bacs à sable d'exécution. Sur ce que ces agents savent faire d'un poste de travail complet, notre article consacré aux agents à usage ordinateur pose le socle.

Une question, un projet IA ?

Vous voulez confier des tâches de code à des agents sans engorger votre circuit de relecture ? Échangeons sur votre contexte.

Prendre contact →