La phrase revient dans presque tous les ateliers de cadrage que j'anime, prononcée en toute bonne foi : « En fait, c'est juste un ChatGPT branché sur nos données. » Elle vient d'un dirigeant sérieux, souvent excellent dans son métier, qui a testé un assistant conversationnel pendant trois semaines et en est ressorti convaincu. Il a raison sur un point : l'outil est effectivement simple à utiliser. Il se trompe sur ce qui compte : la simplicité d'usage ne dit rien de la difficulté d'industrialisation.

Ce malentendu n'est pas anodin. Il produit des budgets sous-dimensionnés, des calendriers irréalistes, des chefs de projet mis en échec et, au bout de la chaîne, la conviction durable que « l'IA, chez nous, ça n'a pas marché ». La difficulté, pour celui qui doit porter le sujet — DSI, responsable de la transformation, consultant ou le dirigeant lui-même face à son comité — n'est pas technique. Elle est pédagogique : comment expliquer une complexité qui, précisément, a été conçue pour rester invisible ?

Le dirigeant n'a pas tort de trouver ça simple

Commençons par rendre justice à son intuition, parce que c'est la condition pour être écouté ensuite. Son expérience est authentique : il a ouvert un navigateur, posé une question en français, obtenu une réponse pertinente en quatre secondes. Aucune formation, aucune installation, aucun projet. Cette facilité d'accès est réelle, et elle constitue une rupture : une technologie de cette portée ne demande pas d'apprendre son mode d'emploi.

Les chiffres confirment cette diffusion spontanée. Selon le 82e baromètre semestriel de Bpifrance Le Lab, publié en janvier 2026 et mené auprès de plus de 4 700 entreprises, 55 % des TPE et PME françaises déclarent utiliser l'IA générative fin 2025, contre 31 % un an plus tôt et 15 % fin 2023. Une multiplication par près de quatre en deux ans, sans plan de déploiement, sans conduite du changement, sans DSI — une trajectoire d'adoption sans équivalent récent en entreprise.

Mais la même enquête contient le chiffre qui devrait retenir l'attention du comité de direction. Sur l'ensemble des TPE et PME interrogées, 17 % déclarent un usage régulier et 37 % un usage occasionnel. Autrement dit : l'IA est massivement essayée, beaucoup moins installée. Les usages dominants le confirment : génération de contenus écrits (72 %), puis recherche et analyse d'informations (67 %) — des tâches individuelles, à la main de celui qui les exécute, sans dépendance de processus. Pour le dirigeant qui souhaite d'abord se faire sa propre idée de ces usages avant d'engager un projet, notre guide pratique de l'IA pour les entrepreneurs qui débutent couvre ce premier palier.

Trois mécanismes qui fabriquent l'illusion de simplicité

1. L'interface conversationnelle masque le système

Un assistant conversationnel présente au dirigeant une surface d'une simplicité absolue : un champ de saisie. Tout le reste — l'infrastructure, les données, les garde-fous, le coût par requête, la journalisation — est délibérément dissimulé, parce que c'est le principe même d'un bon produit grand public. Le dirigeant évalue donc la technologie à travers l'unique fenêtre qui a été conçue pour ne rien laisser voir de sa complexité.

La transposition mentale se fait ensuite toute seule : si poser une question à une IA est si simple, la brancher sur le CRM ne devrait pas être beaucoup plus compliqué. C'est ce saut logique qu'il faut interrompre, et c'est le seul moment de la conversation où l'on a une chance de le faire proprement.

2. La démonstration se joue toujours sur le terrain de l'IA

Une démonstration d'éditeur est un exercice mené sous des contraintes inverses de celles de la production. On y présente des cas choisis, sur des données propres, sans volumétrie, sans cas limite, sans utilisateur pressé, sans exigence d'audit. Le taux de réussite affiché n'est pas une mesure : c'est une mise en scène — parfaitement légitime commercialement, structurellement trompeuse pour évaluer un déploiement.

Gartner a nommé le phénomène dans un communiqué du 25 juin 2025 : l'agent washing, c'est-à-dire le fait de rebaptiser « agent IA » des assistants, des automatisations RPA ou des chatbots déjà en place, dépourvus de toute capacité agentique réelle. Le cabinet estime que, sur les milliers d'éditeurs qui se revendiquent de l'IA agentique, environ 130 seulement relèvent véritablement de cette catégorie, et il prévoit que plus de 40 % des projets d'IA agentique seront abandonnés d'ici à fin 2027, en raison de coûts qui dérapent, d'une valeur métier mal définie ou de contrôles de risque insuffisants. Une précision d'usage, puisque ce chiffre circule beaucoup : il s'agit d'une prévision d'analyste, pas d'une mesure, et l'estimation des 130 éditeurs n'est pas documentée méthodologiquement. Ces réserves ne l'invalident pas ; elles indiquent comment le citer.

Ce constat ne disqualifie pas la technologie : les déploiements qui atteignent la production donnent des résultats réels, comme je l'ai détaillé dans cet état des lieux de l'IA agentique en entreprise. Il disqualifie une méthode d'évaluation — celle qui consiste à décider sur la base d'une démonstration.

3. La fluidité du langage est confondue avec la fiabilité

C'est le mécanisme le plus profond, et le plus difficile à expliquer. Nos cerveaux ont appris à évaluer la compétence d'un interlocuteur à travers l'assurance de son expression. Un texte bien construit, sans hésitation, au vocabulaire juste, déclenche une présomption de fiabilité. Les modèles de langage produisent cette assurance en permanence, y compris — surtout — quand ils se trompent.

Un dirigeant qui lit une note d'analyse générée par une IA ne dispose d'aucun signal perceptible lui indiquant que le troisième paragraphe est une invention plausible. Là où un collaborateur junior hésiterait, nuancerait, dirait « je ne suis pas sûr », le modèle affirme avec la même tonalité que pour le reste. Cette absence de signal de doute est la propriété la plus dangereuse de la technologie, et c'est celle qui ne se voit jamais en démonstration.

Ce que la démonstration ne montre jamais

Il existe une référence qui, en atelier, produit systématiquement un déclic : un article de recherche publié par D. Sculley et ses collègues de Google à la conférence NIPS de 2015 — devenue NeurIPS depuis — sous le titre Hidden Technical Debt in Machine Learning Systems. Sa figure la plus reprise est accompagnée d'une légende sans ambiguïté : « Only a small fraction of real-world ML systems is composed of the ML code, as shown by the small black box in the middle. The required surrounding infrastructure is vast and complex. » — seule une petite fraction des systèmes d'apprentissage automatique réels est constituée du code d'apprentissage ; l'infrastructure qui l'entoure est vaste et complexe.

Autour de cette petite boîte noire centrale, les auteurs placent tout ce qu'il faut construire pour qu'un système fonctionne en production : collecte des données, vérification des données, extraction de caractéristiques, gestion des ressources, infrastructure de service, outils d'analyse, gestion de configuration, surveillance. Pris ensemble, ces blocs pèsent bien davantage que le modèle lui-même.

Une précaution s'impose ici, parce qu'un DSI la soulèvera : ce schéma décrit une chaîne d'apprentissage construite en interne, et ce n'est plus le cas dominant. En 2026, la plupart des entreprises consomment un modèle de fondation par interface de programmation. L'entraînement, l'extraction de caractéristiques et l'infrastructure de service passent chez le fournisseur. Mais d'autres blocs apparaissent, que la figure de 2015 ne contient pas : indexation documentaire, ingénierie de contexte, jeux d'évaluation, garde-fous contre l'injection d'instructions, pilotage du coût par jeton, gestion de l'obsolescence des versions de modèle. La nature du travail périphérique a changé ; sa prépondérance sur le code qui appelle le modèle, non. C'est cela qui reste vrai onze ans plus tard.

Pour un projet d'entreprise, la traduction concrète est la suivante :

  • Les données : identifier ce qui existe réellement, mesurer sa qualité, arbitrer ce qui peut être exposé au modèle, gérer les droits d'accès. Dans les ateliers que j'anime, cette étape révèle le plus souvent des problèmes bien antérieurs au projet IA.
  • L'intégration : connecter l'agent aux systèmes existants (ERP, CRM, GED, messagerie), ce qui suppose des interfaces qui n'ont pas toujours été prévues pour cela, et se heurte à des éditeurs tiers qui n'ont pas toujours envie de les ouvrir.
  • Le coût d'exploitation : le prix par requête, qui croît avec l'adoption au lieu de décroître, les évolutions tarifaires décidées unilatéralement par l'éditeur, et le coût de bascule vers un autre modèle. C'est la première question d'un directeur financier, et celle que les cadrages traitent en dernier.
  • La supervision humaine : définir qui relit quoi, à quel moment, avec quel temps alloué. Un dispositif de supervision dont le temps n'est pas budgété n'existe pas.
  • Le traitement de l'erreur : décider ce qui se passe quand le système se trompe, qui est prévenu, comment on corrige, ce qu'on dit au client concerné. Dans les cahiers des charges que je relis, c'est le point le plus souvent absent.
  • La conformité et la traçabilité : documenter, journaliser, pouvoir reconstituer une décision six mois après. Obligation lourde pour les usages sensibles — sujet traité en détail dans l'article que j'ai consacré à la gouvernance et à la sécurité des agents IA — et affaire de bon sens partout ailleurs.
  • L'appropriation : former les utilisateurs, ajuster les processus, accepter que la première version soit décevante et itérer.

Ce n'est pas une liste de précautions optionnelles : c'est la définition de ce qu'est un déploiement. La démonstration montre la petite boîte du milieu ; le projet, c'est tout le reste.

Le chiffre du MIT : 95 % de projets sans retour mesurable

Le rapport The GenAI Divide : State of AI in Business 2025, publié en juillet 2025 dans le cadre du projet NANDA, hébergé au MIT Media Lab, a marqué les esprits avec un constat brutal : environ 95 % des organisations étudiées n'obtiennent aucun retour financier mesurable de leurs investissements en IA générative, malgré des dizaines de milliards de dollars engagés. Le rapport attribue ce résultat moins à la qualité des modèles qu'à l'absence d'apprentissage et de mémoire dans les systèmes déployés, et à leur faible intégration dans les processus réels.

Ce chiffre est solide dans ce qu'il mesure, à condition de savoir ce qu'il mesure. Il porte sur des déploiements d'entreprise, développés sur mesure ou achetés à un éditeur, et non sur l'usage individuel de l'IA générative. Le document se présente lui-même comme un ensemble de résultats préliminaires, publiés sous la seule responsabilité de leurs auteurs et non comme une position institutionnelle. Sa base est un peu plus de 300 initiatives publiques, 52 entretiens organisationnels et 153 dirigeants interrogés lors de quatre conférences professionnelles — un échantillon auto-sélectionné parmi des personnes venues parler d'IA, ce qui pèse davantage que sa taille.

Le même rapport contient d'ailleurs son propre contrepoint, et c'est le passage le plus intéressant pour un dirigeant : dans plus de 90 % des entreprises interrogées, des salariés déclarent utiliser régulièrement des outils d'IA personnels pour leur travail, avec des gains bien réels. Autrement dit, l'échec massif documenté par le rapport n'est pas celui de la technologie : c'est celui de son industrialisation. La valeur existe, elle se produit hors des projets — et sans traçabilité, sans contrôle, sans maîtrise des données qui sortent de l'entreprise.

Un chiffre présenté avec ses limites convainc durablement ; un chiffre asséné se retourne dès la première objection. C'est vrai de celui-ci comme de tous les autres, et c'est la première chose à transmettre au dirigeant qui repartira le citer en comité.

Cinq façons d'expliquer un projet IA à un dirigeant

Voici les cinq déplacements de conversation qui fonctionnent le mieux, dans l'ordre où je les emploie. Aucun ne demande de compétence technique à celui qui écoute ; tous demandent de la discipline à celui qui parle — à commencer par celle de renoncer au vocabulaire du métier. Répondre à l'excès d'optimisme par un déluge de termes techniques produit l'inverse de l'effet recherché : le dirigeant en retient que c'est compliqué, donc que c'est l'affaire des techniciens, donc qu'il n'a plus à s'en occuper. Un projet IA dont le dirigeant s'est désinvesti est un projet sans arbitrage, sans budget de conduite du changement et sans décideur le jour où il faudra trancher entre vitesse et prudence.

1. Remplacer « est-ce que ça marche ? » par « que fait-on quand ça se trompe ? »

C'est le déplacement le plus efficace, et il tient en une phrase. Tant que la question posée est « est-ce que l'IA sait faire ? », la réponse est presque toujours oui, et la conversation s'arrête là. Dès qu'elle devient « quand elle se trompe — mettons une fois sur vingt — qui s'en aperçoit, en combien de temps, et qui répond au client ? », le dirigeant revient sur son terrain, celui de la responsabilité et de l'organisation, et il mesure immédiatement l'ampleur du sujet. Il n'a besoin de comprendre aucun modèle de langage pour cela.

2. Faire chiffrer le taux d'erreur acceptable avant de parler d'outil

Demandez au dirigeant, sur le cas d'usage envisagé : « Quel pourcentage d'erreurs êtes-vous prêt à accepter ? » La réponse spontanée est souvent « zéro », ce qui ouvre la discussion la plus utile de tout l'atelier — car le processus actuel, tenu par des humains, n'est pas à zéro non plus, et personne ne l'a jamais mesuré. On passe alors d'un débat sur la technologie à un débat sur le niveau de qualité réellement requis, chiffré, comparé à l'existant. C'est là que se joue le sens du projet.

3. Faire la contre-démo

Après la démonstration de l'éditeur, prenez dix minutes avec le dirigeant et un vrai cas de l'entreprise : un dossier client mal renseigné, un contrat scanné de travers, une question posée dans le jargon interne de la maison. Ne cherchez pas à piéger l'outil, mais à lui soumettre un cas ordinaire. L'effet est plus fort que n'importe quelle explication, parce qu'il déplace la conviction du registre du discours à celui de l'expérience. La scène rapportée plus haut, chez le distributeur régional, n'est rien d'autre que ce levier appliqué pendant une demi-heure : un dirigeant qui a vu l'outil buter sur son propre dossier n'a plus besoin qu'on lui explique pourquoi le projet durera six mois.

4. Décrire le système, pas le modèle

L'analogie qui porte le mieux en comité de direction est celle du recrutement. Le modèle d'IA, c'est le candidat : brillant, rapide, généraliste, capable d'écrire dans huit langues. Personne n'a jamais cru qu'embaucher un excellent candidat suffisait à résoudre un problème d'organisation. Il faut un poste défini, des procédures, un manager, des accès aux bons outils, un contrôle du travail et quelqu'un qui assume les conséquences des erreurs. Le projet IA, c'est exactement cette construction-là.

L'analogie s'arrête toutefois à une frontière qu'il faut nommer dans la même phrase, sous peine de faire plus de mal que de bien : un collaborateur apprend de ses erreurs et en répond, le modèle ne fait ni l'un ni l'autre. Ses fautes ne diminuent pas avec l'ancienneté, il n'existe pas de période d'essai au terme de laquelle il serait stabilisé, et il ne constitue pas un point d'imputation de la responsabilité. Cette limite est le vrai sujet du projet, pas une réserve de juriste.

Pour rendre le levier opérant, demandez au dirigeant d'écrire lui-même, en trois lignes, la fiche de poste de l'agent : ce qu'il décide seul, ce qu'il fait valider, et qui est son manager. L'exercice prend cinq minutes et révèle en général que les trois réponses n'existent pas encore.

5. Donner un vocabulaire de décision : essai, pilote, production, échelle

Une part importante des malentendus vient de ce que le dirigeant et l'équipe projet n'appellent pas la même chose du même nom. Posez quatre mots, avec une définition d'une ligne chacun :

  • Essai : quelqu'un teste l'outil à son poste. Coût : quelques heures. Ce qu'on apprend : si l'idée mérite d'être creusée.
  • Pilote : un périmètre réel, des utilisateurs réels, une mesure. Coût : quelques semaines. Ce qu'on apprend : le taux d'erreur observé et le temps réellement gagné.
  • Production : le processus dépend de l'outil, avec supervision, traçabilité et procédure de secours. Coût : plusieurs mois. Ce qu'on obtient : un gain durable et opposable.
  • Échelle : le dispositif est étendu à d'autres processus ou entités. Coût : proportionnel au périmètre, et rarement anticipé. Ce qu'on obtient : le retour sur investissement dont parlent les études.

Le passage du pilote à la production est la marche que la plupart des organisations n'ont pas franchie. La nommer à l'avance évite qu'elle ne soit découverte au pire moment, c'est-à-dire après l'annonce interne.

Quand c'est vraiment simple : le contre-cas

Un article qui explique que rien n'est simple finit par produire l'erreur inverse de celle qu'il combat. Le catastrophisme — risques juridiques, biais, souveraineté, dépendance aux éditeurs — décrit des sujets réels, mais utilisé comme argument principal il produit une paralysie qui a un coût, car pendant ce temps les concurrents apprennent. Il faut donc dire aussi quand la simplicité perçue est justifiée.

Trois conditions réunies signalent un cas où il faut y aller vite, sans cadrage lourd : l'usage reste individuel et outillé — un collaborateur qui rédige, résume ou traduit mieux et plus vite ; aucune donnée sensible ni personnelle ne sort de l'entreprise ; et le dispositif est réversible, c'est-à-dire qu'aucun processus ne dépend de l'outil si on l'arrête demain. Dans ce périmètre, temporiser coûte plus cher que se tromper, et le rapport du MIT cité plus haut le documente lui-même à travers les usages personnels qui produisent de la valeur en dehors de tout projet.

La ligne de partage est nette : dès qu'un processus commence à dépendre de l'outil, ou qu'une donnée client entre dans la boucle, on quitte le contre-cas et on retombe dans tout ce qui précède. La compétence à transmettre au dirigeant est celle de savoir de quel côté de cette ligne il se trouve.

La maîtrise de l'IA, une obligation depuis l'AI Act (article 4)

Il existe un levier que peu de porteurs de projet utilisent, alors qu'il est factuel et directement adressé au dirigeant. L'article 4 du règlement (UE) 2024/1689, dit AI Act, impose aux fournisseurs comme aux déployeurs de systèmes d'IA de prendre des mesures relatives à la maîtrise de l'IA (AI literacy, souvent traduit par « littératie ») de leur personnel et des personnes qui utilisent ces systèmes pour leur compte, en tenant compte de leurs connaissances techniques, de leur expérience et du contexte d'utilisation. Cette obligation s'applique depuis le 2 février 2025, en vertu de l'article 113 du même règlement.

Un point de vigilance s'impose, parce qu'il est récent et que beaucoup d'articles en ligne ne l'ont pas encore intégré : le règlement (UE) 2026/1744, dit « omnibus numérique », publié au Journal officiel de l'Union européenne le 24 juillet 2026 et en vigueur depuis le 27 juillet 2026, a remplacé le texte de l'article 4. La rédaction initiale demandait de garantir un niveau suffisant de maîtrise de l'IA. La nouvelle demande de prendre des mesures pour soutenir le développement de cette maîtrise, et précise explicitement qu'elle n'oblige ni les fournisseurs ni les déployeurs à garantir un niveau déterminé pour une personne donnée. L'obligation n'a pas disparu : elle est passée d'une obligation de résultat à une obligation de moyens.

Deux conséquences pratiques méritent d'être exposées devant un comité de direction. D'abord, l'obligation ne dépend pas du niveau de risque du système utilisé : elle s'applique dès lors que l'organisation déploie de l'IA, y compris un simple assistant conversationnel. Ensuite, elle est proportionnée aux responsabilités et au contexte d'usage : un dirigeant qui utilise ces systèmes ou qui en supervise l'emploi est concerné au même titre que ses équipes.

Une précision d'honnêteté, puisqu'on parle ici de conformité : l'article 4 n'est assorti d'aucune amende spécifique dans le barème de sanctions du règlement, et la surveillance relève des autorités nationales, dont le dispositif n'est effectif que depuis août 2026. Ce n'est donc pas un argument de peur du gendarme — c'en est un de gouvernance. La formation du dirigeant, souvent perçue comme une perte de temps, devient une ligne identifiable dans un plan de conformité, donc quelque chose qui se planifie et se finance.

Ce qui distingue les organisations qui réussissent

Les deux sources citées plus haut convergent sur trois marqueurs, et aucun n'est technologique. Le rapport du MIT identifie l'intégration profonde dans un processus précis, plutôt qu'un déploiement large et superficiel, et la capacité du dispositif à apprendre de son usage au lieu d'être figé le jour de sa mise en service. Gartner y ajoute le troisième : n'engager un projet que là où la valeur métier est explicite, et l'évaluer sur des résultats — temps de traitement, taux de reprise, satisfaction client — plutôt que sur des critères techniques.

Ces trois marqueurs ont un point commun : ils relèvent tous de décisions de direction, pas de choix d'outils. C'est la bonne nouvelle à donner au dirigeant en fin d'atelier — ce qui fait la différence est précisément ce sur quoi il a la main. Le reste, y compris le choix du modèle, est second.

Si vous préparez un cadrage IA, les formations Oppchain comportent un format d'une demi-journée destiné aux dirigeants, construit autour de ces questions ; et un échange de trente minutes suffit généralement à savoir si votre projet relève du contre-cas décrit plus haut ou de la construction complète.

Pour aller plus loin : cinq sources publiques

À propos de l'auteur

Frédéric Michel dirige Oppchain, cabinet et organisme de formation certifié Qualiopi spécialisé en IA agentique. Il anime régulièrement des ateliers de cadrage IA en comité de direction, auprès de dirigeants de PME et d'ETI.