L'advisor pattern : ce que Claude Code nous apprend sur la délégation

Dans toute organisation mature, l’expertise ne se distribue pas uniformément. Un consultant senior n’est pas sollicité pour chaque micro-décision. Il l’est pour les arbitrages qui en valent la peine. Cette économie de l’expertise rare n’a rien de nouveau : elle est la signature des équipes, des cabinets et des bureaux d’étude qui fonctionnent bien. Elle repose sur un principe aussi ancien que le management lui-même — on traite au plus bas niveau de compétence possible, et l’on escalade vers le niveau supérieur quand c’est justifié.

Le 9 avril 2026, Anthropic a publié un nouvel outil pour ses agents IA : l’advisor tool. Derrière une annonce technique présentée comme un simple ajustement d’API se cache quelque chose de plus intéressant. Ce principe organisationnel — l’intervention ciblée de la ressource rare — vient d’être encodé dans un pattern logiciel natif. Un modèle léger exécute la tâche et consulte ponctuellement un modèle puissant pour les arbitrages qui le dépassent.

La thèse de cet article tient en une phrase. L'advisor tool n'est pas une feature, c'est un pattern de gouvernance qui, une fois replacé sur nos architectures applicatives, rend visible un sur-dimensionnement systémique qu'on ne voyait plus.

Nous allons l’explorer en quatre temps. D’abord la mécanique telle qu’Anthropic l’a conçue. Ensuite les chiffres qui en font un pattern sérieux et non un gadget marketing. Puis la filiation directe avec la manière dont les organisations matures délèguent déjà. Enfin le miroir qu’il tend à nos applications métier, et trois questions qu’un CTO de PME ou d’ETI devrait se poser après avoir refermé cet article.

Le pattern qu’Anthropic a retenu

Pour comprendre pourquoi l’advisor tool rompt avec la logique multi-agents classique, il faut d’abord rappeler le schéma qu’il inverse. Dans l’architecture orchestrateur-sous-agents dominante jusqu’ici, un modèle lourd coordonne le travail. Il découpe la tâche, distribue les sous-tâches à des modèles plus légers, agrège les résultats, arbitre les conflits et produit la sortie finale. Le modèle coûteux est mobilisé en permanence, par construction.

L’advisor pattern inverse cette répartition. C’est l’exécuteur — Sonnet 4.6 ou Haiku 4.5 dans la nomenclature Anthropic — qui pilote la tâche de bout en bout. Il appelle les outils, lit les résultats, itère vers la solution. Quand il rencontre un point de décision qu’il ne sait pas résoudre avec confiance, il consulte l’advisor, typiquement Opus. Ce dernier accède au contexte partagé, renvoie un plan court, une correction ou un signal d’arrêt, puis l’exécuteur reprend son travail.

Le détail qui compte : l’advisor ne produit jamais de sortie utilisateur et n’appelle pas d’outils lui-même. Il ne fait que conseiller. Techniquement, tout se passe dans une seule requête API, sans aller-retour supplémentaire ni gestion de contexte à la charge du développeur.

L’économie de décision qui se dessine est différente de ce à quoi on était habitué. Par défaut, on paie le coût de la compétence légère — rapide, efficace, bon marché. Le coût de la compétence lourde n’arrive que lorsqu’il est justifié par une vraie difficulté. Ce qui relevait jusqu’ici de l’ingénierie système — construire sa propre logique d’escalade entre modèles, gérer soi-même les transferts de contexte — devient un primitif natif de l’API. Selon Anthropic, l’advisor ne génère typiquement que 400 à 700 tokens par consultation, le temps de renvoyer un plan court. L’exécuteur, lui, gère l’intégralité de la sortie à son tarif inférieur.

Ce basculement n’est pas un détail d’implémentation. C’est une prise de position architecturale. Anthropic fait le pari que la majorité des tâches agentic n’ont pas besoin d’un modèle frontière mobilisé en permanence, et que la valeur se trouve dans la capacité à convoquer cette frontière précisément au moment où elle change quelque chose.

Pourquoi il surperforme l’orchestrateur classique

Les chiffres publiés par Anthropic au lancement de l’advisor tool ne démontrent pas à eux seuls la supériorité du pattern. Ils en constituent l’indice. L’indice est néanmoins solide.

Sur le benchmark SWE-bench Multilingual, qui mesure la capacité d’un agent à résoudre des issues de développement logiciel dans neuf langages de programmation, Sonnet 4.6 couplé à Opus comme advisor gagne 2,7 points de score par rapport à Sonnet seul. La surprise n’est pas là — une aide d’un modèle plus intelligent améliore logiquement le score. La surprise, c’est que cette même configuration coûte simultanément 11,9 % de moins par tâche agentique. Mieux et moins cher. C’est rare.

Sur BrowseComp, un benchmark de navigation web agentic, l’effet devient spectaculaire pour le modèle le plus léger. Haiku 4.5 seul atteint 19,7 %. Haiku 4.5 avec Opus comme advisor monte à 41,2 %, soit plus du double. La configuration reste 29 % en dessous de Sonnet seul en score, mais à 85 % de coût en moins par tâche. Un doublement de performance sur un modèle léger pour une fraction du prix d’un modèle intermédiaire : l’arbitrage devient difficile à ignorer. Ces chiffres et leur méthodologie — scores moyennés sur cinq essais, 300 problèmes pour SWE-bench Multilingual, 1 266 problèmes pour BrowseComp — sont détaillés dans le billet de blog officiel d’Anthropic du 9 avril 2026.

Pourquoi ces gains, et pourquoi cette économie simultanée ? L’intuition tient dans un phénomène que les praticiens du multi-agents connaissent bien. L’orchestrateur sature en planification. Plus il y a de sous-agents à coordonner, plus le modèle central dépense d’énergie à découper, arbitrer, réécrire les instructions, synthétiser les retours. Cette surcharge cognitive finit par éroder la qualité même des décisions qu’on lui demande de prendre.

L’exécuteur qui pilote directement bénéficie d’une position différente. Il est dans la tâche, pas au-dessus. Il avance. Il ne convoque l’expertise supérieure que lorsqu’elle change quelque chose à la trajectoire. La mécanique est celle du chef de projet qui veut tout décider — ralentissement garanti — opposée à celle du chef de projet qui délègue bien et arbitre au bon moment.

La règle qui se dégage n’est pas « un modèle fait tout ». C’est : chaque niveau de compétence intervient là où il a un rendement.

Ce que ce pattern reproduit de la délégation humaine

Les ingénieurs d’Anthropic n’ont pas inventé cette logique. Ils l’ont transposée.

Dans un bureau d’étude qui fonctionne bien, un junior exécute et un senior conseille. Le senior n’est pas sollicité pour chaque ligne de code, chaque choix de variable, chaque commit. Il l’est pour les arbitrages qui engagent — architecture, dette, choix structurants, décisions à fort impact. Sa rareté n’est pas un problème à résoudre, c’est une contrainte à respecter. Un senior consulté sur tout devient, mécaniquement, un senior qui ne conseille plus vraiment : il s’épuise sur des décisions mineures et n’a plus la disponibilité cognitive pour celles qui comptent. La valeur de l’expertise rare se détruit dans sa propre banalisation.

La même économie se retrouve partout. Une équipe ops qui tourne : le responsable ne valide pas chaque ticket, il valide les escalades. Un cabinet d’avocats : l’associé n’intervient pas sur chaque dossier, il tranche les points où le jugement métier fait la différence. Un hôpital : le chef de service n’examine pas chaque patient, il est appelé quand le diagnostic ou l’arbitrage thérapeutique l’exige. Le schéma est tellement universel qu’on ne le voit plus. Il mérite pourtant d’être nommé. C’est le principe de subsidiarité technique. On traite au plus bas niveau de compétence possible, on escalade au bon niveau quand c’est justifié.

Ce que l’advisor tool encode, c’est ce principe. Il l’encode pour la première fois de manière native dans l’API d’un modèle frontière, avec toute la mécanique qu’une délégation humaine bien faite exige — contexte partagé, appel ciblé, reprise de tâche, retour borné. Anthropic a regardé comment les organisations matures utilisent leurs experts rares et a décidé que ses agents IA fonctionneraient de la même manière.

Le détail le plus éclairant se trouve dans la contrainte posée à l’advisor. Il ne produit pas de sortie utilisateur, ne prend pas la main sur les outils, ne se substitue pas à l’exécuteur. Il donne un avis et rend la main. C’est exactement ce qu’on attend d’un bon conseiller interne — conseiller, pas reprendre. Le pattern reflète une maturité d’organisation, pas seulement une optimisation de coût.

Le miroir qu’il tend à nos architectures applicatives

Poser ce pattern à côté de nos architectures applicatives actuelles produit un effet miroir qui dérange. Beaucoup d’applications métier que nous rencontrons chez nos clients fonctionnent exactement selon le schéma inverse.

Un CRM qui charge l’ensemble de sa logique de règles, de permissions et de segmentation pour afficher un simple champ dans une fiche contact. Un ERP qui lance un moteur de workflow complet, avec toutes ses vérifications de cohérence transversales, pour un changement de statut qui ne devrait impliquer que trois objets. Une plateforme RH qui interroge tous ses modules — paie, formation, temps, congés, contrats — pour déterminer si un collaborateur peut poser une journée la semaine suivante. Ces applications ne sont pas mal construites. Elles sont souvent techniquement solides, fonctionnellement complètes, et elles marchent. C’est précisément le problème. Elles marchent assez pour qu’on ne les remette pas en cause, et elles coûtent à chaque interaction plus que ce qu’elles devraient.

Le coût est rarement un coût visible sur une ligne de facture. Il se paye ailleurs. En temps de réponse perçu par l’utilisateur — la fiche qui met deux secondes au lieu de deux cents millisecondes. En consommation d’infrastructure qui oblige à sur-dimensionner les environnements de production pour tenir la charge. En dette technique qui s’accumule parce que chaque évolution doit traverser toute la logique, même quand elle ne concerne qu’un chemin étroit et isolé. En coût opérationnel à l’échelle qui devient prohibitif quand la base d’utilisateurs croît, alors que le modèle architectural initial ne le permettait pas.

L’alternative n’a rien d’une révolution. Elle porte un nom bien installé : la composition. Des modules légers qui gèrent la majorité des cas — la lecture d’un champ, l’affichage d’une liste, la mise à jour d’un statut simple. Des appels ciblés à la logique lourde quand c’est justifié — la validation métier complexe, l’arbitrage inter-modules, la règle à fort enjeu qui nécessite une vraie inférence. C’est précisément l’économie que le pattern advisor encode dans l’API Anthropic, transposée au design applicatif.

L’enjeu pour un CTO ou un architecte applicatif n’est pas de copier le pattern ligne à ligne. C’est d’utiliser l’advisor tool comme grille de lecture sur ses propres applications. Quand Anthropic a modélisé ses agents IA pour qu’ils ressemblent à des équipes humaines bien structurées, c’est que cette structure est plus performante, plus économe et plus évolutive. La question que ce pattern retourne vers nous est simple : pourquoi nos applications métier, elles, ressemblent-elles encore à des monolithes intelligents qui savent tout faire et coûtent cher à chaque décision ?

C’est précisément ce que nous abordons dans l’architecture durable qui sécurise votre investissement logiciel, et que l’on retrouve, appliqué à une typologie très spécifique d’application métier, dans l’anatomie d’un CRM moderne et ses cinq piliers architecturaux.

Trois questions qu’un CTO devrait se poser

Trois questions découlent logiquement de ce miroir. Elles ne sont pas abstraites. Elles se posent concrètement, application par application, module par module, et structurent une démarche d’audit architectural qu’un bureau d’étude peut conduire avec méthode.

La première question : où vos applications sur-dimensionnent-elles leurs traitements ? Dit autrement, où la compétence lourde est-elle mobilisée par défaut alors qu’un traitement léger suffirait ? Ces points sont rarement des bugs visibles. Ce sont des choix d’architecture anciens qu’on n’a jamais reconsidérés parce que rien ne les y forçait. Ils se détectent à la mesure — temps de réponse, consommation d’infrastructure, traçage des appels — et à l’observation des parcours utilisateurs les plus fréquents. Si les quatre-vingts pour cent d’interactions les plus courantes empruntent la même logique lourde que les vingt pour cent de cas complexes, il y a probablement un sur-dimensionnement à traiter.

La deuxième question est plus structurelle : vos escalades sont-elles formalisées ou implicites ? Dans le pattern advisor, l’escalade est un appel explicitement nommé — une invocation identifiée de la ressource experte. Dans une application métier bien architecturée, les escalades vers la logique lourde — validation métier complexe, arbitrage inter-modules, règle à fort enjeu qui nécessite un vrai raisonnement — devraient être tout aussi explicites. Elles devraient être tracées, gouvernées, mesurées. Quand les vraies décisions d’une application sont diluées dans un enchevêtrement de règles implicites, vous ne savez pas où elles se prennent. Vous ne pouvez donc ni les optimiser, ni les protéger, ni les gouverner. La matrice RACI, que nous avons présentée dans un article dédié à la clarification des rôles projet, est l’outil organisationnel équivalent : elle rend explicite qui décide quoi, quand et avec quelle délégation.

La troisième question porte sur la trajectoire : à quoi ressemblerait votre application recomposée selon ce principe ? Elle n’appelle pas une refonte. Elle appelle une remise en ordre progressive, module par module, qui relève directement du travail de réduction de dette technique. Chaque itération qui sépare le chemin léger du chemin lourd, chaque module qui devient invocable de façon ciblée plutôt que mobilisé par défaut, est un pas qui améliore la performance, le coût à l’échelle et la maintenabilité. Cette stratégie est exactement celle que nous décrivons dans notre article sur la dette technique qui absorbe 20 à 40 % du budget IT.

Ces trois questions ne se répondent pas en une réunion. Elles structurent une démarche qui produit en sortie une cartographie des sur-dimensionnements, une formalisation des points d’escalade, et un plan de remise en ordre séquencé sur plusieurs trimestres.

Ce que vous devez retenir

L’advisor tool n’est pas une rupture technique. Il est un signal. Anthropic n’a pas inventé le pattern qu’il encode — elle l’a rendu visible en le codant dans une API. La leçon pour un DSI ou un CTO n’est pas dans la feature. Elle est dans le miroir.

Pour les applications métier, le rendement ne se trouve plus dans la puissance uniforme. Il se trouve dans la précision de la délégation. Les systèmes les plus performants sur la décennie qui vient ne seront pas ceux qui auront été les plus intelligents partout. Ils seront ceux qui auront su placer l’intelligence au bon endroit, escalader au bon moment, et laisser les traitements légers faire ce qu’ils savent faire sans les surcharger d’une compétence qu’ils n’utilisent pas.

Ce pattern, en tant que pattern, règle la question architecturale. Il ouvre néanmoins une question adjacente, qui devient pressante dès que les agents IA cessent de rester dans la fenêtre de développement pour passer en production autonome. Comment gouverne-t-on un système capable de décider, d’escalader et d’agir sans supervision humaine immédiate ? C’est un sujet différent, qui mérite son propre traitement.