La semaine dernière, en comité de pilotage IA, j'ai vu un directeur général valider un budget de 350 000 euros sur la base d'une démo de 8 minutes. Le modèle générait de jolis tableaux. Tout le monde était impressionné. Personne n'a demandé avec quelles données il avait été entraîné.
Le principal risque de votre projet IA n'est probablement pas technique. C'est cognitif. Les biais — ces raccourcis mentaux qui nous rendent efficaces au quotidien — deviennent dangereux quand ils pilotent des décisions à plusieurs centaines de milliers d'euros. Et avec l'IA, ils s'amplifient d'une manière que la plupart des organisations n'ont pas encore vue venir.
Je ne suis pas psychologue cognitif. Mais après des années à accompagner des transformations IA, j'ai appris à reconnaître les biais qui tuent les projets. En voici cinq — et pour chacun, ce que je fais concrètement pour les déjouer.
Biais 1 : l'effet halo des démos IA
Un modèle génère un texte fluide en 3 secondes. Un agent résume 500 pages en 20 minutes. La salle est impressionnée. Le budget est voté. C'est l'effet wahou dans toute sa splendeur.
L'effet halo, c'est quand la qualité perçue d'une dimension (la fluidité du texte, la vitesse d'exécution) contamine notre jugement sur toutes les autres dimensions (la pertinence, la fiabilité, la faisabilité en production). Une démo réussie ne prouve pas qu'un projet est viable. Elle prouve qu'un scénario contrôlé fonctionne avec des données sélectionnées.
J'ai vu un comité exécutif valider 400 000 euros sur la base d'une démo de 12 minutes. Le modèle avait été entraîné sur un jeu de données parfait. En production, les données réelles étaient incomplètes à 40 %. Le projet a été arrêté quatre mois plus tard.
Ce que je fais : après chaque démo, je pose trois questions. Quelles données ont été utilisées ? En quoi diffèrent-elles des données réelles ? Quel est le taux d'erreur sur des cas limites ? En général, il y a un silence gêné de quelques secondes. Et c'est précisément ce silence qui justifie la question.
Biais 2 : l'ancrage sur le premier POC
Le biais d'ancrage nous fait accorder un poids disproportionné à la première information reçue. En transformation IA, cette première information est souvent un POC — et il empoisonne tout ce qui suit.
Le POC a montré 92 % de précision ? Ce chiffre devient la référence mentale de tous les décideurs. Quand le modèle en production tombe à 74 %, au lieu d'évaluer si 74 % est suffisant pour le use case, tout le monde se demande « pourquoi on a perdu 18 points ». Le projet est perçu comme un échec alors qu'il crée peut-être déjà de la valeur.
L'inverse est tout aussi dangereux : un premier POC raté ancre la perception que « l'IA ne marche pas chez nous ». Des mois de blocage pour un test mal conçu.
Ce que je fais : on définit les critères de succès avant le POC, pas après. Un POC à 92 % n'a aucune valeur si le seuil métier est à 95 %. Un POC à 70 % peut être un succès si le processus actuel tourne à 55 %. Le cadrage évite de devenir prisonnier du premier chiffre qu'on voit.
Biais 3 : la confirmation dans la sélection de use cases
Le biais de confirmation, c'est chercher les informations qui confirment ce qu'on croit déjà. En transformation IA, il s'exprime de manière particulièrement insidieuse : on choisit les use cases qui confirment la stratégie existante plutôt que ceux qui créeraient le plus de valeur.
Le directeur marketing veut un chatbot ? On lancera un chatbot marketing. Le DSI est convaincu par la maintenance prédictive ? On lancera un POC maintenance. Pas parce que ce sont les meilleurs use cases. Parce que ce sont ceux qui confirment les convictions des décideurs les plus influents.
J'accompagne des organisations où la sélection des use cases IA ressemble à un exercice politique déguisé en exercice stratégique. Les données de priorisation existent — impact business, faisabilité technique, disponibilité des données — mais elles sont ignorées dès qu'elles contredisent le narratif dominant.
Ce que je fais : je mets en place un scoring objectif (impact × faisabilité × qualité données) et je le publie avant la réunion de priorisation. Tout écart par rapport au classement doit être justifié par écrit. Ça ne supprime pas la politique — soyons honnêtes — mais ça la rend visible. Et la visibilité change les comportements.
Biais 4 : l'IA comme stagiaire artificiel
Ce biais est plus subtil. Il consiste à utiliser l'IA pour accélérer des processus défaillants au lieu de les corriger. Comme un manager qui donnerait des tâches répétitives à un stagiaire sans se demander si ces tâches devraient exister.
83 % des collaborateurs passent un tiers de leur semaine en réunions, mais seuls 11 % les trouvent productives. La réponse des organisations ? Déployer des outils de prise de notes IA. Le problème n'était pas la prise de notes. Le problème, c'est que ces réunions n'auraient jamais dû exister.
C'est le principe fondamental de l'approche IAgile : optimiser avant de transformer. Si votre processus est défaillant, l'IA ne le corrigera pas — elle le rendra défaillant plus vite.
Ce que je fais : avant chaque projet IA, je pose la question en face : « ce processus mérite-t-il d'être accéléré, ou supprimé ? » La réponse est souvent « supprimé ». Mais la supprimer demande du courage managérial, et c'est toujours plus facile d'acheter un outil IA que de supprimer la réunion d'un directeur.
Biais 5 : le biais du survivant dans les benchmarks
Quand un COMEX étudie l'IA, il lit des cas de succès. Amazon. Google. Leboncoin. Des entreprises qui ont réussi à intégrer l'IA à l'échelle. Ce qu'il ne lit pas : les centaines d'entreprises qui ont essayé la même chose et échoué.
C'est le biais du survivant : ne voir que ceux qui ont réussi et en déduire que la réussite est la norme. Or, selon Gartner, plus de 85 % des projets IA n'atteignent jamais la production. Les articles que vous lisez sur les succès IA représentent les 15 % restants.
Ce biais pousse les organisations à sous-estimer les difficultés, à sur-estimer leur maturité, et à copier des stratégies conçues pour des entreprises tech-native dans des contextes radicalement différents.
Ce que je fais : pour chaque benchmark de succès qu'un client me montre, je cherche un échec dans le même secteur. « OK, Leboncoin a 70 features IA en production. Mais quelle entreprise comparable a essayé et échoué ? Qu'est-ce qui les différencie de vous ? » Si le client ne trouve aucune différence, c'est qu'il n'a pas assez cherché. Ou qu'il ne veut pas trouver.
Le débiaisage structurel : intégrer dans le processus, pas dans la bonne volonté
Connaître ses biais ne suffit pas. Si c'était le cas, les psychologues cognitifs ne commettraient jamais d'erreurs de jugement — or ils en commettent autant que les autres.
La seule approche qui fonctionne est structurelle : intégrer le débiaisage dans les processus décisionnels eux-mêmes.
C'est ce que je fais concrètement avec l'approche IAgile :
- En phase Discovery : scoring objectif des use cases publié avant la réunion de priorisation. Critères de succès du POC définis avant le POC.
- En phase Build : rétrospectives avec questions inversées (« qu'est-ce qui pourrait prouver que notre hypothèse est fausse ? »). Red team interne sur les décisions clés.
- En phase Scale : mesure de l'adoption réelle (pas des licences activées). Confrontation systématique entre valeur attendue et valeur mesurée.
Le framework M3K intègre cette dimension dans le pilier Mindset : former les managers non pas à utiliser l'IA, mais à penser avec l'IA — ce qui implique de reconnaître leurs propres biais face à cette technologie.
Le diagnostic en 5 questions
Avant votre prochain comité de pilotage IA, posez ces cinq questions. Si vous répondez « non » à plus de deux, vos biais pilotent votre stratégie.
- Avez-vous défini les critères de succès du POC avant de le lancer ?
- La sélection des use cases suit-elle un scoring publié et transparent ?
- Avez-vous cherché activement des exemples d'échecs dans votre secteur ?
- Le processus que vous voulez augmenter par l'IA a-t-il d'abord été audité ?
- Vos managers peuvent-ils nommer au moins trois limites de l'IA qu'ils déploient ?
Les biais cognitifs ne sont pas des défauts. Ce sont des mécanismes cérébraux normaux. Mais dans un contexte où chaque décision engage des centaines de milliers d'euros et des mois de travail, « normal » ne suffit pas. Il faut être délibéré.
Pour approfondir, découvrez l'approche IAgile et comment elle structure le débiaisage à chaque phase de la transformation, ainsi que le framework M3K pour développer un leadership lucide face à l'IA.