Votre assistant IA commercial prépare une relance : « Je reviens vers vous, faute de réponse à mon précédent message. » Pourtant, le prospect a répondu hier. Vous devez corriger le brouillon et vérifier les autres recommandations. Avant d’ajouter un exemple au prompt, il faut retrouver ce qui a conduit à cette décision.
Prenons un scénario fictif. L’assistant IA commercial est ici notre exemple d’agent IA : il consulte le CRM, choisit une prochaine action et utilise les outils de l’application.
Le prospect a répondu : « Merci pour votre proposition. Pouvez-vous préciser le périmètre de l’accompagnement ? » La relance préparée ignore cette question. Si elle était envoyée, le commercial devrait rattraper un échange qui donne l’impression de ne pas avoir été lu.
L’équipe envisage d’ajouter cette instruction : « Ne proposez pas de relance lorsqu’un prospect a répondu. » Mais elle suppose que le dernier échange était accessible. Elle interdit aussi trop de choses : un prospect peut demander à être recontacté plus tard.
Pour ce scénario, définissons plutôt le comportement attendu : toute nouvelle réponse doit être examinée avant de proposer la prochaine action. Ici, il faut préparer une réponse à la question sur le périmètre.
Quatre questions pour situer l’erreur
Une mauvaise relance ne permet pas, à elle seule, de choisir une correction. Reprenez l’incident dans cet ordre :
- Le comportement attendu était-il explicite ? Si l’équipe ne s’accorde pas sur le traitement d’une réponse, elle doit d’abord préciser la règle commerciale.
- L’information nécessaire était-elle disponible ? Vérifiez que la réponse figurait bien dans le CRM au moment de la décision et qu’elle était accessible à l’application.
- A-t-elle été récupérée et transmise ? Une donnée présente dans le CRM peut manquer dans le contexte reçu par le modèle. Un appel omis, une erreur d’outil ou un résumé périmé suffisent à créer cet écart.
- La décision était-elle cohérente avec cette information ? Si la réponse a bien été reçue mais que la relance l’ignore, examinez son interprétation et les instructions appliquées.
Ces questions séparent une règle floue, une information absente, un défaut de récupération et une décision incohérente. Elles orientent l’enquête ; elles ne prouvent pas encore qu’une seule cause explique l’incident.
Sans traces, le diagnostic reste limité
Pour répondre, l’équipe doit pouvoir retrouver la demande, la version des instructions, les données reçues, les appels d’outils et leurs résultats. Reliez ces éléments à une même exécution et à son horaire. Une trace d’exécution sert précisément à suivre le parcours d’une requête dans l’application.
La question à poser au responsable technique devient concrète : « Est-ce qu’on conserve ce que l’agent a reçu et les actions qu’il a demandées pour cette décision ? » Le journal doit permettre de vérifier les étapes observables, avec des accès limités et les données sensibles masquées.
Un outil de traçage comme LangSmith peut regrouper les appels au modèle, les outils utilisés et leurs entrées et sorties. L’équipe doit configurer l’enregistrement dans l’application avant de pouvoir examiner ces étapes.
Si ces traces n’existent pas, il faut organiser une reproduction instrumentée, c’est-à-dire enregistrer ces éléments lors d’un nouvel essai. Elle permettra de tester une hypothèse, sans établir avec certitude ce qui s’est passé lors de l’incident initial. Voir une réponse dans le CRM aujourd’hui ne prouve pas qu’elle était disponible hier.
Choisir le levier adapté
Supposons que les traces révèlent un résumé périmé. La première correction consiste à fournir les échanges récents. Si les données étaient présentes mais mal interprétées, une instruction plus précise ou des exemples deviennent des pistes pertinentes.
Le tableau suivant prolonge ce diagnostic. Une information manquante oriente vers sa récupération ; une règle claire mais non respectée peut demander des exemples ou un contrôle applicatif, selon le comportement concerné.
| Cause identifiée | Levier à tester en priorité | Vérification utile |
|---|---|---|
| Deux intentions sont mal distinguées | Consigne explicite et exemples contrastés | La distinction tient sur de nouvelles formulations |
| Le format de sortie est incorrect | Schéma contraignant et validation | La structure est valide ; le contenu fait l’objet d’un contrôle distinct |
| Une règle vérifiable peut être contournée | Contrôle dans le code avant l’action | L’action interdite reste bloquée |
| Une information nécessaire manque ou est périmée | Lecture ciblée de la source de vérité | La bonne donnée arrive jusqu’au modèle |
| Une préférence utilisateur pertinente manque ou est mal sélectionnée | Préférence explicite ou mémoire adaptée à la tâche | Elle correspond à la demande actuelle |
| Une étape d’une opération complexe échoue | Découpage et outils adaptés | Le résultat de chaque étape est vérifiable |
Plusieurs leviers peuvent être nécessaires. La qualité des données aide à décider ; les contrôles de l’application déterminent ce qui peut être exécuté.
Contraindre le format sans confondre structure et justesse
Supposons que la prochaine action doive comporter un identifiant de contact, un type d’action et une justification. Si un champ manque régulièrement, un schéma de sortie contraignant est adapté.
Mais tous les champs peuvent être présents avec le mauvais contact ou une relance injustifiée. Les sorties structurées ne suppriment pas les erreurs de contenu. Vérifiez séparément la structure, l’existence du contact et la cohérence de l’action avec les échanges.
Protéger les règles au moment de l’action
Dans notre scénario, certains commerciaux pourraient avoir le droit d’envoyer des messages, tandis que d’autres ne pourraient préparer que des brouillons.
L’application doit refuser un envoi si l’utilisateur ne dispose pas de la permission nécessaire, même si le modèle le demande. Rappeler la règle dans le prompt peut guider le comportement ; le contrôle reste nécessaire à l’exécution.
La règle doit être suffisamment précise pour être vérifiée. « Ne faites rien de risqué » demande un jugement. « Cet utilisateur n’a pas le droit d’envoyer un message » peut être contrôlé à partir de ses permissions.
Fournir la préférence utile à cette réponse
Reprenons la question du prospect sur le périmètre. Le commercial préfère des messages courts pour les premiers contacts. Cette préférence a été enregistrée, puis injectée dans toutes les demandes de rédaction.
L’assistant IA pourrait alors préparer une réponse si brève qu’elle laisse les questions du prospect sans réponse. Les échanges ont été récupérés, mais le contexte contient une préférence appliquée à la mauvaise tâche.
Précisez sa portée : messages courts pour la prise de contact, réponse suffisamment détaillée lorsqu’un prospect demande des précisions. Une demande actuelle de brouillon détaillé doit aussi pouvoir primer sur une ancienne préférence de concision.
Découper l’opération pour repérer l’étape qui échoue
« Consultez les échanges, choisissez une action et préparez le message » peut être décomposé pour rendre chaque résultat vérifiable.
L’équipe peut alors constater que la lecture fonctionne, mais que le choix de l’action échoue. Ou que l’action est correcte, tandis que la rédaction oublie la question sur le périmètre.
Le découpage aide à localiser le problème. Si l’accès au CRM est défaillant, ajouter des étapes de rédaction ne le corrigera pas. Lorsque cette décomposition implique un choix d’architecture, la comparaison entre agents LLM et workflows IA permet d’aller plus loin.
Quand quelques exemples suffisent
Chaque incompréhension ne justifie pas un chantier technique.
Toujours avec le même prospect, le commercial demande : « Prépare une réponse à sa question sur le périmètre. » Le résultat attendu est un brouillon, sans envoi.
Après vérification, il demande : « Envoie ce brouillon au prospect. » L’application peut alors autoriser l’envoi si les permissions et les conditions métier sont respectées.
Si l’assistant IA confond ces intentions, quelques exemples contrastés peuvent aider à distinguer préparer et envoyer. Les recommandations d’Anthropic sur l’usage des exemples insistent sur leur pertinence et leur diversité.
Une demande comme « Tu peux répondre au prospect ? » peut rester ambiguë dans ce produit. Prévoyez alors une clarification ou un brouillon par défaut, selon la règle choisie par l’équipe.
Les exemples sont pertinents lorsque la difficulté concerne la compréhension du comportement attendu. Vérifiez ensuite la distinction sur des formulations absentes du prompt. Même bien comprise, une demande d’envoi reste soumise aux contrôles de l’application.
Vérifier l’état avant de proposer, puis avant d’exécuter
Revenons à la correction du résumé périmé. L’assistant IA reçoit désormais les échanges récents et prépare une réponse à la question sur le périmètre.
Cela traite le problème d’information au moment de la recommandation. Si le produit permet aussi l’envoi, une autre situation doit être prévue.
Le brouillon peut être préparé le matin, puis le prospect apporter une précision avant son envoi. Les informations utilisées pour rédiger étaient correctes. Elles ne suffisent plus à justifier l’action.
Avant l’envoi, l’application doit vérifier qu’aucun nouvel échange ne remet en cause le brouillon. Si une réponse est arrivée depuis la dernière lecture, elle doit suspendre cet envoi et demander un nouvel examen de la conversation.
Cette vérification protège une étape différente de la récupération initiale. Un correctif peut améliorer la recommandation tout en laissant un problème au moment de l’exécution.
Vérifier la correction sur des résultats attendus
Rejouer l’incident initial est nécessaire, mais une réussite isolée ne suffit pas. Précisez ce qui doit se passer dans chaque situation.
| Situation testée | Résultat attendu |
|---|---|
| Le prospect demande une précision sur le périmètre | Préparer une réponse à cette question |
| Le prospect n’a pas répondu et le délai de relance défini est écoulé | Proposer une relance |
| Le prospect demande à être recontacté plus tard | Proposer une action à la date demandée, sans relance immédiate |
| La préférence « messages courts au premier contact » est disponible | Ne pas l’appliquer au détriment de la réponse sur le périmètre |
| Le commercial demande de préparer une réponse | Créer un brouillon sans envoyer de message |
| Une réponse arrive après la préparation du brouillon | Suspendre l’envoi du brouillon et réexaminer l’échange |
| La lecture du CRM échoue | Signaler l’information indisponible et suspendre la décision qui en dépend |
Conservez des cas qui fonctionnaient déjà. Une correction supprimant toutes les relances ferait disparaître l’incident initial en rendant le produit moins utile.
Une même entrée peut aussi produire des résultats différents. Rejouez plusieurs fois les cas sensibles, dans des conditions comparables, pour repérer un comportement encore instable. Gardez des formulations nouvelles qui ne figurent pas dans les exemples du prompt.
L’équipe doit pouvoir présenter la cause retenue, la correction proposée, les résultats observés et les limites restantes. Le dirigeant dispose alors d’éléments pour décider si la correction mérite d’être livrée.
Ce qu’il faut retenir
Définissez le comportement attendu, puis vérifiez quelle information était disponible, ce qui a été transmis et la décision produite. Les traces rendent cette comparaison possible. Sans elles, une reproduction aide à tester des hypothèses, mais ne prouve pas le déroulement de l’incident passé.
Choisissez ensuite la correction adaptée : exemples pour une distinction mal comprise, données à jour pour une information manquante, contrôle applicatif pour une règle d’exécution. Validez son effet sur des cas nouveaux et sur les situations qui fonctionnaient déjà.
Conclusion
Lors de la prochaine erreur, demandez d’abord à votre équipe de vous montrer la règle attendue et la trace de l’exécution. Faites préciser la cause retenue et le résultat qui permettra de valider la correction.
Si les modifications de prompt s’accumulent sans que leurs effets soient compris, un échange de 30 minutes peut servir à cadrer le diagnostic d’un échec concret.