La démonstration fonctionne toujours : comment distinguer un vrai système d'IA d'un simulé.

Apportez votre propre entrée

La chose la plus utile que vous puissiez faire lors d'une réunion avec un fournisseur est de prendre le clavier. Remettez au système un document provenant de votre propre entreprise : un contrat désordonné, une conversation de support entre trois personnes qui se parlent dessus, une facture du pire fournisseur en termes de mise en forme. Demandez-leur de l'exécuter en direct, sans préparation.

Observez les changements. Temps de réponse, hésitations, mise en forme, confiance de la réponse. Un système qui reste stable face à une entrée non préparée a rencontré le monde réel au moins une fois.

Si le fournisseur refuse, demandez pourquoi. « Vos données ne sont pas chargées dans l'environnement de test » est une réponse acceptable. Acceptez-la, puis formulez ce test par écrit comme une condition avant de signer, avec vos fichiers et votre définition d'un résultat positif.

Demandez ce qui se passe quand c'est faux

Ignorez pendant un instant le pourcentage de précision et interrogez-vous sur le reste. Si le système a raison 92 % du temps, que ressemble l'autre 8 % du temps depuis le point de vue de l'utilisateur ? Il n'y a que trois options : il dit ne pas savoir, il escalade à une personne, ou il produit une réponse sûre et fausse.

Les systèmes qui échouent bruyamment sont faciles à gérer. Les systèmes qui échouent silencieusement sont coûteux, car le coût retombe sur le client qui a agi sur des informations erronées et l'employé qui passe une semaine à défaire le gâchis.

Ensuite, demandez de voir un cas où le système a refusé de répondre. Les équipes ayant un produit opérationnel montrent généralement ces cas avec fierté, car la retenue est la partie la plus difficile à construire.

Demandez d'où vient la réponse

Tout ce qui concerne votre matériel propre - politiques, prix, contrats, spécifications de produits - devrait citer sa source. Demandez une citation, puis ouvrez-la. La question n'est pas de savoir si un lien est apparu. Il s'agit de savoir si le document cité dit réellement ce que la réponse affirme.

Faites cela deux fois. Deux vérifications vous diront plus sur un système qu'une heure de présentations.

Demandez-leur comment ils gèrent les changements de données

Les démonstrations se basent sur une capture instantanée gelée. Votre entreprise ne l'est pas. Ces questions distinguent un produit d'un prototype :

Comment les nouvelles ou les informations corrigées entrent-elles, avec quelle fréquence et quel est le rôle de qui ?
Lorsqu'un document est supprimé ou remplacé, combien de temps faut-il avant que le système cesse de l'utiliser ?
Le système respecte-t-il vos permissions existantes, ou tout le monde reçoit-il les mêmes réponses indépendamment du rôle ?
Lorsque le modèle sous-jacent change, avez-vous la possibilité de tester avant qu'il n'atteigne vos utilisateurs ?
Qui est en service lorsque cela casse un lundi à neuf heures, et quel est le temps de réponse ?

Les réponses vagues à ces questions sont le signal le plus fort que vous recevrez pendant toute la réunion. Une équipe qui a fait fonctionner quelque chose en production a vécu toutes ces cinq situations.

Demandez des chiffres qui coûtent cher à produire

Les pourcentages sur une diapositive sont gratuits. Demandez des chiffres avec une forme : combien d'utilisateurs, sur combien de mois, par rapport à quelle référence, et qui les a mesurés ? « Résout 60 % des tickets de niveau un » signifie peu de choses tant que vous ne savez pas ce que les 40 % restants coûtent en redirigeant, et si ce chiffre provient d'un pilote avec dix personnes ou d'une année avec mille.

De bons fournisseurs répondent avec des spécificités et des réserves. Une équipe confiante a cette réponse prête et elle est généralement précise : longs documents sous forme numérisée, langues en dehors de leur ensemble d'évaluation, tout ce qui nécessite un jugement avec une exposition légale.

Demandez ce qu'il ne peut pas faire

Demandez au fournisseur de décrire les cas d'utilisation où leur système est un mauvais ajustement. Une équipe confiante a cette réponse prête et elle est généralement précise : longs documents sous forme numérisée, langues en dehors de leur ensemble d'évaluation, tout ce qui nécessite un jugement avec une exposition légale.

Une équipe qui dit qu'il gère tout vous indique qu'ils n'ont pas encore fait fonctionner le système assez dur pour trouver les limites. Vous les trouverez plutôt après la signature du contrat.

La dernière question

Avant de partir, demandez à voir ce qu'un client existant voit un mardi ordinaire. Pas la démonstration : le tableau de bord, les journaux, la file d'attente des cas escaladés, le rapport que quelqu'un lit le vendredi matin. Les systèmes réels accumulent cette infrastructure peu glamour parce que quelqu'un a dû les faire fonctionner. Une démonstration répétée n'a pas de mardi.

Nous nous asseyons souvent du côté de l'acheteur et le schéma se répète : les systèmes qui survivent à ces questions sont rarement impressionnants lors d'une démonstration. Ils semblent ennuyeux, spécifiques et instrumentés. C'est ce que ressemble le travail.