| Ce que c'est | Une norme ouverte qui permet aux agents d'IA d'appeler vos systèmes de fret |
| Protocole | JSON-RPC 2.0 via stdio ou HTTP |
| Blocs de construction de base | Outils (actions), Ressources (données en lecture seule), Prompts (modèles) |
| Cas d'utilisation du fret | Devis, réservation, suivi, téléchargement de BL/POD, audit de factures |
| En direct en 2026 | Warp, CargoAi CargoMART, FreightUtils, C.H. Robinson |
| Une intégration | Fonctionne avec Claude, ChatGPT, Copilot, Gemini, Cursor |
Pendant des années, chaque fois que nous connectons un logiciel de fret à un nouveau partenaire, cela signifiait un autre projet d'API sur mesure, et j'ai vu des équipes reconstruire la même infrastructure pour chaque outil. En 2026, une deuxième surface d'intégration est apparue : le Model Context Protocol (MCP), une norme ouverte qui permet à un agent d'IA au sein de Claude, ChatGPT, Microsoft Copilot ou Gemini d'appeler directement vos systèmes de fret. Au lieu qu'une personne clique sur un portail, l'agent demande un devis, réserve un chargement ou récupère une preuve de livraison en langage naturel. Ce guide explique ce qu'est le MCP, comment il s'intègre à une API de fret et présente un serveur de travail minimal. J'expliquerai également qui l'utilise déjà en production et où, selon moi, vous devriez être prudent.
Qu'est-ce que le MCP ?
Le Model Context Protocol est une spécification ouverte, initialement publiée par Anthropic et maintenant développée avec la communauté, pour connecter les modèles d'IA à des outils et des données externes. Il standardise le "format de transmission" entre un client d'IA et votre logiciel, de sorte que vous construisez la connexion une fois plutôt que de la réimplémenter pour chaque assistant.
Techniquement, le MCP utilise JSON-RPC 2.0 via un transport stdio local ou un transport HTTP distant. Un serveur déclare trois types de capacités lorsqu'un agent se connecte :
- Outils — actions exécutables que le modèle peut appeler, telles que l'interrogation d'une API ou l'exécution d'un calcul. Les outils sont contrôlés par le modèle : l'agent les découvre et décide quand les appeler.
- Ressources — données en lecture seule que l'application expose pour le contexte, telles qu'une table de tarifs, une liste de transporteurs ou un document d'expédition. Votre application, et non le modèle, décide quand les attacher.
- Prompts — modèles réutilisables contrôlés par l'utilisateur (par exemple, "planifier un trajet LTL multi-arrêts") qu'un client peut lister et remplir.
Chaque capacité a des méthodes standard list et call/get, c'est exactement pourquoi un serveur MCP fonctionne dans n'importe quel client compatible MCP sans code de liaison personnalisé par assistant.
Pourquoi le MCP est-il important pour le fret spécifiquement ?
La logistique est un problème de coordination entre de nombreux systèmes : un système de gestion des transports (TMS), des API de transporteurs, des moteurs de tarification, des systèmes de suivi et de traçabilité, des données douanières, un ERP. Historiquement, chaque fonctionnalité d'IA signifiait une intégration distincte, et chaque nouvel assistant signifiait de recommencer. Le MCP réduit cela. Vous exposez vos capacités de fret une fois en tant que serveur MCP, et tout agent peut obtenir des devis et réserver via celles-ci, puis suivre tout ce qui est en transit.
Le bénéfice pratique est le même que celui que les expéditeurs obtiennent déjà des logiciels de réservation de fret et des API modernes, à savoir moins d'étapes manuelles sur le portail, mais étendues aux flux de travail en langage naturel. En pratique, un agent enchaîne plusieurs appels. Il lit une ressource tarifaire, appelle un outil get_quote, puis vérifie un outil de suivi et présente le résultat, le tout au sein d'une même conversation.
Mapper une API de fret sur MCP
La manière la plus propre de concevoir un serveur MCP de fret est de trier chaque capacité dans les trois primitives :
- Outils (actions) :
get_quote,book_load,track_shipment,get_documents(lettre de voiture/preuve de livraison),audit_invoice. - Ressources (contexte en lecture seule) : la liste des transporteurs, les tarifs par itinéraire, les tables de frais accessoires, l'historique des statuts d'un envoi.
- Prompts (modèles) : « comparer LTL et FTL pour cet envoi », « trouver le transporteur conforme le moins cher pour les matières dangereuses ».
Une règle empirique utile : tout ce qui change d'état ou coûte de l'argent est un outil qui devrait nécessiter une confirmation ; tout ce qui est donnée de référence est une ressource que l'agent peut lire librement.
Un serveur MCP de fret minimal (exemple concret)
Vous trouverez ci-dessous une ébauche simplifiée de serveur MCP en TypeScript exposant deux outils de fret. Il utilise le SDK officiel et un schéma JSON pour les entrées de chaque outil, puis appelle votre API de fret existante en coulisses :
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";
const server = new McpServer({ name: "freight", version: "1.0.0" });
// Tool 1 — quote a shipment (read-only, safe to auto-run)
server.tool(
"get_quote",
{ origin: z.string(), destination: z.string(), weightKg: z.number(), mode: z.enum(["ltl", "ftl", "van"]) },
async ({ origin, destination, weightKg, mode }) => {
const r = await fetch(`https://api.example-freight.com/v1/quotes`, {
method: "POST",
headers: { authorization: `Bearer ${process.env.FREIGHT_TOKEN}` },
body: JSON.stringify({ origin, destination, weightKg, mode }),
});
const data = await r.json();
return { content: [{ type: "text", text: JSON.stringify(data) }] };
},
);
// Tool 2 — track a shipment (read-only)
server.tool(
"track_shipment",
{ shipmentId: z.string() },
async ({ shipmentId }) => {
const r = await fetch(`https://api.example-freight.com/v1/shipments/${shipmentId}`, {
headers: { authorization: `Bearer ${process.env.FREIGHT_TOKEN}` },
});
return { content: [{ type: "text", text: JSON.stringify(await r.json()) }] };
},
);
server.start(); // stdio by default; HTTP transport for remote agentsUn agent connecté à ce serveur peut maintenant répondre à la question « Combien coûte le transport de 800 kg en LTL de Lisbonne à Madrid, et où se trouve l'envoi ABC123 ? » en appelant les deux outils et en composant la réponse. Un outil book_load suivrait la même structure, mais, comme expliqué ci-dessous, serait soumis à une confirmation humaine explicite car il engage des fonds.
Qui utilise déjà le MCP de fret en 2026
Ce n'est plus théorique. Des déploiements concrets en production sont apparus au cours du premier semestre 2026 :
- Warp a publié warp-agent-mcp sur npm le 16 avril 2026, décrit comme le premier serveur MCP de production pour le fret. Ses 23 outils devisent et réservent des envois LTL/FTL, extraient des documents de lettre de voiture/POD, auditent des factures et rapportent le suivi, le tout sur son réseau réel plutôt qu'une sandbox.
- CargoAi a connecté sa plateforme de réservation de fret aérien CargoMART à Copilot, ChatGPT, Claude et Gemini via MCP le 5 juin 2026, permettant aux transitaires de deviser et de réserver du fret aérien en langage naturel.
- FreightUtils propose un serveur MCP ouvert avec 19 outils gratuits, couvrant la recherche de matières dangereuses ADR, la recherche de code SH, les calculs de poids taxable et de mètres cubes/palettes, l'ajustement de palettes et la capacité de conteneur, le tout sans clé API requise.
- C.H. Robinson a rapporté que ses agents d'IA générative avaient effectué plus de 3 millions de tâches d'expédition, et Nuvocargo a lancé une douzaine d'agents gérant plus de 70 % des points de contact des chargements. C'est le type d'automatisation à haut volume que le MCP est conçu pour standardiser.
Comment commencer en toute sécurité
Exposer les actions de réservation et de paiement à un agent autonome augmente les enjeux, alors mettez en place des garde-fous dès le premier jour :
- Authentifiez et limitez la portée. Déléguez au serveur MCP ses propres identifikasi (jetons OAuth ou à portée limitée), et accordez à chaque outil uniquement les autorisations dont il a besoin, afin qu'un outil de suivi ne détienne jamais les droits de réservation.
- Gardez un humain dans la boucle pour les changements d'état. La cotation et le suivi peuvent s'exécuter automatiquement, mais tout ce qui modifie une réservation ou déplace de l'argent doit nécessiter une confirmation explicite avant que l'Outil ne s'exécute.
- Rendez les actions idempotentes. Utilisez des clés fournies par le client afin qu'une
book_loadrépétée ne puisse pas créer de doublons d'expéditions. - Respectez les limites de débit et enregistrez tout. Les agents peuvent effectuer de nombreux appels rapidement ; limitez-les et conservez une piste d'audit de chaque invocation d'outil pour la résolution de litiges et la conformité.
Risques et limites
Le MCP est puissant, mais pas magique. Les agents peuvent toujours halluciner des arguments, alors validez chaque entrée d'outil par rapport à un schéma strict et rejetez ce qui est invraisemblable. Des permissions d'outils trop larges constituent le principal risque de sécurité, car un agent compromis ou ayant subi une injection de prompt ne devrait jamais pouvoir déplacer de l'argent ou divulguer la grille tarifaire d'un client. Traitez un serveur MCP comme toute autre surface d'API publique : moindre privilège, validation des entrées, surveillance et portes de confirmation pour tout ce qui est irréversible. Pour le fret spécifiquement, gardez les flux réglementés (marchandises dangereuses, douanes) sous revue humaine jusqu'à ce que vous fassiez confiance au comportement de l'agent.Ce que cela signifie pour une place de marché de fret
Chez GetTransport, nous gérons une place de marché où les expéditeurs comparent les transporteurs et réservent des expéditions, et la perspective du MCP rend notre feuille de route concrète. Les mêmes opérations qu'une personne effectue dans notre interface se traduisent directement par des outils MCP : demander des devis à plusieurs transporteurs, comparer le prix au délai, réserver, puis suivre. Les données de référence telles que la couverture des transporteurs et la tarification des itinéraires correspondent plutôt au modèle de ressource. Ce que je trouve le plus utile dans une place de marché ici, c'est l'étendue. Un seul outil get_quote peut s'étendre à de nombreux transporteurs à la fois, ce qui est exactement la comparaison qu'un agent excelle à orchestrer et qu'une personne trouve fastidieuse. Le point à retenir pour les expéditeurs est que le flux de réservation qu'ils connaissent déjà devient quelque chose qu'un assistant peut gérer de bout en bout, à condition que la plateforme l'expose via une API propre et bien gouvernée. Cette dernière condition est là où se trouve la majeure partie du travail réel, et c'est la partie sur laquelle je ne me précipiterais pas.