Les consultants doivent apprendre à coder leurs propres agents

Si je dirigeais encore un cabinet de conseil en management traditionnel, je ne lancerais pas une formation aux prompts. Je ne commencerais pas non plus par une grande campagne d’adoption d’un assistant interne. Je formerais une partie substantielle des consultants à construire leurs propres systèmes agentiques, au-dessus d’une infrastructure fiable.

La nuance compte. Il ne s’agit pas de transformer des consultants en ingénieurs logiciels. Il s’agit de leur apprendre à traduire une méthode de travail en système exécutable : une séquence d’actions, de sources, de règles, de contrôles, de validations humaines et de preuves. C’est un déplacement plus profond que l’usage quotidien de ChatGPT, Claude, Lilli, ou d’un copilote maison.

Le conseil risque de refaire avec l’IA une erreur qu’il connaît bien : confondre adoption d’un outil et transformation d’un métier. Les cabinets savent très bien déployer des formations, nommer des champions, suivre des taux d’usage, publier des cas internes et équiper leurs équipes. Cela produit des gains. Cela ne garantit pas que la compétence stratégique s’est déplacée.

Or la question qui arrive n’est pas seulement : combien de consultants utilisent l’IA ? La question devient : combien de consultants savent transformer leur expertise en système opérable ?

Le conseil évolue par emprunts

Le métier de consultant ne s’est jamais construit uniquement sur ses propres méthodes. Il avance par absorption régulière de langages venus d’ailleurs. Certaines vagues deviennent des modes. D’autres laissent une trace durable. La difficulté est de distinguer le folklore de la compétence qui reste.

Lean, Six Sigma, qualité totale et reengineering ont imposé un langage des processus. Les cabinets n’ont pas formé des consultants aux Black Belts pour qu’ils deviennent tous des spécialistes de production. Ils leur ont appris à regarder le travail autrement : variance, défauts, causes racines, flux, mesure, contrôle. Beaucoup de jargon a mal vieilli. L’idée centrale, elle, est restée : on ne parle pas sérieusement de performance sans parler du système qui la produit.

Le digital a ajouté une autre contrainte. Il est devenu difficile de parler de stratégie sans comprendre les données, les systèmes, les ERP, les CRM, les plateformes, les architectures d’intégration. Là encore, le but n’était pas que chaque consultant écrive du code. Le but était d’éviter un angle mort : une recommandation qui ignore l’architecture existante se transforme vite en intention élégante et inexécutable.

Puis l’agile, le produit et le design thinking ont déplacé l’attention vers l’usage. La caricature était facile : ateliers, post-its, personas... Mais le mouvement amenait quelque chose de beaucoup plus profond : une idée d’innovation ne vaut pas seulement par ses dimensions stratégiques et économiques. Elle doit rencontrer un utilisateur, un comportement, une friction, des tests et itérations en conditions réelles.

L’IA agentique devrait être analysée de la même manière. Le prompt engineering est le folklore visible, la surface. La compétence durable et transformationnelle se situe ailleurs.

Le risque d’une formation IA trop en surface

La plupart des formations IA dans le conseil partent d’une hypothèse raisonnable mais limitée : le consultant doit apprendre à utiliser un assistant. Il doit savoir poser une meilleure question, cadrer une demande, synthétiser un dossier, générer une première version, comparer des sources, accélérer une recherche, revoir un livrable. Ces usages ont de la valeur. Ils réduisent des frictions réelles.

Mais ils maintiennent le consultant au niveau de l’interface.

Ce niveau sera rapidement banalisé. Un analyste qui sait obtenir une synthèse correcte d’un rapport ne crée pas encore un avantage structurel pour un cabinet. Il utilise mieux une capacité devenue largement accessible.

Le niveau supérieur consiste à configurer des assistants, créer des templates, assembler des workflows no-code, spécialiser des agents sur un type de mission. C’est déjà plus intéressant. Mais cela reste souvent artisanal. La méthode dépend d’un prompt long, d’un dossier mal gouverné, d’une mémoire implicite, de règles non testées, de validations humaines floues. On améliore l’usage, sans toujours transformer la méthode en actif réutilisable.

Le troisième niveau est plus rare. Il consiste à coder des systèmes de travail : agents spécialisés, sources autorisées, états intermédiaires, règles d’escalade, critères d’acceptation, logs, tests, contrôles de confidentialité, points de reprise humaine. Le consultant ne se contente plus de demander une analyse. Il définit la machine qui doit produire une analyse fiable dans un contexte donné.

Cela change le rôle du partner, qui ne pourra pas seulement défendre une recommandation devant un Comex. Il devra comprendre la chaîne qui l’a produite : sources retenues, hypothèses écartées, contrôles effectués, zones d’incertitude, points où le jugement humain a repris la main.

Ce que le marché commence à montrer

La bascule n’est pas théorique. Elle apparaît déjà dans les mouvements récents des grands cabinets et des labs IA.

Le modèle de référence reste Palantir. Ses Forward Deployed Engineers ont longtemps incarné une idée à contre-courant dans la tech : mettre des profils techniques chez le client, au contact des opérations, pour adapter la plateforme, construire les intégrations, observer l’usage et faire remonter ce qui peut devenir produit. Pendant des années, cette proximité avec le service a rendu le modèle suspect aux yeux d’une partie de la Silicon Valley. En 2026, elle ressemble plutôt à une réponse réaliste au problème des agents : on ne déploie pas un système qui agit dans l’entreprise depuis une démo centrale.

Ce qui est nouveau, c’est que le vocabulaire se diffuse dans le conseil. Business Insider rapporte que BCG parle désormais de “forward-deployed consultants”, inspirés du modèle Palantir : des consultants qui construisent des outils et des agents sur les missions, puis renvoient ce qui fonctionne vers une équipe R&D interne. Le signal n’est pas que BCG aurait inventé le FDE. Le signal est plus intéressant : même un cabinet de conseil commence à organiser une boucle entre terrain client, build, contrôle et réutilisation.

OpenAI pousse une logique comparable avec Frontier et ses alliances avec BCG, McKinsey, Accenture et Capgemini. Le discours ne porte pas seulement sur l’accès au modèle. Il parle de workflows, d’intégration aux systèmes, de permissions, d’évaluation, de gouvernance et d’équipes FDE capables d’aider les grandes organisations à déployer des agents. Anthropic suit un chemin voisin avec les Big Four : KPMG intègre Claude dans ses plateformes tax et advisory, PwC annonce la formation de dizaines de milliers de collaborateurs à Claude Code, Deloitte a signé un accord pour déployer Claude auprès de centaines de milliers de professionnels.

Ces annonces peuvent être lues comme des accords de distribution. Mon interprétation est différente : les cabinets déplacent une partie de leur appareil productif vers des environnements où les livrables ne sont plus seulement écrits, mais produits par des systèmes.

C’est aussi ce que signalent les plateformes verticales qui se présentent comme des systèmes IA natifs pour le conseil, avec agents spécialisés, workflows prêts à l’emploi, sources curées, auditabilité et productisation de l’IP. Ce type de plateforme répond à un besoin évident. Mais il pose aussi une question dérangeante pour les cabinets : si votre méthode est encapsulée dans un produit externe, où se trouve encore votre différenciation ?

La réponse ne peut pas être simplement “dans nos prompts”. Elle devra être dans la capacité à concevoir, adapter, vérifier et faire évoluer des systèmes agentiques propres à une industrie, un client, un type de décision ou une doctrine de mission.

Pourquoi Claude Code est un bon entraînement

Claude Code n’est pas important parce que tous les consultants devraient coder en production. Il est important parce qu’il expose ce que l’interface de chat rend trop abstrait.

Un agent de code lit un environnement, agit sur des fichiers, appelle des outils, exécute des commandes, propose des changements, se trompe, corrige, laisse un historique. Il oblige l’utilisateur à penser en contexte, permissions, périmètre, tests, rollback, dépendances. Il rend visible la différence entre une instruction et une délégation.

C’est précisément le point pédagogique. Le consultant qui travaille seulement dans une interface conversationnelle peut encore croire que le travail consiste à formuler une demande. Le consultant qui travaille avec un agent dans un environnement vivant comprend autre chose : la qualité de la sortie dépend de l’architecture de la tâche.

Le code n’est donc pas seulement un savoir technique. Dans ce contexte, c’est une contrainte intellectuelle. Il force à expliciter les hypothèses, à nommer les objets, à séparer les étapes, à prévoir les erreurs, à tester les résultats. Une phrase peut être convaincante et fausse. Un workflow mal défini casse plus vite.

C’est pour cela qu’une formation sérieuse à l’agentic AI ne devrait pas être réservée aux profils tech. Les consultants qui portent la méthode doivent comprendre la mécanique. Sinon, le savoir-faire du cabinet finit éclaté : un peu dans les slides, un peu dans les prompts, un peu dans l’équipe plateforme, un peu dans la tête des partners.

A noter que je parle de Claude Code parce que c’est l’outil du moment. Mais dans six mois, ce sera peut-être Codex, Gemini CLI, Cursor, Devin ou autre chose. La solution importe moins que le réflexe.

L’analogie Excel

En cherchant un précédent à l’impact de l’agentic AI dans le consulting, je suis retombé sur la "révolution" Excel.

Excel n’a pas seulement accéléré la finance et la modélisation. Il a en réalité transformé des consultants en builders sans les transformer en développeurs professionnels. Une hypothèse devenait une cellule. Une acquisition devenait un modèle. Un scénario devenait une sensibilité.

L’analyste ne devenait pas ingénieur logiciel. Mais il apprenait à rendre son raisonnement exécutable, modifiable, transmissible, avec un raisonnement somme toute très proche du code (qui dans la salle a parlé de macros et de VBA ?)

Il faut noter que cette appropriation a aussi créé en corollaire une nouvelle classe de risques : erreurs de formule, dépendances invisibles, versions concurrentes, modèles copiés sans contrôle, fichiers critiques que personne ne sait vraiment auditer.

Quand une méthode devient un système qui permet de "dépasser l’humain", elle gagne en vitesse et en portée. Elle gagne aussi une surface d’erreur.

Les agents feront subir au conseil un choc comparable, sur des objets plus ambigus que les cellules d’un modèle financier: ils lisent, sélectionnent, interprètent, écrivent, appellent des outils, récupèrent du contexte, enchaînent des tâches, etc...

Un workflow agentique mal conçu ne produit pas seulement un mauvais calcul. Il peut fabriquer une chaîne de travail plausible, structurée en apparence, mais fausse dans ses sources, ses hypothèses ou ses arbitrages.

C’est pour cela que la formation ne peut pas rester au niveau de l’usage.

Le consultant comme auteur de systèmes

Une partie du conseil repose sur une fiction commode : la valeur serait dans le jugement, pas dans le système qui le produit. Cette fiction devient difficile à tenir quand l’IA génère rapidement les premières versions de ce qui occupait une grande partie du temps junior : synthèses, benchmarks, analyses préliminaires, structures de documents, variantes de recommandations.

La valeur ne disparaît pas. Elle se déplace.

Elle se déplace vers le choix des sources, la formulation des hypothèses, la définition du périmètre, la capacité à identifier ce qui manque, l’organisation du contrôle qualité, la séparation entre fait et inférence, la manière d’intégrer le jugement humain, et la capacité à faire évoluer le système au fil des missions.

Autrement dit, elle se déplace vers la conception du travail.

Un consultant formé à l’agentic AI devrait être capable de construire un agent de recherche sectorielle avec sources autorisées, scoring de fiabilité, rejet des sources faibles et journal des arbitrages. Il devrait pouvoir concevoir un agent de préparation de comité qui distingue décisions, risques, engagements, points ouverts et contradictions. Il devrait savoir écrire un workflow de due diligence qui conserve les hypothèses, force la recherche d’éléments contraires, sépare les faits vérifiés des claims vendeurs et marque les zones non couvertes. Il devrait pouvoir transformer une recommandation en plan d’exécution avec dépendances, preuves attendues, responsables, conditions de rollback et points de contrôle.

Ce n’est pas du “vibe consulting”. C’est presque l’inverse. C’est le passage d’un travail largement narratif à un travail plus instrumenté. Plus de structure, de traces et de contrôles.

Le FDE comme miroir du conseil

La figure du Forward Deployed Engineer est utile parce qu’elle met le conseil face à une faiblesse ancienne : la séparation entre ceux qui pensent, ceux qui construisent et ceux qui opèrent.

Palantir a longtemps été regardé avec méfiance par une partie de la Silicon Valley parce que son modèle ressemblait trop à du service. Des ingénieurs chez les clients, des équipes au contact des opérations, beaucoup d’adaptation terrain. Ce qui paraissait peu scalable a fini par devenir un modèle envié au moment où les entreprises cherchent à faire passer l’IA des démonstrations aux workflows.

Le FDE n’est pas un consultant rebaptisé. Il ne se contente pas de comprendre un problème et de faire une recommandation. Il construit au contact du problème, observe l’usage, ajuste, formalise ce qui peut être réutilisé. Il travaille dans une boucle où le client, le système et le produit se corrigent mutuellement.

Le conseil traditionnel n’a pas à copier ce modèle tel quel. Il devrait en absorber la leçon : une expertise qui ne se traduit pas en système perd une partie de sa valeur dans un monde d’agents.

Cela ne signifie pas que les consultants doivent livrer des logiciels complets. Cela signifie qu’ils doivent savoir produire des artefacts exécutables : spécifications, workflows, agents, règles, tests, jeux d’évaluation, plans de contrôle. Le livrable final peut encore être une note ou une présentation. Mais la valeur se situera de plus en plus dans la chaîne qui l’a produite.

Le challenge de la fiabilité

Le point souvent absent du discours sur les agents est le plus important. Dès qu’un agent agit, le risque change de nature. Un chatbot peut halluciner dans un paragraphe. Un agent peut modifier un fichier, appeler un outil inadapté, récupérer une donnée fausse, propager une erreur, déclencher une action maladroite ou produire une trace incomplète.

Les recherches récentes sur les agents de code et les systèmes agentiques vont dans ce sens. Elles ne disent pas seulement que les agents deviennent plus puissants. Elles montrent que l’essentiel du problème se déplace vers les permissions, l’auditabilité, la gestion du contexte, la récupération des actions, la sécurité des outils et la responsabilité. Un agent capable d’agir doit pouvoir être reconstruit après coup : qu’a-t-il lu, décidé, modifié, ignoré, transmis, bloqué ?

Pour le conseil, ce n’est pas un détail : c’est le cœur du métier. Confidentialité client, traçabilité des sources, justification des recommandations, séparation entre information vérifiée et hypothèse, capacité à expliquer une décision, réutilisation contrôlée de l’IP : ces sujets existaient avant l’IA. Les agents les rendent plus difficiles à contourner.

C’est ici que l’idée de coder ses propres agents doit être prise avec prudence. On ne veut pas des consultants bricolant des automations fragiles dans des environnements non gouvernés. On veut des consultants capables de construire au-dessus d’une infrastructure qui porte déjà les permissions, la mémoire, les sources, les logs, l’audit, la validation humaine, l’évaluation et la sécurité.

C’est le prisme de HLBRT. Pas une interface de plus pour écrire des livrables. Une couche d’operating system sur laquelle une méthodologie de conseil peut devenir une exécution agentique contrôlée et auditable de bout en bout.

Ce qu’il faudrait vraiment enseigner

Une formation agentic AI pour consultants devrait être plus proche d’une formation à l’architecture du travail que d’un cours de prompting.

Elle devrait commencer par le context engineering : quelles informations l’agent reçoit, dans quel ordre, avec quelle provenance, quelles limites, quelle séparation entre sources client, sources publiques et mémoire de mission. Elle devrait continuer par la spécification : quelles règles métier, quelles hypothèses, quels critères de qualité, quelles interdictions. Elle devrait intégrer l’évaluation : quels tests permettent de savoir qu’un résultat est bon, incomplet ou dangereux. Elle devrait aborder l’orchestration : quand faut-il un agent, plusieurs agents, un simple script, une recherche humaine, une validation partner. Elle devrait enfin traiter la gouvernance : qui peut faire quoi, sur quelles données, avec quelles traces, sous quelle responsabilité.

Le code vient ensuite. Non comme un rite de passage technique, mais comme moyen de rendre ces choix explicites. Un consultant n’a pas besoin de devenir full-stack pour écrire un workflow avec les outils modernes. Mais il devrait comprendre assez de code, d’API, de fichiers, de logs, de tests et de permissions pour ne pas rester prisonnier de la surface.

C’est une exigence plus élevée que “être à l’aise avec l’IA”. Elle demandera du temps. Elle créera une différence entre consultants capables de consommer des outils et consultants capables de formaliser une méthode.

Les cabinets connaissent déjà cette dynamique. Tous les consultants n’étaient pas devenus Black Belts. Tous n’étaient pas devenus designers. Tous ne deviendront pas builders agentiques. Mais il faudra probablement un noyau beaucoup plus large qu’une petite équipe innovation. Parce que la méthode de conseil vit dans les équipes de mission, pas seulement dans un lab central.

Le vrai risque pour les cabinets

La tentation sera d’acheter une plateforme, de former les équipes, de communiquer sur l’adoption, puis de considérer que la transformation est engagée. C’est une voie raisonnable à court terme. Elle sera peut-être suffisante pour gagner en productivité sur les livrables. Elle ne suffira pas à reconstruire l’appareil productif.

Le risque est de voir les cabinets créer une population très nombreuse d’utilisateurs avancés, pendant qu’une minorité d’équipes, chez eux ou ailleurs, apprend à construire les systèmes dans lesquels le travail sera réellement produit.

Dans ce scénario, les consultants traditionnels auront gagné du temps. Les builders auront gagné du pouvoir.

La différence est importante. Gagner du temps sur une méthode existante améliore la marge. Transformer la méthode en système change la structure du métier. Cela modifie la formation des juniors, la propriété intellectuelle, la qualité, la traçabilité, la réutilisation des missions, la manière de vendre, et peut-être même la forme du cabinet.

Le conseil a déjà connu des vagues de formation qui semblaient périphériques avant de devenir centrales. Lean a appris à regarder les processus. Le digital a appris à regarder les systèmes. Le design thinking a appris à regarder l’usage.

L’agentic AI doit apprendre aux consultants à regarder l’exécution. Pas l’exécution comme plan d’action dans une slide. L’exécution comme système qui agit, se trompe, se corrige, se trace et s’améliore.

Le marché ne manquera pas de consultants capables d’utiliser l’IA. Il en aura probablement trop.

Il manquera de consultants capables d’écrire le système de travail derrière la recommandation.