Un fournisseur te montre une démo. Elle lit des factures, trie des e-mails ou répond à des demandes clients, selon ton besoin. Elle est impeccable : rapide, propre, pas une seule erreur. Tu signes, vous la branchez sur ton activité réelle, et trois semaines plus tard quelqu’un de l’équipe te dit qu’on ne peut pas lui faire confiance. Le fournisseur jure que c’est le même produit. Il a raison, et c’est exactement le problème : entre la démo et la production, ce n’est pas le système qui a changé, c’est la matière sur laquelle on l’a testé.
La thèse en une ligne : la démo n’échoue pas par mauvaise foi, elle échoue par sélection de l’échantillon. Les documents que tu as envoyés étaient les propres, les tickets étaient les bien rédigés, et les cas qui font tomber ton business case n’y sont jamais entrés. Ce que tu as vu n’était pas un test, c’était une répétition.
Pourquoi la démo d’IA ne ressemble pas à la production
Parce que quelqu’un a choisi les cas. Presque toujours toi, avec les meilleures intentions du monde. On te demande des exemples pour l’essai et tu envoies ce que tu as sous la main : les documents bien scannés, les tickets écrits en phrases complètes, les clients qui suivent le processus exactement comme tu l’as dessiné sur le papier. Avec ça, n’importe quel système raisonnable fait bonne figure. Et le fournisseur s’en sert pour se préparer : il ajuste le prompt, affine les règles, règle les bizarreries qui apparaissent. Quand la démo arrive, le système a déjà vu le sujet de l’examen.
La production, ce n’est pas cet échantillon. C’est toute la distribution, avec ses queues : le scan de travers, l’e-mail de trois lignes sans contexte, le client avec deux raisons sociales, la facture rectificative qui tombe un vendredi après-midi. Un système évalué seulement sur la partie facile de la distribution n’est pas éprouvé, il est répété. C’est la même logique qui explique pourquoi un taux de réussite ne suffit pas en production : le chiffre dépend des cas qu’on met dans le calcul.
Ce qu’une démo laisse de côté, et pourquoi c’est précisément ce qui coûte de l’argent
- Les documents moches. Photos prises au téléphone, PDF scannés à l’envers, tableaux coupés entre deux pages, formats d’il y a cinq ans que personne n’a jamais retirés.
- Les messages mal écrits. Phrases à moitié finies, deux langues dans le même e-mail, références à une conversation précédente que le système n’a pas.
- Les exceptions du métier. Le client aux conditions spéciales, la commande qui mélange deux grilles tarifaires, le cas que seule connaît la personne en poste depuis dix ans.
- Le rare et l’hostile. Entrées vides, doublons, pièces jointes qui ne sont pas ce qu’elles prétendent, quelqu’un qui teste les limites du système.
Il y a pire que la fréquence : les cas rares ne coûtent pas la même chose que les cas ordinaires. Une erreur sur un ticket simple se corrige en une minute. Une erreur sur la facture d’un gros client, ou dans la réponse qui arrive à la direction, se paie en confiance. Voilà pourquoi une démo parfaite sur les cas faciles dit très peu du coût réel de la mise en route.
Le chiffre qui compte n’est pas la moyenne, c’est la mauvaise queue
Si on te dit que le système réussit « presque toujours », demande : sur quoi ? Une moyenne élevée peut cacher que les cas faciles passent presque tous et les difficiles presque tous à côté, alors que ton business case repose sur les difficiles. Si le processus se justifie parce que quelqu’un perd aujourd’hui des heures sur les exceptions, un système qui résout ce qui était déjà facile ne t’économise rien. Regarde le pire tronçon : ce qui se passe avec les cas les plus compliqués, quelles erreurs il commet et à quelle fréquence, lesquelles il détecte seul et lesquelles arrivent jusqu’au client. C’est ce qu’exige dès le premier jour la mesure de la performance de tes automatisations.
Que demander à la place d’une démo : une méthode d’achat en cinq étapes
- Un échantillon aléatoire, choisi par toi. Prends les derniers cas réels d’une période, sans filtrer ni nettoyer, et ne les montre pas au fournisseur avant l’essai. S’il les choisit, on revient au point de départ.
- Avec les cas rares dedans. Ajoute à la main ceux qui te font le plus mal : ceux qui ont escaladé, ceux qui ont fini en réclamation, ceux que seule une personne de l’équipe sait résoudre.
- Le critère avant de voir le résultat. Décide par écrit quelle erreur est acceptable pour chaque type de cas et laquelle ne l’est jamais. Si tu fixes la barre après, tu finis par défendre ce que tu as déjà vu.
- Lis les échecs, pas seulement le pourcentage. Passe en revue à la main les cas qui échouent. Des erreurs réparties au hasard et des erreurs toujours concentrées sur le même type de client sont deux problèmes différents, même avec le même pourcentage.
- Teste avec tes données, dans ton environnement. Avec tes droits, tes formats et tes systèmes connectés. Une évaluation de la qualité des agents d’IA existe justement pour rejouer ce test à chaque changement, pas seulement avant d’acheter.
Quand la démo sert vraiment
Tout n’est pas défiance. Une démo est utile pour voir si l’interface colle à la façon de travailler de ton équipe, si les intégrations existent pour de vrai et si le flux tient debout. Elle suffit aussi quand le coût d’une erreur est faible et réversible : un brouillon qu’une personne relit avant l’envoi n’a pas besoin d’un protocole d’évaluation. La démo répond à « est-ce faisable ? ». Elle ne répond pas à « est-ce que ça tient dans mon activité ? », qui est pourtant la question pour laquelle on signe.
Ce qu’il faut lire dans la réaction du fournisseur
Quand tu proposes l’essai avec échantillon aléatoire et cas difficiles, la réaction t’en dit plus que la démo. Un fournisseur sérieux accepte, t’aide à le concevoir et te montre les échecs avec les réussites. Celui qui se met à négocier l’échantillon, à demander « un cas représentatif » ou à changer le critère de réussite vient de te montrer à quoi ressemblera la relation le jour où quelque chose casse en production.
Si tu compares plusieurs options, comment choisir un outil d’automatisation par IA te donne le reste des critères. Et si tu as déjà vécu un pilote brillant qui n’est jamais arrivé en production, la démo n’est pas le projet raconte ce qui vient après la signature.
La phrase à retenir : une démo ne prouve pas que le système marche, elle prouve qu’il existe un ensemble de cas pour lesquels il marche. Ton travail, avant de signer, est de découvrir quels cas ne sont pas dans cet ensemble.