Le confort d’une conclusion

Lorsqu’un logiciel examine un courriel suspect, la demande paraît simple :

Est-ce une fraude ou non ?

C’est probablement la question que beaucoup d’utilisateurs aimeraient voir apparaître au centre de l’écran, accompagnée d’une réponse nette, éventuellement colorée en rouge ou en vert.

La technologie semble précisément faite pour cela. Elle recueille des informations, applique des règles, rapproche des indices et produit un résultat. Pourquoi s’arrêter avant la conclusion ?

En travaillant sur FrelonMail, nous avons pourtant découvert que cette conclusion était peut-être la partie la plus facile à afficher — et la plus difficile à justifier.

Un message peut contenir plusieurs signes inquiétants sans être frauduleux. À l’inverse, une attaque soigneusement préparée peut ne présenter aucun des indices que le logiciel sait reconnaître. Une adresse inhabituelle, une authentification imparfaite ou un lien dissimulé sont des éléments à examiner. Aucun ne devient automatiquement une preuve par sa simple présence.

Le logiciel peut voir quelque chose.

Il ne voit jamais tout.

La question n’était donc plus seulement de savoir comment détecter davantage de signaux. Elle devenait : comment rendre ces signaux utiles sans leur donner une autorité qu’ils ne possèdent pas ?

Un score n’est pas un verdict

FrelonMail produit un indice de risque déterministe et relie ses conclusions aux éléments qui les motivent. Mais sa documentation précise que cet indice ne constitue ni une probabilité de fraude ni une décision automatique. L’absence de signal détecté ne prouve pas davantage qu’un message est sûr.

Cette distinction pourrait sembler relever de la prudence juridique ou d’une formule destinée à protéger le concepteur.

Elle est en réalité beaucoup plus profonde.

Un score permet de classer, de hiérarchiser ou d’attirer l’attention. Un verdict prétend fermer la question.

Entre les deux, il existe une différence de nature.

Le score dit : « Voici ce que le système a observé selon les règles qu’il connaît. »

Le verdict dit : « Voici ce qui est. »

Une grande partie des difficultés liées à l’automatisation commence lorsque nous confondons ces deux phrases.

Le nombre affiché à l’écran possède une force particulière. Il semble précis parce qu’il est chiffré. Il paraît objectif parce qu’il est calculé. Il peut pourtant agréger des observations incomplètes, des pondérations discutables et des catégories qui ne couvrent jamais entièrement le réel.

L’explication du score ne supprime pas cette limite. Elle permet simplement de la rendre visible.

C’est déjà beaucoup.

Séparer ce que le logiciel observe de ce que l’humain décide

Au fil du développement, une architecture s’est imposée : ne pas mélanger dans un même résultat les faits extraits du message, les règles appliquées, l’interprétation proposée et la décision finale.

Le logiciel peut relever une adresse, une empreinte, un domaine, une incohérence d’authentification ou la présence d’une pièce jointe.

Il peut ensuite appliquer des règles déterminées.

Il peut préparer une synthèse et signaler ce qui mérite une attention particulière.

Mais la revue humaine doit rester distincte, identifiable et datée. Dans FrelonMail, cette décision est conservée séparément de l’analyse automatique ; les rapports et les exports distinguent explicitement le calcul du système de la revue effectuée par une personne.

Cette séparation n’est pas une simple organisation des fichiers.

Elle empêche une confusion fréquente : attribuer au logiciel une conclusion qu’un utilisateur a en réalité validée — ou, à l’inverse, présenter comme humaine une décision qui était déjà pratiquement imposée par l’interface.

Il ne suffit pas de placer un bouton « Confirmer » à la fin d’un processus pour pouvoir affirmer que l’humain est resté dans la boucle.

Encore faut-il qu’il puisse comprendre ce qu’il confirme.

Encore faut-il qu’il puisse refuser.

Encore faut-il que le refus ne ressemble pas à une anomalie gênante que le logiciel cherche immédiatement à corriger.

L’analyse locale comme choix de responsabilité

FrelonMail travaille localement à partir de fichiers de courriels enregistrés par l’utilisateur. Les incidents, les analyses et les décisions sont conservés dans une base locale. Le logiciel ne réalise pas d’enrichissement réseau automatique, ne résout pas les domaines à distance et n’envoie aucun signalement de sa propre initiative.

Ce choix peut d’abord être présenté comme une mesure de confidentialité.

Un courriel contient souvent bien davantage que le message suspect lui-même : identité des correspondants, habitudes de travail, informations contractuelles, signatures, numéros de téléphone ou fragments d’échanges antérieurs. Ne pas transmettre automatiquement ces données réduit naturellement leur exposition.

Mais le fonctionnement local produit aussi une autre conséquence : il maintient la décision près de la personne qui possède le contexte.

Le logiciel peut connaître les caractéristiques techniques du message. Il ignore souvent la relation réelle entre les interlocuteurs.

Il ne sait pas nécessairement qu’un fournisseur vient de changer de banque, qu’un collègue écrit exceptionnellement depuis l’étranger ou qu’une demande apparemment normale contredit une conversation téléphonique tenue quelques minutes auparavant.

Ces éléments ne sont pas toujours présents dans les données analysées. Ils peuvent pourtant déterminer la décision.

En évitant de transformer automatiquement l’observation en action distante, le système reconnaît implicitement cette ignorance.

Il ne dit pas : « Je possède le contexte. »

Il prépare les éléments pour celui qui peut peut-être le retrouver.

Préparer une action n’est pas l’exécuter

Un message réellement frauduleux peut justifier plusieurs réactions : avertir une équipe de sécurité, conserver les indices, signaler une adresse, contacter une plateforme ou documenter une campagne.

L’automatisation de ces démarches paraît séduisante. Une fois la fraude détectée, pourquoi ne pas transmettre immédiatement les informations utiles aux services concernés ?

Parce que la détection peut être erronée.

Parce que le dossier peut contenir des données sensibles qui n’ont aucune raison d’être communiquées.

Parce que le bon destinataire dépend du contexte.

Parce qu’un signalement peut produire des conséquences pour des tiers.

FrelonMail prépare des rapports, des indicateurs techniques et des éléments de signalement, mais ne les transmet pas automatiquement. La documentation demande une confirmation et une catégorisation humaines avant certains exports, et recommande de ne partager que les éléments nécessaires.

Cette distinction entre préparation et exécution est l’un des enseignements les plus importants du projet.

Un outil peut réduire l’effort nécessaire pour agir sans s’arroger le droit d’agir.

Il peut rassembler les informations, éviter les recopies, structurer un dossier et indiquer les interlocuteurs possibles. Il laisse pourtant subsister un dernier geste qui n’est pas seulement mécanique : décider que l’action est justifiée.

Cette retenue peut sembler frustrante. Elle ajoute une étape là où l’automatisation promettait précisément d’en supprimer.

Mais cette étape est parfois l’endroit exact où demeure la responsabilité.

Ce que la prudence coûte

Il serait facile de présenter cette architecture comme une solution parfaite : un logiciel prudent, transparent, local et respectueux du jugement humain.

Ce serait oublier qu’un compromis possède toujours un coût.

Un outil qui refuse de conclure demande davantage d’attention à son utilisateur.

Un système qui n’effectue aucun enrichissement réseau automatique dispose de moins d’informations qu’un service connecté capable d’interroger immédiatement plusieurs bases externes.

Une préparation manuelle du signalement ralentit la réaction.

La séparation entre analyse et décision oblige à lire, à comprendre et parfois à hésiter.

Dans un environnement professionnel chargé, cette prudence peut être vécue comme une complication supplémentaire. L’utilisateur aurait parfois préféré un bouton unique, une recommandation définitive ou une action immédiate.

Le local-first impose aussi ses propres contraintes : installation, mises à jour, conservation des données et responsabilité du poste sur lequel elles sont stockées.

Enfin, FrelonMail ne remplace ni un antivirus ni une analyse dynamique. Il ne visite pas les liens, n’exécute pas les pièces jointes et ne peut garantir qu’un message dépourvu de signaux connus est inoffensif.

Ces limites ne sont pas des détails à dissimuler en bas de page.

Elles définissent ce que l’outil est réellement.

Un logiciel responsable ne devrait pas seulement annoncer ce qu’il sait faire. Il devrait rendre compréhensible ce qu’il ne saura probablement jamais faire seul.

La sécurité contre l’efficacité apparente

L’analyse d’un fichier potentiellement hostile pose une autre question : jusqu’où faut-il aller pour obtenir davantage d’informations ?

Sous Windows, FrelonMail traite actuellement les courriels dans un processus temporaire à faibles privilèges, privé de capacité réseau et limité en durée comme en mémoire. Il ne visite pas les URL et n’ouvre pas les pièces jointes pour en observer le comportement.

Cette décision réduit certaines capacités d’analyse.

Un système plus agressif pourrait suivre les redirections, télécharger des ressources ou interroger directement les infrastructures mentionnées dans le message. Il recueillerait peut-être des renseignements supplémentaires.

Il augmenterait également la surface de risque.

Là encore, la question n’est pas de choisir abstraitement entre prudence et efficacité. Elle consiste à définir quelle efficacité est recherchée et quel danger nous sommes prêts à créer pour l’obtenir.

Un logiciel défensif peut devenir lui-même une source d’exposition s’il contacte automatiquement des domaines hostiles, manipule des contenus actifs ou transmet des informations sans contrôle.

La fonction proclamée du produit ne suffit donc pas à garantir la moralité de son architecture.

Un outil de sécurité peut adopter des méthodes imprudentes.

Un système conçu pour protéger peut retirer à son utilisateur la maîtrise de ses propres données.

La responsabilité ne se déduit pas de l’intention. Elle se construit dans les limites techniques.

Accepter de ne pas savoir

Les logiciels sont généralement valorisés pour leurs réponses.

Ils calculent, reconnaissent, recommandent et prédisent. Leur utilité semble proportionnelle au nombre de situations dans lesquelles ils peuvent conclure.

Pourtant, certaines circonstances exigent une autre compétence : savoir signaler que les éléments disponibles ne suffisent pas.

Cette possibilité est rarement spectaculaire.

Elle ne produit ni verdict impressionnant ni automatisation complète. Elle peut même donner l’impression que le système échoue précisément au moment où nous avions besoin de lui.

Mais une conclusion injustifiée n’est pas toujours préférable à une incertitude correctement formulée.

Dire « aucun signal connu n’a été détecté » est moins rassurant que d’afficher « message sûr ».

C’est aussi plus honnête.

Le premier énoncé décrit ce que le logiciel a fait.

Le second dépasse ce qu’il peut établir.

Cette modestie n’est pas naturelle à l’interface. Tout encourage au contraire les catégories simples, les couleurs immédiates et les recommandations faciles à suivre.

Concevoir un système capable de rester incertain demande donc un effort volontaire.

Il faut résister à la tentation de transformer chaque résultat en réponse.

Une question qui dépasse le courriel

FrelonMail constitue ici un exemple particulier. Le problème apparaît pourtant dans de nombreux autres domaines.

Un outil de conformité peut préparer la liste des obligations applicables sans décider seul qu’une organisation est conforme.

Un logiciel médical peut mettre en évidence des signes sans résumer une personne à un score.

Un système de recrutement peut organiser des informations sans prétendre déterminer automatiquement la valeur d’un candidat.

Une intelligence artificielle peut proposer une formulation, une analyse ou une hypothèse sans que sa réponse devienne une autorité.

Dans tous ces cas, la frontière entre préparer et décider n’est pas fixée une fois pour toutes.

Elle dépend des conséquences possibles, de la qualité des données, de la possibilité de contester, du niveau d’incertitude et de la personne qui supportera l’erreur.

Il ne s’agit donc pas de préserver artificiellement chaque geste humain, comme si toute automatisation constituait une menace.

Certaines décisions mécaniques gagnent légitimement à être confiées à des machines. Certaines vérifications sont plus fiables lorsqu’elles sont automatisées. Certaines répétitions n’apportent aucune valeur particulière au jugement humain.

La question est ailleurs :

à quel moment l’automatisation cesse-t-elle de nous assister pour commencer à décider silencieusement de ce qui mérite notre attention, de ce qui compte comme preuve et de ce qui doit être fait ?

L’architecture est déjà une prise de position

Lorsque nous avons commencé à développer FrelonMail, une grande partie de ces choix pouvait sembler purement technique.

Où conserver les données ?

Quels fichiers générer ?

Faut-il autoriser le réseau ?

Comment représenter la décision humaine ?

À quel moment produire un signalement ?

Ces décisions ont progressivement révélé leur dimension morale.

Conserver localement ne signifie pas seulement choisir un emplacement de stockage.

Séparer la revue humaine ne signifie pas seulement créer un autre fichier.

Refuser l’envoi automatique ne signifie pas seulement repousser une fonctionnalité.

Chaque choix détermine ce que le logiciel pourra faire sans nous, ce qu’il devra nous expliquer et ce qu’il ne pourra accomplir qu’avec notre consentement.

L’éthique n’arrive donc pas après l’architecture sous la forme d’une charte ou d’une promesse.

Elle est déjà présente dans les permissions accordées, les automatismes refusés, les informations conservées et les moments où le système accepte de s’arrêter.

Conclusion — Le dernier geste

Un bon outil ne devrait peut-être pas chercher à supprimer toute hésitation.

Il peut retirer le travail inutile, organiser ce qui était dispersé et rendre visibles des éléments que nous aurions manqués.

Il peut nous aider à décider.

Mais lorsqu’une action engage une personne, transmet des données ou attribue une responsabilité, le dernier geste mérite parfois de rester distinct.

Non par nostalgie d’un monde sans automatisation.

Non parce que l’être humain serait infaillible.

Simplement parce qu’une décision dont personne ne peut expliquer l’origine finit facilement par n’appartenir à personne.

FrelonMail nous a appris qu’un logiciel pouvait être utile sans prétendre posséder le dernier mot.

La question reste ouverte pour tous les autres :

jusqu’où voulons-nous que nos outils préparent nos décisions — et à partir de quel moment commençons-nous à leur abandonner le droit de les prendre ?

Projet étudié

FrelonMail est un projet public développé dans l’écosystème Moralement.NET. Il est présenté ici comme terrain d’expérience sur l’automatisation, la sécurité et le jugement humain, et non comme recommandation commerciale. Sa documentation décrit son fonctionnement actuel, ses choix de conception et ses limites.

Projets et sources mentionnés