Classification automatique tickets : CamemBERT ou GPT 2026

Dans la plupart des équipes support, la journée commence par la même tâche : trier manuellement les tickets entrants, les catégoriser, les affecter à la bonne équipe. Pour un helpdesk qui reçoit 400 tickets par jour, c'est deux heures de travail chaque matin avant que quiconque ait traité le moindre problème réel.

La classification automatique de tickets par IA résout ce problème — mais uniquement si elle est mise en place dans le bon ordre. Le choix entre CamemBERT fine-tuné et GPT-4o mini n'est pas la première décision à prendre. La première décision, c'est la taxonomie. Sans taxonomie cohérente définie par le métier, aucun modèle ne peut être précis.

Cet article couvre l'intégralité du sujet : de la construction de la taxonomie au pipeline d'amélioration continue, en passant par le choix du modèle selon le volume, l'intégration Zendesk/Freshdesk, et les métriques qui comptent vraiment.

Le routing manuel de tickets : un coût invisible mais réel

Le triage manuel de tickets est l'un de ces coûts qui ne figure nulle part dans les bilans mais qui pèse lourd. Une personne qui passe deux heures chaque matin à trier et distribuer des tickets, c'est 40 jours travaillés par an consacrés à une tâche sans valeur ajoutée. Multipliez par le coût salarial chargé, et vous avez un chiffre concret.

Mais le coût caché le plus important n'est pas le temps du dispatcher. C'est le mauvais routage. Quand un ticket urgent atterrit dans la mauvaise file, il peut perdre 48 heures avant d'être redirigé. Sur un SLA de 4 heures, c'est une pénalité contractuelle. Sur un ticket d'un client VIP, c'est un risque de résiliation.

Pourquoi le FCR se dégrade sans classification fiable

Le First Contact Resolution (taux de résolution au premier contact) est le KPI roi du support. Il chute pour deux raisons liées au routing :

• Un ticket envoyé à la mauvaise équipe repart avec une réponse générique ou une demande de complément d'information, forçant le client à revenir.
• Les équipes mal dimensionnées (N2 surchargée de tickets N1 mal triés) priorisent mal et génèrent des temps d'attente excessifs.

La classification automatique résout les deux : routing précis en moins de 500 ms, priorité correctement attribuée, SLA déclenché immédiatement. Les gains mesurés sur nos projets sont cohérents avec les données du secteur : 40 à 60 % de réduction du temps moyen de prise en charge après déploiement.

Si vous êtes en train de définir le périmètre de votre projet, notre guide sur l'audit IA pour PME et ETI explique comment cadrer ce type d'initiative avant de commencer à coder.

La taxonomie comme prérequis dur

Voici la règle que nous répétons à chaque démarrage de projet : la classification n'est aussi bonne que la taxonomie qu'elle cible. Si les catégories se chevauchent, si les équipes ne s'accordent pas sur ce qu'un ticket "bug facturation" signifie exactement, aucun modèle ne peut être précis. Ce n'est pas une limite du modèle — c'est une impossibilité mathématique.

Un modèle apprend à reproduire les décisions humaines passées. Si ces décisions sont incohérentes, le modèle apprend l'incohérence.

Ce qui arrive quand on saute cette étape

Nous avons repris un projet déjà entamé par une autre équipe chez un éditeur SaaS. Le modèle avait été entraîné sur 18 mois d'historique. La précision macro en production était de 0,68, avec des classes entières que le modèle n'attribuait jamais.

Après diagnostic, le problème était simple : la catégorie "bug interface" et "bug fonctionnel" se recouvraient pour 40 % des tickets. Les agents avaient des pratiques différentes. Le modèle avait appris le chaos. Deux ateliers de redéfinition taxonomique plus tard, le modèle ré-entraîné sur les mêmes données mais avec des labels corrigés atteignait 0,89 de F1 macro.

Comment construire une taxonomie qui tient

Une bonne taxonomie pour la classification de tickets répond à trois critères : les catégories sont mutuellement exclusives (un ticket appartient à une seule catégorie principale), collectivement exhaustives (tout ticket peut être catégorisé), et actionnables (chaque catégorie déclenche un routage différent).

La structure hiérarchique à deux niveaux

Nous recommandons systématiquement une taxonomie à deux niveaux :

• Niveau 1 (catégorie) : 5 à 12 catégories larges, stables dans le temps. Exemples : panne matérielle, problème logiciel, question de facturation, demande de fonctionnalité, question d'usage.
• Niveau 2 (sous-catégorie) : 3 à 6 sous-catégories par catégorie de niveau 1, plus granulaires. Exemples sous "panne matérielle" : imprimante, réseau, poste de travail, périphérique.

Le niveau 1 pilote le routing d'équipe. Le niveau 2 pilote l'assignation à l'agent spécialisé ou le déclenchement d'une procédure spécifique.

Un exemple concret pour un helpdesk ITSM

La session d'atelier avec les équipes opérationnelles

La taxonomie ne se construit pas en silo par l'équipe technique. Les deux premières semaines d'un projet doivent inclure au minimum deux ateliers avec les agents et les managers support. Ces sessions permettent de :

• Identifier les cas limites et les zones de recouvrement entre catégories
• Définir une règle de décision écrite pour chaque frontière ambiguë
• Valider que chaque catégorie correspond à un traitement différent (sinon, la distinction ne sert à rien)
• Documenter les exemples canoniques de chaque catégorie pour guider l'annotation

Ce travail prend du temps. C'est normal. C'est le prérequis dur qui conditionne la qualité de tout ce qui suit.

Choisir le modèle selon le volume de tickets

Une fois la taxonomie validée, la question du modèle se pose. La réponse dépend presque entièrement du volume annuel de tickets. Voici les trois cas.

Moins de 5 000 tickets par an : LLM zero-shot ou few-shot

GPT-4o mini ou Mistral Large en zero-shot ou few-shot est la solution la plus rapide à déployer. Aucune annotation requise : on fournit la taxonomie dans le prompt, quelques exemples par catégorie, et le modèle classifie. Les performances sont bonnes sur des taxonomies claires (F1 de 0,80 à 0,87). Le coût est de 0,001 à 0,003 euro par ticket.

• Avantages : déploiement en une semaine, aucune donnée annotée nécessaire, mise à jour de la taxonomie immédiate (modifier le prompt suffit)
• Limites : coût variable, latence de 200 à 800 ms par ticket, performances moindres sur les catégories rares ou ambiguës
• À utiliser pour : POC, validation de concept, volumes faibles, taxonomies instables

Plus de 10 000 tickets par an : CamemBERT fine-tuné

CamemBERT (le modèle BERT pré-entraîné sur le français par l'équipe CentraleSupélec/Inria) fine-tuné sur votre historique annoté est la référence pour les volumes élevés en français. Les performances sur des catégories bien définies dépassent F1 0,90. La latence est inférieure à 50 ms par ticket. Le coût marginal à l'échelle est quasi nul (modèle hébergé en interne ou sur un GPU cloud dédié).

• Avantages : précision supérieure de 5 à 15 points de F1 par rapport au zero-shot, latence excellente, coût prévisible à l'échelle, données qui ne sortent pas de votre infrastructure
• Limites : nécessite 1 000 à 5 000 tickets annotés par classe principale, ré-entraînement nécessaire lors des évolutions de taxonomie
• À utiliser pour : helpdesk à volume élevé, données sensibles, exigences SLA strictes

Entre 5 000 et 10 000 tickets par an : l'architecture hybride

La solution intermédiaire la plus robuste combine les deux approches. Un classifier BERT léger gère les cas courants avec une forte confiance (80 % des tickets). Un LLM traite les cas ambigus pour lesquels le BERT hésite (sous le seuil de confiance). Le résultat : le meilleur des deux mondes en termes de coût et de précision.

Le pipeline d'amélioration continue

Le modèle de classification n'est pas un livrable figé. C'est un système vivant qui se dégrade si on ne l'entretient pas, et qui s'améliore si on lui fournit les bonnes données. La boucle de feedback est le différenciateur long terme entre un projet qui performe encore 18 mois après le lancement et un qui régresse.

La boucle de feedback des agents

Chaque fois qu'un agent corrige un mauvais routage, il produit une donnée précieuse : l'exemple du ticket avec la catégorie correcte. Si cette correction n'alimente pas le prochain cycle d'entraînement, vous perdez votre principale source de données d'amélioration.

Le pipeline d'amélioration continue fonctionne en quatre étapes :

1. Collecte des corrections : chaque re-routage manuel par un agent est enregistré avec la catégorie corrigée.
2. Revue qualité : une fois par mois, un responsable valide un échantillon des corrections pour s'assurer de leur cohérence avec la taxonomie.
3. Ré-entraînement trimestriel : les nouvelles données validées enrichissent le dataset d'entraînement. Le modèle est ré-entraîné sur l'ensemble consolidé.
4. Évaluation sur jeu de test stratifié : avant déploiement, le nouveau modèle est évalué sur un jeu de test stratifié par classe pour s'assurer que les performances globales et par catégorie ont progressé ou maintenu le niveau.

Le monitoring de la distribution des catégories

Au-delà des métriques de précision, il faut surveiller la distribution des catégories en sortie. Un pic inhabituel sur une catégorie spécifique est rarement le signe d'un problème modèle — c'est souvent le signal d'un incident en cours ou d'un problème récurrent qui émerge dans le produit.

Ce monitoring est aussi le premier détecteur de concept drift : si une nouvelle sous-catégorie émerge progressivement dans les tickets et que le modèle commence à la classer dans "autre" ou dans une catégorie approchante, c'est le signal qu'il faut enrichir la taxonomie et ré-entraîner.

Pour comprendre comment ce type de système s'intègre dans un workflow d'automatisation plus large, l'article sur l'automatisation intelligente avec n8n pour les PME donne des exemples concrets de pipelines de traitement en production.

Intégration Zendesk, Freshdesk et Intercom

Les trois grandes plateformes de ticketing exposent des API REST et des systèmes de webhooks qui permettent d'intégrer la classification en temps réel. L'architecture est la même dans les trois cas, avec quelques spécificités.

Architecture d'intégration type

Le flux standard est le suivant :

1. Un ticket est créé sur la plateforme.
2. Un webhook envoie le titre et le corps du ticket à l'API de classification.
3. Le classifier retourne les labels (catégorie, priorité, équipe) avec les scores de confiance.
4. Si la confiance dépasse le seuil (typiquement 0,80), l'API plateforme applique les tags et l'assignation automatiquement.
5. Si la confiance est sous le seuil, le ticket est envoyé en file de triage manuel avec les labels proposés visibles par l'agent.

La sortie JSON du classifier ressemble à ceci :

{
  "ticket_id": "TKT-2026-04521",
  "categorie": "panne_materielle",
  "sous_categorie": "imprimante",
  "priorite": "haute",
  "equipe_cible": "support_niveau_2",
  "labels_supplementaires": ["client_vip", "recurrent"],
  "confidence": {
    "categorie": 0.94,
    "priorite": 0.87
  },
  "requires_human_routing": false
}

Spécificités par plateforme

• Zendesk : l'API Tickets permet de mettre à jour les champs personnalisés, les tags et l'assignation en une seule requête. Les webhooks Zendesk sont stables et bien documentés. Temps d'intégration typique : 3 à 5 jours de développement.
• Freshdesk : les webhooks sont configurables depuis l'interface d'automatisation. L'API REST est cohérente mais les champs personnalisés nécessitent une configuration préalable. Temps d'intégration typique : 3 à 4 jours.
• Intercom : l'API est orientée conversation plutôt que ticket. Il faut mapper les concepts (conversation → ticket, tags → catégories). Plus adapté pour la classification d'intention que pour le routing d'équipe. Temps d'intégration : 5 à 8 jours.
• Cas particulier — ServiceNow on-premise : les API REST de ServiceNow on-premise sont souvent mal documentées et nécessitent des adaptations spécifiques à la version. Prévoir 2 à 3 semaines supplémentaires dans le planning.

Sur les aspects RGPD : les tickets peuvent contenir des données personnelles clients. Les logs d'inférence du modèle doivent être anonymisés ou ne pas être conservés. Si vous utilisez une API LLM externe (OpenAI, Mistral API), vérifiez les conditions de traitement des données — pour des données sensibles, un modèle auto-hébergé est préférable.

Notre cas client sur le support utilisateur d'un éditeur de logiciel médical illustre comment ces contraintes RGPD ont orienté le choix d'une architecture souveraine.

Métriques et objectifs réalistes

Deux erreurs de mesure reviennent systématiquement sur les projets de classification. La première est de piloter uniquement l'accuracy globale. La seconde est de ne regarder que les métriques modèle sans les relier aux indicateurs métier.

Les métriques modèle à suivre

Pourquoi l'accuracy globale est trompeuse

Sur un helpdesk où 70 % des tickets tombent dans deux catégories principales, un modèle qui prédit toujours ces deux catégories obtient 70 % d'accuracy globale. Il est pourtant inutile pour les 30 % restants — parfois les plus urgents. Le F1 macro ou le F1 weighted par classe sont les seules métriques pertinentes pour évaluer une classification déséquilibrée.

Les métriques métier à relier

Les métriques modèle n'ont de sens que si elles sont reliées aux indicateurs opérationnels :

• Temps moyen de première réponse : doit baisser significativement après déploiement (objectif : moins 40 %)
• Taux de re-routage manuel : tickets déplacés d'une équipe à une autre après assignation initiale (objectif : inférieur à 8 %)
• FCR : taux de résolution au premier contact, indicateur de la pertinence du routing
• Temps économisé sur le triage : mesurable directement en heures/semaine

Pour aller plus loin sur la mesure des bénéfices d'un projet IA, l'article sur la mesure du ROI des projets IA en entreprise propose une méthode structurée applicable à ce type de cas.

Coûts, délais et TCO

POC (4 à 6 semaines) : 5 000 à 10 000 euros

Le POC couvre la revue et la stabilisation de la taxonomie avec les équipes, l'annotation de 1 000 à 3 000 tickets historiques, l'entraînement et l'évaluation du classifier (F1 par classe, matrice de confusion), et un tableau de bord de performance. Il ne couvre pas l'intégration en production.

MVP en production (2 à 3 mois) : 12 000 à 20 000 euros

Le MVP ajoute l'intégration API avec la plateforme ticketing, le workflow de triage humain pour les cas sous le seuil de confiance, le monitoring en production, et la mise en place de la boucle de feedback. C'est à ce stade que la valeur métier devient visible.

Planning type

• Semaines 1 à 2 : atelier taxonomie avec les équipes, extraction et annotation de l'historique
• Semaines 3 à 5 : entraînement du classifier, jeu d'évaluation stratifié par classe, calibration du seuil de confiance
• Semaines 6 à 8 : intégration API ticketing, tests UAT, déploiement en shadow mode (le classifier tourne mais ne prend pas de décision automatique)
• Semaines 9 à 12 : activation progressive, monitoring, premier ré-entraînement sur les nouvelles données

TCO annuel : 5 000 à 12 000 euros

Le TCO annuel après la mise en production couvre le coût du modèle (auto-hébergé ou API), le ré-entraînement trimestriel (1 à 2 jours de travail par trimestre), et la revue humaine résiduelle intégrée dans les workflows existants.

Ce chiffre est à comparer au coût annuel du triage manuel. Sur un helpdesk de 10 agents recevant 15 000 tickets par an, si le triage représente 15 % du temps de chaque agent, la classification automatique libère l'équivalent de 1,5 ETP — soit un ROI positif dès la première année.

Pour une mise en perspective avec d'autres projets d'automatisation, notre article sur le budget d'un projet IA en entreprise détaille les structures de coût comparables.

Les pièges fréquents

Piège 1 : taxonomie floue ou instable

Si les humains eux-mêmes ne s'accordent pas sur la catégorie d'un ticket donné, le modèle ne peut pas apprendre. Un Cohen's kappa inférieur à 0,70 sur l'accord inter-annotateur est le signe qu'il faut retravailler les définitions avant d'annoter. Ce travail en amont évite de devoir jeter et refaire l'annotation complète deux mois plus tard.

Piège 2 : classes déséquilibrées ignorées

En pratique, 20 % des catégories représentent 80 % des tickets. Sans sur-échantillonnage ou pondération des classes minoritaires, le modèle ignore les catégories rares. Ces catégories sont souvent les plus critiques (incidents de sécurité, pannes majeures, clients VIP). La solution technique est de pondérer les classes lors de l'entraînement, et d'augmenter les données rares avec du paraphrasage LLM si nécessaire.

Piège 3 : oublier le concept drift

Un modèle entraîné en janvier peut être significativement dégradé en septembre si le produit a évolué, si de nouveaux types de problèmes sont apparus, ou si la base client a changé de profil. Le monitoring de la distribution des catégories en production est le premier détecteur de ce phénomène. Le cycle de ré-entraînement trimestriel est la réponse opérationnelle.

Piège 4 : classification traitée comme une boîte noire

Les équipes opérationnelles doivent comprendre pourquoi un ticket a été mal routé, sinon elles perdent confiance dans le système et le contournent. Ajouter une explication — les mots ou expressions qui ont pesé dans la décision, reformulés en langage naturel — est indispensable pour l'adoption. C'est aussi ce qui permet aux agents de corriger intelligemment, et pas juste de re-router sans comprendre.

Piège 5 : pas de boucle de feedback structurée

Les corrections des agents sont votre plus précieuse source de données d'amélioration. Si elles ne sont pas collectées, tracées et réintégrées dans les cycles d'entraînement, le modèle stagne ou régresse pendant que vos tickets évoluent. C'est le différenciateur entre un projet qui performe à 12 mois et un qui a besoin d'être refait.

Questions fréquentes

Pour aller plus loin

• Automatisation intelligente avec n8n pour les PME : exemples de pipelines en production pour le traitement automatique des flux entrants.
• Budget d'un projet IA en entreprise : structure de coûts détaillée du POC à la production, applicable aux projets de classification.
• Comment mesurer le ROI d'un projet IA : méthode pour relier les métriques modèle aux indicateurs métier.
• Cas client éditeur médical : comment les contraintes RGPD ont orienté l'architecture d'un projet support IA.
• Audit IA Tensoria : cadrage de votre projet avant de choisir une approche technique.
• Agents IA vs chatbots pour les PME : comprendre quand la classification seule suffit et quand un agent plus complexe est nécessaire.