Comment vos données sont sécurisées dans Anantys

Avant de me lancer dans l'aventure Anantys (startup que j'ai fondée avec Maxime Sukrieh et Nicolas Rochelemagne en été 2025), j'ai travaillé pendant une quinzaine d'années pour Weborama, en tant que directeur technique. Webo est un des acteurs majeurs de l'Adtech en Europe et à ce titre, le respect de la réglementation européenne sur la protection des données personnelles (RGPD) a toujours été au cœur des sujets que j'ai été amené à co-construire.

Nous avions par exemple été très impliqués dans le workgroup de Google sur la Privacy Sandbox pour participer aux réflexions, tester les propositions d'API de Chrome pour une meilleure protection des utilisateurs tout en permettant à l'écosystème de fonctionner. J'en avais beaucoup parlé sur le Medium de Weborama à l'époque (ici, et là). Malheureusement ce projet n'a pas abouti, mais c'est une autre histoire.

Un autre exemple est le sujet de la Data Clean Room. Un sujet majeur pour nombre de verticales pour qui l'échange de données et leur protection vont de pair (un paradoxe ? non, un défi technique et intellectuel très intéressant que les DCR résolvent de manière élégante). J'en avais aussi parlé, ici.

À Weborama, j'ai également assumé le rôle de RSSI (en charge des questions de sécurité donc), et à ce titre, j'étais confronté en première ligne aux questions de protection de nos données utilisateurs, des requêtes RGPD d'accès ou de suppression, et des obligations légales à suivre (notamment la fameuse « obligation de moyens » imposée par le RGPD, à savoir : tout mettre en œuvre pour rendre la fuite de données la plus improbable possible).

Vous l'aurez compris, le sujet de la protection des données m'a toujours intéressé. Par éthique, certainement (mon background de développeur open source doit jouer un rôle ici), mais aussi par souci de faire les choses bien, de « dormir tranquille » et également pour le challenge technique que cela représente.

Pourquoi Anantys se doit d'être exemplaire en la matière

Dans le cadre du développement d'Anantys, j'ai franchi un cap. Contrairement à mon expérience à Weborama, je ne manipule plus de simples identifiants web pseudonymisés (les fameux cookies) ni des centres d'intérêt modélisés. Non, désormais, mon code collecte, stocke, et agrège des données personnelles sensibles (nom, prénom, stratégie d'investissement, horizon de placement) et des données bancaires associées (compte bancaire, montant, liste d'actions détenues, etc). Avec la synchronisation bancaire désormais automatisée, ces données ne sont qu'à quelques clics de notre base de données.

Il fallait donc monter d'un cran. Mettre la sécurité au maximum. C'est ce que nous avons fait et je voulais montrer ici pourquoi nous sommes à l'état de l'art en la matière. En deux mots, si vous utilisez Anantys, sachez que vos données personnelles sont extrêmement bien protégées. Explications.

Vos données sont illisibles dans la base de données Anantys

Si vous vous êtes déjà demandé ce qu'il advient de vos données personnelles lorsque vous utilisez un produit fintech, vous vous posez la bonne question. La plupart des plateformes vous diront qu'elles « prennent la sécurité au sérieux ». C'est assez facile à écrire sur un site, ou sur des slides. Dans la pratique, il y a un gouffre entre les différentes approches, qu'on pourrait résumer ainsi, de la moins sécurisée à la plus sécurisée :

Chez Anantys, nous opérons au niveau 2. Chaque adresse email, chaque nom, chaque numéro de compte bancaire, chaque montant de position en portefeuille est chiffré avant de toucher la base de données.

Le chiffrement applicatif : comment ça marche

Notre code chiffre les données avant leur écriture en base. La base de données ne voit jamais votre adresse email — elle voit un jeton cryptographique comme gAAAAABpwmQC0esO8Fup.... Même si quelqu'un obtient un accès complet à la base — via une fuite de sauvegarde, un compte admin compromis ou une brèche d'infrastructure — tout ce qu'il obtient est du texte chiffré sans signification.

La clé de chiffrement vit dans la couche applicative, isolée de la base de données. Pas de clé, pas de données. Point final.

Voici à quoi ressemble réellement une ligne de notre table user :

Pour les plus techniques de mes lecteurs et lectrices, c'est du chiffrement Fernet — AES-128-CBC avec HMAC-SHA256 pour l'authentification. Chaque valeur reçoit un vecteur d'initialisation unique, ce qui signifie que le même email chiffré deux fois produit des jetons complètement différents.

Le problème de la recherche

C'est là que ça devient intéressant d'un point de vue ingénierie.

Si votre email est chiffré avec un vecteur d'initialisation aléatoire à chaque fois, il devient impossible en l'état de retrouver votre compte quand vous vous connectez (on obtient votre email en clair du provider d'identité, mais impossible de matcher l'entrée en base). Concrètement, il est techniquement impossible de faire en SQL : SELECT * from user WHERE email = 'alice@example.com' — la colonne contient un jeton Fernet, pas votre email, et on ne peut pas reproduire le même jeton deux fois de suite pour le même email… Oui, c'est secure, ça oui, mais avons-nous cassé la machine ? Non.

La solution : des hashs HMAC déterministes. À côté de chaque champ chiffré qui doit être recherchable, nous stockons un hash à clé :

Quand vous vous connectez, nous calculons HMAC(votre_email) et recherchons le hash. La même entrée produit toujours le même hash (contrairement à Fernet), mais le hash est irréversible — on ne peut pas retrouver l'email à partir de celui-ci. Et comme il est à clé (HMAC, pas du SHA simple), les attaques par rainbow table sont inutiles.

C'est le même pattern utilisé par Stripe, 1Password et d'autres entreprises orientées sécurité pour gérer les données sensibles à grande échelle.

Ce qui est chiffré

Nous ne chiffrons pas tout — ce serait du gaspillage et empêcherait des opérations utiles en base (tri, filtrage, agrégation). Nous chiffrons ce qui compte : les données qui vous identifient ou révèlent votre situation financière.

Les données non personnelles — tickers boursiers, noms de places de marché, cours de bourse, feature flags — restent en clair. Il n'y a aucun intérêt à chiffrer le fait que l'action Apple vaut 230 $.

RGPD Article 32 : pourquoi c'est important juridiquement

Le RGPD ne dit pas simplement « protégez les données personnelles ». L'article 32 appelle spécifiquement au chiffrement comme mesure technique pour assurer une sécurité adaptée au risque. Et l'article 34 offre un avantage concret : si des données chiffrées font l'objet d'une violation, vous n'avez peut-être même pas besoin de notifier les utilisateurs concernés — parce que les données sont inintelligibles pour l'attaquant.

Avec le chiffrement au niveau base de données (TDE), un dump de base expose toutes les Données Personnelles Identifiables (DPI) en clair. Avec notre approche, un dump est une collection de jetons Fernet. Inutilisable sans la clé applicative, qui est stockée séparément, renouvelée indépendamment, et ne touche jamais la base de données.

Ce type de chantier est souvent difficile à faire approuver dans les entreprises à la roadmap chargée de priorités business sans cesse changeante. C'est difficile à faire rentrer en Sprint car c'est long, difficile, et extrêmement sensible : une erreur dans le déploiement et toute la base est corrompue. Et surtout : tout ce travail est par définition totalement invisible aux yeux des utilisateurs. Quelle valeur ajoutée perçue ? Aucune…

Si ce n'est cet article. Pourtant, nous n'avons pas débattu des heures sur le sujet. C'était une évidence. En réalité, nous avions même établi avec Maxime et Nicolas que cette « fonctionnalité » (c'en est une !) était en réalité un pré-requis. Mandatory.

En effet, le risque zéro n'existe pas. Les violations de données arrivent. Aux startups, aux banques, aux gouvernements. La probabilité qu'une faille nous échappe est réelle, nous ne sommes pas infaillibles, nul ne l'est. Je veux donc pouvoir me dire que si jamais ce cas se produit, si un œil malveillant se pose sur un dump ou un extrait de la base d'Anantys, je veux pouvoir lui dire : be my guest, et retourner tranquillement à mes occupations.

Le coût de bien faire les choses

Je ne prétendrai pas que c'est gratuit. Le chiffrement applicatif ajoute une réelle complexité :

• Pas de requêtes LIKE sur les colonnes chiffrées. On ne peut pas chercher « tous les utilisateurs dont l'email contient @gmail.com ». Il faut des recherches exactes par hash ou du chargement-filtrage dans le code applicatif.
• Pas de ORDER BY sur les données chiffrées. Trier par nom nécessite de déchiffrer d'abord.
• Chaque chemin de requête touchant des DPI a dû être audité et mis à jour. Partout où le code faisait filter_by(email=...), il a fallu passer à une recherche par hash.
• Le surcoût en performance est réel mais gérable : quelques microsecondes par opération de chiffrement/déchiffrement. Sur une plateforme comme la nôtre, c'est imperceptible.

Nous acceptons ces compromis parce que l'alternative — stocker les détails de votre compte bancaire en clair — est tout simplement inacceptable pour une plateforme à laquelle vous confiez vos données financières.