L'essentiel
ThermoTrans, ETI de transport températuré (320 salariés, 45 véhicules, 280 000 livraisons/an), consacrait 22 % du temps de ses 8 coordinateurs à répondre à 2 000 contacts mensuels sur le statut des livraisons — un gisement de productivité identifiable et mesurable.
En 6 semaines de développement, Nehos a déployé un agent IA (Claude 3.7 Sonnet + RAG sur 200 procédures + API TMS Akanea temps réel) connecté à WhatsApp Business et aux emails entrants, avec escalade automatique vers HubSpot pour les cas hors périmètre.
À 3 mois, le taux d'automatisation atteignait 68 % des contacts, le temps de réponse tombait de 47 minutes à 3 minutes, et le CSAT passait de 4,1 à 4,6/5 — avec 2,8 ETP libérés pour des tâches à plus haute valeur.
Le ROI total sur 12 mois s'établit114 2 304 € nets (gains ETP + contrats sauvegardés), pour un investissement de81 3 968 € — payback en 8,9 mois.
Cinq leçons structurantes émergent de ce projet, transposables à toute ETI logistique : intégration TMS dès le jour 1, périmètre d'escalade défini précisément, WhatsApp avant le callbot, coordinateurs formés comme superviseurs IA, CSAT mesuré à chaque interaction.
ThermoTrans : comment un agent IA connecté au TMS a automatisé 68 % des contacts clients
Récit complet d'un projet de 6 semaines pour une ETI logistique de 320 salariés — architecture, résultats à 12 mois et leçons transmissibles à tout transporteur.
Adapté à toute taille de structure
#Le contexte : ThermoTrans, ETI logistique de 320 salariés
ThermoTrans (nom fictif, profil composite issu de projets réels Nehos) est un transporteur spécialisé dans la chaîne du froid pharmaceutique et agroalimentaire. 320 salariés, 45 véhicules frigorifiques, trois sites d'exploitation à Toulouse, Lyon et Nantes. Le chiffre qui compte : 280 000 livraisons annuelles — soit 760 livraisons chaque jour ouvré, 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. Huit coordinateurs logistiques passaient 22 % de leur temps de travail 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". Volume mesuré sur 3 mois avant le projet : 1 200 appels entrants par mois et 800 emails sur ce seul sujet.
Cela représente un équivalent plein temps de 1,8 ETP occupé exclusivement à répondre à des questions dont 78 % trouvent leur réponse dans une seule source — le TMS Akanea, en place depuis 2019.
#Le diagnostic initial (mois 1)
L'audit Nehos a débuté par une cartographie exhaustive des contacts entrants : 200 types de questions différentes recensés à partir de s logs emails, des enregistrements d'appels et des entretiens avec les coordinateurs. Résultat inattendu pour l'équipe ThermoTrans : 78 % du volume se concentrait sur seulement 12 motifs récurrents.
Ces 12 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 Akanea a révélé que ces 12 motifs correspondaient tous à des données déjà disponibles dans le TMS — en temps réel pour la plupart. La conclusion était évidente : 78 % des contacts humains traitaient des données que la machine détenait déjà et pouvait 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 procédures, couplé à une API TMS Akanea 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 retenue
L'architecture déployée repose sur cinq couches fonctionnelles distinctes, chacune ayant un rôle précis dans la chaîne de traitement.
Couche LLM. Claude 3.7 Sonnet 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. Base vectorielle Qdrant indexant 200 documents de procédures internes ThermoTrans (procédures d'exploitation, règles de traçabilité températuré, SLA clients, procédure de réclamation). Modèle d'embedding bge-m3 pour le français. Mise à jour hebdomadaire automatisée via pipeline Python. L'architecture RAG pour connecter l'agent aux données internes a permis de répondre aux questions contextuelles sans coder chaque règle en dur.
Couche données temps réel. Intégration API REST vers Akanea (consultation statut livraison, ETA calculé, relevés température, POD disponibilité). 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 12 motifs 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. HubSpot CRM : toute interaction que l'agent ne peut pas résoudre avec un score de confiance > 0,85 crée automatiquement un ticket HubSpot assigné au coordinateur de permanence, avec le contexte complet de l'échange.
Le standard MCP (Model Context Protocol) pour les agents a été évalué pour l'intégration Akanea — retenu pour la phase 2 uniquement, la phase 1 utilisant une intégration REST directe plus rapide à déployer.
#Le développement : 6 semaines réelles
La cadence de développement a été maintenue sans dérapage grâce à un périmètre fonctionnel strictement borné dès le lancement.
Semaines 1-2 : socle technique. Intégration de l'API Akanea avec mapping des 12 types de requêtes et de leurs champs de réponse. Construction du pipeline RAG sur la base documentaire procédures. Premier prompt système configuré avec les règles de gestion ThermoTrans. Incident identifié en fin de semaine 2 : l'API Akanea présentait des timeouts répétés entre 2h et 5h du matin (plage de batch). Solution : retry exponentiel + cache Redis 5 minutes sur les données statiques (ETA calculé, statut confirmé).
Semaine 3 : canal WhatsApp. Connexion WhatsApp Business API via Twilio, configuration des webhooks n8n, routage par numéro de téléphone vers le contexte client dans Akanea. Tests avec 15 numéros internes.
Semaine 4 : classification emails. Pipeline NLP pour catégoriser les emails entrants sur la boîte générale logistique@thermotrans.fr. Taux de classification correcte sur le corpus de test : 91 % sur les 12 motifs définis, 94 % pour la détection des emails hors périmètre.
Semaine 5 : validation sur données réelles. Tests sur 50 cas historiques anonymisés tirés des 3 derniers mois. Recall global de l'agent sur les 12 motifs : 89 %. Les 11 % d'échecs se répartissent entre : contexte insuffisant dans la question (4 %), données TMS manquantes ou en erreur (4 %), cas limites hors documentation (3 %).
Semaine 6 : pilote contrôlé. Déploiement avec 3 clients volontaires (représentant 8 % du volume de contacts). Formation de 2 coordinateurs à la supervision via l'interface web. Aucun incident majeur sur les 5 premiers jours. Feu vert déploiement complet.
#Les résultats à 3 mois (M1 à M3)
Les chiffres mesurés sur les 3 premiers mois post-déploiement complet ont dépassé les objectifs fixés lors du diagnostic.
Taux d'automatisation global : 68 %. Sur 100 contacts entrants, 68 sont résolus par l'agent sans intervention humaine. Le résidu de 32 % correspond aux réclamations complexes (litige marchandise, responsabilité transporteur), aux clients non-digitaux préférant le téléphone (encore non déployé), et aux cas hors périmètre des 12 motifs.
Par canal. WhatsApp Business : 82 % d'automatisation (canal le plus adapté — questions courtes, contexte clair, clients habitués aux réponses rapides). Email : 61 % d'automatisation (plus de variabilité dans la formulation, certains emails regroupent plusieurs sujets). Téléphone : 0 % en phase 1 — la décision a été prise délibérément de ne pas déployer de callbot vocal IA dans cette première phase, 90 % des contacts étant déjà digitaux.
Temps de réponse moyen. 3 minutes pour une réponse automatisée, contre 47 minutes en traitement humain (incluant file d'attente et temps de consultation TMS). Réduction de 94 %.
Satisfaction client (CSAT). Mesuré via micro-sondage post-interaction (1 question, 5 étoiles). Score moyen : 4,6/5 sur les interactions automatisées, contre 4,1/5 sur les interactions humaines avant déploiement. L'explication tient en une phrase : une réponse précise en 3 minutes satisfait davantage qu'une réponse précise en 47 minutes.
ETP libérés. 2,8 ETP sur 8 coordinateurs 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 n'a pas marché
Tout projet honnêtement raconté intègre ses zones d'échec. Trois points de friction ont émergé.
Les réclamations transporteurs complexes. Les litiges impliquant une question de responsabilité sur une marchandise abîmée pendant le transport (rupture chaîne du froid, casse) ont rapidement révélé les limites du périmètre. L'agent, correctement configuré pour ne pas se prononcer sur les aspects juridiques et financiers, escaladait 100 % de ces cas. Solution déployée dès le mois 2 : un flux d'escalade spécifique vers le responsable sinistres, avec pré-remplissage automatique d'un formulaire de réclamation depuis les données TMS. L'agent ne résout pas la réclamation, mais qualifie et prépare.
Les clients non-digitaux. 5 % du volume de clients — majoritairement de petits producteurs agroalimentaires avec peu d'habitude des canaux digitaux — ont continué à appeler le standard général. La coexistence avec l'équipe humaine a été maintenue 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 a par ailleurs été auditée à ce moment pour s'assurer qu'un appel entrant ne pouvait pas contourner le périmètre de l'agent via injection de prompt.
Quelques hallucinations sur des ETA. Trois cas documentés en mois 1 où l'agent avait affiché un ETA calculé depuis un cache Redis périmé (données antérieures à un retard non répercuté). Correction immédiate : validation obligatoire via appel API TMS live avant tout affichage d'ETA, sans exception même en cas de cache disponible. Depuis cette correction, zéro hallucination sur les données temps réel.
#La montée en charge (M4 à M8)
Avec 3 mois de production stable, ThermoTrans a lancé la phase 2 du projet.
Déploiement callbot vocal. Architecture Twilio + Azure Speech-to-Text + Claude pour le traitement de la voix. Déployé sur le numéro dédié logistique uniquement (pas le standard général). Résultat à 2 mois : 35 % des appels entrants traités automatiquement, sur les mêmes motifs que les canaux digitaux. Le déploiement d'un callbot vocal IA a démontré que l'orchestration LLM était identique au canal texte — seule la couche STT/TTS change.
Agent proactif sortant. Nouveau cas d'usage : notification automatique par SMS/WhatsApp sortant à J-1 (veille de livraison) et H-2 (2 heures avant l'arrivée estimée). Données issues d'Akanea, message personnalisé avec créneau horaire, numéro du chauffeur et code d'accès quai si nécessaire. Résultat : appels entrants "où est ma livraison" en baisse de 43 % supplémentaire sur les 2 mois suivants. La logique est simple — si le client a l'information avant d'en avoir besoin, il n'appelle pas.
Extension géographique. Les sites de Lyon et Nantes ont été 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 était identique.
LangGraph, CrewAI et n8n pour orchestrer les agents ont été réévalués à ce stade pour la coordination multi-agents (Toulouse + Lyon + Nantes avec des contextes distincts). n8n a été retenu pour l'orchestration des workflows d'envoi proactif, LangGraph évalué pour la phase 3 avec orchestration d'agents plus complexes.
#ROI calculé à 12 mois
La méthode de calcul du ROI d'un agent IA appliquée ici est directe : coûts complets versus gains mesurés, sans projections spéculatives.
Coûts totaux.
- Développement et déploiement phase 1 + phase 2 (Nehos) :7 6 272 €
- Support et itérations sur 6 mois inclus dans le forfait : 12 544 €
- Total investissement projet :81 3 968 €
- Coût récurrent annuel : infrastructure (API Claude, Redis, Twilio, Azure STT, Qdrant hébergé) + maintenance Nehos =à partir de 5 500 €/an
Gains mesurés sur 12 mois.
- 2,8 ETP redirigés vers des tâches à plus haute valeur. Coût chargé moyen coordinateur : à partir de 745 €/an. Gain valorisé : 2,8 × 42 000 =12 7 680 €
- Amélioration CSAT (4,1 → 4,6/5) et réponse 94 % plus rapide : identification de 2 contrats grand compte en risque de non-renouvellement (CSAT déclaré insuffisant lors des revues annuelles client). Ces 2 contrats ont été renouvelés. Valeur estimée sur l'année : à partir de 1 362 € de CA maintenu.
- Total gains bruts an 1 :193 12 416 €
ROI net an 1 : 199 600 - 85 000 =114 2 304 € Payback : 85 000 / (199 600 / 12) = 5,1 mois sur les gains seuls, soit 8,9 mois en neutralisant le coût récurrent annuel dès l'année 1.
Sur l'année 2, la structure de coûts change radicalement : à partir de 5 500 € de récurrent pour des gains maintenus (les ETP sont désormais alloués à d'autres missions, les contrats renouvelés). Le ROI annuel récurrent estimé dépasse18 9 472 €.
#Les leçons pour un projet similaire
Cinq enseignements structurants ressortent de ce projet — chacun vérifié sur d'autres missions Nehos dans le secteur transport-logistique.
Intégrer le TMS dès le jour 1. Sans accès temps réel aux données Akanea, l'agent n'aurait eu qu'une base documentaire statique — les questions les plus fréquentes (statut, ETA, température) n'auraient pas pu ê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 nativement.
Définir précisément le périmètre d'escalade. L'agent sait ce qu'il ne sait pas — ou plutôt, il 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 2 à 3 jours lors du diagnostic et conditionne l'ensemble de la qualité en production.
Le WhatsApp Business avant le callbot. ROI plus rapide, déploiement 3× plus simple (pas de STT/TTS, pas de gestion des silences et des interruptions), taux d'automatisation plus élevé (82 % vs 35 % pour les appels). 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 sur ce projet a été quasi-nulle — et ce n'est pas un hasard. Le discours dès le lancement : "vous ne perdrez pas votre travail, vous le changez." Les 2,8 ETP libérés ont été redirigés vers des missions que les coordinateurs eux-mêmes jugeaient 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 de 0,3 point sur 200 interactions consécutives a déclenché une analyse qui a révélé un bug sur la gestion des POD pour une famille de clients pharmaceutiques. Détecté en 48 heures. Sans ce mesure systématique, la dérive aurait été invisible pendant des semaines.
Sur l'architecture de sécurité : les données de livraison client (noms, adresses, plages horaires) transitant par l'agent constituent des données personnelles au sens du RGPD. Un DPA (Data Processing Agreement) avec Anthropic a été signé avant le go-live. La sécurité des agents IA selon l'OWASP LLM Top 10 a été 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, les délais et architectures décrites ici sont représentatifs des projets ETI que nous conduisons. Chaque entreprise a son TMS, ses clients, ses SLA — l'architecture est reproductible, la configuration métier est sur mesure.
Sources
- https://www.gs1.fr/nos-solutions/tracabilite
- https://www.ecr-france.org/publications/ia-supply-chain-retours-experience-2025
- https://www.gartner.com/en/documents/magic-quadrant-transportation-management-systems-2025
- https://www.twilio.com/en-us/state-of-customer-engagement/logistics-2025
- https://www.dhl.com/global-en/delivered/innovation/logistics-trend-radar-2025.html