Mais au fait, c’est quoi une « AI-native consulting firm » ?
La semaine dernière, l’expression “AI-native advisory firm” est arrivée dans le Financial Times, dans un article consacré à l’effet de l’IA sur les grands cabinets de conseil.
Le FT décrit une industrie longtemps protégée par ses marques, ses réseaux de partners, ses équipes internationales et sa pyramide de juniors, désormais attaquée par des structures plus petites, plus techniques, plus automatisées, parfois fondées par d’anciens consultants.
La lecture la plus courte serait d’y voir une histoire de remplacement : des agents à la place de consultants. Mauvais cadrage. Le sujet porte moins sur le remplacement poste par poste que sur la fonction de production du conseil.
Une firme de conseil AI-native n’est pas définie par les outils qu’elle branche, ni par les partenariats qu’elle annonce avec un frontier lab. Elle peut vendre des missions de stratégie, de coûts, de transformation RH, de restructuring ou de performance commerciale. Elle peut même ne jamais vendre une mission “IA” au sens strict. La matière vendue n’est pas le critère.
Le critère est plus précis : comment la firme capte le contexte, structure les décisions, produit le raisonnement, vérifie les livrables, capitalise les erreurs, puis réutilise ce qu’elle apprend d’une mission à l’autre.
Une AI-native consulting firm est une singularity company appliquée au conseil. Pas une entreprise qui attend l’AGI. Pas une organisation sans humains. Une entreprise construite comme si l’intelligence n’était plus seulement dans les personnes, mais aussi dans une couche opérable : contexte structuré, mémoire, workflows, règles, agents, tests, droits d’accès, revues, traces.
Le cabinet traditionnel vend une équipe. Le cabinet AI-enabled vend une équipe équipée d’outils IA. La firme AI-native vend du conseil produit par une organisation reconstruite autour d’une couche logicielle d’intelligence interne : mémoire opérable, workflows gouvernés, contrôle qualité, traces de décision, actifs réutilisables, observabilité, humains d’abord sur le cadrage, le jugement, la relation, les exceptions et la responsabilité.
Une vieille question d’organisation
Les entreprises ont toujours été limitées par le coût de coordination du savoir. La grande corporation, la matrice, les squads, les two-pizza teams d’Amazon ou les modèles plus distribués comme Team of Teams répondent tous à une même contrainte : faire circuler l’information, décider vite, garder le contrôle quand le travail devient trop complexe pour être coordonné par quelques dirigeants.
Ces modèles déplacent l’autorité entre humains. Amazon réduit la taille des équipes pour limiter les frictions. McChrystal pousse la circulation de l’information et la décision plus près du terrain. Les organisations plates suppriment des couches, avec leurs propres risques : pouvoir informel, responsabilités floues, angles morts de gouvernance.
L’AI-native company modifie le problème. Elle ne déplace pas seulement l’autorité entre humains. Elle introduit une couche d’intelligence logicielle entre le contexte, la décision et l’action.
Block l’a formulé dans “From Hierarchy to Intelligence”, signé par Jack Dorsey et Roelof Botha. Le texte décrit une entreprise capable de maintenir un modèle actualisé de ses propres opérations : un company world model, alimenté par les décisions, les plans, les discussions, les artefacts de travail, les problèmes, les progrès et les signaux clients.
Dans une entreprise classique, la hiérarchie transporte une grande partie du contexte. Les managers savent ce qui se passe, priorisent, reformulent, relaient, corrigent, arbitrent. Dans une organisation AI-native, une partie de ce contexte peut être captée, structurée, interrogée et utilisée sans passer par toutes les couches humaines.
Tom Blomfield, chez Y Combinator, donne une image plus dure : les entreprises restent souvent organisées comme des légions romaines. L’information remonte, les décisions redescendent, les humains servent de relais. Son alternative n’est pas d’ajouter un copilote à chaque salarié. C’est de penser l’entreprise comme une série de boucles : capteurs, décision, outils, contrôle qualité, apprentissage.
Avant d’être automatisable, une entreprise doit devenir lisible par des agents. Beaucoup d’organisations font l’inverse. Elles ajoutent des agents à un environnement illisible : décisions dispersées, documents non versionnés, critères de qualité implicites, responsabilités floues, droits d’accès mal définis. On obtient alors un chatbot plus rapide au-dessus d’un système de travail inchangé.
Une singularity company part dans l’autre sens : elle rend ses opérations agent-readable avant de déléguer davantage d’actions.
En langage 2026, cela ressemble moins à du prompt engineering qu’à du context engineering. La question n’est plus de trouver la bonne consigne. Elle est de concevoir l’environnement informationnel dans lequel l’agent travaille : contexte pertinent, données isolées, provenance, contraintes, critères de qualité, règles d’escalade.
Un agent n’est pas un employé numérique. C’est un processus qui consomme du contexte, appelle des outils, produit des artefacts et doit être contraint par des tests. Le comparer trop vite à un consultant masque le sujet principal : l’environnement dans lequel il opère.
Le conseil est exposé à cette bascule parce que son produit historique repose précisément sur la circulation du contexte. Un client apporte une situation confuse. Une équipe collecte, reformule, synthétise, compare, produit un diagnostic, fabrique un livrable, porte une recommandation.
Une partie de cette valeur vient du jugement et de la confiance. Une autre partie vient d’une machinerie humaine de collecte, de consolidation, de mise en forme et de transmission.
L’IA ne remplace pas le jugement. Elle rend cette machinerie plus visible, avec son coût, ses lenteurs et ses pertes de mémoire.
La singularity company comme forme d’entreprise
Le terme “singularity company” reste instable. Il ne désigne pas encore une catégorie aussi codifiée que SaaS, marketplace ou cloud company. Il nomme plutôt une direction : une entreprise construite comme si le coût marginal de certaines tâches intellectuelles allait continuer à baisser, et comme si l’avantage concurrentiel allait se déplacer vers la mémoire, les workflows, les règles, la gouvernance et la vérification.
Une singularity company ne ressemble pas exactement à une organisation plate, à une matrice agile ou à une armée de petites équipes autonomes. Ces modèles restent humains dans leur mécanisme central. Ils réduisent les couches, déplacent l’autorité ou rapprochent les équipes du client, mais l’information circule encore principalement par des personnes.
La singularity company part d’une autre hypothèse : une partie de l’intelligence de l’entreprise peut devenir une infrastructure. Les décisions, méthodes, corrections, standards, exceptions, préférences clients, signaux faibles et règles de qualité peuvent être capturés dans un système qui aide à produire, vérifier et apprendre. La hiérarchie ne disparaît pas. Elle perd une partie de son rôle historique de transport du contexte.
Appliqué au conseil, le déplacement est net. Une firme AI-native n’est pas seulement une pyramide plus petite. Ce n’est pas non plus une organisation plate avec des agents. C’est une firme qui combine un modèle interne de ses missions, des équipes responsables, une mémoire opérable, des workflows réutilisables et une couche de vérification qui s’améliore avec l’usage.
La partie visible peut rester classique : stratégie, performance, coûts, RH, organisation, transformation. La partie décisive est derrière : comment le travail est produit.
Les modèles circulent, se remplacent, se commoditisent partiellement. Ce qui reste plus difficile à copier, c’est l’application située : données propriétaires, workflows, règles métier, mémoire, distribution, confiance, preuve. Pour le conseil, une firme AI-native ne gagne pas parce qu’elle accède au meilleur modèle du moment. Elle gagne si son système de production devient meilleur à chaque mission.
Le conseil comme production de raisonnement
Le conseil s’est longtemps organisé autour de la rareté de l’intelligence structurée. Un bon cabinet savait envoyer une équipe capable d’absorber rapidement du contexte, de trier l’important, de mettre en forme un raisonnement et de le rendre acceptable par une organisation.
Cette valeur ne disparaît pas. Elle se décompose.
Certaines tâches restent fortement humaines : cadrer un problème mal posé, lire les tensions politiques d’un comité exécutif, décider ce qui peut être dit, arbitrer une trajectoire, assumer une recommandation difficile, protéger la relation.
D’autres relèvent davantage de la transformation d’information : recherche, synthèse, comparaison, mise en forme, première version, suivi, mise à jour, consolidation documentaire, préparation d’ateliers.
L’AI-native consulting commence quand cette seconde catégorie n’est plus traitée comme une somme d’heures humaines, mais comme un système.
Ce qui est répétable devient workflow. Ce qui est vérifiable peut être partiellement agentisé. Ce qui est exploratoire peut être assisté. Ce qui relève du jugement politique, juridique, éthique ou relationnel reste supervisé. Ce qui ne peut pas être vérifié ne doit pas être vendu comme autonome.
Certains cabinets automatiseront ce qui se voit : recherches, synthèses, slides, benchmarks. C’est de la bureautique avancée.
D’autres travailleront sur le sous-jacent de l’operating model : sourcing, QA, comparaison d’hypothèses, détection d’incohérences, suivi d’adoption, mise à jour de livrables, capitalisation post-mission.
La différence ne tient pas au nombre d’agents. Elle tient au régime de production et de vérification.
Le saut n’est pas de produire plus de notes, plus de benchmarks ou plus de slides. C’est de transformer chaque unité de raisonnement en objet gouverné : source, hypothèse, décision, niveau de confiance, revue, correction, réutilisation.
Services-as-software
Sequoia parle de “services as the new software”. L’idée est simple : l’IA ne sert pas seulement à améliorer les logiciels utilisés par les entreprises. Elle permet à certains acteurs de vendre directement le travail accompli par le logiciel.
Le conseil est un terrain naturel pour cette thèse. Un cabinet ne vend pas seulement des heures. Il vend une capacité à produire une analyse, une décision, un plan, un arbitrage, une mise en œuvre. Historiquement, cette capacité passait par une pyramide humaine. Si une partie du travail devient systématisable, vérifiable et réutilisable, le cabinet ne vend plus exactement la même chose.
Il peut vendre un diagnostic instrumenté, une capacité de pilotage, une mémoire sectorielle, un benchmark vivant, une QA continue, un système de suivi d’exécution, une fonction d’analyse maintenue dans le temps, un niveau de preuve.
Dans ce modèle, le livrable change de statut. Le deck reste utile, parce que les organisations décident encore avec des objets lisibles. Mais il n’est plus l’actif principal. Il devient une interface vers un système : sources, hypothèses, décisions rejetées, logs, règles, tests, workflows, mémoire de mission, corrections, indicateurs d’adoption.
Le client ne reçoit pas seulement une recommandation. Il reçoit une capacité à maintenir cette recommandation, à la challenger, à l’auditer, à la transmettre et à l’actualiser.
La software factory comme laboratoire
Le logiciel donne déjà une image de ce qui arrive quand une fonction de production intellectuelle se reconstruit autour d’agents.
Le terme “software factory” n’est pas nouveau. Il désignait historiquement une manière d’industrialiser le développement par composants, modèles, frameworks et outils. En 2026, il revient sous une forme différente : des chaînes de production logicielle où des agents prennent en charge une part croissante du travail, pendant que les humains se déplacent vers l’architecture, la revue, la sécurité, la qualité et l’arbitrage.
Business Insider a cité Chime et son système Archimedes, décrit comme une “AI-native software factory” destinée à transformer des idées en produits avec des agents réalisant la majorité du développement. Le chiffre de code généré est moins intéressant que l’architecture implicite. Le code n’est plus seulement écrit plus vite par des développeurs augmentés. Il circule dans une chaîne faite de contexte, agents, tests, CI, revue, sécurité, déploiement et feedback.
Cette analogie éclaire le conseil. La software factory déplace la valeur de la ligne de code vers le système de production logiciel. L’AI-native consulting firm déplace la valeur de l’heure consultant vers un raisonnement produit, vérifié, tracé et maintenu.
Dans le code, le bon système n’est pas seulement un modèle qui écrit mieux. C’est un harnais de production : repo, terminal, permissions, tests, CI, branches, logs, rollback, revue, sécurité. Les travaux récents sur Claude Code montrent bien ce point. Le cœur agentique peut être une boucle assez simple, mais la valeur opérationnelle vient des systèmes autour : permissions, gestion du contexte, extensibilité, sous-agents, isolation, stockage de session, contrôle des actions.
Les meilleurs travaux récents sur le sujet ne décrivent pas seulement des agents qui codent. Ils décrivent un écosystème agentique : agents, APIs, langages, outils, runtime, permissions, environnements d’exécution. Le logiciel ne devient pas AI-native parce qu’un modèle écrit du code. Il le devient quand tout l’environnement de production devient utilisable par des agents et contrôlable par des humains.
On voit déjà émerger une culture de configuration : fichiers de contexte, skills, subagents, règles de repository, permissions, conventions d’architecture. Le modèle ne suffit pas. La performance dépend de ce que l’organisation rend explicite autour de lui. C’est exactement l’enjeu pour le conseil : transformer les méthodes, standards, contraintes de sourcing, règles de QA et préférences de delivery en artefacts que le système peut appliquer.
La course au nombre d’agents est donc un mauvais indicateur. Une partie du marché commence à revenir vers une idée plus sobre : moins d’agents gadgets, plus de skills réutilisables. Des méthodes, procédures et savoir-faire encapsulés dans des artefacts que l’agent peut appliquer. Pour le conseil, c’est un point décisif. La valeur n’est pas d’avoir un “agent stratégie”, un “agent RH” ou un “agent cost cutting”. La valeur est d’avoir des skills fiables : cadrer un problème, qualifier une source, comparer deux hypothèses, challenger un modèle, préparer un comité, détecter une incohérence, documenter une décision.
Dans le conseil, l’équivalent devient : contexte client structuré, séparation stricte des données, sources traçables, workflows par type de mission, agents spécialisés, permissions, QA, revue senior, logs, mémoire de mission, rollback, critères de livraison.
Pas un chatbot. Pas un RAG. Pas une usine à slides générées. Un environnement de production de raisonnement.
La leçon des software factories n’est pas que l’humain disparaît. Quand les agents produisent davantage, le rôle humain se déplace vers ce qui empêche le système de produire n’importe quoi : architecture, contexte, revue, permissions, tests, sécurité, arbitrage.
Dans le conseil, cela s’appelle sourcing, hypothèses, QA, revue senior, cloisonnement client, traçabilité, mémoire de mission, gouvernance, responsabilité.
La mémoire opérable
La mémoire est l’endroit où beaucoup de cabinets vont sous-investir.
Dans un cabinet traditionnel, beaucoup de valeur disparaît. Une objection commerciale reste dans un call. Une correction senior reste dans un commentaire de deck. Un benchmark contesté est corrigé au dernier moment, puis oublié. Une hypothèse invalidée n’est pas réinjectée. Un pattern sectoriel reste dans la tête d’un partner. Une mission livre quelque chose au client, mais la firme ne capitalise pas toujours ce qui a permis de le produire.
Dans une firme AI-native, cette perte devient un défaut de production.
La mémoire ne désigne pas un drive mieux organisé. Elle désigne un système capable de retrouver, comparer, tester, réutiliser, mettre à jour et améliorer. Les entretiens, décisions, sources, corrections, refus, arbitrages, erreurs, workflows, validations et retours clients deviennent la matière d’un système qui apprend.
La bonne mémoire n’est pas seulement consultable par des humains. Elle doit être actionnable par des agents. Un document long, une note de comité ou un benchmark PDF peuvent contenir la bonne information et rester presque inutilisables pour une chaîne agentique. Pour une firme de conseil, la mémoire doit être conçue dès le départ comme un actif machine-actionable : sources, statuts, dates, propriétaires, niveau de confiance, restrictions client, liens vers les décisions, règles de réutilisation.
Block parle de company world model. Blomfield parle de rendre l’organisation lisible à l’IA. Trail of Bits documente une démarche plus terrain : handbook interne, policies d’usage, skills, defaults, adoption engine, outils spécialisés, standardisation, sécurité et QA. Les mots changent, mais le mouvement reste proche : sortir le savoir des têtes, des conversations et des documents morts pour en faire une infrastructure de travail.
C’est le pari que nous construisons chez HLBRT : traiter le conseil non comme une succession de livrables, mais comme une production de raisonnement vérifiable. Le contexte est persisté. Les sources sont tracées. Les hypothèses sont distinguées des faits. Les décisions sont rejouables. Les workflows sont répétables. Les sorties sont vérifiées.
Et surtout, les erreurs et corrections laissent une trace exploitable qui enrichit le système.
À ce stade, la firme cesse d’être seulement une organisation de personnes. Elle devient aussi un dataset vivant de ses propres raisonnements : problèmes rencontrés, sources utilisées, décisions prises, erreurs corrigées, objections traitées, workflows stabilisés. Ce dataset n’a de valeur que s’il est structuré, cloisonné, vérifié et réutilisable. Sinon, ce n’est qu’un cimetière de documents.
Une mission réellement AI-native livre deux choses : un résultat pour le client, et un actif système pour la firme. Le premier crée de la valeur immédiate. Le second rend la prochaine mission moins dépendante de la mémoire individuelle.
Du pod à la pyramide
La pyramide junior-manager-partner devient moins naturelle quand la base documentaire est compressée. Recherche, première structuration, comptes rendus, préparation d’ateliers, drafts de livrables, benchmarks, suivi d’actions : ces tâches ne disparaissent pas, mais elles peuvent être pré-produites, contrôlées et réutilisées.
La pyramide n’est pas seulement plus chère. Elle devient moins adaptée à un monde où le contexte peut être capturé, les tâches répétables exécutées par workflows, et la qualité contrôlée par une proof layer. Son problème n’est plus seulement économique. Il devient architectural.
La réponse ne consiste pas à supprimer mécaniquement les juniors. Elle consiste à changer l’équipe.
Une mission AI-native ressemble davantage à un pod : responsable client, expert métier, AI operator, workflow architect, builder ou FDE, responsable QA, data steward si les données l’exigent, security lead si le risque est élevé. Ce vocabulaire vient moins du conseil classique que du logiciel, de la cybersécurité, de la compliance et du déploiement enterprise.
Les analogies d’organisation aident à comprendre le mouvement. Amazon apporte la petite équipe responsable. Team of Teams apporte la conscience partagée et l’exécution distribuée. La software factory apporte le harnais de production. Block apporte le world model. Le conseil AI-native combine ces éléments au lieu d’en copier un seul.
La firme AI-native ne copie aucun de ces modèles. Elle n’est pas une organisation plate, parce que l’autonomie sans contrôle crée vite ses propres angles morts. Elle n’est pas une matrice agile, parce que le problème n’est pas seulement la circulation des responsabilités. Elle n’est pas une factory au sens tayloriste, parce que le jugement reste central. Elle emprunte plutôt à chaque modèle : petites équipes responsables, information partagée, harnais de production, mémoire opérable, contrôle qualité.
Le manager qui servait surtout de routeur d’information perd de la valeur. Le manager qui arbitre, forme, refuse, protège la qualité et tient la relation client en gagne. Le partner qui vend du volume humain devient plus exposé. Le partner qui vend une capacité de production vérifiée devient plus bankable.
Le junior change aussi de trajectoire. Le conseil recrutait des profils rapides, structurés, capables de transformer un problème flou en livrable clair. Une partie de cette rareté baisse quand la première version devient facile à produire. Le junior AI-native doit apprendre à vérifier : une source, une hypothèse, une sortie d’agent, une permission, une citation, un raisonnement, un modèle financier, un écart entre deux documents.
Le prestige se déplace de la slide propre vers la décision auditable.
QA et preuve
La génération est devenue la partie visible du sujet. La vérification devient la partie économique.
La recherche sur la “jagged frontier” avec BCG reste un garde-fou. Sur certaines tâches, les consultants augmentés par GPT-4 vont plus vite et produisent mieux. Sur une tâche située hors de la frontière de capacité du modèle, ils performent moins bien que ceux qui n’utilisent pas l’IA.
BankerToolBench pousse le sujet dans un autre domaine. Des agents peuvent naviguer dans des data rooms, manipuler des modèles Excel, produire des rapports et des decks d’investissement bancaire, mais les évaluateurs ne jugent pas encore les sorties client-ready.
Ces benchmarks ne disent pas que l’IA est inutilisable. Ils disent autre chose : dès qu’un système produit des livrables crédibles, la vérification devient une fonction de production, pas une relecture finale.
Une firme AI-native doit donc fonctionner comme une usine de vérification : claims sourcés, hypothèses isolées, citations contrôlées, permissions limitées, logs, evals, tests déterministes, revue humaine, red teaming, registre des erreurs, cohérence entre note, modèle financier, deck et annexe.
C’est probablement le vrai moat. Pas le modèle. Pas l’interface. La proof layer : ce qui permet à une firme de montrer pourquoi un raisonnement tient, quelles sources l’ont nourri, quelles hypothèses restent fragiles, qui a validé, ce qui a été corrigé, ce qui peut être rejoué.
Dans le conseil traditionnel, la preuve repose souvent sur la réputation de la firme et le jugement des seniors. Dans une firme AI-native, cette preuve devient plus matérielle : sources, traces, versions, décisions, contrôles, revues, exceptions, responsabilités.
Pricing et incentives
Le conseil vend de la valeur, mais facture encore souvent du temps, des grades, des équipes et des semaines. Si une boucle produit en deux jours ce qu’une équipe produisait en deux semaines, l’acheteur finit par demander ce qu’il paie : l’effort, la marque, la méthode, le résultat, la responsabilité, la mémoire sectorielle, le système maintenu, le niveau de preuve.
Une firme AI-native ne peut pas garder exactement les mêmes incentives qu’un cabinet pyramidal. Certaines missions resteront fortement humaines et premium : arbitrage politique, relation de confiance, transformation sensible, décisions à fort risque.
D’autres, plus répétables et vérifiables, seront compressées ou packagées autrement : diagnostic instrumenté, retainer de capacité, système vivant, QA continue, suivi d’exécution, outcome fee quand la causalité est mesurable.
Dans les organisations les plus avancées, la contrainte commence même à se déplacer : moins de staffing marginal, plus de compute, de tokens, de contexte et de QA. Le coût de production ne disparaît pas. Il change de nature.
Le cabinet traditionnel a intérêt à rendre l’effort visible. La firme AI-native a intérêt à rendre l’effort compressible et la preuve visible.
Les deux logiques peuvent coexister. Elles ne requièrent cependant pas la même organisation.
Le test de maturité
Le test ne tient pas dans le nombre d’agents, la prompt library, le RAG interne ou l’adoption d’une interface de chat. Il tient dans ce que la firme parvient à spécifier. Ses méthodes. Ses standards. Ses arbitrages. Ses règles de sourcing. Ses seuils de validation. Ses exceptions. Ses critères de qualité. Ses droits d’accès.
Une firme encore AI-enabled accélère des tâches : recherche, synthèse, comptes rendus, propositions, benchmarks. Une firme AI-native transforme ses méthodes en corpus opérationnel : contexte, intent, specifications, workflows, QA. C’est ce corpus qui permet ensuite à la firme d’apprendre d’une mission à l’autre.
Une firme réellement AI-native change son operating model : équipes en pods, mémoire opérable, actifs système, pricing partiellement détaché de l’effort humain, formation des juniors à la vérification.
Une mission améliore la suivante. Une erreur de sourcing modifie une règle. Un benchmark contesté enrichit la QA. Une correction senior devient une procédure. Un workflow performant devient un actif réutilisable.
La frontière suivante n’est pas l’autonomie complète. C’est la self-adaptation sous contrôle : un système qui détecte ses propres faiblesses, propose une correction, la fait vérifier, puis améliore son workflow. La firme AI-native ne cherche pas à supprimer la revue humaine. Elle cherche à rendre l’apprentissage organisationnel plus rapide que la circulation hiérarchique classique.
Ce que l’AI-native consulting n’est pas
Ce n’est pas un cabinet qui vend de l’IA. Ce n’est pas un cabinet avec des agents internes. Ce n’est pas une bibliothèque de prompts ou de skills. Ce n’est pas un RAG branché sur le knowledge management. Ce n’est pas une réduction de coûts maquillée en stratégie technologique. Ce n’est pas non plus une entreprise sans humains.
Une firme de conseil AI-native garde les humains aux endroits où ils comptent : cadrage, relation, confiance, arbitrage, responsabilité, gestion du risque, décision politique, moments d’exception. Elle retire progressivement les humains des endroits où ils servaient surtout de tuyaux : transfert d’information, consolidation, reformulation, recherche répétitive, suivi mécanique, première version non critique.
La prochaine génération de cabinets ne sera probablement pas un MBB auquel on a ajouté des agents. Elle va ressembler davantage à un hybride entre cabinet, software company, système de vérification et mémoire propriétaire. La partie visible pourra rester très classique : stratégie, coûts, RH, performance, transformation. La partie décisive sera la fonction de production derrière.
Une AI-native consulting firm ne vend pas nécessairement de l’IA. Elle vend du conseil produit par une entreprise reconstruite autour de l’intelligence logicielle.
L’AI-native n’est donc pas une ligne d’offre. C’est une architecture d’entreprise.
La firme AI-native ne remplace pas le consultant par un agent. Elle remplace une partie de la hiérarchie par un système de mémoire, de production et de preuve.
Le point dur n’est pas d’avoir des agents. C’est de construire une firme que les agents peuvent comprendre, utiliser, corriger et améliorer sans dissoudre ce qui fait encore la valeur du conseil : jugement, confiance, confidentialité, responsabilité.