Comment évaluer la démo d'une agence IA avant de signer

La démo d'une agence IA prouve exactement une chose : le système fonctionne sur les données que l'agence a choisi de vous montrer. Cela ne prouve pas qu'il fonctionnera avec vos données, vos cas limites ou vos utilisateurs à 2 h du matin. Avant de signer, vous devez remplacer leurs données par les vôtres, examiner les échecs plutôt que les succès, et faire inscrire le jeu de tests dans le contrat.

C'est encore plus important pour les projets IA que pour les logiciels classiques. Une application CRUD enregistre la donnée ou ne l'enregistre pas, point final. Un agent propulsé par un LLM peut sembler parfait sur cinquante exemples soigneusement sélectionnés, puis produire des résultats erronés en toute confiance sur le cinquante et unième. Un fondateur incapable de distinguer une démo biaisée d'un système robuste achète sur la foi.

Pourquoi les démos IA sont si faciles à falsifier, même sans le vouloir

Nul n'a besoin d'être malhonnête pour qu'une démo vous induise en erreur. Trois phénomènes se produisent naturellement :

• Les exemples sont triés sur le volet. L'équipe a construit le prototype sur un nombre limité de données, et ce sont précisément celles qui fonctionnent qu'elle vous présente. Si le jeu de démo comprend dix enregistrements propres et bien formatés alors que votre vraie boîte de réception est remplie de tickets de support en deux langues et sans ponctuation, vous regardez un produit différent de celui pour lequel vous allez payer.
• Les échecs sont filtrés avant que vous les voyiez. Un article récent qui a circulé décrivait un benchmark qui attribuait un score parfait de 1,00 à un modèle parce que le système avait silencieusement ignoré les trois questions auxquelles le modèle avait échoué. La même chose se produit dans les démos : une boucle de réessai, un repli sur une réponse préenregistrée ou une ligne discrètement abandonnée masquent les erreurs. Un score de « 98 % » sans dénominateur ni liste des échecs, c'est le même tour de passe-passe dans une police plus élégante.
• Le système est réglé pour la démo, pas pour la production. Température basse, fenêtre de contexte surdimensionnée bourrée de vos documents exacts, pré-nettoyage manuel des données en entrée. Rien de tout cela ne résiste au contact du trafic réel et des coûts réels. Le contexte surdimensionné est particulièrement révélateur : il donne l'impression que chaque réponse est bien ancrée, tout en multipliant discrètement le coût en tokens par requête, dont vous entendrez parler plus tard.

Rien de tout cela n'est malveillant. Mais c'est à vous de voir au-delà.

Apportez vos propres données

La chose la plus utile que vous puissiez faire est de vous présenter avec vos propres données. Pas une description de vos données — les enregistrements réels.

Extrayez 20 à 50 exemples réels du flux de travail que l'agent devra gérer. Incluez délibérément les cas difficiles :

• Un ticket de support rédigé en deux langues, sans ponctuation
• Un PDF scanné dont le tableau est légèrement de travers
• Un formulaire de prospect où le champ « entreprise » indique « n/a » et le numéro de téléphone se trouve dans le champ e-mail
• Deux enregistrements qui ressemblent à des doublons mais n'en sont pas
• Un message demandant quelque chose que l'agent devrait refuser ou escalader

Demandez ensuite à l'agence de les traiter en direct, devant vous, et de vous montrer chaque résultat. Pas un taux de précision. Les résultats bruts, côte à côte avec les données en entrée.

Si elle vous demande une semaine pour « préparer l'environnement », c'est également une information utile. Un système qui a besoin d'une semaine de préparation pour traiter 30 de vos enregistrements est un système qui en aura besoin pour chaque nouveau segment de clients que vous ajouterez.

Demandez à voir les échecs

Inversez le script habituel de démo. Au lieu de « montrez-moi comment ça fonctionne », demandez :

• « Montrez-moi les cinq dernières entrées pour lesquelles le système a donné une mauvaise réponse. » Une équipe sérieuse les a. Elle tient un journal des échecs, car c'est ainsi qu'on améliore un système LLM. Une équipe sans échecs à montrer n'a soit pas testé, soit ne vous dit pas tout.
• « Que fait le système quand le modèle se trompe ? » La réponse honnête implique de la validation, des seuils de confiance et un transfert vers un humain. La réponse inquiétante est : « ça arrive rarement ». Tout modèle se trompe dans un certain pourcentage de cas ; la question de conception est de savoir ce qui se passe ensuite. Nous avons abordé ces modèles dans les garde-fous déterministes pour les fonctionnalités IA.
• « Comment savez-vous que le système n'a pas régressé après une modification de prompt ? » Vous cherchez à entendre le mot evals : un ensemble fixe de données en entrée avec les résultats attendus, qui s'exécute à chaque modification. S'ils n'en ont pas, c'est vous qui serez le jeu d'évaluation, en production.

Demandez ce qui tourne réellement

Une démo masque l'architecture, et c'est l'architecture pour laquelle vous allez payer au cours des deux prochaines années. Demandez-leur de parcourir le cheminement d'une requête de bout en bout :

1. Quel est le modèle, et s'agit-il d'une API fournisseur ou d'un modèle auto-hébergé ?
2. Combien d'appels de modèle par entrée, et combien de temps prend le plus lent ?
3. Quel retrieval est effectué, sur quels documents, mis à jour à quelle fréquence ?
4. Qu'est-ce qui est du code déterministe et qu'est-ce qui est laissé au modèle ?
5. Quel est le coût d'une entrée en tokens, et à quoi cela ressemble-t-il pour votre volume mensuel attendu ?

Soyez particulièrement attentif au théâtre de la complexité. Les agences présentent parfois un pipeline à cinq agents avec planificateurs, critiques et orchestrateurs parce que c'est impressionnant sur une diapositive. Dans notre propre outillage de prospection — où nous scrapons le site de chaque prospect et demandons à un modèle local de rédiger un e-mail personnalisé — la version qui extrayait les faits et rédigeait le brouillon en un seul appel surpassait la chaîne en plusieurs étapes, tant sur le coût que sur la qualité des résultats. Chaque étape supplémentaire était une occasion de plus pour le pipeline de perdre le contexte ou d'halluciner une transition entre les étapes. Nous avons détaillé ces compromis dans appel unique vs chaînes d'agents.

La simplicité n'est pas automatiquement meilleure, mais une équipe capable d'expliquer pourquoi chaque composant existe est une équipe qui comprend le système. Une équipe qui ne le peut pas maintient quelque chose qu'elle a hérité d'un tutoriel.

Vérifiez la feuille de route de production, pas seulement le prototype

L'écart entre une démo et un système déployé est là où la plupart des projets IA échouent. La bonne nouvelle, c'est que les 30 enregistrements que vous avez apportés et le parcours de requête que vous venez d'examiner vous donnent tout ce qu'il vous faut pour rendre ces questions concrètes plutôt qu'hypothétiques :

• À qui appartiennent les prompts et le jeu d'évaluation après le lancement ? À vous. Le jeu d'évaluation, ce sont vos 30 enregistrements plus chaque échec qu'ils vous ont montré, avec les résultats corrects convenus. Assurez-vous qu'il figure nommément dans les livrables, et pas seulement décrit comme « documentation ».
• Que se passe-t-il quand le fournisseur du modèle déprécie la version sur laquelle vous avez testé ? Les fournisseurs retirent les modèles selon un calendrier. La réponse que vous voulez entendre : « Nous remplaçons le modèle, relançons le jeu d'acceptation et vous montrons le diff. » Si relancer le jeu n'est pas une opération en une seule commande, demandez pourquoi.
• Comment le coût est-il plafonné ? Prenez le coût en tokens par entrée issu du parcours de requête, multipliez par votre volume mensuel, et demandez ce qui empêche la facture d'être dix fois plus élevée. Une boucle de réessai incontrôlée ou un spam contre un endpoint non protégé vous le feront découvrir à vos dépens. Les limites de débit et les budgets par utilisateur doivent faire partie du build, pas d'une phase ultérieure.
• Qu'est-ce qui est monitoré ? Au minimum : latence, taux d'erreur, taux de repli et un échantillonnage de contrôle qualité. Le taux de repli est celui à surveiller. C'est la version production de « que se passe-t-il quand le modèle se trompe », et s'il grimpe de 5 % à 20 % après un changement de prompt, c'est votre signal de régression. Si leur réponse est « on ajoutera du logging », ils n'ont encore jamais mis en production un système de ce type.
• À quoi ressemble le troisième mois ? De nouveaux cas limites apparaissent, le jeu d'évaluation s'étoffe, un prompt est ajusté, un modèle est mis à jour. Qui relance le jeu à chaque fois, et quel en est le coût mensuel ?

Une équipe qui a conduit des agents du pilote à la production répondra à ces questions sans hésiter, parce qu'elle s'est déjà brûlée sur chacune d'elles. Notre guide du pilote à la production liste les modes d'échec les plus fréquents que nous observons.

Inscrivez le jeu de tests dans le contrat

Voici ce qui distingue un engagement plein d'espoir d'un engagement sécurisé. Prenez les données que vous avez apportées à la démo, convenez de ce qu'est un résultat correct pour chacune, et inscrivez-les dans le cahier des charges comme test d'acceptation.

Cela accomplit trois choses simultanément. Cela oblige les deux parties à définir concrètement ce que « fonctionner » signifie avant que l'argent ne change de mains. Cela donne à l'agence une cible qu'elle peut réellement atteindre, ce que les bonnes agences apprécient. Et cela vous donne une suite de régression que vous continuerez à utiliser tout au long de la vie du produit.

Convenez d'un seuil, pas de la perfection. Quelque chose comme « au moins 90 % du jeu d'acceptation correct, zéro résultat dans la catégorie non sûre, et chaque résultat incorrect acheminé vers une révision humaine » est réaliste pour la plupart des flux documentaires et commerciaux. Cent pour cent est le signe que personne n'a réfléchi au chemin d'échec.

Une courte liste de contrôle pour la réunion

Présentez-vous avec ceci et vous apprendrez davantage en une heure qu'en trois pitchs soignés :

• Traiter mes 30 données réelles en direct, montrer chaque résultat
• Me montrer cinq échecs récents et ce que vous avez changé suite à ceux-ci
• Me guider à travers une requête de bout en bout : modèles, appels, retrieval, coût
• Que se passe-t-il quand le modèle se trompe ?
• À qui appartiennent les prompts, les evals et le monitoring après le lancement, et quel est le coût au troisième mois ?
• Êtes-vous prêts à inscrire le jeu d'acceptation et le seuil dans le contrat ?

Une agence qui accueille favorablement ces questions est une agence avec laquelle vous pouvez travailler. Celle qui les perçoit comme hostiles vous indique comment le projet se déroulera.

Si vous évaluez actuellement des partenaires IA et souhaitez un second avis sur une proposition, ou si vous voulez voir comment nous traiterions vos 30 enregistrements les plus complexes, parlons-en.