Hébergement dans l'Union européenne, ce qu'on conserve, ce qu'on ne conserve pas, et les clés qui ne quittent jamais nos serveurs. Sans jargon.
27 juin 2026
Cette page existe parce que la réponse courte — « vos données sont en sécurité » — ne veut rien dire. Tout le monde l'écrit, personne ne peut la vérifier, et elle ne vous apprend rien sur ce qui se passe quand vous tapez une phrase dans Prixy.
Voici la réponse longue : où vos données se trouvent physiquement, qui peut les lire, ce que nous gardons, ce que nous ne gardons pas, et ce qui n'est pas encore fait.
Vos données sont hébergées dans l'Union européenne, chez Supabase. Aucune donnée n'est copiée hors de cette région par nos soins.
« Par nos soins » n'est pas une précaution de langage, c'est une limite honnête. Nous contrôlons la région de notre base ; nous ne contrôlons pas le trajet d'un paquet sur le réseau, ni ce qu'un fournisseur ferait d'une sauvegarde s'il changeait ses propres règles. Ce que nous pouvons affirmer, c'est que rien dans notre code n'écrit vos données ailleurs.
Le modèle d'intelligence artificielle qui lit vos phrases est Mistral, une société européenne. Votre demande lui est transmise pour être comprise — c'est le principe même du produit : sans cela, personne ne pourrait traduire « quelque chose pour dormir dans le train » en critères de recherche.
Vos conversations avec Prixy, les produits que vous suivez, vos listes et vos préférences d'affichage.
Chacune de ces données a une raison d'être précise. Les conversations vous permettent de retrouver une recherche d'il y a trois semaines sans la refaire. Les produits suivis servent aux alertes de prix : sans mémoire du seuil que vous avez fixé, il n'y a pas d'alerte possible. Les listes et les préférences évitent de vous reposer les mêmes questions à chaque visite.
Rien de tout cela n'est conservé « au cas où ». Si une donnée ne sert à aucune fonction que vous utilisez, elle n'a pas à exister chez nous.
L'accès aux données passe par des règles appliquées par la base elle-même, et non seulement par notre code applicatif. La distinction est essentielle.
Dans beaucoup d'applications, la séparation entre comptes tient à une condition écrite dans le programme : « ne renvoie que les lignes de cet utilisateur ». Elle fonctionne tant que le programme est juste. Une seule requête mal écrite, un seul chemin oublié, et la barrière disparaît.
Une règle appliquée par le moteur de base de données tient même quand le code au-dessus se trompe.
Ici, une requête qui tenterait de lire les lignes d'un autre compte est refusée au niveau du moteur, quoi que l'application demande. Le code peut avoir un défaut ; la séparation, elle, ne dépend pas de lui.
La clé du modèle d'IA et la clé d'administration de la base n'existent que dans du code exécuté côté serveur. Ce qui est envoyé à votre navigateur ne les contient pas.
Ce point mérite d'être développé, parce qu'il est très souvent mal fait ailleurs. Tout ce que votre navigateur reçoit, vous pouvez le lire : le code d'une application web est public par construction, il suffit d'ouvrir les outils de développement. Une clé « cachée » dans ce code — obscurcie, découpée en morceaux, encodée — reste une clé publique. La dissimuler ne fait que retarder de quelques minutes celui qui la cherche.
La seule protection réelle est qu'elle ne soit pas là du tout. C'est pourquoi toute la logique qui a besoin d'un secret vit dans des fonctions exécutées sur nos serveurs : votre navigateur leur demande un résultat, il ne reçoit jamais le moyen de l'obtenir lui-même.
Votre identité est dérivée d'un jeton signé, vérifié à chaque requête par le serveur. Elle n'est jamais fournie par le navigateur sous forme de simple identifiant.
La nuance compte. Si le client envoyait « je suis l'utilisateur n° 42 » et que le serveur le croyait, n'importe qui pourrait écrire 43 et lire le compte du voisin. Le jeton, lui, est signé : le serveur en extrait l'identité et l'utilise, sans accorder la moindre confiance à ce que le client affirme être.
Sur le web et l'application de bureau, une session s'ouvre au démarrage sans qu'on vous demande de compte : converser avec Prixy ne nécessite pas d'inscription. L'application mobile, elle, fonctionne avec une adresse et un mot de passe. Dans les deux cas, ce qui est verrouillé n'est pas la conversation mais l'écriture : sans identité vérifiée, rien n'est enregistré au nom de quelqu'un d'autre.
Les échanges avec la base et avec le modèle passent par des connexions chiffrées. L'application n'a le droit de contacter qu'une courte liste d'hôtes déclarée à l'avance.
Cette liste est une protection contre nous-mêmes autant que contre un attaquant : si une dépendance tierce tentait un jour d'envoyer quelque chose vers un domaine qui n'y figure pas, la requête serait bloquée par le navigateur, pas seulement déconseillée.
Elle refuse d'exécuter tout script qui ne vient pas de son propre paquet, et de se connecter à un domaine qui n'est pas sur sa liste. Une page piégée n'y ferait rien.
Concrètement : les scripts autorisés sont identifiés à la compilation par une empreinte. Un script injecté à l'exécution — le vecteur classique d'une attaque par contenu — n'a pas cette empreinte, et la fenêtre refuse de l'exécuter. Ce n'est pas un réglage qu'on active, c'est une porte qui n'existe pas.
Nous préférons l'écrire que le laisser deviner.
Il n'existe pas encore d'export en un clic de tout ce que nous détenons sur vous, ni de suppression de compte entièrement automatique. Les deux sont demandables par écrit et traités à la main. C'est légal, et c'est insuffisant : une démarche qui dépend d'un humain disponible est une démarche qu'on repousse.
Nous n'avons pas non plus de certification externe à faire valoir. Les mesures décrites ici sont des choix de conception que vous pouvez juger sur pièces, pas un audit signé par un tiers. Nous préférons le dire que laisser un logo suggérer le contraire.
Un comportement qui vous semble anormal, une donnée qui apparaît là où elle ne devrait pas, une question qui n'a pas sa réponse ici : écrivez-nous. La page « Nous écrire » est faite pour ça, et un signalement de sécurité passe avant le reste de la file.