Pourquoi votre pitch IA n'intéresse pas le CODIR - et comment passer de l'ingénieur à l'expert métier
La compétence technique ne suffit pas. Ce qui fait la différence, c'est la capacité à traduire - pas à vulgariser.
Retour terrain 2LKATIME
Lors de nos missions d'audit IA et cybersécurité, l'un de nos experts seniors - certifié OSCP, OSEP et titulaire d'un badge red team de l'ESIEA - observe le même schéma dans la quasi-totalité des organisations auditées : les équipes techniques ont construit des solutions réelles et efficaces. Elles ne parviennent pas à les vendre en interne parce qu'elles parlent de ce qu'elles ont fait, pas de ce que cela change pour le business. Cet article explique pourquoi - et comment y remédier.
Le signal d'alerte pour le dirigeant
Si vos équipes techniques présentent leurs projets IA en CODIR et repartent systématiquement sans décision, le problème n'est probablement pas la qualité des projets. C'est la façon dont ils sont présentés. Et tant que cette compétence de traduction n'est pas dans l'équipe, vos meilleurs projets continueront à mourir faute de budget approuvé.
Il y a un paradoxe que nous observons chaque semaine dans les organisations que nous accompagnons : plus un ingénieur IA est compétent techniquement, moins il est entendu en comité de direction. Ses projets sont souvent les plus solides, les mieux construits, les plus utiles. Et pourtant, ils n'obtiennent pas de budget, pas de validation, pas de priorité. Pas parce que le CODIR manque d'intelligence. Parce que le pitch s'adresse au mauvais interlocuteur dans le mauvais langage.
Cet article démonte ce mécanisme avec précision - en s'appuyant sur la psychologie comportementale de Kahneman, sur ce que nous observons lors de nos audits, et sur une distinction que peu d'écoles d'ingénieurs enseignent : la différence entre vulgariser et traduire. Avec des schémas, des exemples concrets, et les 5 règles que nous appliquons pour transformer un projet technique en décision business.
1. Le "curse of knowledge" : quand la compétence devient un obstacle
En 1990, des chercheurs de Stanford ont mené une expérience simple. Un groupe de participants devait taper le rythme de chansons connues (Joyeux Anniversaire, La Marseillaise) sur une table. Un autre groupe devait deviner les chansons. Les "tapeurs" estimaient que les auditeurs allaient réussir à identifier les chansons dans 50 % des cas. Le taux réel était de 2,5 %.
La raison : dans la tête du "tapeur", la mélodie résonne clairement. Il entend la chanson en tapant. L'auditeur, lui, n'entend que des coups secs et irréguliers. Le tapeur ne peut pas s'imaginer ne pas entendre ce qu'il entend. Il a oublié ce que c'est que de ne pas savoir.
Les psychologues appellent ce phénomène le "curse of knowledge" - la malédiction de la connaissance. Et c'est exactement ce qui se passe quand un ingénieur IA présente son travail à un CODIR. Il entend la mélodie - l'élégance de l'architecture, la difficulté technique surmontée, la pertinence du choix du modèle. Le directeur financier n'entend que des coups secs : pipeline RAG, embedding vectoriel, fine-tuning, latence p99.
Le résultat est prévisible : le pitch décrit le travail plutôt que la valeur. Il parle de l'outil construit plutôt que du problème résolu. Et sans le réaliser, l'ingénieur transforme chaque présentation en cours magistral non sollicité - face à un auditoire qui n'a pas demandé à apprendre, mais à prendre une décision.
Ce n'est pas un problème de manque de pédagogie. Des profils brillants, capables d'expliquer clairement le fonctionnement d'un transformeur à un développeur junior, restent muets face à un DAF. Parce que l'enjeu n'est pas d'être clair sur ce que c'est - c'est d'être pertinent sur ce que ça change.
Le "curse of knowledge" a une conséquence directe sur la structure du pitch : l'ingénieur organise son discours autour de ce qui lui a coûté le plus d'effort intellectuel (la complexité technique résolue), plutôt qu'autour de ce qui a de la valeur pour son auditoire (l'impact sur les chiffres ou le quotidien). C'est une erreur de perspective, pas d'intelligence. Et elle se corrige - une fois qu'on en a conscience.
Ce biais s'aggrave avec l'expérience : plus vous maîtrisez un sujet, plus il vous semble évident, et moins vous comprenez pourquoi votre interlocuteur "ne saisit pas". La solution n'est pas de simplifier - c'est de changer d'angle de départ.
2. Comment le cerveau d'un dirigeant filtre votre pitch - la leçon de Kahneman
Daniel Kahneman, prix Nobel d'économie 2002 et auteur de "Système 1 / Système 2 : les deux vitesses de la pensée" (2011), a décrit deux modes de fonctionnement du cerveau. Le Système 1 est rapide, automatique, émotionnel - c'est lui qui traite la quasi-totalité de nos perceptions et prend la majorité de nos décisions en quelques fractions de seconde. Le Système 2 est lent, délibératif, analytique - c'est celui que nous croyons utiliser quand nous "réfléchissons vraiment", mais il intervient bien moins souvent qu'on ne le pense.
Le problème fondamental du pitch technique, c'est qu'il s'adresse au Système 2 d'un interlocuteur qui filtre avec le Système 1.
Un dirigeant en CODIR traite des dizaines de sujets en quelques heures. Avant même que vous ayez terminé votre deuxième slide, son Système 1 a rendu un verdict : "est-ce que ça me concerne directement ?" Si la réponse n'est pas immédiate et positive, votre pitch entre dans la catégorie mentale "intéressant mais pas urgent" - ce qui en pratique signifie "on en reparle", c'est-à-dire jamais.
Il y a pire. Les termes techniques que vous utilisez pour démontrer votre légitimité - LLM, RAG, fine-tuning, agents IA autonomes - activent chez certains dirigeants un signal négatif. Pas parce qu'ils ne comprennent pas. Mais parce qu'ils sonnent comme une tentative d'impressionner plutôt que de résoudre. Et la tentative d'impressionner, le Système 1 la lit instantanément comme un manque de clarté sur la valeur réelle du projet.
Un dirigeant qui sent qu'on cherche à l'impressionner avec des mots techniques se met en posture défensive. Il commence à chercher les failles plutôt que les opportunités. Il demande "mais est-ce que ça marche vraiment ?" non pas parce qu'il doute de votre compétence, mais parce que son Système 1 a interprété votre discours comme un signal de risque plutôt qu'une promesse de valeur.
Schéma 1 - Le filtre CODIR : ce qui passe et ce qui est bloqué
La bonne nouvelle : vous pouvez court-circuiter ce filtre. Pas en simplifiant le technique - en commençant par la réponse à la question que votre interlocuteur se pose en boucle sans jamais la formuler : "Est-ce que ça résout MON problème, à MOI, maintenant ?" Chaque phrase de votre pitch doit répondre silencieusement à cette question. Pas seulement votre conclusion - chaque phrase, dès la première.
3. Vulgarisation vs Traduction : la distinction que personne n'enseigne
C'est la distinction la plus importante de cet article, et l'une des moins enseignées dans les cursus d'ingénieur ou de data scientist.
Vulgariser, c'est rendre le technique compréhensible. "Un modèle de langage, c'est comme un système de prédiction très sophistiqué qui a analysé une grande partie des textes disponibles sur internet et peut générer des réponses cohérentes à partir d'un contexte donné." C'est clair, c'est pédagogique - et ça ne fait pas avancer d'un centimètre la décision d'un directeur financier ou d'un PDG dont le temps se compte en minutes.
Traduire, c'est transformer un choix technique en conséquence business directement chiffrable. Pas "on a utilisé un modèle fine-tuné sur nos données contractuelles internes", mais "notre équipe juridique analyse désormais trois fois plus de contrats par semaine, à effectif constant." Le technique disparaît complètement. La valeur reste seule, précise, actionnable.
La différence peut sembler subtile à l'écrit. Elle ne l'est pas dans une salle de réunion. Vulgariser s'adresse au Système 2 de votre interlocuteur : "je veux que tu comprennes ce que j'ai fait." Traduire s'adresse à son Système 1 : "je veux que tu ressentes le bénéfice avant même de l'analyser." La compréhension peut venir après. La décision, elle, vient du ressenti.
Schéma 2 - De la langue technique à la traduction métier : exemples concrets
Notez que dans chaque traduction, le terme technique a complètement disparu. Ce n'est pas de la simplification - c'est un changement radical de point de vue. Vous passez de "ce que j'ai fait" à "ce que ça change pour toi." Le technique peut rester dans l'annexe, dans la documentation, dans la question-réponse en fin de réunion. Il n'a pas sa place dans les deux premières minutes d'un pitch CODIR.
Cette compétence - la traduction - est la vraie rareté dans le marché de l'IA en 2026. Pas les ingénieurs capables de construire des agents, ils sont de plus en plus nombreux. Les profils capables de connecter ce que ces agents font techniquement à ce que cela change concrètement pour un directeur commercial ou un DAF restent exceptionnellement rares. Et contrairement à la maîtrise technique, cette compétence ne s'acquiert pas dans un cursus : elle se construit en passant du temps à observer les problèmes métier de ses interlocuteurs avant de proposer des solutions.
4. La double couche 2LKATIME : vendre ce qui est invisible
Il y a des contextes où la traduction est encore plus difficile que la normale. Vendre une fonctionnalité IA à un CODIR, c'est déjà un défi - vous avez vu pourquoi. Vendre un audit de sécurité ou un audit IA, c'est un défi d'un autre ordre.
Pourquoi ? Parce que vous ne vendez pas quelque chose de visible, de tangible, ou de mesurable immédiatement. Vous vendez la prévention d'un risque que votre client ne voit pas encore - et parfois, qu'il espère sincèrement ne jamais avoir à voir. C'est ce que nous appelons chez 2LKATIME la "double couche de traduction" : non seulement passer du technique au métier, mais aussi passer du métier au risque chiffré.
Schéma 3 - La pyramide de traduction : les trois niveaux de difficulté
Un audit de cybersécurité, c'est "nous allons chercher les failles dans votre système pour qu'un attaquant ne les trouve pas avant vous." La valeur est réelle et documentée : le coût moyen d'une compromission pour une PME française dépasse 180 000 euros selon l'ANSSI, sans compter l'interruption d'activité. Mais cette valeur est conditionnelle, future, et totalement invisible tant qu'aucun incident ne s'est produit.
Comment pitcher quelque chose d'invisible à un CODIR ? En le traduisant en coût d'opportunité ou en coût potentiel concret. Pas "on va tester vos défenses contre les attaques connues", mais : "une PME de votre taille et de votre secteur subit en moyenne deux incidents de sécurité significatifs par an. Le dernier incident comparable dans votre secteur a provoqué une interruption de 23 jours et coûté 240 000 euros en remédiation et perte d'exploitation. Notre audit complet prend 5 jours ouvrés. Votre choix est entre 5 jours de travail préventif planifié et une interruption subie qui peut dépasser un mois."
C'est le même service. C'est une traduction radicalement différente. Et c'est précisément la compétence que notre équipe - dont notre auditeur senior certifié OSCP, OSEP et formé à l'ESIEA - apporte dans chaque engagement : transformer un investissement en sécurité ou en IA d'une décision technique floue en une décision business avec des chiffres clairs et une comparaison de risques intelligible.
Sur le ROI de l'IA en PME, nous avons compilé les chiffres PwC, Gartner et Deloitte qui confirment que la majorité des investissements IA n'ont pas de mécanisme de mesure. L'absence de traduction dès le pitch initial en est souvent la cause profonde.
5. Les 5 règles d'un pitch IA qui obtient une décision
Ces règles sont celles que nous appliquons - et que nous conseillons aux DSI et CTO que nous accompagnons lorsqu'ils doivent défendre leurs projets IA en interne. Elles ne sont pas théoriques : elles sont issues de dizaines de réunions de direction observées et analysées.
Règle 1 - Commencez par la conséquence, jamais par la cause
Votre première phrase doit être le résultat, pas le moyen. "Ce projet permettra à votre équipe RH de réduire de 60 % le temps de traitement des candidatures" - et seulement ensuite, si on vous le demande, vous expliquez comment. La cause (le technique) justifie la conséquence. Elle ne la crée pas dans l'esprit du dirigeant.
Règle 2 - Nommez un problème que votre interlocuteur reconnaît
Avant de présenter votre solution, nommez le problème avec les mots que le CODIR utilise lui-même. "Vous m'avez dit lors de notre dernière réunion que le délai moyen de réponse client était votre principal frein à la croissance." Si votre interlocuteur s'entend dans la description du problème, il est déjà disposé à entendre la solution.
Règle 3 - Chiffrez avant d'expliquer
Le chiffre convainc. L'explication justifie. Dans l'ordre idéal : "40 % de réduction du temps de traitement" - puis - "grâce à un système IA qui pré-qualifie automatiquement les demandes." Inverser cet ordre, c'est demander à votre interlocuteur de travailler (comprendre le système) avant de lui donner une raison de le faire (le chiffre).
Règle 4 - Éliminez les buzzwords qui sonnent creux
LLM, RAG, fine-tuning, agents autonomes, embedding vectoriel - ces termes n'ajoutent aucune valeur dans un pitch CODIR. Ils envoient un signal négatif : "je suis plus impressionné par ma technologie que par votre problème." Remplacez chaque terme technique par sa conséquence fonctionnelle. Si vous ne pouvez pas, c'est que le terme n'a pas sa place dans ce pitch.
Règle 5 - Terminez par une décision, pas une question ouverte
"Qu'en pensez-vous ?" est la pire façon de finir un pitch. Elle remet la responsabilité de structurer la suite sur votre interlocuteur. Terminez par une décision claire et simple à prendre : "Pour avancer, j'ai besoin de votre validation sur le budget de 15 000 euros d'ici vendredi. Je prépare le contrat lundi." Un CODIR sait prendre des décisions binaires. Il ne sait pas gérer les fins floues.
2 min
Temps dont vous disposez avant le verdict du Système 1
0
Termes techniques autorisés dans les 3 premières phrases
1
Décision claire à demander en conclusion, pas plus
3x
Plus de chances d'obtenir un budget si le chiffre vient en premier (PwC 2026)
6. Ce que 2LKATIME fait concrètement
Chez 2LKATIME, nous intervenons à deux niveaux sur ce sujet. D'abord, nous accompagnons les DSI et CTO de PME à Paris et Lyon qui ont des projets IA ou cybersécurité solides mais qui peinent à obtenir la validation de leur direction. Nous aidons à restructurer le pitch : identifier le chiffre qui convainc, trouver l'angle de risque ou d'opportunité, et préparer la conclusion actionnable.
Ensuite, nous incarnons nous-mêmes cette traduction dans notre propre démarche commerciale. Quand notre équipe - dont notre auditeur senior certifié OSCP, OSEP et titulaire d'un badge red team de l'ESIEA avec plus de 16 ans d'expérience en sécurité offensive - présente un audit à un CODIR, elle ne parle pas de CVE, de vecteurs d'attaque ou de surface d'exposition. Elle parle de jours d'interruption potentielle, de coûts de remédiation dans votre secteur, et du temps que prend l'audit préventif en comparaison.
Nous sommes convaincus que le déficit de traduction est l'une des causes principales du manque de ROI de l'IA en entreprise. Des projets meurent non pas parce qu'ils sont mauvais, mais parce que personne dans l'équipe n'a su les présenter avec les mots qui déclenchent une décision. Et c'est une compétence qui se transmet - une fois qu'on a compris la règle fondamentale : chaque phrase doit répondre silencieusement à "et donc, moi je gagne quoi ?"
Nos accompagnements à Bordeaux et dans toute la France incluent systématiquement ce volet : audit technique, mais aussi préparation de la communication interne vers la direction, avec les chiffres et la narration qui transforment un projet en décision.
FAQ - Pitch IA et convaincre le CODIR
Qu'est-ce que le "curse of knowledge" dans un contexte de pitch IA ?
Le "curse of knowledge" - ou malédiction de la connaissance - est un biais cognitif documenté depuis 1990 (expérience de Stanford) qui empêche un expert de se souvenir de ce que c'est que de ne pas savoir. En pitch IA, cela se traduit par des présentations centrées sur l'architecture technique plutôt que sur la valeur métier. L'ingénieur "entend la mélodie" pendant qu'il pitch ; le dirigeant n'entend que des coups secs incompréhensibles.
Quelle est la différence entre vulgariser et traduire un projet IA ?
Vulgariser, c'est rendre le technique compréhensible - expliquer ce qu'est un modèle de langage avec des mots simples. Traduire, c'est transformer un choix technique en conséquence business directement chiffrée. "On a utilisé un modèle fine-tuné" est de la vulgarisation. "Notre équipe juridique traite désormais 3 fois plus de contrats par semaine à effectif constant" est une traduction. La vulgarisation s'adresse à la compréhension. La traduction s'adresse à la décision.
Comment convaincre un CODIR d'investir dans un audit cybersécurité ?
En traduisant le risque en coût d'opportunité mesurable. Pas "on va tester vos défenses", mais : "une PME de votre taille subit en moyenne deux incidents significatifs par an. Le dernier incident comparable dans votre secteur a provoqué une interruption de 23 jours et coûté 240 000 euros. Notre audit préventif prend 5 jours. Le CODIR comprend les chiffres et les arbitrages - pas les menaces abstraites."
Pourquoi les buzzwords IA nuisent-ils à un pitch CODIR ?
Parce qu'ils activent un signal négatif dans le Système 1 de Kahneman : le dirigeant lit "tentative d'impressionner" plutôt que "clarté sur la valeur." Un interlocuteur qui se sent impressionné se met en posture défensive et cherche les failles plutôt que les opportunités. LLM, RAG, embedding vectoriel, fine-tuning - ces termes n'ont pas leur place dans un pitch CODIR. Leur conséquence fonctionnelle, si.
Quelles sont les 5 règles d'un pitch IA efficace devant un CODIR ?
1. Commencer par la conséquence, pas par la cause technique. 2. Nommer un problème précis que l'interlocuteur reconnaît dans ses propres mots. 3. Chiffrer avant d'expliquer - le chiffre convainc, l'explication justifie. 4. Éliminer tous les buzzwords techniques qui ne contribuent pas à la décision. 5. Terminer par une décision claire et binaire à prendre, pas par une question ouverte qui dilue la conclusion.
Votre projet IA mérite un meilleur pitch
En 30 minutes avec notre équipe, nous analysons votre projet IA ou cybersécurité et vous aidons à construire la traduction métier qui obtiendra la validation de votre direction - avec les chiffres, l'angle de risque, et la conclusion actionnable. Nos auditeurs certifiés OSCP, OSEP et formés à l'ESIEA savent transformer la complexité technique en décision business claire.