logo

La démo et la production parfaites lundi

30 septembre 2026

Une démo est conçue pour fonctionner. Elle s'exécute sur des données préparées, avec un utilisateur disposant de tous les droits, en suivant le parcours optimal du produit et sans aucune des exceptions inhérentes à une utilisation réelle. Rien de tout cela n'est trompeur : c'est la définition même d'une démo. L'erreur consiste à la considérer comme la preuve que le système fonctionnera correctement lundi matin dans votre entreprise.

L'écart entre ces deux éléments explique une part importante des abandons constatés. S&P Global Market Intelligence estimait en mars 2025 que 421 % des entreprises avaient abandonné la plupart de leurs initiatives en matière d'IA, contre 171 % l'année précédente, abandonnant en moyenne 46 % de leurs projets de validation de concept.

Les six choses qu'une démo n'apprend jamais

Dimension

Dans la démo

Lundi en production

Données

Sélectionné et complet

Incomplet, dupliqué, contradictoire

Permis

Utilisateur disposant d'un accès complet

Rôles différents, visibilité restreinte

Volume

Quelques cas

Des milliers, avec des pics et des embouteillages

Exceptions

Aucun

Entre 15% et 30% de volume

Intégration

Copier et coller entre les écrans

Véritable connexion avec les ERP, CRM et l'identité

Coût

Non pertinent

Coût unitaire qui détermine la rentabilité

Aucune des six colonnes de droite ne peut être déduite de celles de gauche. Par conséquent, une excellente démonstration ne renseigne pas sur les risques du projet ; elle renseigne sur la qualité de l’interface et sur le scénario le plus favorable.

Comment transformer une démo en un avis utile

La solution n'est pas de se méfier des démos, mais de changer ceux qui les conçoivent. Voici cinq demandes précises que vous pouvez adresser à tout fournisseur réputé :

Laissez-les utiliser vos données, même si elles sont peu nombreuses. Cent enregistrements réels, avec leurs doublons et leurs champs vides, sont plus instructifs que dix mille enregistrements synthétiques.

Incluez un cas rare que vous aurez choisi. Il ne s'agit pas d'un cas générique ou rare : c'est le vôtre, avec votre règle non écrite. Cette demande distingue celui qui a conçu un système de celui qui a simplement créé une présentation.

Demandez à quelqu'un de votre équipe de s'en charger. Pas la publicité. La différence entre regarder un expert utiliser un outil et l'utiliser soi-même est souvent considérable.

Montrez ce qui se passe en cas d'échec. Demandez-lui de provoquer une erreur. La manière dont elle la communique, ce qu'elle enregistre et comment elle s'en remet en disent plus sur le produit que n'importe quelle fonctionnalité.

Cela vous donne le coût par caisse pour votre volume. Extrapolation, y compris les tentatives de reprise. Si vous ne pouvez pas le calculer, vous ne pourrez pas non plus le budgétiser.

Un fournisseur qui accepte les cinq conditions est susceptible de tenir ses engagements. Celui qui en reporte trois à une « phase d'analyse ultérieure » laisse présager des dépassements de coûts.

Le test de lundi

Avant de signer, il est conseillé de faire un exercice mental spécifique : décrire le lundi matin.

Un employé, disposant des autorisations nécessaires, ouvre le système et traite le premier dossier de la journée. Ce dossier contient des informations erronées, le client a un ticket d'assistance ouvert et un accord commercial conclu par téléphone n'est enregistré dans aucun système.

Les questions auxquelles il faut répondre :

  1. Que voit cette personne ?
  2. Que fait le système avec les données mal orthographiées ?
  3. Comment se renseigner sur l'incident en cours ?
  4. Qu’en est-il des personnes sans papiers ?
  5. Si le système suggère une information incorrecte, comment est-elle détectée et qui la corrige ?

Si le projet ne peut pas répondre aux cinq questions, il n'est pas prêt pour la production, aussi réussie soit la démo. C'est le même diagnostic que nous avions posé dans… le purgatoire du pilote [lien interne], appliqué avant l'achat et non après.

Pourquoi le pilote ne suffit pas non plus

Un projet pilote est préférable à une démo, mais il partage une partie du problème : il est mené avec des utilisateurs volontaires, avec une attention particulière de l’équipe, et sur un sous-ensemble favorable.

Les trois éléments qui font d'un rapport de pilote une information fiable :

De vrais utilisateurs, pas des passionnés. Ceux qui seront tenus de l'utiliser, et non ceux qui se sont inscrits.

Cas consécutifs et non sélectionnés. Tous les cas d'une semaine, y compris les plus sordides.

Sans soutien extraordinaire. Si, pendant la phase pilote, un ingénieur est attentif à chaque incident, le pilote mesure le système en plus de l'ingénieur.

Un programme pilote conçu de cette manière peut donner de moins bons résultats qu'un programme plus complaisant. Ces résultats moins bons sont les vrais, et les connaître avant de passer à l'échelle supérieure est bien plus précieux qu'un rapport optimiste.

Ce que cela signifie pour l'acheteur

La conclusion pratique est simple et permet d'économiser beaucoup d'argent : Le critère d'achat ne devrait pas être la qualité de la démonstration, mais la capacité du fournisseur à expliquer les lacunes de son produit..

Un fournisseur qui décrit avec précision ses limitations, les cas d'utilisation non pris en charge et la gestion des données corrompues prouve qu'il a exploité le système en conditions réelles. Un fournisseur qui prétend que tout fonctionne n'a même pas encore atteint le stade de la production.

Foire aux questions

Pourquoi une version de démonstration d'un logiciel fonctionne-t-elle alors que la version de production échoue ?

La démonstration utilise des données sélectionnées et complètes, un utilisateur disposant de tous les droits, un faible volume de données, aucune exception et aucune intégration réelle avec les systèmes existants. Aucune de ces conditions n'est réunie en production et aucune ne peut être déduite de l'observation de la démonstration.

Cinq points essentiels : l’outil utilise vos propres données, même si elles sont peu nombreuses ; il inclut un cas rare que vous avez choisi ; il est géré par un membre de votre équipe et non par l’équipe commerciale ; il montre ce qui se passe en cas d’échec ; et il calcule le coût par cas en fonction de votre volume réel, y compris les nouvelles tentatives.

Un exercice d'évaluation consiste à décrire le premier scénario concret, un lundi matin : un employé, avec son profil d'autorisations, traite un dossier contenant des données erronées, un client ayant un problème en cours et une condition convenue verbalement. Si la situation ne peut être décrite, le système n'est pas prêt.

Uniquement si elle est bien conçue. Elle doit être testée avec de vrais utilisateurs, et non des volontaires enthousiastes, sur des cas consécutifs et non sélectionnés, et sans soutien exceptionnel de l'équipe technique. Autrement, elle ne mesure que le système et les conditions favorables qui l'entourent.

S&P Global Market Intelligence a rapporté en mars 2025 que les entreprises abandonnaient en moyenne 461 TP3 000 de leurs projets de validation de concept et que 421 TP3 000 avaient abandonné la plupart de leurs initiatives en matière d'IA par rapport à 171 TP3 000 l'année précédente.

Ce n'est pas tant la qualité de la démonstration qui compte, mais la précision avec laquelle le fournisseur explique les limites de son produit : les cas d'utilisation non pris en charge, son comportement avec des données incomplètes et les conséquences d'une panne. Cette capacité témoigne d'une véritable expérience en production.

Allez-vous évaluer les fournisseurs ? Nous pouvons définir les critères, concevoir le test avec vos données et évaluer les offres selon des critères techniques indépendants, sans nous présenter comme candidats. Parlons-en →

Projet d'intelligence artificielle passant d'une démonstration à un environnement de production réel
Évaluation stratégique du moment opportun pour utiliser l'intelligence artificielle dans une entreprise
Risque de fuite de données confidentielles via l'intelligence artificielle