Évaluer une démo IA : 12 questions techniques pour ne pas se faire vendre du vent
Selon une étude du MIT, 95 % des projets d'IA générative en entreprise échouent. Gartner estime que plus de 40 % des projets d'IA agentique seront abandonnés d'ici fin 2027. Pourtant, chaque semaine, des décideurs signent des contrats après avoir assisté à une démo spectaculaire — sans savoir distinguer une vraie solution fonctionnelle d'une mise en scène bien rodée.
Le phénomène porte un nom : l'IA washing. La SEC américaine a même commencé à sanctionner des entreprises pour fausses déclarations sur leurs capacités IA — avec des amendes totalisant 400 000 $ dès les premiers cas en mars 2024. Le problème ne touche pas que la finance : Gartner estime que sur les milliers de fournisseurs d'IA agentique recensés, seuls 130 environ proposent des capacités réelles.
Cet article vous donne les 12 questions concrètes à poser lors d'une démo IA pour séparer la substance du marketing. Vous n'avez pas besoin d'être technique pour les utiliser.
TL;DR — La majorité des démos IA sont conçues pour impressionner, pas pour informer. Pour évaluer objectivement une solution, posez des questions sur les données d'entraînement, les taux d'erreur réels, la latence en production, et exigez un test sur vos propres données. Les 12 questions de cet article vous permettent de mener cet exercice sans compétence technique.
Pourquoi la plupart des démos IA ne reflètent pas la réalité
Le fossé entre la démo et la production
Une démo IA est une vitrine. Elle montre le meilleur scénario possible, sur des données soigneusement sélectionnées, dans un environnement contrôlé. La réalité en production est radicalement différente : données bruitées, cas limites, montées en charge, pannes de services tiers.
Ce décalage n'est pas toujours intentionnel. Certains éditeurs croient sincèrement en leur produit mais n'ont testé que sur des jeux de données propres. D'autres maîtrisent parfaitement l'art de la mise en scène. Le résultat est le même pour l'acheteur : une décision prise sur des bases faussées.
En France, seules 4 % des organisations déclarent percevoir des bénéfices financiers significatifs de leurs investissements IA, selon les données compilées par Squid Impact à partir de rapports sectoriels 2024-2025. Ce chiffre traduit un problème systémique dans la sélection et l'évaluation des solutions.
La technique du « Wizard of Oz »
Le terme vient de l'informatique des années 1980, inventé par le chercheur John F. Kelley à Johns Hopkins University. Le principe : l'utilisateur interagit avec ce qu'il croit être un système automatisé, alors qu'un opérateur humain se cache derrière le rideau et produit les réponses manuellement.
IBM utilisait déjà cette technique dans les années 1970 pour simuler un système de reconnaissance vocale — les utilisateurs parlaient à un ordinateur, convaincus que la machine transcrivait leur parole, alors qu'un humain tapait en temps réel dans la pièce d'à côté.
Aujourd'hui, la technique a évolué. Lors de certaines démos IA, la part d'automatisation réelle peut être masquée par des interventions humaines invisibles. L'affaire Nate Inc. en est l'illustration extrême : le fondateur a levé 42 millions de dollars en prétendant que son application utilisait l'IA pour traiter les transactions, alors que des travailleurs manuels effectuaient les achats. Le taux d'automatisation, annoncé à plus de 90 %, était en réalité proche de zéro. La SEC et le DOJ ont engagé des poursuites en avril 2025.
L'IA washing : un phénomène documenté et sanctionné
L'IA washing consiste à revendiquer des capacités d'intelligence artificielle que le produit ne possède pas réellement. Cela va du simple embellissement marketing (rebaptiser un système de règles en « IA ») à la fraude caractérisée.
En mars 2024, la SEC a sanctionné simultanément Delphia (USA) Inc. et Global Predictions Inc. pour déclarations trompeuses sur leur utilisation de l'IA dans les processus d'investissement. En janvier 2025, Presto Automation Inc. est devenue la première entreprise cotée sanctionnée pour IA washing — l'analyse de la SEC a révélé que la technologie de reconnaissance vocale présentée comme automatisée reposait en fait sur une intervention humaine significative et appartenait à un tiers non divulgué.
Gartner a introduit le concept d'« agent washing » pour décrire les fournisseurs qui rebaptisent chatbots, RPA et assistants existants en « agents IA » sans capacités agentiques réelles. Le phénomène touche la majorité du marché.
Les 4 catégories de signaux d'alerte pendant une démo
Signaux visuels : ce que vous voyez (ou pas)
Pendant une démo, observez ce que le présentateur ne montre pas autant que ce qu'il montre. Voici les signaux d'alerte à repérer :
| Signal d'alerte | Ce que ça peut cacher | Question à poser |
|---|---|---|
| La démo utilise toujours le même jeu de données | Le système ne fonctionne que sur des données préparées | « Peut-on tester avec nos propres données ? » |
| Le présentateur évite les cas limites | Le modèle échoue sur les exceptions | « Que se passe-t-il si l'entrée est incomplète ou ambiguë ? » |
| Les temps de réponse semblent instantanés | L'environnement de démo est surdimensionné | « Quel est le temps de réponse moyen en production ? » |
| L'interface est très léchée mais les résultats vagues | Effort mis sur le front-end, pas sur le modèle | « Quel est le taux de précision documenté ? » |
| Aucune erreur ne survient en 30 minutes de démo | Le scénario est scripté | « Montrez-moi un cas où le système se trompe » |
Signaux discursifs : le vocabulaire qui doit alerter
Certaines formulations sont des marqueurs de solutions immatures ou survendues. Quand un commercial dit « notre IA comprend », « notre algorithme apprend en temps réel » ou « notre système est intelligent », ce sont des métaphores marketing, pas des descriptions techniques.
Un fournisseur sérieux parle de taux de précision, de rappel, de F1-score, de latence au 95e percentile, de volume de données d'entraînement. Il quantifie les limites de son système au lieu de les nier.
Signaux commerciaux : la pression à signer
Un fournisseur qui pousse à signer rapidement après une démo sans proposer de phase de test sur vos données a quelque chose à cacher — ou ne croit pas lui-même que son produit survivra à un test en conditions réelles.
Le schéma classique : démo impressionnante → urgence artificielle (« les tarifs augmentent le mois prochain ») → contrat pluriannuel sans POC. Ce schéma doit déclencher un réflexe de méfiance, pas d'enthousiasme.
Signaux techniques : l'absence de documentation
Un produit IA mature dispose d'une documentation technique accessible : architecture du système, sources de données, métriques de performance, politique de gestion des erreurs, feuille de route. Si cette documentation n'existe pas ou n'est « pas encore disponible », le produit n'est probablement pas prêt pour la production.
Les 12 questions à poser lors d'une démo IA
Questions sur le modèle et les données (1-4)
Question 1 : « Quel type de modèle utilisez-vous et est-il propriétaire ou basé sur un modèle fondation ? »
Cette question permet de comprendre si le fournisseur a développé son propre modèle ou s'il a construit une couche applicative au-dessus de GPT-4, Claude ou Gemini. Aucune des deux approches n'est intrinsèquement meilleure, mais les implications en termes de coûts, de dépendance et de contrôle sont radicalement différentes. Un fournisseur qui ne peut pas répondre clairement à cette question ne maîtrise probablement pas sa propre stack technique.
Question 2 : « Sur quelles données le modèle a-t-il été entraîné ou fine-tuné ? »
La qualité d'un modèle IA dépend directement de la qualité et de la représentativité de ses données d'entraînement. Si le fournisseur a fine-tuné un modèle sur des données sectorielles, demandez lesquelles, en quel volume, et comment elles ont été annotées. Si les données ne correspondent pas à votre secteur ou à votre géographie, les performances en production seront dégradées.
Question 3 : « Nos données seront-elles utilisées pour entraîner ou améliorer votre modèle ? »
Cette question touche à la propriété intellectuelle et à la conformité RGPD. Si vos données alimentent le modèle du fournisseur, elles bénéficient indirectement à ses autres clients — y compris vos concurrents. La réponse doit être claire et contractuellement formalisée, pas un « en principe, non ».
Question 4 : « Le modèle est-il explicable ou de type boîte noire ? »
Un modèle explicable permet de comprendre pourquoi une décision a été prise. Pour certains cas d'usage (scoring crédit, diagnostic médical, conformité réglementaire), l'explicabilité n'est pas optionnelle — l'AI Act européen, entré en vigueur en juin 2024, l'impose pour les systèmes à haut risque. Si le fournisseur ne peut pas expliquer les décisions de son modèle, vérifiez que votre cas d'usage ne tombe pas dans une catégorie réglementée.
Questions sur la performance réelle (5-8)
Question 5 : « Quel est votre taux de précision documenté, et sur quel jeu de données a-t-il été mesuré ? »
La différence entre 80 % et 95 % de précision peut paraître marginale. En pratique, elle signifie que le système se trompe quatre fois plus souvent dans le premier cas. Demandez sur quel benchmark ou jeu de test ce taux a été calculé, et s'il reflète des conditions réelles de production ou un environnement de laboratoire.
Question 6 : « Quelle est la latence au 95e percentile en environnement de production ? »
Le temps de réponse moyen est un indicateur trompeur. Si un système répond en 200 ms en moyenne mais met 5 secondes une fois sur vingt, l'expérience utilisateur sera dégradée. Le 95e percentile (P95) révèle ce que vivent vos utilisateurs dans les cas défavorables — c'est cette donnée qui compte pour dimensionner l'infrastructure.
Question 7 : « Que se passe-t-il quand le modèle ne sait pas répondre ? »
Tout modèle IA a des limites. Un système bien conçu détecte ses propres zones d'incertitude et escalade vers un humain ou signale un niveau de confiance faible. Un système mal conçu hallucine — il fabrique une réponse plausible mais fausse avec la même assurance qu'une réponse correcte. La gestion des cas d'échec en dit plus sur la maturité d'un produit que ses cas de succès.
Question 8 : « Pouvez-vous montrer un cas où le système échoue ? »
Un fournisseur qui refuse de montrer les limites de son système ou qui affirme « notre IA ne se trompe jamais » ment ou se ment à lui-même. Tout système a des faiblesses. Un fournisseur mature les connaît, les documente et les gère activement. Cette transparence est un marqueur de fiabilité plus fort que n'importe quelle métrique de performance.
Questions sur l'intégration et l'exploitation (9-12)
Question 9 : « Comment le système s'intègre-t-il à notre stack existante ? »
Une IA qui fonctionne en silo n'a pas de valeur métier. Demandez quelles API sont disponibles, quels formats de données sont supportés, quelles sont les contraintes d'authentification et de sécurité. Vérifiez que l'intégration ne nécessite pas de middleware propriétaire qui crée une dépendance supplémentaire.
Question 10 : « Quel est le coût total de possession sur 3 ans, incluant l'infrastructure, la maintenance et le réentraînement ? »
Les coûts d'une solution IA ne se limitent pas à la licence. Il faut compter l'infrastructure de calcul (GPU, cloud), la maintenance du modèle (dérive des performances dans le temps), le réentraînement périodique, le coût de l'annotation de données, et le support. Demandez une décomposition détaillée. Si le fournisseur ne peut la fournir, il n'a probablement pas de clients en production depuis assez longtemps pour connaître ces coûts.
Question 11 : « Que se passe-t-il si nous décidons d'arrêter le service ? »
La réversibilité est un critère souvent négligé. Vos données sont-elles exportables ? Dans quel format ? Les modèles fine-tunés sur vos données vous appartiennent-ils ? Quel est le délai de transition ? Un fournisseur qui rend la sortie difficile ou impossible construit son business model sur l'enfermement, pas sur la valeur de son produit.
Question 12 : « Pouvons-nous réaliser un POC de 30 jours sur nos propres données avant de nous engager ? »
C'est la question décisive. Un proof of concept (POC) de 30 jours sur vos données réelles, avec des métriques de succès définies à l'avance, est le seul moyen fiable de valider qu'une solution IA tient ses promesses. Tout fournisseur sérieux accepte ce principe. Gartner note que 70 % des POC d'IA ne passent jamais en production — ce qui prouve que le fossé entre la démo et la réalité est la norme, pas l'exception.
La grille d'évaluation : noter une démo IA en 15 minutes
Les 5 critères pondérés
Utilisez cette grille pour structurer votre évaluation à la sortie de chaque démo. Chaque critère est noté de 1 à 5 et pondéré selon son importance.
| Critère | Poids | 1 (Insuffisant) | 3 (Acceptable) | 5 (Excellent) |
|---|---|---|---|---|
| Transparence technique | 30 % | Réponses vagues, jargon marketing | Explications claires mais incomplètes | Documentation détaillée, métriques précises |
| Gestion des erreurs | 25 % | « Notre IA ne se trompe pas » | Erreurs reconnues sans solution | Limites documentées + mécanismes de fallback |
| Adaptabilité aux données client | 20 % | Refus de tester sur vos données | Test possible mais conditions floues | POC structuré sur vos données proposé |
| Maturité de déploiement | 15 % | Pas de client en production | Quelques clients, retours non vérifiables | Références vérifiables + études de cas |
| Conditions contractuelles | 10 % | Engagement long, réversibilité floue | Conditions standard négociables | Flexibilité, réversibilité, SLA clairs |
Comment interpréter le score
- Score 4,0 à 5,0 — Solution crédible. Passez à la phase POC avec confiance.
- Score 3,0 à 3,9 — Potentiel mais zones d'ombre. Demandez des clarifications écrites avant d'aller plus loin.
- Score 2,0 à 2,9 — Signaux d'alerte significatifs. Comparez avec d'autres options avant de vous engager.
- Score inférieur à 2,0 — Passez votre chemin. Le risque d'IA washing est élevé.
Le piège du « on verra en POC »
Attention à ne pas utiliser le POC comme substitut à l'évaluation critique. Un POC mal cadré — sans métriques de succès prédéfinies, sans jeu de données représentatif, sans durée suffisante — ne prouve rien. Définissez les critères de réussite avant le lancement, pas après.
Un POC sérieux dure au minimum 30 jours, utilise un échantillon représentatif de vos données réelles (pas des données synthétiques), mesure la performance sur des cas normaux et des cas limites, et intègre un comparatif avec le processus existant (avec ou sans IA).
Construire votre propre scénario de test
Préparer vos données de test avant la démo
Ne laissez pas le fournisseur choisir les données de démonstration. Préparez trois catégories de données avant la session :
Données « faciles » — des cas standards que tout système raisonnablement entraîné devrait traiter. Elles servent de baseline : si le système échoue sur ces cas, la suite est inutile.
Données « réalistes » — des cas représentatifs de votre quotidien, avec leur lot d'ambiguïtés, d'erreurs de saisie, de formats hétérogènes. C'est le vrai test de la solution.
Données « limites » — des cas que vous savez difficiles : exceptions métier, langues rares, formats inhabituels. Le but n'est pas de piéger le fournisseur mais de comprendre comment le système réagit quand il atteint ses limites.
Documenter les résultats de manière structurée
Pour chaque test, notez : l'entrée fournie, la sortie attendue, la sortie obtenue, le temps de réponse, et le verdict (succès, échec partiel, échec total). Ce tableau factuel vaut plus que n'importe quelle impression subjective.
Conservez cette documentation. Elle servira de base de comparaison entre fournisseurs et de référence pour le POC.
Impliquer un profil technique dans la boucle
Vous n'avez pas besoin d'être développeur pour poser les 12 questions de cet article. Mais au moment de passer du POC à l'engagement contractuel, un regard technique indépendant est indispensable. Pas pour valider le choix — pour identifier ce que la démo et le commercial ne vous ont pas dit.
Ce profil technique peut être un CTO, un architecte solution freelance, ou un partenaire de développement capable d'auditer l'architecture, les API et la documentation technique du fournisseur. L'investissement (quelques jours-homme) est négligeable comparé au coût d'un projet IA qui échoue.
Les spécificités françaises à prendre en compte
L'AI Act et ses implications pour l'évaluation
L'AI Act européen, entré en vigueur en juin 2024, classe les systèmes IA en catégories de risque. Si votre cas d'usage implique de la prise de décision automatisée touchant des personnes (recrutement, crédit, santé), le fournisseur doit pouvoir démontrer la conformité de son système avec les exigences correspondantes.
Lors de la démo, posez la question directement : « Dans quelle catégorie de risque de l'AI Act se situe votre système pour notre cas d'usage, et quelles mesures de conformité avez-vous mises en place ? » Si le fournisseur ne connaît pas l'AI Act ou botte en touche, c'est un signal d'alerte majeur pour toute entreprise opérant en Europe.
Le marché français en chiffres
Le contexte d'adoption en France est structurant pour évaluer la maturité du marché des fournisseurs locaux. Selon les données INSEE 2024, 10 % des entreprises françaises de plus de 10 salariés utilisent au moins une technologie IA — en hausse de 4 points par rapport à 2023, mais en retrait par rapport à la moyenne européenne de 13 %.
Le taux monte à 33 % dans les entreprises de plus de 250 salariés et à 42 % dans le secteur information et communication. L'écosystème compte plus de 1 000 startups IA et 16 licornes orientées IA. Cette dynamique crée un marché où coexistent des solutions matures et des produits encore au stade de prototype — d'où l'importance d'une évaluation rigoureuse.
RGPD et souveraineté des données
Toute solution IA traitant des données personnelles doit respecter le RGPD. Mais au-delà de la conformité théorique, posez des questions pratiques : où sont hébergées les données ? Quels sous-traitants ont accès aux données envoyées au modèle ? Les données transitent-elles par des serveurs hors UE ? Le fournisseur peut-il fournir un DPA (Data Processing Agreement) conforme ?
Pour les secteurs sensibles (santé, finance, défense), la question de la souveraineté des données va au-delà du RGPD. Si le fournisseur utilise un modèle hébergé chez un hyperscaler américain, vos données sont potentiellement soumises au Cloud Act. Ce n'est pas rédhibitoire dans tous les cas, mais cela doit être documenté et accepté en connaissance de cause.
Après la démo : les étapes pour sécuriser votre décision
Exiger un engagement écrit sur les métriques
Tout ce qui a été promis à l'oral pendant la démo doit être formalisé par écrit. Demandez un document qui précise les métriques de performance engagées (précision, latence, disponibilité), les conditions dans lesquelles ces métriques ont été mesurées, et les conséquences contractuelles si elles ne sont pas atteintes en production.
Un fournisseur qui refuse de s'engager par écrit sur les performances montrées en démo vous envoie un message clair : ces performances ne sont pas reproductibles.
Structurer le POC avec des critères go/no-go
Avant de lancer le POC, définissez des critères binaires qui détermineront si vous poursuivez ou non :
- Taux de précision minimum sur vos données réelles (ex. : > 90 % sur les cas standards)
- Latence maximale acceptable au P95 (ex. : < 2 secondes)
- Taux de disponibilité minimum sur la période de test (ex. : > 99,5 %)
- Capacité d'intégration avec au moins un système existant (ex. : votre CRM ou ERP)
- Coût par transaction cohérent avec le business case
Si l'un de ces critères n'est pas rempli à l'issue du POC, c'est un no-go — indépendamment de la qualité de la démo initiale.
Vérifier les références clients de manière indépendante
Les études de cas sur le site du fournisseur sont des outils marketing, pas des preuves. Demandez à parler directement avec des clients en production — pas des « partenaires stratégiques » ou des « early adopters » mais des organisations qui utilisent le produit quotidiennement depuis au moins six mois.
Posez-leur trois questions : le système fait-il ce qui a été promis ? Quels problèmes avez-vous rencontrés ? Recommanderiez-vous ce fournisseur à un pair ? Les réponses à ces questions valent plus que n'importe quelle démo.
FAQ
Comment savoir si une démo IA est truquée ? Demandez à tester la solution avec vos propres données en temps réel. Si le fournisseur refuse ou temporise, c'est un signal d'alerte. Observez aussi si le scénario de démonstration suit toujours le même chemin — un système réellement fonctionnel peut être testé de manière ad hoc sans préparation.
Faut-il être technique pour évaluer une démo IA ? Non. Les 12 questions de cet article sont conçues pour être posées par un profil non technique. Les réponses du fournisseur sont révélatrices : un éditeur sérieux répond avec des chiffres et de la documentation, pas avec du jargon ou des métaphores. Faites-vous accompagner d'un profil technique au moment du POC.
Combien de temps doit durer un POC IA pour être fiable ? Un minimum de 30 jours sur des données réelles est recommandé. En dessous, vous ne captez pas les variations de performance liées au volume de données, aux cas limites ou à la montée en charge. Définissez les métriques de succès avant le lancement, pas après.
Qu'est-ce que l'IA washing et comment s'en protéger ? L'IA washing consiste à revendiquer des capacités d'intelligence artificielle que le produit ne possède pas réellement. Pour vous en protéger, exigez des métriques documentées, demandez à voir la documentation technique, et vérifiez les références clients de manière indépendante. La SEC américaine sanctionne désormais cette pratique.
Quelles sont les obligations du fournisseur IA vis-à-vis de l'AI Act européen ? L'AI Act, entré en vigueur en juin 2024, classe les systèmes IA par niveaux de risque. Pour les systèmes à haut risque (recrutement, crédit, santé), le fournisseur doit garantir l'explicabilité du modèle, la documentation technique, et la supervision humaine. Demandez dans quelle catégorie se situe votre cas d'usage.
Quel budget prévoir pour évaluer correctement un fournisseur IA ? Le POC lui-même est souvent proposé gratuitement ou à coût réduit par le fournisseur. Le vrai coût est interne : temps de préparation des données de test, mobilisation d'une équipe d'évaluation, et éventuellement quelques jours d'un profil technique indépendant pour auditer l'architecture. Comptez 5 à 15 jours-homme au total — un investissement dérisoire face au risque d'un contrat à six chiffres sur une solution inadaptée.
AI Coder Squad : évaluer une solution IA, c'est aussi savoir ce qu'on veut en faire
Poser les bonnes questions à un fournisseur suppose d'avoir clarifié son besoin métier, défini ses critères de performance et anticipé les contraintes d'intégration. C'est exactement le travail que fait une équipe de développement senior avant de construire ou d'intégrer une brique IA.
AI Coder Squad conçoit des applications sur mesure et des agents IA pour les entreprises qui veulent aller vite sans sacrifier la qualité — avec des développeurs senior et une approche propulsée par l'IA.
→ Démarrez votre projet et découvrez comment AI Coder Squad peut accélérer votre prochaine réalisation.