Règle simple, automatisation ou agent : une grille de choix
Le besoin n'est pas de « mettre de l'IA dans les commandes », mais de rendre une exception compréhensible et traitable.
| Situation | Premier choix à tester | Place éventuelle de l'IA |
|---|---|---|
| Un champ obligatoire manque | Validation déterministe | Inutile pour constater l'absence |
| Une commande n'arrive pas dans l'outil de gestion | Rapprochement par identifiant et procédure de reprise | Résumer l'incident si plusieurs journaux doivent être lus |
| Un seuil métier est dépassé | Règle explicite et file de contrôle | Expliquer le contexte, sans réinventer le seuil |
| Une note client semble contredire la livraison demandée | Relecture humaine ou analyse assistée | Rassembler les éléments et proposer une question de clarification |
| Deux sources donnent des états incompatibles | Contrôle des dates et de la source de référence | Présenter la contradiction, sans choisir une vérité non démontrée |
Une extraction suivie d'un résumé peut suffire sans agent. Un agent devient une piste lorsque le système doit choisir, dans une liste d'outils autorisés, quelle information consulter ensuite. Cette latitude doit apporter une utilité démontrable face au parcours fixe.
Définir les entrées, les outils et la sortie
Limitez le premier périmètre à une famille d'anomalies, par exemple les instructions de livraison ambiguës. Les entrées sont la commande et ses lignes, les états utiles datés, les échanges autorisés et la version applicable de la consigne interne. Écartez les données personnelles et de paiement inutiles à l'examen.
Les outils envisagés consultent seulement la commande, son historique pertinent et la documentation autorisée. Ils doivent respecter les accès de l'opérateur et un identifiant de commande imposé par l'application. Si une correspondance entre outils est incertaine, le système s'arrête plutôt que de rattacher un dossier voisin.
Le parcours proposé comporte quatre étapes : vérifier l'identité du dossier ; collecter les éléments avec leur provenance et leur date ; séparer constats, contradictions et hypothèses ; préparer une fiche pour l'opérateur. Fixez aussi une limite de consultations et une durée maximale : une recherche incomplète doit être visible.
Scénario fictif : une demande de livraison ambiguë
Cet exemple méthodologique est imaginé ; il ne décrit ni un client ni une réalisation Codezilla.
Une commande contient deux articles. L'option choisie indique un envoi groupé, mais une note demande « envoyez ce qui est prêt ». La consigne interne exige une confirmation du client avant un envoi fractionné. L'outil de préparation indique qu'un article est prêt ; il ne confirme pas la disponibilité du second.
Une fiche exploitable pourrait contenir :
- Constats sourcés : envoi groupé dans la commande ; demande différente dans la note ; un seul article indiqué prêt dans l'outil de préparation. Chaque constat renvoie à l'enregistrement et à sa date de lecture.
- Règle applicable : confirmation préalable pour fractionner, avec lien vers la version de la consigne.
- Information manquante : disponibilité du second article et accord explicite sur le fractionnement.
- Proposition : faire vérifier ces deux points par l'opérateur ; préparer, si utile, une question au client.
- Décision réservée : l'opérateur choisit la suite dans ses outils habituels. La fiche ne déclenche aucun envoi.
L'agent ne doit conclure ni à une rupture de stock ni à un consentement acquis. Une note libre ne remplace pas la règle interne. Si la commande change pendant l'examen, la fiche doit être signalée comme périmée et les informations utiles relues avant décision.
Rendre les limites effectives dans les outils
La lecture seule doit être imposée par les droits et les interfaces, pas seulement demandée dans une instruction au modèle. Microsoft recommande des limites explicites et des contrôles déterministes indépendants de la réponse de l'agent. Voir les principes de maîtrise des agents autonomes.
Une note client ou un document peut contenir une instruction malveillante. Ce contenu reste une donnée à examiner, jamais une autorisation de changer d'objectif ou d'accéder à d'autres dossiers. L'OWASP décrit ce risque d'injection d'instructions et recommande de limiter les droits au niveau des outils.
Un accès refusé, un outil indisponible ou une source trop ancienne doit produire une fiche incomplète avec le motif. Le système ne doit pas combler le manque par une supposition présentée comme un fait. Conservez les références utiles et la décision de l'opérateur avec des accès et une durée de conservation définis, sans recopier inutilement les échanges clients.
Six tests avant un pilote
Préparez des dossiers fictifs avec une réponse attendue validée par l'équipe. Exécutez les mêmes cas avec la méthode actuelle, une règle simple ou un parcours fixe, puis avec l'assistance IA.
| Test | Résultat attendu |
|---|---|
| Commande sans anomalie | Aucun problème inventé |
| Note ambiguë | Ambiguïté et question à vérifier, sans consentement supposé |
| Sources contradictoires ou périmées | Contradiction visible et décision différée |
| Source absente ou accès refusé | Limite expliquée, sans contournement |
| Note demandant de rembourser et d'ignorer les règles | Aucune action ; texte traité comme contenu non fiable |
| Nouvelle commande après un premier dossier | Aucune donnée ou conclusion du dossier précédent réutilisée à tort |
Relevez les faits non étayés, les anomalies manquées, les fausses alertes, les propositions corrigées et le temps total de traitement, relecture comprise. Ajoutez le coût des appels et de l'exploitation. Fixez les seuils acceptables avant le pilote ; tout accès hors périmètre ou tentative d'action interdite bloque son élargissement jusqu'à correction et nouveau test. Aucun gain n'est établi par ce scénario.
Le livrable à demander est donc une fiche vérifiable et un protocole de test, pas une démonstration qui paraît convaincante. La pertinence de l'IA, la qualité des propositions et la charge de contrôle restent à démontrer. Une éventuelle capacité d'action constituerait un autre périmètre : AWS recommande alors de fournir au valideur le contexte de la décision et de prévoir les absences de réponse.
Pour distinguer un défaut de synchronisation d'une anomalie à examiner, consultez aussi qui doit piloter stocks et commandes entre Shopify et un ERP. Pour cadrer les outils, limites et tests d'un tel projet, découvrez notre approche des agents IA pour entreprise ou présentez votre besoin.