La démo marche, le projet s'arrête

Le schéma se répète tellement qu’on peut le raconter à l’avance.

Quelqu’un montre un outil qui répond à des questions sur les documents de l’entreprise. La salle est impressionnée. On décide de le déployer. Trois mois plus tard, personne ne l’utilise, et l’entreprise conclut que « l’IA n’est pas encore mûre ».

Ce n’est presque jamais le modèle qui a échoué. C’est le passage de la démo au service quotidien, et il achoppe sur trois choses qu’une démo ne montre jamais.

Les vingt pour cent de cas particuliers

Une démo se fait sur des cas choisis. Le travail réel arrive avec les autres : la pièce jointe illisible, le client qui pose trois questions dans un même message, le dossier qui référence un accord commercial négocié à l’oral en 2019.

Un outil qui traite bien quatre-vingts pour cent des cas et se plante sur le reste, sans prévenir, est plus coûteux que pas d’outil du tout. Vos équipes doivent alors relire cent pour cent des sorties pour attraper les vingt, et le temps gagné disparaît.

La question à poser n’est donc pas « est-ce que ça marche ? » mais « est-ce que ça sait quand ça ne sait pas ? ». Un agent utilisable détecte ses propres limites et passe la main. C’est du travail d’ingénierie, ce n’est pas une option de configuration, et c’est ce qui sépare une démo d’un outil.

Les droits d’accès

En démo, l’outil voit tous les documents. En service, il répond à une personne précise, qui n’a pas le droit de tout voir.

Si votre agent de support peut lire la base RH, vous avez créé une fuite de données interne, avec une interface conversationnelle bien pratique pour l’exploiter. Ce n’est pas théorique : c’est la raison la plus fréquente pour laquelle un projet est arrêté par la DSI juste avant le déploiement.

Un agent doit agir avec les droits de la personne pour qui il travaille, et pas plus. Ça se conçoit au départ. Ça se rajoute très mal après.

La reprise en main

Le troisième point est humain. Un outil déposé sur le bureau de quelqu’un qui n’a pas participé à sa construction ne sera pas utilisé, même s’il est bon. Surtout s’il est bon, parce que la personne se demandera ce qu’il reste de son travail.

C’est pour ça qu’on construit avec les personnes concernées, pas pour elles. Elles savent où sont les cas tordus, elles savent quelles réponses passent mal auprès des clients, et elles savent quelles règles ne sont écrites nulle part. Ces trois savoirs sont exactement ce qui manque à un projet mené depuis une salle de réunion.

Ce qu’on en tire

Une démo se fait en un après-midi. Un agent en service se fait en deux à quatre semaines, et la différence entre les deux n’est pas de la puissance de calcul : ce sont les cas particuliers, les droits, et les gens.

C’est aussi pour ça qu’on préfère commencer petit. Une tâche, mesurée, en service. Le reste vient après, et il vient plus vite, parce que la deuxième fois l’entreprise sait ce qu’elle achète.