L'endroit par défaut où exécuter un agent de codage aujourd'hui, c'est à l'intérieur de votre éditeur. Cursor, Claude Code, l'assistant intégré à votre IDE — ils s'installent à vos côtés, vous les regardez travailler, vous approuvez chaque étape. Cela semble naturel car cela imite le pair programming : un développeur junior très rapide par-dessus votre épaule, et vous qui gardez une main sur le volant.
Ce modèle convient parfaitement à un agent qui a besoin d'une supervision constante. Le problème, c'est que les agents ont besoin de moins en moins de supervision chaque mois, et plus ils gagnent en autonomie, plus il paraît étrange de les garder attachés à un seul ordinateur portable qui n'est éveillé que lorsque vous l'êtes.
Le plafond du local
Un agent local hérite de toutes vos contraintes. Il fonctionne tant que votre machine est allumée et s'arrête dès que vous la fermez. Il entre en concurrence avec votre éditeur, votre navigateur et votre build pour le même CPU et la même mémoire. Il ne traite qu'une seule chose à la fois, parce que vous ne pouvez vous-même surveiller qu'une seule chose à la fois. Et tout ce qu'il fait se passe dans un endroit que vous seul pouvez voir.
Rien de tout cela n'est un défaut des outils — c'est simplement la logique du « local ». L'agent vit là où vous vivez, il est donc borné par tout ce qui vous borne : vos horaires de travail, votre matériel, votre attention, votre unique paire d'yeux. Tant que l'agent avait besoin d'un humain surveillant chaque étape, ces limites étaient gratuites. Dès qu'il n'en a plus besoin, elles deviennent un coût pur.
L'alternative asynchrone et distante
L'autre modèle est celui autour duquel nous avons construit TaskGoblin : l'agent ne vit pas du tout dans votre éditeur. Il vit sur une infrastructure dédiée et vous atteint via les outils que votre équipe utilise déjà — un ticket Linear, une merge request GitLab ou GitHub, un fil Slack. Vous lui confiez du travail comme vous le confieriez à un coéquipier distant situé dans un autre fuseau horaire, et il va l'exécuter dans un sandbox cloud pendant que vous passez à autre chose.
Ce changement ressemble à une simple question de l'endroit où s'exécute le calcul. En réalité, il s'agit de ce que l'agent est autorisé à être. Retirez-le de l'ordinateur portable, et les contraintes du « local » tombent une par une :
- Il fonctionne en parallèle. Dix tickets peuvent être traités en même temps, car aucun humain n'a besoin de surveiller chacun d'eux.
- Il est toujours actif. Un agent distant ne s'arrête pas quand vous fermez votre ordinateur portable ; un travail assigné à 18 h est terminé au matin. Les heures-agent disponibles dans une journée cessent d'être vos horaires de travail.
- Il fonctionne sur une infrastructure conçue pour lui, sans se battre avec votre éditeur pour les ressources d'un ordinateur portable de développeur.
- Il travaille là où l'équipe peut le voir. Le résultat est une merge request et un historique de commentaires, pas une session privée — la supervision devient quelque chose que toute l'équipe pratique dans des espaces partagés.
- Il est natif de la plateforme. Il est déclenché par les événements qui circulent déjà dans vos outils — une assignation, une mention, une nouvelle pull request — plutôt que par vous ouvrant une application.
- Il est isolé par construction. Chaque exécution est un environnement sandbox tout neuf avec des identifiants à portée limitée et intermédiés que l'agent ne détient jamais lui-même — une posture de sécurité qu'un processus tournant sur votre propre machine ne peut égaler.
Aucun de ces avantages n'est spectaculaire pris isolément. Ensemble, ils s'accumulent en un écart difficile à contester : dix agents travaillant sans relâche contre un seul qui s'arrête quand vous vous arrêtez.
« Mais j'ai besoin d'une boucle de rétroaction rapprochée »
L'objection la plus forte contre le distant, c'est la boucle rapprochée : l'aller-retour rapide qui consiste à observer un agent, à le corriger en cours de route, à le piloter au feeling. C'est réel, et pour un travail véritablement exploratoire — tester une idée, déboguer quelque chose que vous ne comprenez pas encore vous-même — le local reste le bon outil.
Mais deux choses sont vraies à propos de cette boucle. Elle représente une part du travail plus petite qu'il n'y paraît ; une grande partie de l'ingénierie réelle consiste en des tâches bien spécifiées qui n'ont pas besoin d'un humain penché par-dessus. Et elle se réduit à chaque fois que les agents s'améliorent, car la raison pour laquelle vous restez penché dessus, c'est que vous ne faites pas encore confiance à l'agent pour terminer sans surveillance — et c'est précisément cette confiance qui augmente. La boucle rapprochée ne va pas disparaître, mais elle va décrire une part de plus en plus réduite de la journée.
« Mais la sécurité »
L'objection la plus sérieuse ne concerne pas le flux de travail, mais la confiance : placer votre code et vos identifiants sur l'infrastructure de quelqu'un d'autre. Celle-ci mérite une véritable réponse plutôt qu'un geste évasif, et elle constitue une grande partie de ce que nous construisons. Les exécutions sont isolées par sandbox ; les secrets sont chiffrés au repos et ne sont jamais placés dans l'environnement de l'agent ; les données de chaque organisation sont strictement cloisonnées de celles de toutes les autres. Distant ne signifie pas négligent — fait correctement, un sandbox conçu à cet effet avec des identifiants intermédiés est plus défendable qu'un agent tournant librement sur l'ordinateur portable d'un développeur, avec les jetons réels présents dans son environnement.
Où cela nous mène
Nous n'affirmons pas que le local va disparaître. Le travail exploratoire et certains environnements soumis à des contraintes de conformité conserveront, pendant longtemps encore, une place pour un agent dans l'éditeur. Notre affirmation est plus étroite et, selon nous, plus difficile à esquiver : à mesure que les agents deviennent capables de terminer du vrai travail sans qu'un humain les surveille, le centre de gravité se déplace de l'ordinateur portable vers une infrastructure partagée, toujours active — non pas parce que les développeurs le préfèrent, mais parce qu'une équipe qui fait tourner dix agents sans relâche produira tout simplement davantage qu'une équipe qui n'en fait tourner qu'un jusqu'à ce qu'elle ferme le capot.
C'est le pari sur lequel TaskGoblin est construit. Pas une meilleure fenêtre sur un agent installé sur votre machine, mais un agent qui n'a jamais été sur votre machine — attendant dans les outils que votre équipe utilise déjà, prêt avant même que vous n'ayez fini votre café.
