DeepSeek Super-agent : qu’est-ce qu’un agent de codage cloud, et quelle est sa place ?

Une nouvelle habitude s’est répandue dans les outils de développement : confier une tâche quelque part — une Issue, une mention dans un chat, un champ de prompt —, fermer son ordinateur portable et retrouver une branche ou une pull request produite par un agent pendant son absence. GitHub, Cursor, OpenAI, Anthropic, Cognition et xAI proposent désormais chacun une version de ce concept, sous des appellations telles qu’agent cloud, agent en arrière-plan, session cloud ou ingénieur logiciel autonome. Cet article présente cette catégorie : ce que font réellement ces produits, comment fonctionne le processus, ce à quoi vous renoncez et quelle place y occupe le prototype open source Super-agent de DeepSeek.

Qu’est-ce qu’un agent de codage cloud ?

Le terme est assez vague ; il est donc utile de nommer les trois éléments communs à tous les produits de cette catégorie :

• Un déclencheur qui ne nécessite pas d’éditeur ouvert. Le travail arrive sous forme d’affectation d’Issue, de mention @ dans Slack ou Feishu, de prompt dans une application web, d’appel API ou de transfert depuis une CLI.
• Un environnement hors de votre machine. L’agent clone le dépôt, installe ce dont il a besoin et travaille dans un bac à sable ou un espace de travail géré par le fournisseur ou votre organisation.
• Un résultat vérifiable. Il produit une branche, un diff, une PR en brouillon ou un commentaire — quelque chose qu’une personne peut examiner et traiter.

Cela distingue cette catégorie de deux voisines. Un agent d’IDE local s’exécute sur votre ordinateur portable pendant que vous le surveillez ; un assistant de chat répond aux questions sans toucher au dépôt. Un agent de codage cloud se situe entre les deux : il dispose d’outils réels et d’un véritable checkout, mais l’humain est censé s’absenter.

Le mot bot décrit la forme de chat de la même idée. Au lieu d’attribuer une Issue, vous mentionnez l’agent dans Slack, Teams ou Feishu. Le déclencheur change, mais pas l’environnement distant. Le résultat peut être une PR, un diff ou un ensemble de fichiers terminés.

Panorama des produits

Six produits, décrits selon les termes de leurs fournisseurs :

Grok Bot est l’entrée la plus généraliste : xAI le décrit comme un coéquipier IA persistant, lancé depuis un chat sur ordinateur ou mobile, ou en mentionnant @bot sur X lorsque les comptes sont associés. Il s’exécute sur une machine cloud liée au compte et hébergée par Cursor, avec accès au navigateur, au stockage et à la ligne de commande. Sa documentation parle de fichiers terminés et de brouillons, mais pas d’un processus lié à un dépôt ; la création de branches et de PR n’y est pas documentée. Il se situe donc à l’extrémité « bot » du spectre.

Quatre différences comptent davantage que le tableau :

L’emplacement du déclencheur. L’agent cloud GitHub Copilot et OpenAI Codex Cloud sont conçus pour traiter des tâches qui se trouvent déjà sur GitHub ou dans l’application ChatGPT. Cursor Cloud Agents et Devin privilégient une interface de chat : une conversation Slack ou Teams sert de point d’entrée. Les sessions cloud Claude Code peuvent être déclenchées depuis un navigateur, un téléphone, l’application de bureau ou la commande claude --cloud dans un terminal ; elles peuvent aussi s’exécuter selon un calendrier.

La transparence du fournisseur. Claude Code documente en détail son isolation : dans les environnements hébergés par Anthropic, chaque session s’exécute dans une VM isolée, l’accès réseau est limité par défaut et les identifiants Git restent hors du bac à sable ; un proxy s’authentifie au nom de la session. Les organisations peuvent plutôt rediriger les sessions vers un environnement auto-hébergé, dont l’isolation est alors de leur responsabilité. Les sessions cloud partagent les limites de requêtes de votre forfait, sans frais distincts pour la VM ; elles nécessitent une connexion à claude.ai et ne sont pas disponibles lorsque Claude Code est configuré avec Amazon Bedrock, Agent Platform de Google Cloud ou un autre fournisseur tiers. Les autres fournisseurs publient moins d’informations sur le fonctionnement interne ; « bac à sable » ou « VM » constitue souvent toute la description publique.

Ce à quoi l’agent est autorisé à accéder. Certains produits se limitent à un seul dépôt ; d’autres mettent en avant le travail à l’échelle d’une organisation ou sur plusieurs dépôts. C’est le premier point à vérifier par rapport à votre propre configuration : un agent compétent auquel on donne accès au mauvais périmètre de dépôts est soit inutile, soit dangereux.

Le type de travail visé. La plupart des produits de cette liste sont conçus pour coder dans un dépôt donné. Grok Bot est un coéquipier cloud généraliste : sa documentation parle de fichiers et de brouillons, pas d’un processus lié à un dépôt. Voyez « agent cloud » comme un spectre, et non comme une forme de produit unique.

Comment fonctionne réellement le processus

Dépouillé de son habillage marketing, le processus est similaire partout :

1. Réception. Un déclencheur arrive. Le produit détermine s’il s’agit d’une véritable tâche, pose parfois une question de clarification, puis met une session en file d’attente.
2. Environnement. L’agent clone le dépôt sur la bonne branche, exécute un script de configuration ou une image, puis installe la chaîne d’outils. L’accès réseau et les secrets sont configurés à cette étape, pas plus tard.
3. Travail. L’agent lit le code, modifie des fichiers, lance des tests et des commandes et ouvre parfois un navigateur. Les tâches longues se poursuivent même lorsque votre ordinateur portable se met en veille.
4. Résultat. Il pousse une branche et ouvre une PR, ou laisse un diff accompagné d’un résumé écrit. Certains produits renvoient des PR en brouillon parce que l’agent est censé s’arrêter avant la fusion.
5. Révision. Une personne lit le diff, laisse des commentaires, puis fusionne, demande des modifications ou reprend le travail dans une session locale. Certains produits peuvent aussi surveiller la PR et pousser des correctifs en cas d’échec de la CI.

Les différences qui posent problème se trouvent aux étapes 2 et 5. Un script de configuration trop long, un dépôt que l’agent ne peut pas cloner, une politique réseau qui bloque un registre de paquets ou des identifiants invisibles depuis le bac à sable peuvent interrompre une tâche qui semblait simple. Et « résultat vérifiable » signifie toujours qu’un humain l’examine : aucun de ces produits ne supprime l’étape de révision, ils déplacent la saisie.

Pourquoi cette vague arrive maintenant

Trois conditions devaient être réunies. Les modèles sont devenus assez fiables pour exécuter de longues séquences d’appels d’outils sans supervision constante. Les bacs à sable et les scripts de configuration sont devenus assez abordables pour offrir un environnement propre à chaque tâche. Enfin, la pull request est devenue l’interface par défaut entre un agent et une personne chargée de la révision, ce qui a évité aux équipes d’inventer un nouveau processus de révision.

Il y a aussi la question de l’attention. L’essai de conception qui accompagne DeepSeek l’énonce explicitement : une tâche unique est limitée par le modèle, mais le débit d’une personne sur plusieurs tâches est limité par son attention. Un agent cloud décharge la personne de la gestion des sessions, du changement de contexte et de l’attente. Cette affirmation vient de l’essai de DeepSeek, et non d’une étude indépendante, mais elle explique pourquoi cette catégorie paraît utile.

Ce à quoi vous renoncez

Tous les produits hébergés échangent du contrôle contre de la commodité :

• Périmètre de confiance. Votre code, et parfois vos identifiants, quittent votre machine. Les fournisseurs publient des informations plus ou moins détaillées sur l’isolation, la conservation des données et l’accès réseau ; examinez-les pour chaque produit au lieu de supposer que toute la catégorie fonctionne de la même manière.
• Isolation. Une VM gérée est conçue pour contenir l’agent, mais elle reste dans l’environnement du fournisseur. « Bac à sable » peut désigner aussi bien une VM renforcée qu’un conteneur doté d’un large accès réseau.
• Personnalisation. Les agents hébergés proposent des paramètres, pas leur code source. Si votre processus nécessite un autre déclencheur, une autre règle de révision ou un autre modèle, vous êtes limité aux options offertes par le produit.
• Modèle tarifaire. La plupart de ces produits sont facturés par abonnement ou forfait assorti de limites d’utilisation ; le temps de travail de l’agent n’est pas un poste de dépense que vous contrôlez directement. Établissez votre budget en fonction du forfait, et non des tokens.
• Périmètre et dépendance au fournisseur. La prise en charge de plusieurs dépôts, les intégrations de chat et les contrôles d’entreprise varient selon le fournisseur, et transférer un processus de l’un à l’autre n’est pas gratuit.

La voie auto-hébergée : Super-agent de DeepSeek

La publication de DeepSeek est intéressante, car elle demande à quoi ressemble le même processus lorsque le plan de contrôle reste entre vos mains. Le dépôt contient un plug-in TypeScript sous licence MIT pour DeepSeek Harness (DSH), version 0.1.0, publié comme prototype de recherche. Le README précise qu’il a été adapté pour publication, qu’il ne correspond pas exactement à la version interne de DeepSeek et qu’il ne met pas en œuvre toutes les idées de l’essai de conception.

Son architecture repose sur une session Router de longue durée et une session Worker par ticket. Les événements suivent le chemin Source → Trigger → Thread → Eval → Mandate → Ticket → Assignment → Executor. Une équipe autorise le travail au moyen d’une politique ; les mentions @ explicites provenant de personnes autorisées sont acceptées, tandis que le travail proactif démarre en mode observe, qui consigne ce que l’agent aurait fait sans ouvrir de tickets. Chaque Ticket possède sa propre session et son propre répertoire ; une commande de préparation peut créer un git worktree par ticket.

Le modèle opérationnel est à l’opposé d’un bac à sable fourni par un prestataire. Il écoute un dépôt github.com (pas GitHub Enterprise Server) et, éventuellement, Feishu. Les préréglages Router et Worker s’exécutent tous deux avec danger-full-access, sous le compte système d’exploitation de l’opérateur ; les wrappers de compte sélectionnent les identifiants de l’agent, mais n’isolent pas le processus. Le guide de déploiement recommande un compte système dédié qui ne détient que les identifiants de l’agent. L’état est stocké dans SQLite, sous un stateDir configuré. La philosophie se résume en un objectif : solliciter le moins possible l’attention humaine et apporter autant de valeur que possible.

L’essai présente des chiffres de planification issus d’une charge de travail synthétique — environ 300 messages et 20 demandes de travail, des outils simulés, cinq exécutions —, avec un p50/p95 d’environ 12.4 / 15.7 minutes, contre un p95 d’environ 29.5 minutes pour une référence à session unique qui n’effectuait aucun appel à des sous-agents. Il s’agit des propres mesures de l’essai obtenues avec des outils simulés, et non d’un benchmark indépendant de la qualité du code.

Ce que démontre le prototype est plus limité et plus utile qu’un lancement de produit : l’agent de codage déclenché par événement et dont le travail est examiné à la fin n’est pas confiné au cloud d’un fournisseur. Vous pouvez gérer vous-même l’orchestrateur, l’état et le choix du modèle. Le prototype montre aussi le coût de cette maîtrise : vous exécutez le processus, sécurisez le compte et acceptez qu’aucun bac à sable ne soit fourni par défaut.

Qui devrait choisir quoi

Restez avec un agent cloud hébergé si vous souhaitez n’avoir aucune opération à gérer, un bac à sable administré par le fournisseur, des fonctionnalités multi-dépôts ou destinées aux organisations, ainsi qu’un déclencheur dans GitHub, Slack, Teams ou une application web. Le fournisseur prend en charge l’isolation et la disponibilité.

Envisagez le prototype auto-hébergé si le code ne peut pas quitter votre infrastructure, si vous devez modifier l’orchestration ou si vous souhaitez choisir un modèle pour chaque rôle. Prévoyez une machine dédiée ou un compte de système d’exploitation dédié, et considérez ce code comme un logiciel de recherche.

Une approche pratique : des agents hébergés pour les tâches courantes sur les dépôts, et un agent auto-hébergé uniquement pour les dépôts où la frontière des données est importante. L’étape de vérification est la même dans les deux cas.

Remarque sur les modèles

Le prototype ne fixe pas de modèle dans le code. Il utilise le modèle par défaut du profil Harness, sauf si Eval ou Execution le remplacent ; une équipe peut donc affecter un modèle plus léger au Router et un modèle plus puissant aux Workers. AIHubMix connecte DeepSeek Harness via un endpoint compatible avec OpenAI à https://aihubmix.com/v1 ; l’exemple du guide DeepSeek Harness utilise le fournisseur aihubmix et le modèle auto. Le guide explique la connexion DSH de base, pas le plug-in Super-agent, et les produits hébergés ci-dessus gèrent eux-mêmes le choix du modèle.

FAQ

Qu’est-ce qu’un agent de codage cloud ?
Un logiciel qui prend en charge une tâche de codage reçue via une Issue, une mention dans une conversation ou un appel API, l’exécute dans un environnement extérieur à votre machine et renvoie une branche, un diff ou une pull request à examiner.

Est-ce la même chose qu’un agent de codage local ?
Non. Un agent local s’exécute dans votre terminal ou votre IDE pendant que vous le surveillez. Un agent cloud continue de travailler après la fermeture de votre ordinateur portable et est conçu pour être examiné plus tard.

Faut-il quand même examiner le code ?
Oui. Tous les produits présentés ici fournissent un diff ou une PR qu’une personne doit examiner. L’agent se charge de la saisie, pas de l’approbation.

Où votre code s’exécute-t-il ?
Dans l’environnement du fournisseur. Les détails varient : Copilot décrit un bac à sable cloud ou un environnement Actions, Cursor des VM isolées, Codex un espace de travail cloud, Claude Code une VM isolée gérée par Anthropic ou un environnement auto-hébergé par une organisation, et Devin un espace de travail comprenant un terminal, un éditeur et un navigateur. Consultez la documentation de sécurité de chaque fournisseur avant de lui confier du code privé.

Qu’est-ce qu’un bot de codage ?
La version intégrée aux conversations du même concept : vous mentionnez l’agent dans Slack, Teams ou Feishu au lieu de lui attribuer une Issue. Il travaille toujours dans un environnement distant ; le résultat peut être une PR ou un diff, ou, dans le cas d’un coéquipier polyvalent comme Grok Bot, des fichiers finalisés et des brouillons.

Qu’apporte le Super-agent de DeepSeek ?
Une implémentation auto-hébergée, sous licence MIT, de la même boucle, avec une architecture Router–Worker, un modèle de règles et de tickets, et une intégration Feishu facultative. C’est un prototype de recherche, pas un produit hébergé.

Est-il prêt pour la production ?
Non. Le README le qualifie de code de recherche, les configurations prédéfinies s’exécutent avec danger-full-access et aucun bac à sable n’est fourni par défaut. Si vous l’essayez, utilisez un compte de système d’exploitation dédié et un compte GitHub réservé à l’agent.

Sources

1. deepseek-ai/dsh-superagent-prototype — README, essai de conception cité et docs/000–008
2. Connecter DeepSeek Harness à AIHubMix — AIHubMix
3. Agent cloud GitHub Copilot — Documentation GitHub
4. Agents cloud Cursor — Documentation Cursor
5. Codex Cloud — ChatGPT Learn / OpenAI
6. Claude Code dans le cloud — Anthropic
7. Documentation Devin — Cognition
8. Documentation Grok Bot — xAI