DeepSeek ouvre le prototype Super-agent : le p95 du temps de tâche passe de 29,5 à 15,7 minutes

DeepSeek a publié en accès libre le prototype Super-agent, un système multiagent qui sépare la conversation avec les humains de l'exécution du travail, confiées à des sessions distinctes. Une session routeur reçoit les demandes et répartit les tâches. Des workers isolés les exécutent en parallèle, déclenchés par des événements GitHub. Dans le test de DeepSeek, le p95 du temps d'exécution d'une tâche est passé de 29,5 à 15,7 minutes, par rapport à une session unique. L'analyste en actualités IA @kimmonismus a signalé la sortie ; son post sur X a recueilli environ 91,6 mille vues.

Le routeur d'un côté, les workers de l'autre

Le schéma sera familier à ceux qui ont déjà construit des agents de développement. Dans une configuration classique à agent unique, le même agent discute avec l'utilisateur et mène lui-même le travail de longue haleine : lire le dépôt, modifier le code, lancer les vérifications. Tant qu'il est occupé, les nouvelles demandes attendent ou s'insèrent dans son contexte et perturbent la tâche en cours.

Dans Super-agent, ces rôles sont séparés. Le routeur reste la « vitrine » du système : il parle aux humains, comprend ce qu'on lui demande et transmet le travail. Le travail proprement dit revient aux workers. Chacun est isolé : il vit dans un environnement distinct, avec son propre contexte, et n'influe pas sur ses voisins. Les déclencheurs sont des événements GitHub : l'apparition d'une issue, un commentaire, une pull request et autres signaux similaires. L'agent n'attend pas une commande dans un chat, il réagit à ce qui se passe dans le dépôt.

Cette approche présente deux avantages évidents. Les tâches parallèles ne font pas la queue au même endroit, et l'erreur ou le blocage d'un worker n'abîme pas le contexte des autres et ne bloque pas le dialogue avec l'humain.

Ce que montre la mesure de DeepSeek

La seule donnée chiffrée publique du message est le p95 du temps d'exécution. C'est le temps dans lequel 95% des tâches sont terminées : un indicateur de « longue traîne », qui reflète les cas les plus lents. C'est précisément celui qui compte pour le travail en équipe : la vitesse moyenne dit peu de chose si une tâche sur vingt traîne pendant une demi-heure. Pour la session unique, le p95 atteint 29,5 minutes ; pour le système avec routeur et workers, 15,7 minutes. La traîne des délais a donc été réduite de près de moitié, d'environ 47%.

L'explication plausible est le parallélisme. Quand les tâches arrivent en lot, la session unique les traite l'une après l'autre, et les dernières attendent le plus longtemps. Les workers les prennent simultanément, et la file ne s'allonge pas. Cette explication est déduite de la description de l'architecture, et non des données publiées du test.

Ce qui manque dans le message

Il faut lire ces chiffres avec prudence. Premièrement, le test a été réalisé par DeepSeek elle-même, et aucune reproduction indépendante n'existe pour l'instant. Deuxièmement, le post ne permet pas de connaître la composition de la charge : combien de tâches, quelle complexité, à quelle fréquence elles arrivaient simultanément. Avec un faible parallélisme, le gain pourrait être nettement plus modeste. Troisièmement, le lien vers la solution de référence est tronqué dans le post, si bien que l'on ignore avec quelle configuration à session unique la comparaison a été faite.

Par ailleurs, la vitesse n'est qu'un axe parmi d'autres. Le message ne dit rien de la qualité du résultat : part de pull requests acceptées, nombre d'erreurs, consommation de tokens. Plusieurs workers consomment presque certainement plus de calcul qu'une session unique, ce qui signifie que l'accélération se paiera en argent.

Que faire côté développeurs

Cette publication mérite d'être ouverte par ceux qui construisent des agents autour de GitHub et butent sur des files d'attente. Le prototype permet de voir comment DeepSeek organise le routeur, l'isolation des workers et le lancement par événements, et de comparer avec son propre schéma. Le mot « prototype » parle de lui-même : il est encore trop tôt pour le considérer comme un produit prêt pour la production.

On peut vérifier le gain annoncé sur sa propre charge : prendre un dépôt avec un flux de tâches typiques, les faire passer par un agent unique puis par le schéma « routeur plus workers », et comparer le p95, mais aussi le coût et la part de modifications acceptées. Si la traîne des délais diminue de façon comparable, l'architecture sera rentabilisée. Sinon, les chiffres de DeepSeek resteront un bon résultat sur son propre jeu de tâches.