Elytre Elytre

Réalisations · Étude de cas · Prototype

Comment savoir si un assistant de tri d’e-mails est fiable avant de le mettre en service ?

Prototype personnel, évalué sur un corpus entièrement fictif : aucun client, aucun courrier réel. Cette étude décrit comment je mesure ce que l’assistant classe bien, ce qu’il rate et quand il s’abstient.

Par Robin Lasserye · Mise à jour le

L’étude, rubrique par rubrique

Statut : prototype. Chaque rubrique dit ce qui est établi, et ce qui ne l’est pas.

Le contexte et le problème

Une boîte e-mail partagée, du type contact@, reçoit de tout : demandes de projet, factures, candidatures, lettres d’information.

Un assistant peut classer ces messages, signaler l’urgent et préparer des brouillons. La vraie question vient avant : comment savoir qu’il se trompe rarement, et qu’il s’abstient quand il doute ?

J’ai donc construit le prototype et sa chaîne de mesure ensemble. Le cas d’étude est un cabinet d’architecture inventé.

Le statut

Prototype personnel. Il n’est en service chez personne. Tout le courrier est inventé : personnes, sociétés, adresses. Les domaines se terminent par .test, qui n’existe pas sur Internet.

Il tourne sur ma machine, contre un serveur de courrier de test qui ne relaie rien vers l’extérieur.

Les dates et mon rôle

Le dépôt a été ouvert le 7 septembre 2026. Le corpus de mise au point et sa vérité de référence datent du 7 septembre, la chaîne de mesure du 9 septembre, le jeu réservé du 14 septembre. Le moteur a été réorganisé le 16 septembre. Le projet est en cours.

Conception, architecture, décisions et validation : Robin Lasserye. Le code est produit avec des assistants de programmation.

L’architecture et le flux

  1. Lire. L’assistant lit la boîte par IMAP. Il ne garde qu’un extrait : expéditeur, objet, début du texte, noms des pièces jointes.
  2. Appliquer les règles. Des règles écrites passent avant le modèle, de la plus fiable à la moins fiable : en-têtes, domaine de l’expéditeur, mots de l’objet.
  3. Interroger le modèle. Un modèle de langage exécuté en local classe le message. Le contenu du message lui est présenté comme une donnée, jamais comme une instruction.
  4. Douter. Si la règle et le modèle sont en désaccord, le message va dans une file « à trier », pour une personne.
  5. Décider et tracer. L’assistant pose une étiquette, signale l’urgent, prépare parfois un brouillon. Chaque décision est écrite dans un journal SQLite, avec son motif.
  6. Relire. Une interface web de revue humaine, servie par FastAPI, affiche les décisions et la file « à trier ».

Il n’envoie jamais rien et ne supprime jamais rien. Un test échoue si une fonction d’envoi apparaît dans le moteur.

LangGraph : pratiqué sur un projet personnel depuis septembre 2026, pas encore en mission client. Le traitement de chaque message a d’abord été un graphe LangGraph, avec un point de reprise SQLite. Le 16 septembre 2026, il a été réécrit en Python, sans cette bibliothèque.

Les choix et les compromis

Aucun évaluateur LLM. La mesure compare chaque décision à une vérité de référence écrite à la main. Tout se calcule hors ligne.

La confiance qu’un petit modèle déclare ne sert à rien : elle vaut 0,95 partout. Le doute se détecte par une contre-question posée au modèle.

L’avis « urgent » du modèle n’est retenu que s’il est corroboré : condition écrite pour la catégorie, ou échéance explicite dans le texte.

Une instruction cachée dans un message est signalée et tracée. Le message est classé normalement, sans brouillon, et sans urgence accordée sur la foi du modèle.

Le modèle est local par défaut : aucun message ne part chez un tiers. Un test pose une fausse clé distante, fait tourner l’assistant et vérifie qu’aucune connexion ne sort. Le même test rallume le traçage, pour prouver qu’il verrait une fuite.

La bibliothèque de graphe a été retirée le 16 septembre 2026. Ses dépendances embarquaient un outil de traçage distant. La garantie repose maintenant sur une absence, pas sur une neutralisation.

La méthode de validation

Le corpus de mise au point compte 120 messages fictifs, répartis en 10 catégories. 10 sont volontairement ambigus. 6 contiennent une instruction déguisée.

Une vérité de référence dit, pour chaque message : sa catégorie, s’il est urgent, s’il devait partir « à trier ».

Trois mesures, une par question. La catégorie est jugée sur les seuls messages non ambigus, et un message rangé « à trier » ne compte pas comme bien classé. L’urgence sépare les deux erreurs : faux urgent et urgent manqué. Le doute : un message ambigu est-il bien parti « à trier » ?

Un rejeu hors ligne repasse tout le corpus sans boîte e-mail et produit un rapport daté. Il sert à comparer deux versions : modèle, consignes ou seuils.

29 tests automatisés couvrent cette chaîne de mesure (relevé du 14 septembre 2026).

Un second jeu de 60 messages fictifs, dit réservé, a été écrit sans regarder les règles du moteur. Un contrôle vérifie qu’il ne recouvre pas le premier : identifiants et empreintes de texte disjoints.

Les résultats et les limites

La justesse mesurée sur les 120 messages est optimiste : ces messages ont servi à régler les règles et les consignes. Elle dit ce que le moteur a appris de ce corpus, pas ce qu’il ferait sur du courrier nouveau. De combien elle est optimiste reste inconnu : je ne la publie donc pas.

Plusieurs modèles locaux ont été mesurés dans les mêmes conditions. Leur classement relatif garde sa valeur : il a servi à choisir le modèle.

Sur le jeu réservé, seule une base de comparaison sans modèle a été mesurée : un classement par mots-clés, figé avant l’écriture du jeu. Elle rend 29 décisions sur 60 et laisse 31 messages « à trier ». Elle repère les 5 messages ambigus, mais abandonne aussi 26 messages qui ne l’étaient pas.

Aucune de ces 29 décisions n’est fausse. Ce n’est pas une mesure de fiabilité : cette base s’abstient dès qu’elle doute.

La mesure qui manque : le moteur complet, avec son modèle, n’a pas encore été mesuré sur le jeu réservé.

Le jeu réservé et son protocole ont le même auteur : ce n’est pas une validation externe.

Les 6 instructions déguisées sont toutes détectées, mais par des règles écrites en regardant ces 6 messages. Cela ne prouve rien sur une formulation nouvelle.

Tout le courrier est inventé. Seul un pilote sur une vraie boîte dirait ce que l’assistant ferait chez un client.

L’exploitation

Le prototype n’est pas en service. Ce qui est prévu et testé pour l’exploitation : un journal de chaque décision, et la reprise après coupure sans doublon.

Une personne peut corriger une décision. Sur une vraie boîte, ces corrections deviendraient la vérité de référence.

Si le journal est perdu, la reconstruction est approchée : un message peut recevoir un second brouillon. Deux tests démontrent cette limite au lieu de la taire.

Toutes les réalisations, avec leur statut · Agent IA sur mesure : le déroulé, les forfaits publiés et les questions d’un dirigeant · Voir les technologies pratiquées, avec leur niveau de preuve

Un agent à évaluer avant de le lancer ? Parlons-en.

Décrivez votre contexte, votre objectif et votre échéance. Vous pouvez aussi me joindre directement.

Basé à Croix, près de Lille · Missions à distance · Déplacements à convenir