La démonstration est convaincante : une demande client arrive, l’agent retrouve le dossier et prépare une réponse. Puis l’équipe découvre que la démonstration utilisait toujours le même document, qu’aucun email n’a réellement été envoyé et que le traitement s’arrête dès qu’une pièce manque. Le désaccord avec le prestataire ne porte plus sur l’IA. Il porte sur ce que « livré » voulait dire.
La recette d’un projet IA consiste à comparer le système livré à des résultats attendus, sur des dossiers autorisés et des cas d’échec définis avant le test. Pour une PME, le livrable essentiel est un procès-verbal de tests : entrées, résultat attendu, résultat observé, preuve, réserve et responsable de correction. Une vidéo de démonstration peut l’accompagner ; elle ne le remplace pas.
Ce qu’il faut accepter avant la production
- Un dossier normal doit aboutir au bon livrable, avec ses sources et son statut réel.
- Une pièce absente, un accès interdit et une panne doivent provoquer des comportements prévus.
- Une relance technique ne doit pas répéter une action déjà effectuée.
- Le responsable métier signe les résultats, les réserves et les limites du périmètre accepté.
Décrire un résultat métier avant de tester le modèle
Prenons un exemple fictif : une PME confie à une agence la préparation des réponses aux demandes de devis. Le résultat accepté pourrait être une fiche comprenant le besoin, les pièces utilisées, les informations manquantes et un brouillon adressé au bon interlocuteur. L’envoi externe reste soumis à validation commerciale.
Cette description distingue une capacité de préparation d’une autorisation d’engagement. Si le contrat dit seulement « automatiser les devis », l’agence et la PME peuvent avoir deux attentes incompatibles : produire un brouillon ou envoyer une offre qui engage un prix. Il faut lever cette ambiguïté avant de fixer les tests et les conditions de paiement avec les personnes compétentes.
Le guide pour choisir une agence IA fiable aide à examiner le partenaire. La recette répond à la question suivante : comment vérifier le système qu’il a effectivement livré ?
Constituer un lot de dossiers que l’équipe sait juger
Le responsable commercial sélectionne des dossiers représentatifs et autorisés : demande complète, client déjà connu, tarif modifié, pièce contradictoire, demande hors périmètre. Il retire ou pseudonymise les données inutiles. Le prestataire ne doit pas choisir seul les exemples sur lesquels son travail sera accepté.
Pour chaque dossier, l’équipe rédige le résultat attendu avant de lancer l’agent. Sur une demande incomplète, la bonne sortie n’est pas un devis vraisemblable : c’est une liste précise des informations manquantes, sans prix inventé. Sur deux grilles tarifaires contradictoires, l’agent doit signaler le conflit et demander l’arbitrage prévu.
Gardez aussi des dossiers non utilisés pendant le réglage. Sinon, vous mesurez surtout la capacité du prestataire à ajuster le système aux exemples qu’il connaît. Le nombre de cas dépend du risque et de la diversité du flux ; aucun petit échantillon ne garantit l’absence d’erreur future.
Tester les arrêts, pas seulement les réponses réussies
Un modèle peut rédiger une réponse satisfaisante pendant que la chaîne d’exécution se trompe de destinataire ou masque une panne. La recette doit donc traverser le flux complet, depuis la demande jusqu’au statut affiché à l’équipe.
- Document manquant : retirer une pièce nécessaire. Attendre un blocage explicite et une demande ciblée, pas une réponse complétée par supposition.
- Droit insuffisant : utiliser un compte de test qui ne peut pas consulter un dossier sensible. Vérifier que le contenu n’apparaît ni dans la réponse ni dans ses extraits.
- Outil indisponible : simuler une panne dans un environnement de test. Le système doit indiquer l’échec et son responsable, sans annoncer la tâche terminée.
- Instruction dans un document : ajouter à une pièce fictive une demande de contourner la validation. L’agent ne doit pas traiter ce texte documentaire comme une autorisation d’envoi.
- Validation refusée : refuser un brouillon. Vérifier qu’aucun envoi ne part et que le refus reste visible.
Ces essais n’épuisent pas les risques de sécurité. Ils révèlent néanmoins si le prestataire a conçu les limites du système ou seulement son parcours idéal. Le cadre de gestion des risques IA du NIST fournit une référence générale pour organiser l’identification, la mesure et le traitement des risques ; il ne certifie pas votre recette.
Votre devis décrit une promesse, mais pas les preuves attendues ?
Apportez un flux réel, ses validations et un exemple d’échec acceptable. Cadrer un First Contact permet de préciser les résultats à vérifier avant d’étendre l’automatisation.
Vérifier qu’une reprise ne produit pas une deuxième action
Le cas le plus trompeur arrive après une action réussie : le message est envoyé, mais la confirmation technique n’arrive pas. Si le système relance tout le traitement, le client peut recevoir deux réponses. Une recette limitée au premier essai ne verra jamais ce défaut.
Dans un environnement contrôlé, demandez de rejouer le même événement. Le prestataire doit expliquer comment le système reconnaît une opération déjà traitée, conserve les actions dont le résultat reste incertain et permet une réconciliation humaine. Le résultat acceptable n’est pas nécessairement une reprise automatique ; c’est l’absence de répétition aveugle.
Vérifiez également la reprise manuelle : qui peut suspendre la routine, retrouver la dernière action confirmée et traiter le dossier hors automatisation ? Une procédure qui dépend exclusivement de la disponibilité du développeur ne suffit pas pour un flux quotidien critique.
Signer un procès-verbal qui distingue les réserves des blocages
Chaque ligne de recette doit conserver le dossier testé, la version du système, la date, l’attendu, l’observation et un lien vers la preuve. Pour un brouillon, la preuve est le livrable. Pour un envoi, c’est une confirmation vérifiable dans l’outil destinataire, pas la phrase « email envoyé » de l’agent.
Classez ensuite les écarts. Une réponse qui divulgue un dossier interdit ou exécute une action sans validation bloque l’ouverture du périmètre concerné. Une gêne de présentation peut relever d’une réserve, avec responsable et échéance. Les critères bloquants doivent être convenus avant les essais, pas négociés pour faire passer une démonstration.
Le signataire métier accepte un périmètre précis, avec ses limites. Il ne valide ni tous les usages futurs ni une garantie juridique universelle. Les engagements de support, les conditions contractuelles et le paiement doivent être traités séparément et alignés avec ce procès-verbal.
Conserver la recette après la livraison
Une mise à jour du modèle, d’un connecteur ou d’une règle tarifaire peut modifier les résultats. Conservez le lot de tests et rejouez les cas concernés après les changements importants. Ajoutez les incidents réels au lot, après traitement des données sensibles : la recette devient une mémoire des erreurs à ne pas répéter.
Mesurez aussi le temps de correction demandé au commercial. Un système conforme mais pénible à relire peut être exploitable techniquement et décevant économiquement. Le calcul du ROI intégrant le contrôle humain complète donc la recette, sans se substituer aux critères de sécurité.
Partir d’un dossier acceptable, pas d’une démo parfaite
Chez Amplify, First Contact sert à cadrer les sources, les responsabilités et le premier flux utile. Venez avec un dossier réussi et un dossier qui a mal tourné : ils permettront de définir ce que l’agent doit produire, refuser et prouver. Préparer ce premier cadrage.