Sécurité — comment nous protégeons votre compte et vos données

Les contrôles de sécurité réellement en place chez EuTrustedIA : authentification, limitation de débit partagée, chiffrement, scellement des rapports, signature du logiciel. Et ce qui n'est pas encore en place.

Nous vendons de la conformité documentée. Il serait incohérent de vous demander d'auditer vos systèmes sans exposer les nôtres. Cette page décrit les contrôles effectivement en place, au niveau de détail que notre code permet de tenir — et se termine par ce qui ne l'est pas encore.

Nous documentons, nous ne certifions jamais. Cette page n'est ni un label, ni un audit tiers, ni une présomption de conformité. C'est une description vérifiable de nos propres pratiques, datée.

Se connecter : trois surfaces, trois modèles

Nos deux services n'ont pas le même modèle d'authentification, parce qu'ils n'ont pas la même surface d'attaque.

L'Annuaire — sans mot de passe, par construction

L'Annuaire n'a pas de mot de passe. On s'y connecte par lien à usage unique envoyé par e-mail, ou par Google. Ce choix ferme une catégorie entière d'attaques : le credential stuffing, qui consiste à essayer en masse des couples identifiant / mot de passe fuités d'autres sites, n'a rien à tester chez nous.

Les comptes d'administration — un seul chemin, et il n'est pas l'e-mail

Sur un site sans mot de passe, le vrai vecteur de prise de contrôle d'un compte d'administration est la compromission de la boîte mail. Nous l'avons fermé : aucun lien de connexion n'est jamais émis pour un compte d'administration, même si quelqu'un le demande depuis cette boîte mail. Ces comptes se connectent exclusivement via Google, et sont restreints par une liste explicite d'adresses autorisées — l'authentification à double facteur est donc déléguée à Google.

L'Espace Client POSITRONIA — mot de passe et double facteur

L'Espace Client, lui, utilise un mot de passe : c'est une vraie surface de credential stuffing, et elle est traitée comme telle (voir la limitation de débit ci-dessous). Vous pouvez y activer une authentification à double facteur (TOTP) depuis vos réglages, avec des codes de secours. Le secret et les codes de secours sont chiffrés en base, jamais stockés en clair.

Cette activation est à votre main, et nous vous invitons à la faire dès votre premier accès : c'est, de tout ce qui figure sur cette page, la seule mesure dont l'effet dépend de vous.

Limiter les tentatives : ce qui tient, et ce qui est du bonus

Une limitation de débit (« rate limiting ») sert à empêcher qu'on essaie des milliers de combinaisons. Encore faut-il qu'elle compte juste. Nos services tournent sur une infrastructure serverless, où chaque requête peut être traitée par une instance différente : un compteur gardé en mémoire y est un compteur par instance, qu'un attaquant contourne simplement en répartissant ses requêtes.

C'est pourquoi les compteurs qui protègent la connexion sont stockés dans notre base de données, partagée par toutes les instances, sur les deux services. Des seuils resserrés s'appliquent en plus sur les points d'entrée sensibles. Ce contrôle est vérifié par un test automatisé qui exécute la configuration de production réelle et exige le refus au-delà du seuil — et non par une simple relecture du code, qui ne détecterait pas une faute de frappe rendant la règle silencieusement inopérante.

Ailleurs dans l'application, d'autres limitations s'ajoutent en défense en profondeur. Nous les traitons comme telles : ce ne sont pas elles qui font autorité. Sur ces parcours, ce qui borne réellement l'usage est d'une autre nature — quota attaché à votre offre, validation stricte des données reçues, et coupe-circuit de dépense quotidienne. Un contrôle empilé n'est utile que si l'on sait lequel tient ; nous le savons, et nous ne comptons pas sur le mauvais.

Vos données

Votre code ne part pas

POSITRONIA analyse votre code sur votre machine. Ce qui remonte dans votre Espace Client, ce sont les rapports— pas les sources. C'est une propriété d'architecture, pas un réglage : nous n'avons pas de bouton pour recevoir votre code.

Chiffrement

Les contenus sensibles stockés pour votre compte — rapports, liens de partage, RIB pour les versements d'affiliation — sont chiffrés en AES-256-GCM, avec des clés tenues hors de la base de données. Nous n'employons aucun algorithme de chiffrement maison.

Nous n'écrivons pasque nos serveurs seraient « aveugles » ou que le dispositif serait à « connaissance nulle » : ce serait faux, et ces formules servent le plus souvent à faire croire à davantage. Nous exploitons un service qui déchiffre ce qu'il doit vous rendre.

Des rapports scellés, dans l'ordre

Chaque rapport est empreint en SHA-256, et chaque empreinte est chaînée à la précédente. Modifier un rapport après coup casse la chaîne, et cela se voit. C'est ce qui permet à un rapport POSITRONIA d'être opposable : non pas parce que nous affirmons qu'il n'a pas bougé, mais parce que sa place dans une suite le démontre.

Licences et règles signées

Les licences de l'application et les règles d'analyse qu'elle télécharge sont signées en Ed25519. L'application vérifie la signature avant d'appliquer une règle : une règle modifiée en transit est refusée, pas exécutée.

Le logiciel que vous installez

L'application POSITRONIA pour Windows est signée avec un certificat de signature de code — à l'installation, Windows affiche le nom de l'éditeur vérifié. Chaque machine sur laquelle vous l'activez est enrôlée sur votre compte, visible depuis votre Espace Client, et vous êtes averti lors d'un nouvel enrôlement.

Ce qui n'est pas encore en place

Cette section existe parce qu'une page sécurité qui ne listerait que des réussites ne mériterait pas d'être lue. Nous nous en tenons toutefois à ce que vous avez besoin de savoir pour décider : le détail de nos contrôles en cours de renforcement se partage avec les chercheurs qui nous écrivent, pas avec le tout-venant.

  • Notre feuille de route d'authentification n'est pas terminée. Des renforcements sont spécifiés et budgétés sur les parcours de connexion. Ils sont tracés dans nos décisions d'architecture, avec leur échéance.
  • Double facteur applicatif sur l'administration de l'Annuaire. Il y est aujourd'hui délégué à Google, ce qui est un choix assumé et non un oubli : l'y ajouter en propre supposerait de réintroduire des mots de passe, donc la surface d'attaque que ce service n'a pas.
  • Audit de sécurité externe par un cabinet indépendant. Il est prévu, budgété, et il n'a pas encore eu lieu. Tant qu'il n'a pas eu lieu, nous ne parlons pas de code audité par un tiers — c'est la seule raison pour laquelle nous le mentionnons ici.

Signaler une faille

Si vous pensez avoir trouvé une vulnérabilité, écrivez à contact@eutrustedia.eu. Nous accusons réception, nous corrigeons ce qui doit l'être, et nous ne poursuivons personne pour une recherche menée de bonne foi et sans destruction de données.

Notre politique de divulgation est également publiée au format normalisé /.well-known/security.txt (RFC 9116). Nous n'exploitons pas de programme de primes à ce jour, et nous préférons l'écrire plutôt que de laisser espérer une récompense qui n'existe pas.

Pour aller plus loin


Page sécurité EuTrustedIA — Version 1.0, publiée le 27 juillet 2026. Elle décrit l'état de nos contrôles à cette date et sera mise à jour à mesure qu'ils évoluent ; une page de ce type sans date de vérification ne veut rien dire.
Responsable de la publication : Laurent SOUHY EI — contact@eutrustedia.eu