DeepSeek publie les plans d’un agent IA qui corrige du code seul

DeepSeek dévoile en accès libre l’architecture d’un agent IA qui repère un bug et propose un correctif seul. Qui relit ce travail ? Détails à vérifier.

6 min de lecture

Une main humaine relit un document de code posé à côté d’un petit robot qui lui tend une page corrigée

DeepSeek, le laboratoire chinois d’intelligence artificielle, aurait publié en accès libre les plans d’un agent IA, c’est-à-dire d’un programme qui agit seul au lieu d’attendre chaque consigne. Selon le média chinois 量子位 (QbitAI), cet agent peut repérer un bug et proposer un correctif sans qu’on le lui demande. L’idée est séduisante. Elle pose une question très concrète : quand une machine corrige du code, qui vérifie son travail ?

Un agent qui agit sans qu’on le lui demande

Ce qui est en jeu : savoir si l’IA reste un outil qu’on interroge, ou devient un collègue qui prend des initiatives.

Un assistant classique, comme un robot de discussion, attend une question et répond. Un agent va plus loin : il enchaîne des actions, lit des messages, ouvre des fichiers, propose des modifications. DeepSeek appelle son système un « super-agent ».

Selon QbitAI, il peut se passer d’instruction humaine. Il peut repérer un bug, chercher d’où il vient, puis soumettre une correction sous forme de pull request. C’est une proposition de modification du code, déposée sur la plateforme GitHub, que l’équipe examine avant de l’accepter ou de la refuser.

Le média ajoute que l’agent peut suivre les messages d’un groupe de travail, collaborer entre plusieurs plateformes et traiter plusieurs tâches en parallèle. Il peut aussi tourner 24 heures sur 24.

Attention au vocabulaire : « open source » signifie que le plan de construction est publié et que n’importe qui peut le lire, l’étudier et le réutiliser. QbitAI renvoie vers un dépôt GitHub nommé « dsh-superagent-prototype ». Ce nom suggère un prototype plutôt qu’un produit fini, mais c’est une déduction, pas une information de la source.

Un répartiteur et des exécutants

Ce qui est en jeu : comprendre comment un agent peut suivre dix chantiers sans perdre le fil, alors qu’un humain en gère trois à cinq.

Selon QbitAI, DeepSeek observe qu’une personne ne suit en général que trois à cinq conversations actives avec une IA à la fois. Plus les modèles progressent sur chaque tâche, plus l’attention humaine devient le goulot d’étranglement. Le super-agent essaie de contourner cette limite.

Son architecture comporte deux étages, d’après le texte :

  • en haut, le Router (« routeur »), sorte de standardiste qui reçoit les messages, répartit le travail et garde la vue d’ensemble ;
  • en bas, les Workers (« exécutants »), des sessions d’agent qui traitent chacune une tâche précise, en parallèle.

Exemple donné : un Worker prend en charge une pull request sur GitHub et reçoit ensuite directement les commentaires qui s’y rattachent, sans repasser par le routeur. Autre exemple : un utilisateur choisit la solution A dans un groupe de discussion, puis demande la solution B dans un commentaire GitHub. L’agent comprend, selon QbitAI, que les deux messages concernent le même travail et ajuste la suite.

En clair : l’utilisateur parle à un seul interlocuteur, et c’est le système qui gère les sessions en coulisses.

Agir avant qu’on le demande, avec modération

Ce qui est en jeu : une IA qui agit seule risque aussi de submerger les gens de notifications inutiles.

Le texte décrit une technique appelée exécution spéculative. Si des collègues discutent d’un bug, l’agent commence à le reproduire et à en chercher la cause. S’il trouve une correction simple, il la propose. S’il ne trouve rien d’utile, il se tait pour ne pas déranger. Le principe vaudrait aussi pour un assistant personnel : face à une invitation à une réunion, il vérifierait l’agenda, rassemblerait des documents et préparerait un brouillon de réponse en attendant la validation de l’utilisateur.

Pour tenir dans la durée, QbitAI cite d’autres mécanismes :

  • un tri des messages : des règles simples écartent le bruit, puis le modèle d’IA juge si le reste demande une action, ce qui réduit la consommation de tokens (des fragments de texte, environ un demi-mot chacun, que le modèle lit et facture) ;
  • une boucle asynchrone, qui permet de répondre à une nouvelle consigne pendant qu’une tâche longue tourne. Selon l’article, elle est implémentée dans l’outil DeepSeek Harness mais pas activée par défaut ;
  • une séparation entre le calcul (dans le nuage), l’état de la session (conservé à part) et l’environnement local, pour que la tâche survive à une mise hors ligne de l’ordinateur ;
  • un agent superviseur, chargé de détecter les pannes, les boucles sans issue et les dérives, et d’essayer de réparer.

Des chiffres qui viennent de DeepSeek seul

Ce qui est en jeu : savoir quoi croire dans un résultat annoncé par celui qui l’a obtenu.

Selon QbitAI, l’équipe a simulé un environnement de travail d’environ 300 messages et 20 demandes, et répété chaque configuration cinq fois. Le super-agent aurait terminé ses tâches en 12,4 minutes en médiane, c’est-à-dire pour la moitié des cas. Pour le 95e centile, c’est-à-dire le seuil sous lequel 95 % des tâches sont finies, le chiffre serait de 15,7 minutes. La méthode classique, une seule session avec des sous-agents, aurait atteint 29,5 minutes pour ce même seuil dans les conditions « neutres » du test.

Supprimer le raccourci qui envoie les commentaires directement au bon exécutant augmenterait d’environ 30 % le nombre de décisions du routeur et d’environ 37 % la lecture de données en mémoire, d’après le texte.

En clair : le système serait environ deux fois plus rapide dans cette simulation. Mais il s’agit d’un test conçu et mené par DeepSeek, sur un scénario à 20 demandes, rapporté par un seul média. Nous n’avons pas lu le texte original de DeepSeek, seulement son récit par QbitAI. Rien ne dit que ces résultats tiendraient face à un vrai projet, avec des demandes floues, des équipes qui se contredisent et du code ancien.

Qui relit le travail de la machine ?

Ce qui est en jeu : une correction automatique mal contrôlée peut introduire une faille ou une erreur dans un produit que des clients utilisent.

Une pull request n’est pas une décision : c’est une proposition. Le modèle de travail décrit garde donc, sur le papier, un humain à la fin de la chaîne. Il faut pourtant poser les questions pratiques. Le relecteur aura-t-il le temps d’examiner dix propositions par jour au lieu de deux ? Saura-t-il distinguer une correction juste d’une correction qui masque le problème ? Et l’agent superviseur, qui surveille les autres agents, est lui aussi une IA : qui le surveille ?

Pour une PME ou un salarié qui testerait ce genre d’outil, la règle de bon sens est simple. Une modification faite par une IA se traite comme celle d’un stagiaire très rapide : on la relit, on la teste, puis on la valide. Plus l’agent est autonome, plus cette relecture compte.

Reste le débat de stratégie. Un laboratoire chinois publie ici ses plans, alors que certains concurrents américains gardent souvent leurs outils fermés. La source consultée ne fait pas cette comparaison et ne dit rien des choix des autres laboratoires. On peut seulement noter que, lorsque les plans sont publics, chacun peut les examiner, les tester et en critiquer les failles. Cela n’établit pas qui fixera les règles de l’IA qui agit seule, ni si un plan ouvert est plus sûr qu’un plan fermé.

Une chose se vérifie dès maintenant : le dépôt est public. Les développeurs peuvent le lire et contrôler eux-mêmes si les promesses de vitesse et d’autonomie résistent à l’épreuve.

Sources

À lire aussi

Tous les articles