C’est l’expertise déléguée qui est en train de mourir.
Bonne lecture
Le jour où l’IA avait déjà fait le diagnostic « à ma place »
Je me souviens très bien de ce CODIR.
PME industrielle. Environ 250 personnes. Des clients en Europe et en Afrique. Je suis appelé pour un audit SI, cyber et IA. Et oui, en 2026, faire semblant de séparer ces sujets devient dangereux.
Le sujet paraît classique : comprendre où en est l’organisation, ce qu’elle expose, ce qu’elle maîtrise vraiment, et ce qu’elle croit maîtriser alors qu’elle ne fait que l’utiliser.
Le dirigeant arrive avec un sourire et un dossier relié.
Il me dit :
« On a pris un peu d’avance. On a testé un assistant IA spécialisé dans le conseil et l’analyse des risques. Il nous a généré un diagnostic stratégique avec des recommandations. Vous allez pouvoir valider, affiner, et surtout vous concentrer sur la partie technique. »
Je feuillette.
Douze pages. Une SWOT propre. Une analyse des risques SI. Un plan d’action en dix points. Des graphiques colorés, un vocabulaire sérieux, des phrases bien structurées.
Sur la forme, rien à dire. En même temps, c’est un LLM.
Et soyons honnêtes : avant l’IA, j’ai déjà vu des rapports humains vendus très cher qui ressemblaient exactement à ça. Je ne citerai pas de nom.
Puis je commence à poser des questions. Sur le parc machine en Afrique. Sur les connexions entre sites. Sur les sous-traitants. Sur les flux de données réels, pas ceux de l’organigramme.
Très vite, un premier décalage apparaît. Le diagnostic IA part du principe que tous les sites ont le même niveau de connectivité, les mêmes pratiques, les mêmes contraintes réglementaires. Ce n’est pas le cas. Ce ne l’est jamais.
Deuxième décalage : le rapport préconise un SI unifié basé sur un cloud unique, sans un mot sérieux sur la souveraineté des données, les contraintes locales, ni la dépendance à un fournisseur hors Europe. Dans une organisation qui, en vraie vie, a déjà du mal à suivre ses droits d’accès et ses prestataires.
Troisième décalage : une belle matrice des risques cyber, très académique, avec des termes ANSSI ou ISO bien alignés. Mais aucune prise en compte des incidents vécus, des alertes déjà remontées, des audits passés, ni des comportements concrets des équipes.
Je pose alors deux questions simples :
« Qui a alimenté l’IA ? »
« Qu’est-ce que vous lui avez donné comme données ? »
Silence.
Des documents internes. Des extraits d’audit. Quelques détails sur les contrats. Des schémas réseau.
Le tout dans un outil dont personne ne sait vraiment dire où il est hébergé, qui le maintient, ni ce qui sera fait des données une fois la mission terminée.
À la pause, le dirigeant me dit :
« Franchement, je pensais qu’on avait fait 80 % du boulot. En fait, j’ai surtout compris qu’on avait donné beaucoup, pour un diagnostic qui colle mal à notre réalité. »
Ce jour-là, j’ai compris une chose simple. Le problème n’est pas que l’IA « fasse du conseil ». Le problème, c’est tout ce qu’on est prêt à lui déléguer sans maîtrise, puis à faire valider par quelqu’un comme moi.
Le sujet n’est donc pas la disparition du conseil. Le sujet, c’est la disparition progressive d’un certain conseil : celui qui confond production de livrables et production de discernement.
Expertise assistée, expertise déléguée : il faut arrêter de tout mélanger
On mélange tout.
On met dans le même sac le consultant qui utilise l’IA pour gagner du temps sur la recherche, la mise en forme ou la simulation, et celui qui laisse l’IA produire l’essentiel de l’analyse avant de corriger vaguement la forme et de signer.
Pourtant, ce n’est pas le même métier.
Dans l’expertise assistée, l’IA est un outil. Puissant, oui. Mais un outil. Et seulement un outil.
Concrètement, dans une mission de conseil, cela veut dire : cadrer soi-même le problème, construire ses hypothèses, identifier les fragilités, repérer les angles morts, puis utiliser l’IA pour explorer des pistes, structurer des idées, tester plusieurs scénarios ou produire des brouillons.
Ensuite, le consultant reprend la main. Il vérifie. Il coupe. Il recontextualise. Il évalue les risques. Il assume les arbitrages.
L’IA augmente son rayon d’action. Elle ne remplace ni son jugement, ni sa compréhension, ni sa responsabilité.
Dans l’expertise déléguée, le scénario est différent.
La mission commence par :
« Demande à l’IA de me faire un diagnostic. »
« Génère-moi un plan d’action en dix étapes. »
« Propose trois scénarios de transformation. »
Puis on ajoute parfois une couche de théâtre :
« Mets bien que je suis expert. »
« Fais sérieux. »
« Ajoute que j’ai vingt ans d’expérience. »
Voilà. Vous voyez le problème.
Le consultant devient orchestrateur de prompts. Il lance des requêtes vagues, collecte des sorties, assemble des morceaux, applique une couche de cosmétique PowerPoint, puis présente le résultat comme une analyse.
Sur le papier, il y a un livrable. Dans la réalité, il y a très peu de pensée.
Le danger n’est pas l’outil. Le danger, c’est l’illusion de maîtrise qu’il produit. Le résultat est propre, fluide, crédible. Donc tout le monde croit que le travail a été fait. Et bien fait. Après tout, on n’a pas payé pour rien.
On l’a déjà vécu sans IA : rapports produits en série, slides recyclées, recommandations standard posées sur des clients très différents. L’IA ne crée pas ce travers. Elle l’accélère.
Avec une différence majeure : quand tu délègues ta pensée à la machine, tu délègues aussi ta capacité à repérer ses erreurs. Et là, l’hallucination n’est plus un bug amusant. Elle devient un risque métier.
L’IA ne détruit pas l’expertise. Elle révèle brutalement ceux qui s’étaient déjà habitués à travailler sans elle.
Apprendre n’est pas maîtriser
Je vois la même confusion chez les jeunes développeurs. Ils ouvrent Copilot, Cursor, un modèle de code, une IA embarquée dans leur IDE. Ils tapent une intention : API de paiement, authentification, gestion des erreurs, intégration CRM.
L’IA produit du code qui tourne. Oui, sur le moment, la démo fonctionne. La fonctionnalité est visible. Le client ou le manager est impressionné. Tout le monde a l’impression d’avoir gagné du temps. Magie. Et en plus, c’est moins cher.
Sauf que personne n’a vraiment regardé l’architecture.
Les normes de sécurité ne sont pas respectées. Le code n’est pas documenté. Les logs sont absents ou mal pensés. Les dépendances externes ne sont pas cartographiées. Les comportements en erreur sont improvisés. La maintenance future est laissée au prochain qui passera.
Et le prochain, souvent, ne maintient pas. Il refond. Ils confondent réussite locale et maîtrise globale.
Un POC réussi n’est pas une preuve de compétence. C’est seulement la preuve que, dans un contexte donné, quelque chose a fonctionné une fois.
La vraie question arrive juste après : est-ce que c’est maintenable ? Est-ce que c’est sécurisé ? Est-ce que c’est documenté ? Est-ce que quelqu’un comprend vraiment ce qui vient d’être branché ?
Si la réponse est non, ce n’est pas une innovation. C’est une dette avec une belle interface.
Le conseil connaît la même illusion : une forme propre, une impression d’expertise, et parfois très peu de maîtrise derrière.
L’outil a produit une forme. La maîtrise suppose autre chose : comprendre ce qu’on fait, pourquoi on le fait, ce que cela implique à trois ans, et ce qu’on est prêt à assumer quand ça casse.
Beaucoup confondent apprendre et maîtriser. C’est probablement l’une des grandes confusions de l’époque. L’outil a réduit la friction d’entrée. Il n’a pas produit l’expertise.
Pourquoi tant de consultants basculent du mauvais côté
Ce glissement vers l’expertise déléguée n’est pas d’abord un problème moral. Il est structurel.
Le conseil s’est longtemps organisé autour du temps passé, du livrable produit, du workshop tenu, du nombre de slides livrées. Ce modèle valorisait la démonstration visible de l’effort. Plus on produisait, plus cela semblait justifier le prix.
L’IA vient casser ce contrat implicite. Ce qui prenait cinq jours peut parfois être généré en quarante minutes. Ce qui nécessitait trois juniors en back-office peut être préparé par un agent et revu par un senior.
Dans ce contexte, la tentation est immense : laisser l’IA faire 70 % de la matière, ajuster les titres, ajouter deux ou trois exemples, emballer proprement, facturer comme avant.
Extérieurement, rien ne change. Intérieurement, l’essentiel a été délégué.
À cela s’ajoute un autre phénomène : le confort cognitif.
L’IA propose une sortie de secours à l’effort de penser. Lire des documents longs, croiser des sources, comprendre un système fragmenté, reconstruire un raisonnement, cela coûte de l’énergie. L’outil, lui, livre un texte déjà structuré, des options déjà ordonnées, des formulations déjà crédibles.
On passe très vite de « je dois réfléchir » à « je dois relire ». Et c’est là que le métier commence à se vider. À force de ne plus faire l’effort, on perd le muscle qui permet de détecter les erreurs.
C’est la dette cognitive appliquée au conseil : le système tourne encore, le livrable sort encore, mais plus personne ne comprend assez profondément pour sentir quand le raisonnement dérape.
Le marché ne va pas manquer de consultants capables de produire. Il va manquer de consultants capables d’assumer ce que l’IA leur permet de produire.
La génération « POC = maîtrise »
J’enseigne, je forme et j’accompagne des équipes, des startups et des entrepreneurs depuis plus de vingt ans. Depuis deux ou trois ans, je vois arriver une génération de profils brillants, rapides, à l’aise avec les outils. Ils testent, déploient, itèrent très vite.
C’est une force. Mais cette force peut se retourner contre eux lorsqu’elle n’est pas encadrée.
Ils montent un chatbot interne. Ils branchent un connecteur no-code. Ils déploient une API. Ils automatisent un workflow métier.
Le POC marche. Et c’est souvent là que les ennuis commencent. Ici, on n’est plus dans la compétence individuelle. On entre dans autre chose : la tentation de transformer une démonstration réussie en promesse de marché. Parce qu’à partir du moment où « ça marche », beaucoup arrêtent de poser les bonnes questions.
On peut le généraliser. On peut le vendre. On peut conseiller dessus. On peut lever des fonds.
Très bien. Mais sur quoi exactement ? Sur une architecture revue ? Sur une sécurité testée ? Sur une documentation propre ? Sur une gouvernance claire ? Sur une cartographie des dépendances ? Ou seulement sur une démo qui a fonctionné une fois ?
C’est inconfortable à entendre. Mais c’est souvent là que commence le vrai diagnostic.
On retrouve exactement le même travers chez certains entrepreneurs : un premier usage IA qui fonctionne avec un client, et la conviction d’être devenu cabinet de conseil IA.
La vitesse donne une impression de maturité. Elle ne la crée pas.
Dans plusieurs organisations que j’ai pu observer ou accompagner en Afrique, je vois aussi autre chose.
Beaucoup de jeunes développeurs, administrateurs et chefs de projet ont une envie d’apprendre énorme. Ils veulent progresser, comprendre les outils, faire les choses proprement, monter en compétence durablement.
Mais ils évoluent parfois dans des environnements où la maîtrise locale reste difficile à construire : décisions prises loin du terrain, prestataires historiques, contrats captifs, dépendances techniques anciennes, solutions imposées sans transfert réel de compétence.
Résultat : ceux qui veulent bien faire sont bridés. Ceux qui voudraient mettre de la rigueur sont écartés. Ceux qui poussent pour une vraie maîtrise locale sont parfois tenus à distance.
Dans ce contexte, l’IA peut devenir une couche de plus au-dessus de systèmes que les équipes locales n’ont jamais vraiment eu les moyens de comprendre, documenter et gouverner.
Ce n’est pas de la transformation. C’est une couche de modernité posée sur une dépendance non résolue.
Le grand théâtre de la maîtrise
Ajoute à cela un autre effet pervers. Les grands groupes de conseil savaient déjà, avant l’IA, produire des présentations impeccables. Ils savaient emballer une idée moyenne dans une forme impressionnante.
Avec l’IA, ils ajoutent une couche d’animations, de récits, d’images parfaites, de fluidité visuelle. La question devient alors très simple : qu’est-ce qui est réellement vendu ?
De la maîtrise ? Ou une scénographie de maîtrise ?
Le politique fait souvent la même chose : contrôler d’abord, normer d’abord, encadrer d’abord, avant même d’avoir compris le terrain réel.
Pendant ce temps, sur le terrain, les systèmes restent fragmentés. Les outils s’empilent. Les flux ne sont pas cartographiés. Les équipes bricolent. Les usages IA se développent hors gouvernance. Les dépendances augmentent.
Le niveau du discours monte. Le niveau de la maîtrise, lui, ne suit pas toujours.
C’est là qu’apparaît l’architecture illusionniste : tout a l’air cohérent en slide, personne ne sait répondre simplement à la question : « Où passent les données ? »
Ou à cette autre question, plus brutale encore : « Qui garde le jugement ? »
L’IA ne remplace pas le conseil. Elle sépare brutalement deux formes de conseil qui cohabitaient déjà : le conseil de production et le conseil de discernement.
Ce que l’IA ne voit pas, même quand elle conseille
On me demande souvent si l’IA va remplacer les consultants.
Sur certains aspects, elle fait déjà mieux que beaucoup de rapports moyens : synthèse de documents, benchmark de solutions, production de plans d’action génériques, rédaction de brouillons.
Mais heureusement, le conseil réel ne se réduit pas à cela.
L’IA ne voit pas le non-dit. Elle ne capte pas les silences, les regards, les réticences, les jeux d’acteurs, les agendas cachés. Elle lit ce qui est formulé. Elle ne voit pas ce qui ne l’est pas encore.
Or, dans une mission de conseil, ce qui ne se dit pas est souvent plus important que ce qui figure dans le cahier des charges.
L’IA ne connaît pas non plus la réalité du SI. Elle connaît sa fiction.
Sur le papier, toutes les architectures sont propres. Tous les processus sont documentés. Tous les organigrammes sont nets. Tout est propre et lisse.
Dans la vraie vie, les audits montrent autre chose : des droits d’accès jamais revus, des flux non cartographiés, des prestataires oubliés, des scripts critiques bricolés il y a huit ans, des sauvegardes jamais testées, des autorisations jamais supprimées, des dépendances invisibles jusqu’au jour où elles cassent. Ou jusqu’au jour où quelqu’un les exploite.
Un consultant qui ne met plus les mains dans le réel finit par croire que l’organisation ressemble à son PowerPoint. L’IA ne fait que renforcer cette tentation.
Elle ne gère pas non plus la souveraineté réelle. Elle sait écrire les mots : « souverain », « conforme », « responsable ». Elle peut citer le RGPD, recommander un cloud, aligner des principes de gouvernance.
Mais elle ne sait pas réellement où tournent les modèles utilisés dans la mission, où vont les données injectées dans les prompts, qui les héberge, avec quelles lois, ni ce qu’implique une dépendance technique dans le temps.
Ça, c’est du terrain. Du contrat lu. De la cartographie. De l’architecture. Des choix d’infrastructure. De l’énergie. De la proximité.
L’IA ne voit pas l’infrastructure qui lui donne vie
C’est ici qu’intervient un point presque toujours absent des discours.
L’IA donne l’illusion d’être légère, immatérielle, « dans le cloud ».
Dans la réalité, derrière chaque assistant, chaque modèle, chaque agent, il y a des salles serveurs, des racks, des systèmes de refroidissement, des réseaux physiques, des contrats d’énergie, des contraintes de raccordement et des limites de puissance.
L’IA n’est pas seulement une interface. C’est une industrie de conversion de l’énergie en intelligence opérationnelle.
C’est aussi pour cela que le sujet des datacenters compte autant. Les centres de calcul deviennent des infrastructures de pouvoir. Penser l’IA sans parler d’énergie, de refroidissement, de densité de calcul, de résilience et de localisation des capacités de traitement, c’est produire un discours amputé de sa base matérielle.
Et je ne parle même pas encore du bruit, de l’incompatibilité avec certains voisinages, des contraintes foncières, des arbitrages locaux.
Depuis Adamentis, cette réalité se regarde autrement.
Pas depuis une keynote. Depuis des compteurs, des courbes de consommation, des contraintes physiques, des choix de refroidissement, des limites de puissance et des arbitrages très concrets.
Quand un consultant recommande de « mettre l’IA partout », de connecter tous les flux à des agents ou de déployer massivement des modèles internes sans jamais parler d’infrastructure, il ne fait pas réellement du conseil.
Il produit un discours numérique sur une infrastructure qu’il n’a jamais réellement regardée.
L’IA ne flotte pas. Elle tourne quelque part, chez quelqu’un, sous des lois précises, avec des limites physiques réelles.
Conseiller, c’est aussi se mettre à la place de l’autre
Il y a une autre limite plus humaine encore.
Conseiller, ce n’est pas appliquer une recette. Ce n’est pas dérouler la même méthodologie sur tout le monde.
Deux organisations d’un même secteur peuvent vivre dans des mondes opérationnels totalement différents. L’une peut être dans une métropole française avec des équipes structurées et un SI relativement suivi. L’autre peut être dans une ville moyenne, ou dans un pays africain avec des contraintes de bande passante, d’énergie, de compétences disponibles, de priorités budgétaires et de dépendances externes radicalement différentes.
Pour conseiller, il faut écouter, regarder, être attentif, être patient, parfois empathique, toujours capable de s’adapter. Il faut presque, pendant un moment, se mettre à la place de la personne que l’on conseille.
Pas comme un persona. Pas comme une cible marketing. Comme un humain placé dans un système réel, avec des contraintes réelles et des conséquences réelles.
Pas en théorie. En pratique.
L’IA applique des patterns à des contextes. Toi, tu accompagnes des humains dans un moment précis, avec des contraintes précises, des peurs précises, des conséquences réelles.
Tu peux travailler dans le même domaine sans travailler de la même façon. Heureusement. Sinon, tu ne fais plus du conseil. Tu distribues des réponses préfabriquées.
Et franchement, je ne vois pas l’intérêt de faire ce métier pour ça.
Quand l’expertise est déléguée, voici ce qui casse
Tout cela n’est pas un débat abstrait. Les conséquences sont très concrètes.
La première, c’est la Shadow IA du consultant.
Des consultants internes ou externes utilisent des LLM grand public, des assistants non cadrés ou des outils SaaS « magiques » pour faire relire un rapport, résumer un audit, analyser un contrat ou générer un plan d’action.
Ils y collent des extraits de contrats, des schémas d’architecture, des éléments d’incident, des données clients, sans vérifier précisément les conditions d’usage ni informer le client.
Ce ne sont plus seulement les collaborateurs qui exposent des données dans des outils non maîtrisés. Ce sont parfois les gens censés justement aider à réduire ce risque.
La deuxième conséquence, c’est l’amplification des erreurs de jugement.
Dans un monde sans IA, un mauvais consultant produisait un rapport faible, mais son impact restait limité par sa capacité de production. Dans un monde avec IA, ce même consultant peut produire très vite beaucoup de recommandations, sur beaucoup de clients, en s’appuyant sur des modèles qu’il ne comprend qu’à moitié.
Les erreurs ne sont pas forcément plus nombreuses. Elles sont plus rapides, plus scalables, plus difficiles à retracer.
Et quand elles portent sur l’architecture SI, les choix cloud, les conditions contractuelles ou la gouvernance des données, on ne parle pas d’un mauvais slide. On parle de décisions structurantes pour cinq à dix ans.
La troisième conséquence, c’est la dette cognitive.
À force de laisser l’IA structurer, rédiger, proposer, certains consultants perdent leur capacité à reconstruire un raisonnement depuis zéro, à sentir quand une recommandation est absurde, à écrire un diagnostic sans béquille.
Le jour où l’outil tombe, où l’accès se coupe, où la situation sort du cadre connu, ils ouvrent un document vierge et rien ne vient.
Dans certains contextes africains, la standardisation peut devenir brutale
En Europe, la standardisation des conseils par l’IA est déjà problématique. Dans certains contextes africains, elle peut devenir encore plus violente.
Pas parce que les compétences seraient absentes. C’est même souvent l’inverse : les compétences existent, l’envie existe, l’intelligence terrain existe.
Ce qui manque parfois, ce sont les marges de manœuvre, le transfert réel de compétence, la documentation, la confiance institutionnelle et la possibilité de reprendre la main sur des systèmes hérités ou imposés.
Quand des modèles entraînés sur des réalités européennes ou nord-américaines recommandent les mêmes architectures cloud, les mêmes feuilles de route data, les mêmes grilles de maturité et les mêmes séquences de transformation sur des contextes où le réseau est moins stable, l’énergie plus contrainte, les budgets différents et les compétences locales parfois sous-exploitées, on fabrique des stratégies hors-sol.
On empile de la dette technique, de la dette organisationnelle et de la dépendance au nom de « bonnes pratiques » qui n’ont jamais regardé le terrain. Là où il faudrait du sur-mesure, on injecte des clones de clones.
Et le jour où cela casse, ce ne sont pas les modèles qui trinquent. Ce sont les équipes locales, qui avaient souvent vu les limites, mais qu’on n’a pas assez écoutées.
Le conseil n’a pas la même valeur quand il permet à une organisation de reprendre la main, ou quand il l’installe dans une dépendance plus élégante.
La forme peut être moderne. La dépendance, elle, reste ancienne.
Reprendre la main côté consultant : devenir vraiment Consultant_IA
Tout cela ne veut pas dire qu’il faudrait rejeter l’IA. Ce serait une erreur.
L’IA est une puissance de traitement de l’information. La question n’est pas « pour ou contre ». La question est : comment l’utiliser sans se renier, sans exposer ses clients, sans perdre son jugement, sans transformer son métier en chaîne de sous-traitance cognitive ?
C’est là qu’intervient ce que j’appelle le Consultant_IA. Le vrai.
Pas celui qui vend du ROI magique, des formations miracles, trois prompts recyclés et une promesse de transformation en quatre heures. Pas celui qui confond communication, automatisation et expertise.
Un Consultant_IA sérieux ne parle pas seulement de modèles, de prompts et d’agents. Il comprend les systèmes d’information, leurs dettes, leurs fragilités. Il maîtrise les enjeux cyber, la gouvernance des données, la souveraineté réelle, les limites des modèles et la relation humaine de conseil.
Le vrai Consultant_IA n’est pas celui qui connaît le plus de prompts. C’est celui qui garde le jugement. Il sait dire où l’IA l’aide, où elle s’arrête, et où commence sa responsabilité.
Dans certaines missions, cela veut dire accompagner des jeunes développeurs très à l’aise avec les outils IA, mais qui manquent de cadre. Le rôle n’est pas de leur dire : « n’utilisez pas l’IA ». Le rôle, c’est de leur montrer où les modèles peuvent les piéger, de leur apprendre à documenter ce qui est généré, de les obliger à penser l’architecture avant de produire des morceaux de code, de les confronter au SI réel plutôt qu’à leur environnement de test.
L’IA leur donne de la vitesse. Le conseil doit leur donner de la direction.
Trois règles simples : déclarer, sécuriser, signer
Dans ma pratique, trois règles me paraissent désormais non négociables.
Déclarer.
Dire au client quels outils IA sont utilisés, à quels moments, sur quelles données, avec quelles limites. Pas comme un aveu. Comme un positionnement professionnel.
« J’utilise l’IA pour accélérer certaines tâches. Mais c’est moi qui pense, qui recadre, qui vérifie, qui décide et qui signe. »
Sécuriser.
Ne pas utiliser des modèles grand public ou non cadrés pour des données sensibles, des schémas SI, des contrats, des éléments d’incident ou des informations stratégiques.
Travailler dans des environnements maîtrisés, avec des briques auditées, avec une compréhension claire de l’hébergement, des flux, des juridictions et des dépendances.
La souveraineté réelle commence là : savoir ce qu’on donne, où, à qui, et comment on peut arrêter.
Signer.
Ne jamais se cacher derrière la machine.
Si une recommandation est dans un rapport, il faut être capable de l’expliquer sans l’IA, de la défendre en réunion et d’en répondre si elle produit un effet indésirable.
L’IA ne se présentera pas devant un conseil d’administration à ta place. Elle ne sera pas mise en cause devant un tribunal.
Tu peux déléguer des tâches. Tu ne peux pas déléguer ta responsabilité.
Reprendre la main côté client
Les dirigeants, DSI, DRH et DAF ont aussi un rôle à jouer. Ils peuvent cesser d’acheter du conseil aveuglément.
Quelques questions simples suffisent souvent à distinguer l’expertise assistée de l’expertise déléguée :
- Quels outils IA utilisez-vous dans vos missions ?
- Où sont hébergées les données que vous traitez avec ces outils ?
- Quelles parties de votre travail faites-vous sans IA ?
- Si demain vos outils IA tombent, que reste-t-il de votre expertise ?
- Quand vous recommandez une solution IA, où tournent concrètement les modèles ?
- Dans votre recommandation, qui gagne quoi : la plateforme, vos partenaires, mes équipes, mon territoire ?
Ce sont des questions qu’on entend encore trop rarement, notamment dans des contextes où les dépendances technologiques peuvent être fortes, et où les solutions importées sont parfois acceptées comme des évidences.
Le jour où un dirigeant local pose ces questions à un grand cabinet, à un intégrateur ou à un vendeur de plateforme « clé en main », on voit très vite s’il achète de la maîtrise… ou simplement un nouvel étage de dépendance emballé dans un beau discours.
Les signaux d’alerte sont assez simples : refus de transparence sur les outils utilisés, discours centré sur la vitesse et le volume, réponses génériques, incapacité à expliquer une recommandation au tableau, sans support, sans interface.
À l’inverse, un consultant qui a compris l’époque commence par cartographier, poser les limites, rendre visibles les flux, les briques, les agents, les dépendances et les responsabilités.
Il ne promet pas la magie. Il travaille la maîtrise. Et surtout, il accepte de dire :
« Ça, je ne le sais pas encore. Voilà comment on va le vérifier. »
Le doute raisonnable n’est pas une faiblesse. C’est une compétence.
Le conseil comme muscle de maîtrise
On peut continuer à dire que l’IA va tuer le conseil. C’est un récit simple, spectaculaire, pratique. Mais ce n’est pas ce que je vois sur le terrain.
L’IA industrialise la synthèse, la recombinaison, la rédaction, la vitesse de production.
Ce qui meurt, ce n’est pas le conseil.
Ce qui meurt, c’est le conseil qui vend du temps au lieu de vendre du discernement, des slides au lieu de vendre de la clarté, des livrables au lieu de vendre de la maîtrise.
Dans un monde où n’importe qui peut générer un rapport en dix minutes, la valeur ne se trouve plus dans ce qu’on produit.
Elle se trouve dans ce qu’on comprend, dans ce qu’on refuse de déléguer, dans ce qu’on est prêt à assumer devant des humains quand on dit :
« Voilà ce que je vous recommande, et voilà pourquoi je mets mon nom dessous. »
Le conseil n’est pas mort.
Ce qui est en train de mourir, c’est le conseil hors-sol, l’expertise déléguée à des modèles qu’on ne comprend pas, le théâtre des livrables standardisés, les stratégies copiées-collées d’un contexte à l’autre sans regarder les réseaux, les datacenters, l’énergie et les humains qui feront réellement tourner tout ça.
Le reste va rester. Le métier, le vrai.
Celui qui parle autant d’énergie, de serveurs et de latence que de prompts. Celui qui écoute un jeune développeur autant qu’un COMEX. Celui qui prend au sérieux une DSI d’Afrique de l’Ouest autant qu’un siège parisien. Celui qui assume ce qu’il signe, même quand l’IA s’est trompée.
C’est ce métier-là qui mérite encore le nom de conseil. Et c’est probablement là que l’IA va rendre le métier plus exigeant.
Parce qu’elle ne va pas seulement accélérer les bons. Elle va aussi exposer les creux.
Ceux qui utilisaient déjà les livrables comme décor vont produire plus vite. Ceux qui utilisaient déjà le conseil comme métier de maîtrise vont devoir aller plus loin.
Plus clair. Plus responsable. Plus assumé.
L’IA ne tue pas le conseil. Elle oblige enfin à répondre à une question simple :
Quand la machine produit le texte, qui produit encore le jugement ?