Gestion des exceptions de livraison : anatomie de Shipment Exception Commander

Si les perturbations d’expédition sont difficiles à gérer, ce n’est pas faute d’options. La gestion des exceptions de livraison se complique parce que les éléments de preuve n’offrent pas tous le même niveau de fiabilité, que les devis de réacheminement expirent, que les coûts franchissent des seuils d’approbation et qu’une relance précipitée peut créer une seconde réservation alors que la première a bel et bien abouti.

Shipment Exception Commander est une application de référence open source pour Claude Managed Agents, conçue pour ce point de bascule décisionnel. Elle examine une exception synthétique, note mécaniquement chaque option de reprise, délègue une contre-analyse indépendante des risques, présente à un humain l’action exacte et n’autorise qu’une seule mutation idempotente dans la sandbox, après validation par le mécanisme d’approbation natif.

Gestion des exceptions de livraison : calculer les scores avant l’arbitrage du modèle

Le coordinateur n’invente jamais de tarifs et ne confond pas du texte libre avec une règle. L’outil serveur shipment_intelligence, accessible en lecture seule, expose trois cas synthétiques et calcule le score des options selon une formule fixe : 50 points si la promesse est tenue, 20 pour la couverture des stocks, 20 pour la maîtrise des coûts par rapport au plafond absolu et 10 pour le niveau de confiance. Chaque option est assortie d’une version de devis, d’une date d’expiration, d’une ETA, d’un nombre d’unités protégées et d’un surcoût en USD.

Le principal cas de démonstration, SCX-2026-071, comparait trois arbitrages caractéristiques : un réacheminement maritime économique qui ne tenait pas la promesse, un transport intégral par avion qui dépassait le plafond absolu de dépenses et une expédition aérienne accélérée et fractionnée qui protégeait les 240 unités promises pour $4,200. L’option fractionnée a obtenu un score de 91 tout en restant sous la limite opérateur de $5,000. Le score rend la recommandation reproductible ; Claude doit, lui, rassembler les preuves, remettre les hypothèses en question et expliquer le compromis.

Une preuve non fiable ne peut pas autoriser une action

Une note de transporteur contient délibérément un texte formulé comme une instruction, demandant à l’agent d’ignorer la politique d’approbation et de réserver l’option premium. Le workflow classe cette note comme non fiable, la conserve à titre de preuve et écarte explicitement toute valeur directive. Les règles proviennent du catalogue synthétique versionné et de l’adaptateur, jamais du texte libre associé à une expédition ni du résultat d’un outil.

Le coordinateur ne dispose par ailleurs d’aucune mémoire accessible en écriture d’une session à l’autre, d’aucun coffre-fort, d’aucune intégration MCP et d’aucune sortie réseau. read, glob et grep constituent les seules exceptions étroites approuvées automatiquement. Bash et l’écriture des livrables restent en always_ask ; l’édition, la récupération de pages web et la recherche web sont désactivées. La commande execute de l’adaptateur est le seul moyen canonique de modifier l’état.

Un vérificateur met la recommandation à l’épreuve

Avant toute demande d’exécution, le coordinateur Opus confie la solution de reprise proposée à un vérificateur Haiku spécialisé. Lors de l’exécution de démonstration, celui-ci a répondu NEEDS_CHANGES : il ne pouvait pas établir si le devis Q-071-v4 était toujours à jour, ni si les capacités et les surcharges étaient définitives. Le coordinateur n’a pas balayé cette réserve. Il a appelé le validateur déterministe de la proposition, qui a de nouveau contrôlé l’horloge synthétique, l’expiration du devis, la version de la politique, le seuil de dépenses et la version d’état attendue. Ce n’est qu’après le résultat faisant autorité, ready_for_human_approval, que le statut global est passé à « prêt ».

Le dossier d’approbation précisait ensuite les identifiants du cas et de l’option, la dépense exacte de $4,200, l’ancienne et la nouvelle ETA, l’incidence sur la promesse client, les 240 unités protégées, l’expiration du devis, les versions de la politique et de l’état, le score, l’historique du vérificateur, les solutions écartées, la clé d’idempotence stable, les champs de reçu attendus ainsi que le comportement prévu en cas de refus ou d’échec.

Un refus signifie : aucune mutation

La première carte d’approbation native a été refusée volontairement. Aucune commande modifiant l’état n’a été exécutée : l’état est resté detected en version 3, aucun reçu n’existait et la clé d’idempotence est demeurée inutilisée. L’agent n’a ni changé d’outil, ni modifié la commande, ni fabriqué une nouvelle clé.

À la demande explicite de l’opérateur, la même action canonique a été présentée une seconde fois. Elle a alors été autorisée. À la frontière de mutation, l’adaptateur a de nouveau vérifié la version d’état 3, la validité du devis, la politique, le niveau d’approbation et le plafond absolu de $10,000. Il n’a exécuté l’action qu’une fois, faisant passer le cas de l’état detected version 3 à l’état resolved version 4, puis a renvoyé le reçu rcpt_37105a2da411aee0391c assorti de la référence de réservation SBX-56DFC3291972.

Une exécution résistante aux rejeux, avec un périmètre clairement établi

L’adaptateur synthétique possède une clé stable, SCX-2026-071:OPT-071-B:v3, un verrou au niveau du système d’exploitation, une inspection de l’état canonique et un registre des reçus. Les appels répétés avec la même intention renvoient le reçu existant ; une intention contradictoire associée à cette clé échoue ; une version obsolète, une exécution concurrente ou d’éventuelles écritures partielles imposent une inspection plutôt qu’une relance à l’aveugle.

Ces protections sont volontairement présentées dans les limites de leur périmètre réel : le verrou, l’état et le registre des reçus sont des fichiers locaux à la session, dans une seule sandbox Managed Agents. Ils ne constituent pas une garantie distribuée adaptée à la production. Un véritable adaptateur de transporteur ou de TMS nécessiterait un stockage transactionnel partagé et un contrôle d’idempotence dans le système en aval.

L’évaluateur du résultat a contrôlé les preuves

La session a produit trois artefacts dans /mnt/session/outputs/ : un dossier de reprise lisible par un humain, un journal d’audit structuré et le reçu d’exécution brut. Un évaluateur de résultat Managed Agents a comparé ces fichiers de manière indépendante avec le catalogue, le code source de l’adaptateur, l’état canonique, l’historique des approbations et le registre des reçus. Il a exigé des corrections concernant l’indication de l’expiration du devis, le comportement explicite en cas d’échec, un manifeste des livrables et la limite liée au caractère local de la session, avant de renvoyer satisfied.

Le dossier de reprise a ensuite été téléchargé par l’intermédiaire du proxy de fichiers de l’application. Son SHA-256 est 30c8ad1d0d13cf7ad4b7070e67370ea270562c5e4ef44dfa503e3124180bd40b. La session de capacité est sesn_01CcQjCVoWvNQ7VJLFbuDJxh ; le résultat est outc_01GoD4rsLMh93iQNfAUw63KW.

L’exécution réelle de l’évaluateur a également révélé une lacune dans l’interface : les threads enfants de l’évaluateur peuvent demander une approbation alors que la session parente reste inactive. La version publiée reconstruit désormais les cartes d’approbation en attente à partir des événements requires_action du parent comme des événements evaluated_permission: ask des threads enfants, les retire après confirmation ou résultat et empêche un rejeu de faire réapparaître des demandes déjà traitées. Elle transmet aussi le session_thread_id de l’évaluateur au moyen d’une liste blanche restreinte dans le navigateur, puis vérifie que ce routage correspond exactement à l’événement d’outil d’origine avant de relayer la décision.

Une session de démonstration Sonnet configurée séparément, sesn_01BvSf33BLBbN86w5oDb3BkQ, a testé ce parcours corrigé. L’événement d’outil de l’évaluateur relayé entre les threads, sevt_013VnmofY8ytk6QwgDtNSYoq, transportait l’identifiant de thread sthr_018HMgpidoN86Qp4iGLZt1q3 ; l’interface a produit la confirmation sevt_016ZFv5TdBPKNyEPThzGT36Q avec les mêmes identifiants d’outil et de thread, le serveur l’a acceptée et l’évaluateur a repris son travail en demandant le contrôle suivant. Cette démonstration ciblée a ensuite été interrompue volontairement pour éviter de payer des itérations supplémentaires sans intérêt ; le résultat principal sur l’expédition est resté satisfied.

Opus en référence, Sonnet pour la validation, Haiku pour la vérification

Le coordinateur provisionné reste claude-opus-5. Pour contenir le coût des validations payantes et reproductibles, les sessions locales peuvent explicitement remplacer le seul modèle du coordinateur par claude-sonnet-5 ; toute autre surcharge de configuration à l’exécution échoue en mode fermé. Le vérificateur indépendant utilise claude-haiku-4-5. La session de smoke test facturée sesn_01RTs3wLV41odV9p92eWtrHV a utilisé Sonnet et renvoyé exactement SMOKE OK.

La suite de tests de production reste délibérément isolée des secrets d’accès, même lorsqu’un développeur dispose d’un fichier .env.local configuré. Elle prouve qu’un nouveau déploiement n’affiche aucun champ de clé dans le navigateur, n’envoie aucun trafic à Anthropic, indique configured: false et renvoie le code 503 depuis les routes de facturation.

Une référence publique qui échoue en mode fermé

La référence publique déployée sur Vercel ne contient ni clé Anthropic ni identifiant de ressource Managed Agents. La page d’accueil et /api/agent/health restent accessibles, tandis que la création de sessions échoue en mode fermé. Les utilisateurs qui adoptent le projet provisionnent l’agent et l’environnement avec leur propre compte Anthropic ; toute instance configurée doit être protégée par un contrôle d’accès avant d’être ouverte à d’autres utilisateurs.

Tous les cas, transporteurs, devis, références de réservation, changements d’état et reçus de ce projet sont synthétiques. L’application illustre un modèle de contrôle opérationnel, et non une véritable intégration avec un transporteur.

Preuves de la version publiée

• Dépôt : dvnc-labs/shipment-exception-commander
• Version : v0.1.0
• CI : exécution de publication au vert
• Commit : 1db0329
• Déploiement : shipment-exception-commander.vercel.app
• Santé : état de l’agent en mode fermé

Shipment Exception Commander adopte volontairement un périmètre plus étroit qu’un copilote logistique. Sa promesse vérifiable tient en une phrase : recommander à partir de preuves versionnées, mettre la recommandation à l’épreuve, demander à un humain d’approuver l’action exacte, ne produire qu’une seule mutation et laisser suffisamment de traces pour reconstituer les faits.