Les présentations d’IA parlent souvent de transformer une industrie. Dans une équipe occupée, on aimerait parfois juste arrêter de trier manuellement la même liste chaque matin.

Classer une demande, signaler une anomalie, suggérer une quantité ou placer certains dossiers en haut d’une file peut enlever une vraie friction sans demander au modèle de diriger l’entreprise. Ces tâches ont un avantage : on peut décrire l’entrée, la sortie, la personne responsable et le coût d’une erreur.

Prenons le tri des demandes de soutien. Le pipeline lit le sujet, le texte, le produit, le client et l’heure d’arrivée. Il transforme les mots en variables numériques, combine ces variables avec quelques attributs structurés, puis un modèle produit un score par catégorie. Le score n’est pas une certitude; c’est une mesure issue des exemples d’entraînement. Une règle compare ensuite ce score à des seuils et décide si le billet est routé automatiquement, proposé à un agent ou laissé dans la file générale.

Cette dernière règle fait partie du produit autant que l’algorithme. Un modèle peut avoir 90 % d’exactitude globale et rater presque toutes les urgences si celles-ci sont rares. Il faut regarder la matrice de confusion : urgences correctement détectées, urgences manquées, demandes normales faussement signalées et demandes normales correctement laissées. Le seuil acceptable dépend du coût de ces quatre cases, pas d’un chiffre de performance isolé.

Un tri modeste avec une sortie de secours

Supposons que 1 000 demandes arrivent par jour, dont 50 sont réellement urgentes. Le système pourrait suivre ce flux :

1. valider les champs et retirer du texte les secrets ou renseignements qu’on ne veut pas envoyer au modèle;
2. calculer un score d’urgence et une catégorie avec une version précise du modèle;
3. placer les scores supérieurs à 0,85 dans une file prioritaire, mais afficher la raison et le texte original à l’agent;
4. envoyer les scores entre 0,45 et 0,85 dans une file de vérification plutôt que forcer une décision;
5. enregistrer la correction de l’agent séparément de la prédiction, puis mesurer chaque semaine les erreurs et le délai réel de traitement.

Si ce seuil trouve 45 des 50 urgences mais ajoute 30 faux positifs, l’équipe examine 75 dossiers prioritaires au lieu de 1 000. C’est peut-être une très bonne amélioration. Si elle ne peut vérifier que 20 dossiers, le même modèle surcharge la file et repousse les vrais cas. La capacité du processus impose donc le seuil et parfois le nombre maximal de suggestions.

Avant l’automatisation, je ferais tourner le modèle en mode fantôme : il calcule ses scores sans modifier la file. On compare ensuite ses choix aux décisions réelles, par type de client et de demande. Cette période révèle les champs manquants, les catégories ambiguës et les raccourcis indésirables. Un nom d’entreprise peut, par exemple, devenir un proxy involontaire pour le niveau de service alors que le contrat devrait être la vraie variable.

Les pannes ne sont pas toutes des erreurs de prédiction. Le service peut expirer, recevoir un texte dans une langue mal représentée, rencontrer une nouvelle catégorie ou perdre l’accès à une variable. Le workflow doit conserver la demande originale, appliquer une règle de repli et permettre à l’agent de corriger le routage. Un modèle indisponible ne devrait jamais faire disparaître un dossier. Une dérive des données ou une baisse de rappel sur les urgences doit déclencher une revue, pas nécessairement un réentraînement automatique.

Je préfère donc une phrase testable : « Le système propose les demandes à vérifier en premier; une personne décide et toutes les demandes restent accessibles. » On peut mesurer le temps gagné, les urgences manquées, la charge ajoutée et les corrections. Une job plate, répétée souvent et bien encadrée, devient ainsi un bon projet d’IA — justement parce qu’on sait où elle commence et où elle doit s’arrêter.