Un filtre à mots-clés repère facilement les mails qui parlent de commandes. Mais il confond aussi les commandes fermes avec des demandes de devis, des relances ou des échanges administratifs. Un modèle de décision peut-il réduire ce bruit sans faire disparaître de véritables commandes ?
Un essai sur 206 mails, avec plusieurs modèles et une validation humaine, met en évidence un résultat prometteur — et quelques précautions importantes pour qui souhaite reproduire la méthode.
1. Poser la bonne question
À la différence d'un modèle de langage chargé de rédiger une réponse, un modèle de décision reçoit un contexte et renvoie une valeur exploitable par un programme : par exemple, la probabilité qu'un mail transmette une nouvelle commande ferme.
Il vaut mieux demander directement « Ce mail transmet-il une nouvelle commande ferme ? » que demander une classification générale (« commande », « devis », « relance », « administratif »), puis en extraire une catégorie. Dans cet essai, la question oui/non a mieux limité les faux positifs pour tous les modèles testés.
{
"state": { "sujet": "...", "expediteur": "...", "corps": "..." },
"questions": {
"commande_ferme": {
"type": "noul",
"instructions": "Ce mail transmet-il une nouvelle commande ferme du client ?"
}
}
}La réponse est un score numérique, comparé à un seuil. Il reste à déterminer sur quelles données ce seuil est réellement fiable.
2. Construire une référence fiable
Un banc d'essai n'a de valeur que si les mails de référence sont correctement étiquetés. Trois règles sont particulièrement utiles :
- Éliminer les doublons techniques pour ne pas compter plusieurs fois un même envoi.
- Attribuer les verdicts sans connaître les réponses des modèles pour éviter de biaiser le classement.
- Conserver séparément les prédictions et les verdicts humains afin de pouvoir auditer les désaccords et recalculer les statistiques.
Dans l'échantillon, 49 mails sur 206 présentaient au moins un désaccord entre la référence humaine et les dix votes produits par cinq candidats évalués avec deux questions. Une nouvelle lecture de ces 49 cas, sans afficher les verdicts initiaux ni les prédictions, a conduit à 11 corrections.
3. Mesurer les deux erreurs qui comptent
Après cette revue, les 206 mails comprennent 163 commandes ou doublons et 43 autres messages. Le filtre à mots-clés conserve les 206 : aucune commande perdue, mais 43 faux positifs à examiner. Voici les résultats avec le texte du mail seul et un seuil oui/non de 0,5 :
| Solution | Faux positifs conservés / 43 | Commandes perdues / 163 |
|---|---|---|
| Filtre à mots-clés seul | 43 | 0 |
| Liquid d1-ultra | 8 | 1 |
| Liquid d1 | 5 | 11 |
| TypeSafe Jev | 1 | 16 |
| Microsoft Decision-1 | 7 | 19 |
Liquid d1-ultra écarte ainsi 35 des 43 faux positifs (81 %) et ne laisse de côté qu'une commande. TypeSafe Jev est plus strict : presque aucun faux positif, mais beaucoup trop de commandes perdues pour servir seul de filtre.
La précision d'un classement ne suffit donc pas. Le coût d'une commande manquée est très supérieur au coût d'un mail inutile affiché. Il faut choisir le seuil et le modèle selon cette asymétrie, pas seulement selon un score global.
4. Faut-il lire les pièces jointes ?
Les bons de commande arrivent souvent en PDF. Sur les 89 mails pour lesquels le texte extrait des pièces jointes était disponible, l'ajouter à la requête a surtout aidé les modèles les moins performants :
| Modèle | Faux positifs : sans → avec PJ | Commandes perdues : sans → avec PJ |
|---|---|---|
| Liquid d1-ultra | 3 → 4 | 0 → 0 |
| Liquid d1 | 1 → 1 | 4 → 1 |
| TypeSafe Jev | 0 → 2 | 6 → 1 |
| Microsoft Decision-1 | 2 → 1 | 8 → 1 |
Sur ce sous-ensemble, d1-ultra retrouvait déjà toutes les commandes sans pièces jointes. L'OCR n'a donc pas amélioré son rappel, tandis que celui des autres modèles progressait nettement.
Le volume facturé à l'API n'augmentait ici que d'environ 20 % avec les pièces jointes. Le coût à surveiller est surtout opérationnel : extraction des fichiers, OCR des scans, gestion des erreurs et maintenance.
5. Un coût faible ne dispense pas de mesurer
Dans les conditions et tarifs de cet essai, d1-ultra revenait à environ 0,00007 $ par mail, soit 7 $ pour 100 000 mails, avec une réponse de l'ordre d'une demi-seconde. Ces montants ne sont pas des tarifs garantis : ils dépendent du fournisseur, du contenu envoyé et de son découpage en tokens.
Pour comparer utilement les candidats, mieux vaut enregistrer le coût réel par message et les erreurs de classement, plutôt que le seul nombre de tokens ou le prix affiché par million de tokens.
6. Déployer comme outil de tri, pas comme guillotine
Un modèle qui retrouve 162 commandes sur 163 reste capable d'en manquer une. L'architecture la plus prudente est donc simple :
- Conserver le filtre initial pour repérer les messages candidats.
- Classer par probabilité : les mails jugés peu pertinents descendent dans la liste, mais ne sont ni supprimés ni invisibles.
- Détecter les commandes répétées par le code, notamment à partir des numéros de commande : un modèle lisant un mail isolé ne peut pas connaître l'historique.
- Garder la validation humaine et journaliser les décisions pour suivre les faux positifs et les commandes manquées sur les mails suivants.
À retenir
Les modèles de décision peuvent rendre un tri commercial sensiblement moins bruyant, à un coût d'API très faible. Le résultat dépend toutefois davantage de la qualité des exemples étiquetés, de la formulation de la question et de la gestion des erreurs que de la seule sophistication du modèle.
Le bon objectif n'est pas d'automatiser le rejet des messages, mais de faire examiner les vrais candidats en priorité, puis de vérifier les performances sur de nouveaux mails, hors du banc d'essai.