Étude de cas · Triage support N1
Trier 800 tickets/jour sans embaucher.
Comment une couche IA bien posée peut remplacer deux ETP de tri N1 chez une PME SaaS de 30 personnes, et pourquoi le projet devait commencer par une architecture classique plutôt que par un chatbot.
Le contexte
Une PME SaaS B2B reçoit plusieurs centaines de demandes support par jour. La pile existe déjà : helpdesk, CRM, base clients, application PHP. Le problème n’est pas le manque d’outils, mais la charge humaine créée par le tri initial. Chaque ticket doit être lu, qualifié, priorisé, puis envoyé à la bonne personne. Le recrutement d’un second profil support N1 est envisagé, mais la marge rend la décision difficile.
Pourquoi j’ai failli refuser
Le premier brief demandait un chatbot. Mauvaise question. Un chatbot aurait ajouté une interface visible, difficile à maintenir et probablement frustrante pour les clients. Le vrai besoin n’était pas de répondre à leur place, mais de réduire le temps perdu avant qu’un humain compétent intervienne. Cette clarification change toute l’architecture.
Le vrai problème
L’analyse d’un échantillon montre trois familles : environ 30% des tickets relèvent de FAQ, 50% nécessitent un humain, 20% restent ambigus. La valeur n’est pas dans une réponse automatique totale. Elle est dans le routage, la qualification et la suggestion. Le système doit accélérer le support sans masquer les zones de doute.
L’architecture choisie
Pas un chatbot. Un classifieur et un routeur. Le webhook helpdesk déclenche un service Python qui nettoie le ticket, interroge un modèle avec un prompt versionné, puis renvoie une catégorie, un niveau de confiance et une suggestion. PHP conserve la logique métier, l’audit trail et les règles de fallback. Le LLM aide, mais ne décide pas seul.
Architecture — classifieur + routeur
Ce que j’ai testé avant de coder
Avant l’intégration, un eval set de 200 tickets annotés sert de référence. Une baseline par règles mesure ce que l’on peut faire sans IA. Ensuite seulement, le modèle est comparé sur précision, coût, stabilité et erreurs dangereuses. Si l’amélioration n’est pas nette, la couche IA est refusée.
L’intégration
Le flux final reste simple : webhook helpdesk, classifieur, tag, suggestion, validation humaine. Les tickets à forte confiance sont pré-triés. Les tickets ambigus restent visibles. Les agents support peuvent corriger la catégorie, ce qui alimente les jeux d’évaluation futurs.
Les garde-fous
Budget tokens mensuel, logs de prompts, version de modèle figée, kill switch, fallback déterministe. Un système IA en production doit pouvoir être coupé sans casser l’application. C’est cette contrainte qui sépare une intégration sérieuse d’une démo impressionnante.
Les résultats
Le temps moyen de traitement baisse d’environ 40% sur le tri initial. Le coût mensuel IA reste inférieur à un huitième d’un salaire chargé. Le gain principal n’est pas seulement financier : le support récupère de l’attention pour les cas complexes.
Ce que je referais autrement
J’ajouterais plus tôt une interface d’audit pour relire les décisions du modèle par période. Les logs existaient, mais une vue métier dédiée aurait accéléré les arbitrages avec l’équipe support. Le point n’est pas de rendre l’IA invisible, mais de la rendre gouvernable.