---
title: 'DeepSeek SuperAgent : un agent autonome piloté par GitHub'
description: "DeepSeek ouvre dsh-superagent, un prototype d'agent qui travaille sur un dépôt GitHub, découpe les demandes en tâches parallèles et répond dans le fil d'origine."
pubDate: 2026-11-02
family: 'intelligence-artificielle'
tags: [DeepSeek]
heroImage: /images/deepseek-superagent-un-agent-qui-travaille-a-ta-place.webp
videoUrl: 'https://youtu.be/5cn3S6TiF0A'
faq:
  - question: 'SuperAgent est-il un produit officiel DeepSeek ?'
    answer: "Non. Le dépôt le présente comme un prototype de recherche, pas un produit DeepSeek, et précise que le code publié diffère de la version interne et de l'architecture décrite dans l'article de conception."
  - question: 'Peut-on utiliser son propre compte GitHub ?'
    answer: "Techniquement oui, mais se mentionner soi-même dans une issue ne déclenche pas de tâche : il faut un second compte pour que l'agent soit mentionné et puisse répondre. Un compte dédié reste la recommandation du guide d'installation, pour identifier clairement ce que l'agent a produit."
  - question: 'Combien de tâches peut-il exécuter en parallèle ?'
    answer: "Le prototype observé dans la démonstration en exécute trois au maximum. Les évènements GitHub sont par ailleurs relus toutes les 60 secondes, alors qu'une réponse dans un fil auquel l'agent est abonné arrive directement."
---

Le 31 octobre 2026, l'équipe DeepSeek Harness a publié `dsh-superagent-prototype` sous licence MIT, avec une description sans ambiguïté : « Towards a More Autonomous Agent System ». Le dépôt a dépassé les 12 000 étoiles en deux jours. Ce n'est pourtant ni un produit, ni une version de DeepSeek Chat : c'est un prototype de recherche, et le README insiste lourdement sur ce point.

L'idée tient en une phrase, citée du guide : **« take as little human attention as possible, and give as much value as possible »**. L'agent ne remplace pas ta session de code, il absorbe la coordination : recevoir une demande, ouvrir un ticket, travailler dans son propre contexte, répondre dans le fil d'origine.

## Le problème qu'il prétend résoudre

Un assistant classique fonctionne par session : tu ouvres une conversation, tu donnes une tâche, tu attends. Pour avancer sur autre chose, tu relances une session, tu redonnes du contexte, et tu recommences. Quand tu multiplies les sessions, tu passes plus de temps à les surveiller qu'à coder.

DeepSeek chiffre cette limite dans son article de conception : un développeur suit en pratique **trois à cinq sessions actives** en parallèle. Au-delà, la coordination coûte plus cher que le travail produit. SuperAgent déplace cette coordination du développeur vers le système.

## Quatre piliers

La vidéo les présente dans cet ordre, et ils expliquent l'architecture qui suit.

- **Continuité** : le système garde une vue d'ensemble du projet au lieu de conversations isolées qui ignorent le travail des autres.
- **Productivité** : une demande peut être répartie entre plusieurs agents qui avancent chacun de leur côté.
- **Proactivité** : un évènement GitHub est analysé pour décider s'il mérite une intervention, mais uniquement si les règles définies l'autorisent.
- **Persistance** : une tâche qui attend une réponse ou prend du temps reste suivie et peut être reprise.

## Router et Workers

Deux rôles distincts, et c'est la partie la plus intéressante du projet.

Le **Router** est le chef d'orchestre : il reçoit les demandes, regarde ce qui se passe sur le dépôt et décide si une tâche doit être lancée. Il conserve une vue globale sans connaître chaque ligne modifiée.

Les **Workers** exécutent : analyser le code, corriger un bug, développer une fonctionnalité, préparer une pull request. Chacun dispose de son propre environnement de travail, ce qui évite de mélanger les contextes, un peu comme des worktrees Git.

Le prototype publié n'implémente pas toute la vision décrite dans l'article de conception. Le README prévient qu'il a été adapté pour la publication, qu'il diffère de la version interne et que certaines idées restent des directions futures. La séparation complète entre l'orchestration et les machines d'exécution en fait partie : c'est un objectif, pas une fonctionnalité livrée.

## Comment une tâche démarre

Tu n'as pas besoin d'ouvrir une conversation. Le système surveille le dépôt GitHub : une issue créée, un commentaire sur une pull request, une CI en échec. Le Router récupère l'évènement, vérifie les autorisations, puis décide s'il y a lieu d'intervenir. Si la demande est acceptée, il crée une tâche et la confie à un Worker.

Le suivi reste attaché à la discussion GitHub d'origine. Tu peux continuer à échanger avec l'agent là où la demande a été faite, sans lui réexpliquer ce qu'il vient de faire.

## Installation

Les prérequis, listés dans le guide : Node.js 22.19 ou plus récent, ou Node 24 ; pnpm ; git 2.32 ; Python 3.8 ; tmux ; GitHub CLI 2.48 ; une version de DeepSeek Harness compatible avec le champ `engines.dsh` du projet ; et un fournisseur de modèle configuré, sinon l'agent ne peut rien exécuter.

Les commandes viennent de `docs/006-deployment.md` :

```bash
npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone https://github.com/deepseek-ai/dsh-superagent-prototype dsh-superagent
cd dsh-superagent
pnpm install && pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"
```

La quatrième commande crée le profil `superagent` à partir du modèle Web de DSH ; la cinquième y installe le bundle. Elle **remplace** le profil s'il existe déjà et supprime son `cordis.patch.yml` : à ne jamais relancer sur une installation existante.

Tu n'es pas obligé de suivre ces étapes à la main. Le dépôt fournit `SETUP.md`, un protocole destiné à un agent de code : tu lui demandes de lire le fichier et de t'accompagner. C'est la méthode utilisée dans la vidéo, avec OpenCode. L'agent pose une question à la fois, avec une réponse recommandée, affiche le plan complet, puis exécute.

Les questions portent sur les sources (GitHub seul ou GitHub et Feishu), le dépôt, le compte agent, la liste des personnes autorisées, le clone local, l'identité de commit et l'auto-merge. Le mode d'acceptation par défaut est `observe` : l'agent enregistre le travail proactif sans l'exécuter.

## Ce que la démonstration montre

Une fois le profil lancé, le panneau est disponible sur le port `3082`, avec une entrée **SuperAgent**.

Dans la vidéo, quatre tickets sont d'abord créés sur le blog, puis l'agent est mentionné dans une issue. Deux détails pratiques apparaissent :

- **Se mentionner soi-même ne fonctionne pas.** Avec un compte personnel, la mention de son propre nom ne déclenche rien. Il faut un compte dédié à l'agent, l'inviter sur le dépôt, et le mentionner lui. C'est aussi ce qui rend ses commits et ses pull requests identifiables.
- **Les évènements ne sont pas instantanés.** Un polling de 60 secondes relit les évènements GitHub. En revanche, quand l'agent est abonné à un fil, les réponses suivantes arrivent directement.

Le panneau montre aussi la limite d'exécution du prototype : **trois tâches en parallèle** au maximum. Les suivantes attendent.

À la fin de la démonstration, deux pull requests sont ouvertes par l'agent, avec résumé, tests et fichiers modifiés visibles dans l'interface. Leur CI est rouge pour une raison instructive : le déploiement Vercel n'est autorisé que pour le compte du propriétaire du dépôt. Un agent qui travaille sous un autre compte produit du code valide mais ne déclenche pas les mêmes permissions. C'est le genre de détail qui se règle dans les règles du dépôt, pas dans le prompt.

## Ce qui doit te retenir

Le README est plus honnête que la plupart des annonces :

- le code est un **prototype de recherche**, pas un logiciel prêt pour la production ;
- il peut contenir des bugs et des incohérences de style ;
- il diffère de la version interne de DeepSeek et de l'architecture décrite dans l'article ;
- il faut le relire et l'adapter avant de l'utiliser.

Ajoute une règle de conception que le projet assume : un agent qui agit pour toute une équipe peut aussi **consommer l'attention de toute l'équipe**. D'où la liste d'autorisation, le mode `observe` et l'interdiction d'agir sans demande explicite.

## Pour qui, et à quelle condition

SuperAgent a du sens si tu as déjà un dépôt, plusieurs demandes qui arrivent dans des issues, et que la coordination te coûte plus cher que l'écriture. Il n'a pas de sens pour un projet solo où une session Claude Code suffit, ni comme remplacement d'une CI : l'agent produit du code, il ne garantit pas qu'il passe les tests.

La bonne façon de l'essayer : un dépôt de test, un compte GitHub dédié, une liste d'autorisation réduite à toi, et le mode `observe` pendant quelques jours. Tu regardes ce qu'il aurait fait avant de le laisser ouvrir des pull requests.

Si tu veux comparer avec une approche plus classique, l'article sur [Claude Code et le coût du contexte](/blog/claude-code-graphify-enfin-la-solution-quon-attendait-tous/) explique comment mesurer ce qu'une session consomme réellement, et [le cluster d'agents de code](/blog/agents-ia-code/) rassemble les outils qui travaillent déjà sur un dépôt. Pour comprendre la base sur laquelle SuperAgent est construit, [DeepSeek Harness et son architecture modulaire](/blog/deepseek-harness-claude-code-ne-sait-pas-faire-ca/) restent la page de référence.

## Questions fréquentes

**SuperAgent est-il un produit officiel DeepSeek ?**

Non. Le dépôt le présente comme un prototype de recherche, pas un produit DeepSeek, et précise que le code publié diffère de la version interne et de l'architecture décrite dans l'article de conception.

**Peut-on utiliser son propre compte GitHub ?**

Techniquement oui, mais se mentionner soi-même dans une issue ne déclenche pas de tâche : il faut un second compte pour que l'agent soit mentionné et puisse répondre. Un compte dédié reste la recommandation du guide d'installation, pour identifier clairement ce que l'agent a produit.

**Combien de tâches peut-il exécuter en parallèle ?**

Le prototype observé dans la démonstration en exécute trois au maximum. Les évènements GitHub sont par ailleurs relus toutes les 60 secondes, alors qu'une réponse dans un fil auquel l'agent est abonné arrive directement.