Ce que coûte un mauvais aiguillage
Une demande mal orientée n’est pas simplement retardée. Elle est traitée plusieurs fois.
Quelqu’un l’ouvre, la lit, comprend que ce n’est pas pour lui, la transfère. Une deuxième personne fait la même chose. Le temps cumulé de lecture dépasse parfois le temps de résolution, et le client, lui, ne voit qu’une chose : le silence.
Trois défaillances se combinent dans la plupart des organisations.
Le tri en lot. Quelqu’un dépouille la file le matin. Une demande arrivée à dix heures attend le lendemain matin.
L’attribution nominative. Les demandes vont à la personne qu’on connaît plutôt qu’à celle qui est disponible. Résultat : deux personnes saturées, deux autres en attente.
Le suivi d’engagement à la main. Les délais contractuels sont surveillés par quelqu’un qui regarde une liste, quand il y pense. Un dépassement se constate au moment du dépassement, c’est-à-dire trop tard.
Ce qu’on automatise
La captation multicanale. Messages, formulaire, téléphone, canal client — une file unique.
La classification. Sujet, produit ou service concerné, type de demande, gravité.
L’identification du client et de son contrat, avec les engagements qui en découlent.
Le rattachement. Fil existant, dossier ouvert, incident en cours qui touche plusieurs clients.
L’attribution selon compétence, disponibilité et charge réelle.
Le compteur d’engagement, en heures ouvrées, avec mise en pause pendant l’attente d’une réponse client.
L’escalade avant échéance, graduée.
La détection de récurrence. Plusieurs demandes similaires en peu de temps : signal d’un incident général, remonté immédiatement plutôt que traité dossier par dossier.
Comment ça marche techniquement — pour qui veut le détail
Le rattachement au fil. Sur les demandes par courriel, on utilise les en-têtes Message-ID, In-Reply-To et References, jamais le sujet du message — un sujet se modifie, se traduit, se voit ajouter des préfixes par les clients de messagerie. En complément, un jeton de référence inséré dans le corps des réponses sortantes permet de rattacher même quand les en-têtes sont perdus par un client de messagerie mal élevé.
La classification. Deux étages. Un classifieur léger entraîné sur votre historique — régression logistique ou SVM linéaire sur des vecteurs TF-IDF, ou un petit modèle de type SetFit — traite la grande majorité des demandes en quelques millisecondes, localement, pour un coût nul. Il est entraîné sur vos catégories réelles et se réentraîne sur les corrections. Un modèle de langage n’intervient que sur les demandes dont le classifieur est peu sûr, avec une sortie contrainte par schéma. Cette architecture coûte très peu et se révèle souvent plus stable qu’un appel systématique à un grand modèle.
La découverte des catégories. Au démarrage, on ne devine pas la taxonomie : on calcule des plongements de six à douze mois de demandes passées avec un modèle local, on regroupe par classification non supervisée — HDBSCAN sur une projection UMAP donne des groupes propres sans exiger de fixer leur nombre à l’avance —, et on présente les groupes obtenus avec leurs exemples représentatifs. L’équipe nomme et fusionne. La taxonomie qui sort de là est presque toujours meilleure que celle qui figurait dans l’ancien outil.
Le calcul de gravité. Somme pondérée de signaux explicites : présence de termes d’indisponibilité, nombre d’utilisateurs affectés quand il est mentionné, niveau de contrat, historique récent du client, ancienneté de la demande. Le résultat est une matrice impact × urgence lisible, pas un score opaque — un responsable doit pouvoir expliquer à un client pourquoi sa demande est en priorité trois.
L’attribution. Le problème est une affectation sous contraintes : compétences requises, disponibilité au calendrier, charge courante pondérée par la difficulté, et équité sur la période. Un algorithme glouton avec scoring suffit très largement au volume d’une PME ; l’optimisation globale n’apporte rien de perceptible. La règle importante est ailleurs : l’attribution est révisable, et une reprise manuelle est journalisée pour ajuster les règles.
Le compteur d’engagement. Calcul en heures ouvrées à partir d’un calendrier paramétrable — horaires, jours fériés, astreintes — avec mise en pause automatique lorsque l’état passe à « en attente du client » et reprise à sa réponse. Table d’échéances consommée par un travailleur régulier via FOR UPDATE SKIP LOCKED, pour que les alertes survivent aux redémarrages. Seuils d’alerte en pourcentage du délai — 50 %, 75 %, 90 % — plutôt qu’en valeur absolue, pour que la mécanique vaille quel que soit l’engagement.
La détection d’incident général. Fenêtre glissante sur les plongements des demandes récentes : une concentration anormale de demandes proches en peu de temps déclenche un signalement. Comparaison à la fréquence de base par catégorie pour éviter les fausses alertes sur les sujets naturellement fréquents. Détecter qu’une panne touche quinze clients avant d’avoir répondu quinze fois individuellement est le gain le plus spectaculaire de ce type de système.
La déduplication. Un client qui écrit trois fois en dix minutes ne crée pas trois dossiers : fenêtre de regroupement par expéditeur et proximité sémantique. Les messages sont ajoutés au même fil.
Les indicateurs. Délai de première réponse et délai de résolution en médiane et en neuvième décile — la moyenne masque précisément les cas qui font les clients mécontents —, taux de réattribution, taux de réouverture, répartition par catégorie. Le taux de réattribution mesure directement la qualité du routage et guide les corrections.