Worldwide Express confie ses factures litigieuses à des agents IA et réduit sa dette de 75%

Worldwide Express, courtier américain en transport de marchandises, réalise un chiffre d'affaires d'environ $5 milliards par an. Il compte 130 000 clients et 75 transporteurs de fret groupé (LTL : les lots de plusieurs clients voyagent dans le même camion). L'entreprise a confié le traitement de ses factures litigieuses à des agents IA.

Le problème était très concret. Environ 14% des factures des transporteurs échouent au « rapprochement à trois voies » : la facture doit correspondre à la commande et au bon de réception de la marchandise. Chaque facture concernée devient un litige, et tant que celui-ci n'est pas clos, l'argent reste immobilisé.

Dans ces « exceptions », environ $15 millions de trésorerie disponible étaient bloqués. Avec AWS et l'intégrateur LTM, l'entreprise a construit un système multi-agents sur Amazon Bedrock, intégré à son système de gestion des expéditions SpeedShip. Six mois plus tard, le volume de litiges non résolus est tombé à $4 millions.

Pourquoi les factures des transporteurs ne correspondent pas

Les litiges se répartissent en trois types :

• Écarts de lignes. La quantité ou le code de service figurant sur la facture ne correspond pas à l'enregistrement de l'expédition.
• Écarts de prix. Le transporteur a facturé un tarif différent du tarif contractuel.
• Frais supplémentaires inattendus. Hayon élévateur, livraison à une adresse résidentielle, recalcul du poids. Ces frais ne figuraient pas dans le devis initial.

Auparavant, chaque dossier suivait cinq étapes : identifier le type de litige, trouver la cause dans les enregistrements du fournisseur, écrire au transporteur ou à l'entrepôt, attendre la réponse, saisir la décision dans le système. Le travail était confié à un service externalisé, qui traitait les dossiers un par un, par téléphone. Chaque transporteur a ses propres tarifs et sa propre procédure de litige : le service des opérations financières (FinOps) croulait sous les tâches répétitives.

L'automatisation robotisée des processus (RPA) ne convient pas ici : elle est efficace pour des scénarios rigides. Or il faut lire la politique du transporteur, rapprocher les frais de la réalité de la livraison et décider s'ils sont légitimes pour le montant concerné. C'est un travail sur du texte et du contexte, d'où le choix d'agents reposant sur des modèles de langage.

Trois agents et une base de règles par transporteur

Un litige est confié à l'un des trois agents spécialisés :

• Invoice Matching Agent retrouve l'enregistrement d'expédition auquel se rapporte la facture et signale ce qui ne concorde pas.
• Pricing Variance Agent compare le prix facturé au prix contractuel et détermine si l'écart est justifié.
• Accessorial Validation Agent vérifie si les frais supplémentaires sont étayés par des événements de livraison réels : un hayon élévateur a-t-il été utilisé, l'adresse était-elle résidentielle.

Chaque agent dispose d'une instruction (rôle, limites de décision, format de réponse), d'un ensemble d'actions dans SpeedShip et d'un accès à une base de connaissances. Cette base contient les règles tarifaires, les définitions des frais, les procédures de litige et les seuils d'écart admissibles de chaque transporteur. Avant de décider, l'agent récupère les documents de ce transporteur précis. C'est pourquoi les mêmes trois agents travaillent avec les 40+ transporteurs connectés, sans code spécifique pour chacun.

Côté ingénierie, les choix sont soignés. L'entreprise a développé elle-même l'orchestration sur des serveurs Amazon EC2 avec mise à l'échelle automatique, et n'utilise Bedrock que pour appeler les modèles via une API unique. La logique de routage reste entre les mains de l'équipe, et il est possible d'utiliser des bibliothèques open source pour les agents. Les agents accèdent à SpeedShip via les mêmes API que les analystes : ils voient donc les mêmes tarifs contractuels, les mêmes données d'expédition et les mêmes preuves de livraison. Une fois la décision prise, le système rédige une note claire : ce qui a été trouvé et ce qui a été fait. Pour des litiges portant sur de l'argent, cette explicabilité est indispensable.

L'humain n'a pas été écarté. Au départ, un employé validait chaque recommandation dans son interface habituelle. Quand la précision a dépassé 99%, la validation en masse est devenue le mode principal. Les rejets sont journalisés, et l'équipe s'en sert pour corriger les instructions et les bases de connaissances. Les indicateurs suivis sur les tableaux de bord : taux d'automatisation par transporteur, erreurs par type de litige, délai de résolution, fréquence des corrections humaines.

Les chiffres, et ce qu'il faut vérifier

Résultats annoncés sur six mois :

• Les agents closent environ 10 000 litiges par semaine, soit à peu près la moitié du flux. Moins de 1% d'erreurs.
• Les litiges non résolus sont passés de $15 millions (juin 2025) à $4 millions.
• Le cycle de transformation d'une commande en encaissement a raccourci de 4 semaines.
• Plus de $1 million d'économies par an ; retour sur investissement annoncé dès la première année : 60 fois la mise ; afflux unique de trésorerie : $10 millions.

Il s'agit d'un article publié sur le blog d'AWS lui-même, et les chiffres n'y concordent pas tout à fait. Le taux d'automatisation est indiqué tantôt comme « environ 50% », tantôt comme « plus de 40% ». Le gain de $10 millions est présenté à la fois comme une libération unique de trésorerie et comme un volume hebdomadaire de factures traitées plus vite.

La baisse de $15 millions à $4 millions représente en réalité 73%, et non exactement 75%. Ni le modèle utilisé ni le coût des appels ne sont précisés, alors que ce sont eux qui déterminent pour l'essentiel l'économie du projet. Est vraisemblablement considéré comme une « erreur » ce que le valideur a rejeté ; les erreurs qu'il a laissé passer lors de la validation en masse ne sont pas couvertes par ce chiffre.

Le schéma paraît néanmoins transposable à la logistique et à toute entreprise confrontée à un flux de factures. Commencez par le type de litige le plus fréquent et prouvez la précision sur celui-ci. Stockez les règles des contreparties sous forme de documents interrogeables, sans les coder en dur. Donnez à l'agent accès aux mêmes API que les humains, et laissez la validation à l'humain tant que les indicateurs ne montrent pas une précision stable. L'entreprise étend déjà cette approche à d'autres étapes du cycle « de la commande au paiement ».