Agents IA : explorer plusieurs pistes avant de décider

L'essentiel à retenir

Deepthink est un projet open source qui fait travailler plusieurs stratégies sur un même problème. Chaque stratégie avance dans sa propre branche : elle produit une solution, reçoit une critique qui ne la réécrit pas, puis se corrige à l’itération suivante. Des tests ciblés vérifient en cours de route les points incertains, une évaluation périodique garde, réoriente ou remplace les branches, et un juge final retient une solution.

Pour une équipe de 10 à 50 personnes, il sert dans un cas précis : un problème qui admet plusieurs solutions défendables et dont le résultat se vérifie. Par exemple un écart inexpliqué entre deux exports, une règle de regroupement à choisir avant une migration, un traitement qui échoue de temps en temps. Le travail technique revient à la personne qui maintient vos outils ou à un prestataire, car Deepthink s’installe et se règle. Vous fixez le problème, le critère de réussite, le nombre de branches et d’itérations ; vous recevez, pour chaque piste, sa solution et ses critiques, et c’est vous qui décidez.

Le problème que ça résout

Deepthink part d’une idée simple : au lieu d’une seule réponse, plusieurs stratégies distinctes travaillent le même problème, se font critiquer, se corrigent, et une seule est retenue à la fin. Ce que le projet propose est une organisation de la recherche, pas un résultat garanti : ni son README ni sa documentation ne présentent de mesure comparant ce fonctionnement à une trajectoire unique.

Pour une équipe de votre taille, la question utile n’est donc pas « faut-il de l’IA multi-agent ? », mais « quel problème a plusieurs bonnes réponses possibles, et un moyen de les départager ? ». Trois situations s’y prêtent :

• Un écart que personne n’explique. Si votre export comptable et votre facturation divergent certains mois, plusieurs causes sont plausibles : arrondis, dates de facture, doublons. Chaque cause devient une branche, et le test est le mois litigieux, rejoué sur les fichiers que vous joignez au run.
• Une règle à choisir avant une migration. Si vous reprenez votre catalogue produits avant de changer d’outil de gestion, plusieurs façons de regrouper les variantes se défendent. Chaque branche en applique une ; le test est une liste de produits que votre équipe a déjà classés à la main.
• Un traitement fragile. Si un script interne échoue de temps en temps sans message clair, chaque branche suit une hypothèse et doit la démontrer dans le bac à sable du projet, qui peut exécuter du Python, du Node.js ou du Rust.

Dans les trois cas, le travail technique revient à la personne qui maintient vos outils ou à un prestataire : Deepthink est une application à installer, qui appelle le modèle de langage que vous lui configurez. Le cas de test se joint au problème avec les fichiers, et le bac à sable doit être activé pour que les agents puissent rejouer un calcul ou un script plutôt que de raisonner dessus. Votre rôle se situe avant et après le run. Avant, vous formulez le problème, fournissez les fichiers et le cas de test, et fixez le nombre de branches et d’itérations. Après, vous relisez ce que chaque piste a produit et vous décidez. Le juge final du projet désigne une solution ; il ne remplace pas votre arbitrage.

Ce que c'est concrètement

Deepthink est un projet open source écrit en TypeScript. Son mécanisme commence avant toute exécution : un générateur propose des stratégies, puis un relecteur de proximité les renvoie au générateur pendant quelques tours, pour écarter les variations de surface, les idées qui se recouvrent et les angles morts.

Chaque stratégie devient ensuite une branche, dans son propre répertoire. Lors de la première itération, chaque branche produit une première solution, puis un agent critique l’évalue sans la réécrire : justesse, complétude, contraintes non respectées, faiblesses de structure, et viabilité de la stratégie elle-même.

À partir de la deuxième itération, chaque branche passe par une correction puis une nouvelle critique. La correction reçoit le problème, sa stratégie, l’historique de ses critiques et corrections, ainsi que le dernier travail et les dernières critiques des autres branches. Elle peut donc tirer parti d’une piste voisine sans abandonner son propre angle. Toutes les branches terminent une itération avant que l’une d’elles passe à la suivante.

Toutes les quelques itérations, un « heartbeat » fait le point. Un agent de synthèse résume où en est chaque branche, puis un générateur de modules et un relecteur proposent des vérifications ciblées : une incertitude, un goulot d’étranglement, un petit cas révélateur. Chaque module est testé à part, par un agent testeur dédié, et les résultats vérifiés sont transmis aux seules branches qui en ont besoin. Ces modules sont optionnels : le run fonctionne sans eux.

À intervalle plus long, une évaluation globale examine la trajectoire de chaque branche. Un agent décrit ce qui a progressé ou régressé pendant la période, et ce sont des formules fixes, pas un agent, qui en tirent la décision : continuer, faire évoluer la stratégie en gardant le travail, revenir à la dernière bonne itération avec une stratégie modifiée, ou élaguer la branche et la remplacer par une stratégie neuve. Chaque branche non élaguée condense alors son historique dans une mémoire compacte : ce qui a marché, les échecs qui reviennent, les réparations tentées.

À la fin, un juge reçoit la dernière solution et la dernière critique de chaque branche restante, et retient la meilleure.

Avec le bac à sable activé, les agents travaillent dans un dépôt git partagé : chaque branche écrit dans son répertoire, chaque testeur dans le sien. Tous les agents peuvent toutefois lire l’ensemble du dépôt, et l’option qui isole les branches agit par les consignes données aux agents, pas par une barrière technique.

Le projet propose aussi une variante, Adaptive Deepthink, sans calendrier fixe ni juge séparé : un orchestrateur central décide à chaque passe s’il faut générer ou remplacer des stratégies, tester des modules, exécuter, critiquer, corriger, sauvegarder une branche prometteuse ou soumettre la réponse.

Un point à vérifier avant toute réutilisation : le README annonce une licence Apache-2.0, alors que GitHub affiche MIT pour le même dépôt. Contrôlez le fichier de licence de la version que vous utilisez.

Comment s'en servir

Étape 1 : écrire le problème et son test avant d’installer quoi que ce soit

Rédigez en quelques lignes le problème, les fichiers nécessaires et le test qui dira qu’une piste a réussi : le mois comptable qui doit retomber juste, la liste de produits déjà classés, le script qui doit passer sans erreur. Sans test, les branches produiront des textes différents que personne ne pourra départager.

Étape 2 : donner à chaque piste un principe propre

Deepthink génère lui-même les stratégies et retient la dernière proposition de son générateur : vous ne les validez pas une à une. Vos leviers sont en amont : l’énoncé du problème, et le prompt du générateur de stratégies, modifiable dans l’interface. Dites-y ce qui doit distinguer les pistes : une hypothèse, une méthode ou une priorité propre à chacune, et la preuve attendue. Si, après le run, deux pistes ne diffèrent que par leurs mots, resserrez l’énoncé avant de relancer.

Étape 3 : préparer les vérifications

Décidez comment les pistes seront comparées : cas connus, contraintes obligatoires, reproduction de l’erreur, contrôle par la personne qui connaît le métier. Dans Deepthink, les vérifications en cours de route prennent la forme de modules, testés à part puis transmis aux branches concernées. Si votre problème n’en a pas besoin, la configuration permet de les désactiver.

Étape 4 : borner la largeur et la profondeur

La configuration encadre déjà le run : de 1 à 5 branches, de 5 à 20 itérations (10 par défaut), une évaluation globale toutes les 3 à 8 itérations. Pour un premier pilote, restez en bas de ces plages : 2 ou 3 branches, 5 itérations, et une évaluation globale toutes les 3 itérations. Avec le réglage par défaut, toutes les 5, un run de 5 itérations n’en déclencherait aucune : vous ne verriez jamais une branche réorientée ou remplacée. Ce format garde le nombre d’appels bas tout en montrant le mécanisme complet.

Étape 5 : garder la décision

Le juge final désigne une solution parmi les branches restantes. Lisez aussi les critiques de celles qu’il écarte : l’objection qui compte pour votre métier peut s’y trouver. La décision d’appliquer une solution reste la vôtre.

Étape 6 : observer le run

Le run laisse des traces séparées : solutions, critiques, corrections, modules testés et leurs résultats, décisions des évaluations globales, mémoires condensées. Demandez à la personne qui lance le run de conserver ces traces : elles permettent de relier chaque résultat à la branche et à l’itération qui l’ont produit.

Étape 7 : comparer avec une seule piste

Relancez enfin le même problème avec une seule branche, ce que la configuration autorise, et confrontez les deux résultats au même test. Si la version à plusieurs branches ne fait pas mieux sur votre test, gardez la plus simple.

Ce que ça coûte vraiment

Le dépôt ne publie aucun tarif : le coût dépend du modèle que vous configurez et de son prix chez votre fournisseur. La documentation permet en revanche de compter les appels. À chaque itération, chaque branche fait travailler deux agents : une première solution ou une correction, puis une critique. Avec 3 branches et les 10 itérations par défaut, le cœur du run enchaîne donc 60 appels d’agent. Avec 5 branches et 20 itérations, il en enchaîne 200. S’y ajoutent la génération des stratégies, les heartbeats, les évaluations globales et le juge final. Sans bac à sable, un appel d’agent correspond à un appel de modèle, hors relances en cas d’erreur ; avec le bac à sable, chacun enchaîne plusieurs tours de modèle.

Avec le bac à sable activé, chaque appel d’agent dispose par défaut d’un budget de 64 appels d’outils et d’un délai de 60 minutes. Au-delà, le harnais accorde encore quelques tours pour conclure. Ce sont des budgets par appel, pas une estimation : ils ne disent pas ce que le run consommera sur votre problème.

Comptez aussi le temps humain, que le dépôt n’évalue pas : celui de la personne qui installe, règle et surveille le run, et le vôtre pour écrire le test puis relire les pistes. Chiffrez-le avant le pilote, à côté du coût des appels.

Pour qui ce n'est pas

• Si personne, dans l’entreprise ou chez un prestataire, ne peut installer l’application, configurer un modèle de langage et lire ce que produisent les branches.
• Si votre question n’a pas de test : un choix de goût, un texte commercial, une décision qui dépend d’informations absentes des fichiers. Plusieurs branches produiront plusieurs avis, sans moyen de les départager.
• Si une seule piste, relue par quelqu’un qui connaît le sujet, vous suffit déjà : le parallèle multiplie les appels, et ni le README ni la documentation ne mesurent ce qu’il apporterait de plus.
• Si les fichiers concernés ne peuvent pas être envoyés au fournisseur du modèle : la documentation précise que les fichiers texte joints au run sont intégrés au problème transmis aux agents.
• Si le pilote touche à quelque chose d’irréversible : envoi définitif, engagement contractuel, suppression de données, décision qui affecte directement une personne. L’exploration doit pouvoir échouer sans conséquence hors du bac à sable.

Source : https://github.com/ryoiki-tokuiten/Deepthink

FAQ

Faut-il savoir programmer pour utiliser Deepthink ?

Pour le lancer, il faut quelqu’un à l’aise avec un dépôt de code : c’est une application web en TypeScript, à faire tourner soi-même, qui appelle un modèle de langage configuré. Le réglage se fait ensuite dans son interface, avec un panneau de configuration et un éditeur des prompts des agents. Votre rôle est de poser le problème, de fournir le cas de test et de relire les pistes.

Combien de pistes lancer pour un premier pilote ?

La configuration accepte de 1 à 5 branches. Commencez à 2 ou 3, avec 5 itérations, le minimum autorisé, et une évaluation globale toutes les 3 itérations pour qu’elle intervienne au moins une fois. Vous verrez les trajectoires diverger en gardant le nombre d’appels bas.

Combien coûte un run ?

Le dépôt ne donne aucun prix. Il permet de compter : deux appels d’agent par branche et par itération pour le cœur du run, soit 60 avec 3 branches et 10 itérations, plus la génération initiale des stratégies, les étapes périodiques et le juge final. Le prix dépend ensuite du modèle choisi.

Le juge final peut-il décider à ma place ?

Il désigne la meilleure solution parmi les branches restantes ; rien ne vous oblige à la suivre. Comparez les pistes au test que vous avez fixé, et lisez les critiques de celles que le juge écarte.

Les branches peuvent-elles se copier entre elles ?

Par conception, une branche reçoit le travail et les critiques des autres au moment de sa correction. L’option qui isole les branches coupe cet échange, mais par les consignes des agents : techniquement, tous peuvent lire l’ensemble du dépôt.

Que mesurer pendant le pilote ?

Le résultat de chaque piste sur votre test, le nombre d’appels réellement consommés, et la solution retenue par le juge. Puis le même problème avec une seule branche, pour savoir si le parallèle a servi.

---

Publié le 28 octobre 2026.

Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.