Imaginons une PME de logistique de 12 personnes qui coordonne du fret régional sur le corridor du Saint-Laurent : une équipe qui fait le travail opérationnel d'une entreprise deux fois plus grande. Leur boîte de réception est un organisme vivant. Confirmations de transporteurs, escalades de retards, demandes de tarifs, signalements douaniers, et à l'occasion un expéditeur à bout de patience qui a besoin que quelqu'un, n'importe qui, lui réponde maintenant, à 23 h 30 un mardi soir.
Avant le déploiement, « maintenant » voulait dire le matin. L'équipe couvrait les heures ouvrables avec une discipline raisonnable ; en dehors de ces heures, il n'y avait qu'une seule rotation d'astreinte qui, dans les faits, laissait les courriels en attente jusqu'à 7 h. Temps de première réponse moyen hors heures : six heures et douze minutes. Pas catastrophique selon les normes du secteur. Tout de même un handicap concurrentiel quand deux de leurs cinq plus gros comptes magasinaient activement chez des alternatives.
Ce qui rendait le problème difficile
Un simple « répondeur automatique » n'a jamais été une option. Les opérations logistiques comportent une vraie responsabilité juridique. Une fenêtre de livraison incorrecte, un statut douanier mal communiqué ou un remplacement de transporteur raté peuvent se transformer en milliers de dollars de surestaries ou en relation client brisée. Le système devait être réellement juste ou explicitement incertain, jamais faux avec assurance.
La deuxième contrainte était la fragmentation des données. L'équipe opérait sur trois systèmes : un TMS (système de gestion du transport) patrimonial avec une API en lecture seule, un portail transporteur extrait par scraping parce qu'aucune API n'existait, et une boîte de réception opérationnelle partagée dans Gmail qui était, dans les faits, la source de vérité pour tout ce qui était tombé dans les mailles des deux autres. Tout agent traitant des requêtes clients devait raisonner à travers ces trois sources, avec exactitude.
Troisièmement : l'équipe devait lui faire confiance. Un système que le personnel opérationnel perçoit comme une responsabilité dont il doit nettoyer les erreurs est pire qu'aucun système. Chaque brouillon produit, chaque escalade soulevée, devait sembler juste. Pas plausible, juste.
Quatre couches, une boucle
La couche d'ingestion est volontairement simple. Trois sources (Gmail via webhook, TMS via interrogation toutes les 90 secondes, et un portail transporteur via un scraper Playwright léger) convergent toutes vers une file d'événements unifiée. Aucun traitement n'a lieu ici. C'est un tuyau.
Le classificateur est là que vit la première vraie décision. Chaque message entrant reçoit une étiquette d'intention et un score de confiance. Les étiquettes couvrent quatorze catégories : requête de date d'arrivée estimée, statut d'expédition, demande de tarif, remplacement de transporteur, signalement douanier, escalade, et huit autres. Tout ce qui passe sous 0.82 de confiance est immédiatement signalé pour un acheminement humain. Le système n'essaie pas de classifier les choses ambiguës.
Le copilote ancré, la couche qui rédige effectivement les réponses, ne peut affirmer que ce qu'il peut citer. Il tire le contexte du retriever TMS, le confronte à la requête entrante et génère un brouillon avec des citations en ligne vers les enregistrements sources. Si un statut d'expédition ne peut pas être récupéré, le brouillon le dit explicitement. Le copilote n'a pas accès au bouton d'envoi. Il produit du texte. Le budget de confiance décide de la suite.
Ce qui est automatisé, et pourquoi
| Intention | Volume | Traitement | Justification |
|---|---|---|---|
| Requête de statut d'expédition | 34 % | envoi automatique | Entièrement ancré dans le TMS. Aucune ambiguïté, aucune responsabilité. |
| Confirmation d'arrivée estimée (DAE) | 18 % | envoi automatique | Source de vérité unique. Le scraper transporteur valide. |
| Demande de tarif (compte existant) | 11 % | envoi automatique | Table des tarifs à jour. Budget de confiance rarement épuisé. |
| Demande de preuve de livraison | 10 % | envoi automatique | Récupération de document, aucun jugement requis. |
| Demande de remplacement de transporteur | 9 % | brouillon + révision | Le copilote rédige les options. L'équipe ops confirme avant l'envoi. |
| Signalement douanier ou de conformité | 6 % | brouillon + révision | Surface de responsabilité trop élevée pour un envoi autonome. |
| Ouverture d'une réclamation ou d'un litige | 4 % | escalade | Requiert un responsable ops nommé. Aucune automatisation. |
| Ambiguë ou à intentions multiples | 8 % | escalade | Sous le seuil de confiance. Un humain classe et achemine. |
La décision de ce qu'on automatise n'est pas une question de confiance. C'est une question de responsabilité. Le statut d'expédition et la confirmation de date d'arrivée sont entièrement récupérables depuis un seul système de référence, donc ils partent en envoi automatique. Le remplacement de transporteur est aussi récupérable, mais les conséquences en aval d'une erreur (surestaries, pénalités de retard, fenêtres douanières manquées) sont assez importantes pour que l'équipe veuille un humain dans la boucle, peu importe le score de confiance du copilote. L'ouverture de réclamation et de litige n'est jamais automatisée. Jamais.
Douze semaines après le lancement
| métrique | avant | après | signal |
|---|---|---|---|
| première réponse hors heures (p50) | 6 h 12 | 4 min | −99 % |
| entrants acheminés de façon autonome | 0 % | 73 % | net new |
| envois automatiques incorrects | n/a | 0 / 90 j | cible atteinte |
| capacité ops par ETP | 1,0× | 2,1× | +110 % |
| delta d'effectif | 12 | 12 | inchangé |
Le chiffre de zéro envoi automatique incorrect est celui qui compte le plus pour l'équipe. Le budget de confiance et la politique de rédaction citée exclusivement ont amené le système à échouer de façon visible plutôt que silencieuse. Sur la fenêtre modélisée de 90 jours, onze cas se sont présentés où le copilote avait suffisamment de confiance pour rédiger un brouillon mais pas assez d'ancrage pour citer. Les onze ont été correctement interceptés par la porte de secours et escaladés. Aucun expéditeur n'a reçu un statut fabriqué.
Le chiffre de 2,1× de capacité ops par ETP est celui qui compte le plus pour la direction. L'équipe n'est pas plus grande. Ce qui a changé, c'est la composition du travail : les heures précédemment consacrées aux requêtes de statut, aux demandes de preuve de livraison et aux confirmations de date d'arrivée routinières vont maintenant vers les cas complexes qui nécessitent réellement un humain (les litiges, les négociations avec les transporteurs, la gestion des exceptions). Le plafond de ce que 12 personnes peuvent accomplir a bougé sans ajouter d'effectif.
Ce qui n'a pas fonctionné
Le scraper transporteur est fragile. Deux des neuf transporteurs de leur réseau mettent à jour irrégulièrement le balisage de leur portail, ce qui brise le scraper en silence. On n'obtient pas d'erreur, on obtient des données périmées que le budget de confiance traite comme fraîches. La correction consiste à apposer un horodatage de fraîcheur sur chaque enregistrement extrait et à fixer un plafond strict sur l'ancienneté acceptable des données transporteur avant que le copilote soit forcé de dire qu'il ne sait pas. Ce plafond est maintenant de 4 heures. Au-delà, le brouillon est signalé peu importe le score de confiance.
Le jeu de données d'entraînement initial du classificateur était trop propre. Les courriels opérationnels réels sont désordonnés : fils renvoyés avec trois niveaux de texte cité, messages mi-français mi-anglais en milieu de phrase, abréviations absentes de tout corpus d'entraînement. La précision du classificateur en première semaine était de 0.74 sur le trafic réel contre 0.91 sur les données de test réservées. Deux semaines de mode shadow en production avec des étiquettes humaines ont comblé cet écart à 0.88.
Enfin : l'expérience d'escalade n'était pas assez bonne au lancement. Quand le système escaladait quelque chose, il envoyait une notification Slack avec un lien et l'étiquette d'intention. Ce n'est pas suffisant de contexte pour quelqu'un réveillé à 2 h du matin. La version deux accompagne l'escalade du brouillon complet, du contexte récupéré et de la raison précise pour laquelle le budget de confiance a été déclenché. Le temps de réponse sur les fils escaladés a chuté de 40 % après ce changement.
Si vous souhaitez qu'on examine où une pile d'automatisation des messages entrants rapporterait dans votre opération, le formulaire de contact est le moyen le plus rapide. Nous faisons des révisions gratuites de 30 minutes pour les systèmes en production.