ADHD : corriger la convergence prématurée des agents de code par un raisonnement divergent parallèle

Donnez un problème ouvert à un agent et il a un défaut prévisible : il s’arrête au premier plan qui paraît plausible, puis continue d’écrire cette seule voie. Le README en donne un exemple réel. Un CLI appelle un LLM et se bloque parfois 90 secondes, et on demande à l’agent de concevoir une stratégie de retry et de timeout. Un agent en coup unique donne une réponse très standard : timeout de premier token à 15 secondes, timeout entre tokens à 30 secondes, plafond absolu à 90 secondes, plus un retry automatique, en citant le chapitre 22 du livre Google SRE. Rien à redire, mais il ne demande pas une seule fois si le mauvais modèle a été choisi pour ce problème, là où l’appel lent ne devrait pas être retenté du tout, mais relancé sur un modèle plus rapide.

C’est la lacune qu’ADHD vient combler. C’est le paquet npm adhd-agent, sous licence MIT, bâti sur l’Agent SDK de Claude et Codex. Il déploie un problème en parallèle à travers plusieurs frames cognitifs isolés en des dizaines d’idées, puis utilise un seul appel critic séparé pour noter, regrouper, élaguer les pièges et approfondir les meilleures. Dans cette série sur les LLM locaux, il joue un rôle inhabituel : il ne résout pas « où tourne votre modèle », il résout « si votre agent réfléchit assez large à un point de décision clé ».

Le verdict d’abord : il corrige la convergence prématurée

La convergence prématurée (premature convergence) est un problème structurel des modèles autorégressifs. Le modèle génère token par token, et chaque nouveau token est entraîné par ce qui a déjà été écrit. Son premier plan tend donc à être le plus typique, le plus « de manuel » des données d’entraînement. Cette réponse est généralement correcte, mais généralement sans originalité, et pire, souvent un piège qui paraît juste précisément parce qu’il est familier.

Quand cela vous mord-il vraiment ? Sur les décisions d’architecture comme le stockage en couches, le sharding, les modèles d’auth et la topologie de files ; sur le nommage des fonctions, des produits et des variables d’environnement ; et sur un bug flou sans cause racine claire, où il faut d’abord lister quelques classes d’hypothèses. Le point commun : il n’y a pas de réponse standard, et manquer l’option non évidente mais viable peut coûter une réécriture des mois plus tard.

À l’inverse, tout ce qui a une réponse claire ne devrait pas l’utiliser. Chercher comment appeler une API, corriger un bug dont vous avez déjà trouvé la cause, tout ce qui est à une recherche de distance : c’est du temps et de l’argent gaspillés ici. Un test en une ligne : ce qu’un junior trouverait en googlant, laissez la baseline y répondre ; le moment où un senior s’arrêterait pour dire « il faut que j’y réfléchisse autrement une minute », c’est là qu’ADHD gagne sa place.

Le mécanisme : un mur dur entre deux phases

ADHD est une boucle à deux phases avec une cloison dure entre les phases. L’auteur insiste : mélanger divergence et revue est exactement ce qui détruit la qualité des idées, parce que le critic étrangle le générateur sur place.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Divergence : N branches qui ne se voient pas

La première phase choisit N frames cognitifs et lance N appels Agent SDK concurrents, chacun une session neuve et sans état. Chaque branche ne voit que trois choses : le problème d’origine, le prompt de point de vue d’un frame, et un system prompt qui interdit l’évaluation et le classement. L’essentiel : les branches ne peuvent pas se voir. La branche au point de vue « régulateur » ne lit jamais ce qu’a écrit la branche « speedrunner ». Sans contexte partagé, l’ancrage n’est pas réprimé par le prompt ; il n’existe tout simplement pas par construction.

Focalisation : un seul appel critic séparé

Le critic n’entre en jeu qu’en deuxième phase et fait trois choses. Il note d’abord chaque idée de 0 à 10 sur nouveauté, viabilité et adéquation, et marque chaque piège d’une raison mécaniste, par exemple « shelve n’est pas thread-safe sous charge multi-écriture » plutôt qu’un vague « c’est risqué ». Il regroupe ensuite par angle sous-jacent plutôt que par mots-clés de surface, pour que vous voyiez la forme de tout l’espace de conception. Enfin il approfondit le top-K, 3 par défaut, avec un croquis, le risque porteur, la première étape concrète et 3 à 5 idées filles.

Il y a ici un choix de conception facile à manquer : la séparation entre générateur et critic est mécanique, faite de deux appels API différents avec deux system prompts opposés, et non une promesse faite à la même session de « diverger d’abord, converger ensuite ». L’appel d’une branche isolée ressemble à peu près à ceci :

const branches = await Promise.all(
  frames.map(frame => withSemaphore(concurrency, () => callLLM({
    systemPrompt: `${frame.vantage}\n\nFORBIDDEN: evaluation, ranking, hedging. JSON array out.`,
    userPrompt:   `${problem}\n\n${context ?? ""}`,
  })))
);

Le coût en tokens croît linéairement avec le nombre de branches, et non de façon quadratique, parce que les branches suivantes ne relisent jamais ce qu’ont écrit les précédentes. La concurrence est gouvernée par un sémaphore, 4 par défaut.

Ce que vous obtenez d’une exécution n’est pas un mur de texte mais un résultat structuré : l’ensemble complet d’idées regroupées, une liste courte de 2 à 4 candidats, une option « non évidente mais viable » explicitement signalée, une liste de pièges avec une raison pour chacun, les branches approfondies, et une provocation joker. De retour au problème de retry, le coup unique ne donnait que l’hybride de manuel ; l’option qu’ADHD a fait remonter parmi plus de 30 idées était « un bouton qui chauffe d’autant plus qu’on attend, un clic annule et resoumet à un modèle plus rapide de la famille Haiku », tout en signalant tôt des idées qui sonnent amusantes mais sont des pièges, comme « streamer les tokens à l’envers » et « facturer à la patience », avant qu’elles ne coûtent du temps d’ingénierie.

En quoi il diffère de Chain-of-Thought et Tree-of-Thought

Ces trois-là sont les plus faciles à confondre, mais ils sont structurellement différents.

Trois différences porteuses méritent d’être isolées. Premièrement, c’est de l’isolation, pas de la recherche. Les branches de CoT et ToT partagent une fenêtre de contexte, si bien qu’à l’étape quatre le modèle est ancré sur ses trois premières étapes ; les branches d’ADHD ne se voient pas pendant la divergence, donc l’ancrage est éliminé par construction. Deuxièmement, il varie le frame, pas l’étape suivante. Les branches de ToT varient en général le prochain coup (essaie ce nombre, essaie celui-là), tandis qu’ADHD varie le point de vue sur tout le problème, demandant en somme au modèle de « reposer ceci comme un problème matériel », ce qui produit des idées structurellement différentes plutôt que des ajustements voisins. Troisièmement, la séparation générateur-critic est mécanique plutôt que promise.

Une précision : ADHD est lui-même une variante de Tree-of-Thought, et la phase d’approfondissement déploie bel et bien des nœuds top-K. La nouveauté, c’est que le branchement est piloté par des frames, et que la séparation de la revue repose sur deux appels réellement distincts.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Ce qu’est un frame : changer le point de vue sur tout le problème

Un frame n’est pas du jeu de rôle. C’est un « opérateur de point de vue », un system prompt qui repose tout le problème depuis une position cognitive donnée. Contrairement à la recherche sur les prompts de persona et son « tu es un ingénieur de 34 ans nommé Alex », un frame ne fait pas jouer un personnage au modèle ; il le force dans un coin de pensée vers lequel il ne dériverait pas naturellement.

Le projet livre 15 frames, et avec codeMode activé (par défaut) il penche vers des points de vue d’ingénierie. Quelques-uns concrets : l’ingénieur matériel pense en latence, en disposition mémoire et en contraintes physiques ; l’astreinte de 3 heures du matin pense « quel design m’éviterait d’être réveillé » ; le frame « retirer l’hypothèse porteuse » demande « qu’est-ce qui reste possible si le framework, la base et le réseau ont tous disparu ». Chaque exécution choisit les frames de façon déterministe selon une seed et réserve toujours un wild slot, pour que la divergence reste un peu étrange.

Quelques frames inter-domaines sont particulièrement doués pour extraire des idées transposables : la biologie s’appuie sur le système immunitaire, la plasticité neuronale et la signalisation cellulaire ; la logistique pense en files, en lots, en livraison juste-à-temps et en moyeu-rayons ; le game design pense en boucles, récompenses, friction, points de sauvegarde et astuces de speedrun. La vraie bonne réponse à un problème ouvert vit souvent hors du manuel d’un seul domaine et doit être transplantée d’ailleurs, ce qui est précisément la raison d’être des frames inter-domaines.

Écrire votre propre frame prend environ 5 lignes de code. Un bon frame remplit au moins deux critères sur trois : un vocabulaire qu’aucun autre frame n’emploie, une posture distincte des autres (adversariale, constructive, naïve, maximaliste), et une distorsion reproductible qui fait remonter des idées que les autres frames manquent. Se contenter de renommer le domaine en disant la même chose ne passe pas.

Quand l’utiliser, et quand non

Traitez-le comme un outil de point de décision, pas comme un outil à chaque frappe. Le tableau ci-dessous s’applique directement.

Ayez le coût en tête. Une exécution par défaut représente environ 10 appels LLM : 5 appels de divergence par défaut, plus 1 notation, 1 regroupement et 3 approfondissements, soit environ 5 à 10 fois un coup unique, avec 30 à 90 secondes de temps réel. Le cadrage de l’auteur est concret : dépenser environ 0,30 dollar pour élargir une décision d’architecture à 50 000 dollars, ne pas l’exécuter à chaque frappe, l’exécuter aux points de décision. Une réserve honnête : dans une session Claude Code portant un gros CLAUDE.md et un contexte d’outils, chaque branche recharge ce substrat de base, si bien que le coût réel en tokens est plus proche de « branches fois base plus branche », supérieur au coût algorithmique brut.

Comment l’installer et le déclencher

L’installation tient en une commande qui détecte automatiquement votre agent parmi Claude Code, Cursor, Antigravity, Codex, Cline, Gemini CLI, Windsurf et une cinquantaine d’autres.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

npx skills add UditAkhourii/adhd

Une fois installé, déclenchez-le explicitement avec /adhd "votre problème", ou laissez-le se déclencher automatiquement sur des intentions d’idéation. Codex a sa propre voie de découverte ; quand la commande universelle ne s’enregistre pas, forcez la cible :

npx skills add UditAkhourii/adhd -a codex -g

Vous pouvez aussi copier SKILL.md à la main dans le répertoire de skills de Codex, ~/.codex/skills/adhd/ ; après un redémarrage, /adhd "design a rate limiter" passe par ce skill. Les usages CLI et bibliothèque existent aussi : npm install -g adhd-agent pour la CLI, npm install adhd-agent pour l’utiliser comme bibliothèque.

Avant d’installer un skill tiers, lisez son SKILL.md pour voir ce qu’il demande à l’agent, surtout s’il appelle des commandes externes. Le guide pratique de revue de sécurité des skills OpenClaw est une référence utile ici ; passer 5 minutes sur les frontières de permissions vaut mieux que de réparer après coup.

Au sujet des modèles locaux, soyons francs : ADHD est bâti sur l’Agent SDK et utilise par défaut des modèles de la famille Claude, ce n’est donc pas un outil local clé en main. Brancher un modèle local, par exemple servi par Ollama, suppose d’écrire vous-même un adaptateur à la couche d’appel, et le projet ne promet pas que cette voie soit fluide. Sa place dans cette série sur les LLM locaux tient à sa réflexion au niveau du raisonnement des agents, pas à l’idée qu’on pourrait le donner tel quel à un petit modèle local.

Conclusion

Traitez ADHD comme un outil qu’on sort à un point de décision, pas comme quelque chose qui prend en charge tout votre flux de travail. Sa valeur n’est pas « penser plus » mais « penser autrement », plus une passe de revue séparée qui pointe les pièges. Exécutez-le une fois sur une décision d’architecture pour laquelle vous avez déjà une réponse, comparez l’option non évidente qu’il renvoie à votre propre plan, puis décidez si vous le branchez dans votre boucle d’agent.

Pour continuer, voyez le panorama des outils de code IA 2026 pour situer sa place dans le paysage des outils, ou l’analyse de l’architecture DeepAgents pour comprendre comment les sous-agents et les outils de planification organisent le raisonnement.