Quand on regarde les outils d’email IA qui sortent en ce moment, ils ont un point commun.
Au lieu de réduire les problèmes, ils ajoutent encore plus d’interface, collent des cartes de suggestion à chaque email, affichent des badges du type « l’IA recommande de répondre », et accumulent des brouillons jamais relus.
Résultat : la boîte de réception ne devient pas plus calme, elle devient au contraire plus bruyante.
C’est pourquoi Klorn est parti d’une approche différente. Au lieu d’« ajouter » quelque chose à l’email, il a été conçu pour tout supprimer sauf une seule chose.
Chaque email aboutit à un seul résultat, et aucune autre information n’est affichée.
La classification se limite à un système à 4 niveaux :
- SILENT — archivage uniquement, rien n’apparaît à l’écran (marketing, reçus, etc.)
- QUEUE — l’email s’accumule dans la file, mais sans notification
- PUSH — email à voir immédiatement (notification / Telegram / appel optionnel)
- AUTO — classification uniquement pour l’instant (exécution volontairement désactivée)
Le point important, c’est que chaque email est obligatoirement rangé dans une seule de ces catégories. Il n’y a pas de statuts multiples ou ambigus.
Dans Klorn, le LLM ne prend pas la « décision ». À la place, il lit l’email et n’en extrait que 4 valeurs numériques :
- le degré de confiance
- le niveau de fiabilité de l’expéditeur
- le caractère réversible ou non de l’action
- le niveau d’urgence
Le niveau final est ensuite calculé à partir de ces chiffres selon des règles fixes. La raison est simple.
Faire en sorte que le résultat ne varie pas même si le modèle change. À mes yeux, c’est le plus important.
De plus, même si le LLM tombe en panne ou se retrouve limité par un rate limit, un fallback basé sur des mots-clés produit les mêmes 4 valeurs, afin que les emails urgents ne passent pas à travers.
Le résultat de la classification ne peut pas être modifié ensuite.
Les entrées utilisées au moment de la classification (from, subject, snippet, etc.) sont hachées et stockées telles quelles, puis rehachées lors de la relecture pour comparaison. Si les valeurs diffèrent, l’opération échoue simplement.
Ainsi, même si quelque chose ajoute ou modifie des données plus tard, une décision prise auparavant ne peut pas « changer en silence ».
Les actions dangereuses ont été rendues volontairement contraignantes.
En réalité, il n’y a pas tant d’actions risquées que ça dans l’email :
- envoyer un email
- supprimer définitivement
- transférer vers l’extérieur
Une seule erreur suffit pour que ce soit irrémédiable,
et c’est pourquoi toutes ces actions sont placées derrière une étape de vérification supplémentaire : sans clic explicite de l’utilisateur, elles ne sont jamais réellement exécutées.
- le payload est figé au moment de l’approbation
- il est revérifié au moment de l’exécution
- au moindre écart, l’opération échoue simplement
L’exécution automatique est elle aussi bloquée par défaut. Le choix a été fait du côté du non.
Le projet a été conçu avant tout pour du self-host. Il est open source sous AGPLv3, et n’importe quelle API compatible OpenAI peut être branchée.
- compatible avec Ollama / LM Studio / vLLM
- possibilité de configurer le système sans envoyer les données email à l’extérieur
- les clés cloud ne sont utilisées qu’en option
Pour les notifications non plus, pas besoin d’utiliser du web push à tout prix : les recevoir via Telegram peut être plus simple.
Le projet en est encore à ses débuts. Mais cela ne veut pas dire pour autant que les performances sont mauvaises.
Parce que :
- sur une base de 50 emails personnels, le système a eu environ 80 % de justesse (un seul test, selon mes critères)
- il n’y a qu’un seul utilisateur réel : moi
- l’exécution de
AUTOest volontairement désactivée - l’UI est encore en cours de rangement
Plutôt que d’exagérer, je décris les choses telles qu’elles sont aujourd’hui.
Pour l’essayer, comme il s’agit encore d’une démo, Google OAuth est en mode test (limité à 100 personnes). Si vous voulez l’utiliser, envoyez-moi votre email et je vous ajouterai immédiatement.
Le moyen le plus rapide reste simplement le self-host.
- vous pouvez utiliser votre propre OAuth
- le service démarre directement sans authentification Google
2 commentaires
Vous devez le publier avec
show.Comme je ne peux pas le modifier, je le publierai en mode show la prochaine fois..