# Un LLM pour prioriser les tickets HubSpot d’une collectivité

> Un tri automatique par LLM avait relégué des signalements urgents en fin de file. Retour sur l'incident et sur la règle de sécurité qui l'a corrigé.

- Auteur : WordPress Développement
- Publié le : 2024-07-07
- Mis à jour le : 2024-07-07
- Catégorie : IA &amp; MCP
- URL : https://www.wpmoderne.fr/ia-mcp/llm-priorise-tickets-hubspot-collectivite/

## L’essentiel

- Le tri sémantique seul ignore l'urgence implicite
- Une règle de sécurité minimale corrige les angles morts
- Le score du modèle reste une aide, jamais une décision finale

Six pour cent. C'est la proportion de signalements réellement urgents que le tri automatique d'une communauté de communes du Val d'Orne a envoyés en bas de la file d'attente HubSpot, un mois après sa mise en service. Le chiffre a mis du temps à sortir : personne ne relit une file de tickets triée par ordre décroissant de priorité pour vérifier ce qui se trouve tout en bas.

Le service instruction avait pourtant de bonnes raisons de vouloir automatiser ce tri. Plusieurs centaines de demandes citoyennes arrivaient chaque semaine par le formulaire de contact du site, converties en tickets HubSpot par un connecteur maison. Un agent traitait ces tickets dans l'ordre d'arrivée, ce qui revenait à traiter une demande de duplicata de carte grise avant un signalement de fuite de gaz simplement parce que le premier message était arrivé trois minutes plus tôt.

## Le principe du tri par LLM

La solution retenue consistait à faire relire chaque nouveau ticket par un modèle de langage au moment de sa création, via un appel sortant déclenché par un workflow HubSpot. Le prompt demandait un score de 1 à 5 accompagné d'une justification courte, en tenant compte du vocabulaire employé, du service concerné et de mots-clés sensibles (« danger », « fuite », « chute », « inondation »). Le score alimentait ensuite une propriété personnalisée du ticket, utilisée pour trier la vue par défaut de l'équipe.

Sur le papier, le dispositif fonctionnait bien : dans l'immense majorité des cas, le modèle repérait correctement l'urgence d'un message, même mal orthographié ou incomplet. Le problème est apparu sur les messages courts, rédigés dans un style neutre, qui décrivaient une situation grave sans utiliser aucun des mots que le prompt avait appris à surveiller.

## L'incident : des signalements urgents en fin de file

Un habitant avait signalé un poteau électrique penché après un orage, en une phrase sobre : « Le poteau devant chez moi ne tient plus droit, merci de vérifier. » Le modèle a attribué un score de 2, jugeant la formulation trop calme pour relever de l'urgence, et l'a classé après une dizaine de demandes de renseignement administratif. Le ticket est resté trois jours sans réponse avant qu'un agent, en parcourant la file par curiosité, ne le remonte manuellement.

L'analyse a posteriori a montré que ce cas n'était pas isolé : sur un échantillon de deux mille tickets, six pour cent des signalements réellement urgents (au sens du service technique, pas du modèle) avaient reçu un score inférieur à 4. Le LLM jugeait l'urgence à la tonalité du texte plutôt qu'à son contenu factuel, un biais difficile à corriger uniquement en reformulant le prompt.

> L'essentiel à retenir : Le tri sémantique seul ignore l'urgence implicite ; Une règle de sécurité minimale corrige les angles morts ; Le score du modèle reste une aide, jamais une décision finale

## La règle de sécurité ajoutée en complément

Plutôt que de complexifier encore le prompt, l'équipe a ajouté une deuxième couche, indépendante du modèle : une liste de motifs de tickets HubSpot (voirie, réseaux, sécurité publique) qui déclenche systématiquement un score plancher de 4, quel que soit l'avis du LLM. Cette règle s'exécute après l'appel au modèle et peut uniquement relever le score, jamais le baisser.

```
function applyMinimumPriority(ticket, llmScore) {
  const urgentCategories = ['voirie', 'reseaux', 'securite-publique'];
  if (urgentCategories.includes(ticket.category) && llmScore < 4) {
    return { score: 4, source: 'regle-securite', overridden: true };
  }
  return { score: llmScore, source: 'llm', overridden: false };
}
```

Ce garde-fou repose sur la catégorie choisie par le citoyen dans le formulaire, un champ fiable puisqu'il ne dépend pas de l'interprétation du modèle. Il ne remplace pas le tri sémantique, qui reste utile pour départager les tickets à l'intérieur d'une même catégorie, mais il empêche qu'un signalement grave passe sous le radar à cause d'un ton de rédaction trop neutre.

### Ce que la règle ne corrige pas

- Les signalements urgents envoyés dans une catégorie mal choisie par erreur restent exposés au biais du modèle.
- La règle ne détecte pas l'urgence dans les catégories « autre » ou « question générale », volontairement larges.
- Elle ne remplace pas une relecture humaine périodique de l'ensemble de la file, même triée.

> Sur ce type de dispositif, la règle qu'on ajoute après coup vaut souvent mieux que le prompt qu'on réécrit pour la dixième fois : elle est prévisible, elle se teste en une ligne, et elle ne régresse pas silencieusement lors d'une mise à jour du modèle.

## Résultats mesurés après trois mois

Une fois la règle en place, le taux de signalements urgents mal classés est tombé sous le seuil de détection de l'échantillon suivi (moins de dix tickets sur deux mille). Le temps moyen de prise en charge des demandes classées prioritaires a également baissé, de fait mécanique puisque moins de faux négatifs venaient diluer la file du haut.

Le service a par ailleurs ajouté un tableau de bord hebdomadaire listant tous les tickets où la règle de sécurité a corrigé le score du modèle, afin de suivre la fréquence des écarts et d'ajuster la liste des catégories concernées si de nouveaux angles morts apparaissent.

## En résumé

Un LLM reste un outil probabiliste, y compris sur une tâche apparemment simple comme évaluer l'urgence d'un texte. Pour un usage public, où une erreur de tri peut avoir des conséquences concrètes, une règle déterministe en dernier rempart n'est pas un aveu d'échec du modèle : c'est la condition pour pouvoir s'appuyer dessus sans surveillance permanente.
