La semaine dernière, en comité de pilotage IA. Un directeur général valide 350 K€ 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. Il est cognitif.
Les biais — ces raccourcis mentaux qui nous rendent efficaces au quotidien — deviennent radioactifs quand ils pilotent des décisions à 6 chiffres. Et avec l'IA, ils s'amplifient d'une manière que la plupart des organisations n'ont pas vue venir.
21% seulement des projets IA génèrent une vraie valeur (Gartner). Une bonne partie des 79% restants n'a pas échoué sur la techno. Elle a échoué en salle de réunion. Voici les cinq biais que je vois revenir — et pour chacun, ce que je fais pour les neutraliser.
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é, la vitesse) contamine le jugement sur toutes les autres (pertinence, fiabilité, 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.
Cas vécu : un comité exécutif valide 400 K€ sur la base d'une démo de 12 minutes. Modèle entraîné sur un jeu de données parfait. En production, les données réelles incomplètes à 40%. Projet arrêté quatre mois plus tard.
Ce que je fais : après chaque démo, trois questions systématiques.
→ 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, silence gêné de quelques secondes. 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 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.
Biais 3 — La confirmation dans la sélection des use cases
Le biais de confirmation, c'est chercher ce qui confirme 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 lance un chatbot marketing.
→ Le DSI est convaincu par la maintenance prédictive ? On lance un POC maintenance.
→ Le DRH a entendu parler de matching CV ? On lance un projet matching CV.
Pas parce que ce sont les meilleurs use cases. Parce que ce sont ceux qui confirment les convictions des décideurs les plus influents. La sélection ressemble à un exercice politique déguisé en exercice stratégique.
Ce que je fais : scoring objectif publié avant la réunion de priorisation (impact × faisabilité × qualité données). Tout écart par rapport au classement doit être justifié par écrit. Ça ne supprime pas la politique. Ça la rend visible. Et la visibilité change les comportements.
Biais 4 — L'IA comme stagiaire artificiel
Plus subtil. Utiliser l'IA pour accélérer des processus défaillants au lieu de les corriger. Comme un manager qui donne 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 de la plupart 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. Et plus discrètement.
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 le supprimer demande du courage managérial, et c'est toujours plus facile d'acheter un outil IA que de supprimer la réunion récurrente 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. 85% des projets IA n'atteignent jamais la production. Les articles de succès que vous lisez représentent les 15% restants.
Ce biais pousse les organisations à sous-estimer les difficultés, à surestimer 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. 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.
Débiaiser 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. 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 :
→ 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.
→ Build — rétrospectives avec questions inversées ("qu'est-ce qui prouverait que notre hypothèse est fausse ?"). Red team interne sur les décisions clés.
→ 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.
Lundi matin — 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 : IAgile et le framework M3K.
Lequel de ces 5 biais a pesé le plus dans votre dernière décision IA à 6 chiffres ?