Photo : Tiger Lily · PexelsExemple : un agent IA connecté au TMS pour répondre aux contacts clients
Exemple de situation (non réel) pour une ETI logistique — architecture, indicateurs à mesurer et leçons transmissibles à tout transporteur.
Nos clients types
Exemple de situation. Cet article décrit une situation type, construite pour illustrer la démarche d'un agent IA de service client dans le transport et la logistique. Ce n'est pas un projet client, et nous ne publions pas de chiffres de résultat : ils dépendent de chaque entreprise.
#Le contexte : une ETI logistique et ses contacts sur le statut des livraisons
Prenons un transporteur spécialisé dans la chaîne du froid pharmaceutique et agroalimentaire : ETI de plusieurs centaines de salariés, une flotte de véhicules frigorifiques, plusieurs sites d'exploitation. Un volume de livraisons annuel considérable, chacune avec son lot de coordonnées, plages horaires, températures de transport et destinataires.
Ce volume génère une pression opérationnelle prévisible mais négligée depuis des années. Les coordinateurs logistiques passent une part importante de leur temps hebdomadaire à répondre à des questions sur le statut des livraisons : « votre colis est-il parti ? », « à quelle heure arrive le chauffeur ? », « pouvez-vous confirmer l'enlèvement ? », « j'ai besoin du relevé de température ». Ces questions arrivent par téléphone et par email.
Cela représente l'équivalent de plusieurs postes occupés exclusivement à répondre à des questions dont l'essentiel trouve sa réponse dans une seule source : le TMS (Transport Management System) en place.
#Le diagnostic initial
L'audit commence par une cartographie exhaustive des contacts entrants : recensement des types de questions à partir des logs emails, des enregistrements d'appels et d'entretiens avec les coordinateurs. Résultat fréquent, et souvent inattendu pour l'équipe : l'essentiel du volume se concentre sur une douzaine de motifs récurrents.
Ces motifs, classés par fréquence décroissante : statut de livraison en temps réel, ETA (heure d'arrivée estimée), confirmation d'enlèvement, relevé de température transport, POD (Proof of Delivery) manquant ou en retard, anomalie de traçabilité GPS, réclamation pour retard, modification de plage de livraison, demande de reprogrammation, statut douanier sur flux internationaux, demande de document CMR, confirmation de réception quai.
L'analyse des logs du TMS montre que ces motifs correspondent à des données déjà disponibles, en temps réel pour la plupart. La conclusion est évidente : la majorité des contacts humains traitent des données que la machine détient déjà et peut restituer sans intervention d'un coordinateur.
La décision prise à l'issue du diagnostic : un agent IA avec architecture RAG pour connecter l'agent aux données internes sur la documentation des procédures, couplé à une API du TMS en consultation temps réel. Périmètre explicitement délimité : questions d'information seulement, aucune action dans le TMS en phase 1.
#L'architecture envisagée
L'architecture repose sur cinq couches fonctionnelles distinctes, chacune ayant un rôle précis dans la chaîne de traitement.
Couche LLM. Un LLM comme Claude d'Anthropic, hébergé via API cloud avec accord de traitement des données UE. Choix justifié par ses capacités de raisonnement sur des données logistiques semi-structurées et sa fiabilité sur les instructions complexes incluant des règles métier.
Couche RAG. Une base vectorielle (par exemple Qdrant) qui indexe les procédures internes (procédures d'exploitation, règles de traçabilité températuré, SLA clients, procédure de réclamation). Un modèle d'embedding adapté au français. Mise à jour régulière automatisée via un pipeline Python.
L'architecture RAG pour connecter l'agent aux données internes permet de répondre aux questions contextuelles sans coder chaque règle en dur.
Couche données temps réel. Intégration API REST vers le TMS (consultation du statut de livraison, de l'ETA calculé, des relevés de température, de la disponibilité du POD). Aucune écriture en phase 1 — l'agent interroge mais ne modifie pas.
Couche canaux entrants. WhatsApp Business API (webhook n8n) pour les contacts clients directs. Classification NLP des emails entrants avec routage : les questions relevant des motifs identifiés sont traitées par l'agent, les autres sont transmises aux coordinateurs avec un tag catégorie. Interface web interne (Next.js) pour que les coordinateurs visualisent les interactions en cours et prennent la main en un clic.
Couche escalade. CRM (HubSpot par exemple) : toute interaction que l'agent ne peut pas résoudre avec un score de confiance suffisant crée automatiquement un ticket assigné au coordinateur de permanence, avec le contexte complet de l'échange.
Le standard MCP (Model Context Protocol) pour les agents peut être évalué pour l'intégration du TMS — plutôt en phase 2, la phase 1 utilisant une intégration REST directe plus rapide à déployer.
#Le développement : un périmètre strictement borné
La cadence de développement se maintient sans dérapage grâce à un périmètre fonctionnel strictement borné dès le lancement.

Socle technique. Intégration de l'API du TMS avec mapping des types de requêtes et de leurs champs de réponse. Construction du pipeline RAG sur la base documentaire des procédures. Premier prompt système configuré avec les règles de gestion de l'entreprise. Incident typique : l'API du TMS peut présenter des timeouts répétés pendant sa plage de batch nocturne. Solution : retry exponentiel + cache Redis court sur les données statiques (ETA calculé, statut confirmé).
Canal WhatsApp. Connexion WhatsApp Business API (par exemple via Twilio), configuration des webhooks n8n, routage par numéro de téléphone vers le contexte client dans le TMS. Tests avec des numéros internes.
Classification des emails. Pipeline NLP pour catégoriser les emails entrants sur la boîte générale logistique : détection des motifs définis, détection des emails hors périmètre.
Validation sur données réelles. Tests sur des cas historiques dépersonnalisés. On mesure le recall de l'agent sur les motifs définis et on analyse les échecs : contexte insuffisant dans la question, données TMS manquantes ou en erreur, cas limites hors documentation.
Pilote contrôlé. Déploiement avec quelques clients volontaires. Formation de quelques coordinateurs à la supervision via l'interface web. Feu vert au déploiement complet quand aucun incident majeur n'est observé.
#Ce qu'on mesure à trois mois
Nous ne publions pas de résultats chiffrés pour cet exemple. Dans un vrai projet, on relève les indicateurs ci-dessous avant le projet, puis à trois mois et à douze mois.
Taux d'automatisation global. Part des contacts entrants résolus par l'agent sans intervention humaine. Le résidu correspond aux réclamations complexes (litige marchandise, responsabilité transporteur), aux clients non digitaux qui préfèrent le téléphone, et aux cas hors périmètre des motifs définis.
Par canal. WhatsApp Business est le canal le plus adapté à l'automatisation (questions courtes, contexte clair, clients habitués aux réponses rapides). L'email est moins automatisable (plus de variabilité dans la formulation, plusieurs sujets regroupés). Le téléphone n'est pas couvert en phase 1 — décision délibérée de ne pas déployer de callbot vocal IA dans cette première phase.
Temps de réponse moyen. Une réponse automatisée est quasi immédiate, là où le traitement humain inclut file d'attente et temps de consultation du TMS.
Satisfaction client (CSAT). Mesurée via un micro-sondage post-interaction (une question, 5 étoiles). L'explication tient en une phrase : une réponse précise très rapide satisfait davantage qu'une réponse précise tardive.
Temps de coordinateur libéré. Les coordinateurs sont redirigés vers des activités à plus haute valeur : gestion des incidents critiques, animation de la relation grands comptes, optimisation des tournées, formation des nouveaux chauffeurs.
→ Prêt à passer à l’action ? Réservez un appel découverte de 15 minutes avec notre équipe pour analyser votre projet — sans engagement.
#Ce qui peut ne pas marcher
Tout projet honnêtement raconté intègre ses zones d'échec. Trois points de friction sont typiques.
Les réclamations transporteurs complexes. Les litiges impliquant une question de responsabilité sur une marchandise abîmée pendant le transport (rupture de la chaîne du froid, casse) révèlent vite les limites du périmètre. L'agent, correctement configuré pour ne pas se prononcer sur les aspects juridiques et financiers, escalade 100 % de ces cas.
Solution : un flux d'escalade spécifique vers le responsable sinistres, avec pré-remplissage automatique d'un formulaire de réclamation depuis les données du TMS. L'agent ne résout pas la réclamation, mais qualifie et prépare.
Les clients non digitaux. Une partie des clients — souvent de petits producteurs agroalimentaires avec peu d'habitude des canaux digitaux — continue à appeler le standard général. La coexistence avec l'équipe humaine se maintient sans friction : le standard humain gère ces appels, l'agent gère les canaux digitaux.
La sécurité des agents IA selon l'OWASP LLM Top 10 doit par ailleurs être auditée pour s'assurer qu'un appel entrant ne peut pas contourner le périmètre de l'agent via injection de prompt.
Des hallucinations sur les ETA. Un cas typique : l'agent affiche un ETA calculé depuis un cache périmé (données antérieures à un retard non répercuté). Correction : validation obligatoire via un appel API live au TMS avant tout affichage d'ETA, sans exception même en cas de cache disponible.
#La montée en charge
Après une période de production stable, l'entreprise peut lancer une phase 2 du projet.

Déploiement d'un callbot vocal. Architecture Twilio + Speech-to-Text + LLM pour le traitement de la voix, sur un numéro dédié logistique plutôt que sur le standard général. Les mêmes motifs que les canaux digitaux sont traités. Le déploiement d'un callbot vocal IA montre que l'orchestration LLM est identique au canal texte — seule la couche STT/TTS change.
Agent proactif sortant. Nouveau cas d'usage : notification automatique par SMS/WhatsApp sortant la veille de la livraison et quelques heures avant l'arrivée estimée. Données issues du TMS, message personnalisé avec créneau horaire, numéro du chauffeur et code d'accès quai si nécessaire. La logique est simple — si le client a l'information avant d'en avoir besoin, il n'appelle pas.
Extension géographique. Les autres sites sont intégrés dans le même déploiement. Adaptation nécessaire : création de contextes système spécifiques par site (procédures de quai différentes, SLA clients locaux), sinon l'infrastructure est identique.
LangGraph, CrewAI et n8n pour orchestrer les agents sont à réévaluer à ce stade pour la coordination multi-agents (plusieurs sites avec des contextes distincts). n8n convient à l'orchestration des workflows d'envoi proactif ; LangGraph peut être évalué pour une phase 3 avec orchestration d'agents plus complexes.
#Mesurer le retour sur investissement
La méthode de calcul du ROI d'un agent IA est directe : coûts complets versus gains mesurés, sans projections spéculatives.
Coûts à compter.
- Développement et déploiement des phases 1 et 2
- Support et itérations sur les premiers mois
- Coût récurrent annuel : infrastructure (API du LLM, Redis, Twilio, Speech-to-Text, base vectorielle hébergée) + maintenance
Gains à mesurer.
- Temps de coordinateur redirigé vers des tâches à plus haute valeur (à valoriser au coût chargé moyen d'un coordinateur)
- Amélioration du CSAT et de la rapidité de réponse : un meilleur service peut sécuriser le renouvellement de contrats grands comptes
- Valeur de CA maintenu, estimée prudemment
On calcule ensuite le payback sur les gains seuls, puis en intégrant le coût récurrent annuel. À partir de l'année 2, la structure de coûts change radicalement : seul le récurrent reste, pour des gains maintenus.
#Les leçons pour un projet similaire
Cinq enseignements structurants ressortent de ce type de projet dans le secteur transport-logistique.
Intégrer le TMS dès le jour 1. Sans accès temps réel aux données du TMS, l'agent n'a qu'une base documentaire statique — les questions les plus fréquentes (statut, ETA, température) ne peuvent pas être traitées. La valeur est dans la donnée live, pas dans la documentation. Tout projet agent IA logistique qui commence par la « base de connaissance » avant l'intégration TMS part dans le mauvais sens.
Voir comment la plateforme agents IA de Nehos gère ces intégrations TMS.
Définir précisément le périmètre d'escalade. L'agent est configuré pour reconnaître les cas où son niveau de confiance est insuffisant pour répondre seul. La définition de ce périmètre (quelles questions ? avec quel seuil de confiance ?) est un travail métier, pas technique. Elle prend du temps lors du diagnostic et conditionne l'ensemble de la qualité en production.
Le WhatsApp Business avant le callbot. Retour plus rapide, déploiement bien plus simple (pas de STT/TTS, pas de gestion des silences et des interruptions), taux d'automatisation plus élevé. Le WhatsApp Business IA : cas d'usage et mise en œuvre est le premier canal à adresser pour toute entreprise logistique dont les clients sont des professionnels B2B.
Former les coordinateurs comme superviseurs IA, pas comme remplacés par l'IA. La résistance au changement est quasi nulle quand le discours est clair dès le lancement : « vous ne perdrez pas votre travail, vous le changez ». Les coordinateurs sont redirigés vers des missions qu'ils jugent eux-mêmes plus intéressantes.
L'interface de supervision leur donne une visibilité totale et un bouton « reprendre la main » en permanence. Ce positionnement n'est pas de la communication interne — c'est une condition de succès.
Mesurer le CSAT à chaque interaction automatisée. Le CSAT post-interaction (une question, 5 étoiles, optionnel) est l'indicateur de dérive précoce le plus fiable. Une baisse sur plusieurs centaines d'interactions consécutives doit déclencher une analyse, qui peut révéler un bug sur un cas précis (par exemple la gestion des POD pour une famille de clients). Sans cette mesure systématique, la dérive reste invisible pendant des semaines.
Sur l'architecture de sécurité : les données de livraison client (noms, adresses, plages horaires) qui transitent par l'agent sont des données personnelles au sens du RGPD. Un DPA (Data Processing Agreement) avec le fournisseur du LLM doit être signé avant le go-live. La sécurité des agents IA selon l'OWASP LLM Top 10 doit être appliquée point par point, notamment sur la prévention des injections de prompt via les emails entrants.
Pour nos services agent IA sur mesure dans le secteur logistique, l'architecture est reproductible ; la configuration métier est sur mesure (chaque entreprise a son TMS, ses clients, ses SLA). Un MVP d'agent IA démarre à 11 000 € HT, et un audit IA express d'une journée coûte 990 € HT (déduit du projet s'il est lancé dans les trois mois).
Photos : Pavel Danilyuk, MART PRODUCTION sur Pexels.
Questions & réponses
Questions fréquentes : agent IA et TMS logistique
L'intégration repose sur l'API REST exposée par le TMS (Generix, Hardis, etc.) — l'agent IA appelle ces endpoints pour récupérer les données en temps réel (statut livraison, ETA, température, POD). Techniquement, un "outil" est déclaré dans la configuration de l'agent : une fonction Python qui formate la requête, interroge l'API TMS et retourne la réponse structurée. L'agent décide seul, selon la question reçue, s'il doit appeler cet outil. La qualité de l'intégration dépend de la richesse de l'API TMS et de la granularité des données exposées — certains éditeurs ont des APIs documentées, mais certains TMS legacy nécessitent une couche d'abstraction intermédiaire.
Oui, avec une couche OCR en amont. Les documents CMR et BL (lettres de voiture, bons de livraison) sont des PDFs ou images qui nécessitent une extraction avant traitement par l'agent. La chaîne technique : OCR (Azure Document Intelligence ou AWS Textract pour les documents de transport) → extraction des champs clés → enrichissement du contexte agent. En phase 1, on peut exclure ce cas d'usage pour accélérer le déploiement. En phase 3, l'agent pourra répondre à « pouvez-vous me renvoyer le CMR de la livraison du 15 mai ? » en récupérant et transmettant le document directement.
Les données de livraison (nom du destinataire, adresse, créneau horaire) constituent des données personnelles au sens du RGPD. Leur traitement par un système IA requiert une base légale (contrat ou intérêt légitime pour la gestion opérationnelle des livraisons), un registre des traitements mis à jour, et si le LLM est hébergé par un tiers (Anthropic, OpenAI), un DPA (Data Processing Agreement) conforme article 28 RGPD. Pour les données pharmaceutiques spécifiquement, des exigences additionnelles s'appliquent (qualification des fournisseurs IT selon les BPF). Nous recommandons une qualification RGPD avant go-live sur ces projets.
Dans l'exemple, un cache Redis court est retenu pour les données statiques (procédures, SLA clients), mais les données dynamiques comme l'ETA et le statut de livraison ne sont jamais cachées — elles sont interrogées en temps réel à chaque requête. C'est la leçon tirée des hallucinations sur ETA. La règle : toute donnée pouvant changer rapidement ne doit pas être mise en cache. Pour une donnée stable (ex : confirmation d'enlèvement déjà effectué), un cache court est acceptable pour réduire la charge sur l'API du TMS.
Techniquement oui — les API de nombreux TMS exposent des endpoints en écriture. Mais la recommandation Nehos est ferme : aucune écriture automatique dans le TMS sans validation humaine en phase 1. Les modifications de livraison (reprogrammation, changement d'adresse) ont des conséquences opérationnelles immédiates sur les chauffeurs et les quais. Une phase 2 peut prévoir la création automatique de réclamations dans le CRM (pas dans le TMS), avec transmission du contexte pré-rempli au responsable sinistres. Les modifications TMS nécessitent une phase de test prolongée et un audit de sécurité spécifique avant toute autonomie.
Les grands comptes disposant de leur propre portail de suivi (EDI, API clients, portails type Shiptify ou Transporeon) se traitent en configuration d'exception. Pour ces clients, les questions de statut passent par leur propre système — l'agent IA cible principalement les contacts entrants non structurés (WhatsApp, email libre, appel). Pour les clients avec intégration EDI active, l'agent peut néanmoins gérer les écarts entre leur portail et la réalité terrain, ainsi que les demandes hors système (document exceptionnel, réclamation, contact direct chauffeur).
Parlons de votre projet
Un devis chiffré, sans engagement
Décrivez votre besoin en deux minutes : un consultant senior vous répond avec une première estimation et les prochaines étapes.
- Réponse sous 24 h ouvrées
- Sans engagement
- Un consultant senior vous répond