Centre de confiance

Centre de confiance de Filarr : sécurité, confidentialité, conformité.

Filarr chiffre vos fichiers sur votre appareil avant l’envoi. Nos serveurs ne stockent que des données chiffrées qu’ils ne peuvent pas lire, avec la copie chiffrée de votre clé. Seule exception, à votre choix : les bases que vous confiez à la boîte noire hébergée par Filarr. Cette page documente ce que cela implique, et ce que nous ne pouvons pas faire.

Mis à jour le 27 octobre 2026

Le chiffrement de bout en bout

Chaque fichier est chiffré en AES-256-GCM sur votre appareil, dans le navigateur pour Filarr Send. Pour un partage Filarr Send, la clé voyage dans le fragment d’URL (#), la portion d’un lien que les navigateurs n’envoient jamais au serveur (RFC 3986). Pour une demande de fichiers, le déposant scelle sa clé vers votre clé publique X25519, elle aussi transmise par le fragment du lien. Nos serveurs ne stockent que du chiffré opaque et des métadonnées.

Architecture cryptographique et modèle de menace →

Ce que nous pouvons — et ne pouvons pas — faire

C’est la conséquence directe du chiffrement de bout en bout. C’est aussi notre engagement. Elle ne vaut pas pour les bases confiées à la boîte noire hébergée (voir plus bas).

Ce que nous ne pouvons pas faire

Lire vos fichiers à partir de ce que nous stockons : des données chiffrées, et une copie de votre clé qui ne s’ouvre qu’avec votre mot de passe ou votre phrase de récupération.
Analyser ou scanner vos fichiers côté serveur, y compris pour la modération automatique ou l’eDiscovery.
Récupérer vos données sans votre mot de passe ni votre phrase de récupération.
Récupérer un fichier Filarr Send dont le lien complet, qui porte la clé, a été perdu.
Transmettre un contenu en clair à un tiers, y compris à une autorité : nos serveurs ne le stockent que chiffré. Exception : les bases que vous confiez à la boîte noire hébergée, déchiffrées par nos serveurs tant qu’elles restent confiées.

Ce que nous pouvons faire

Fournir des métadonnées limitées en réponse à une demande légale valide : horodatages, pays et sous-réseau /16. L’adresse IP complète n’est enregistrée qu’après un signalement grave, dans les limites décrites par la politique de confidentialité.
Révoquer et supprimer un partage par son identifiant, sur signalement (voir Trust & Safety).

Boîte noire hébergée par Filarr

Pour servir une base sous forme d’API, quelque chose doit la déchiffrer. Par défaut, c’est une boîte noire que vous faites tourner vous-même, sur votre machine, votre serveur ou votre compte Cloudflare : nos serveurs n’en voient que des blocs chiffrés. La boîte noire hébergée par Filarr est une option payante qui vous évite de l’installer. En contrepartie, les bases que vous lui confiez ne sont plus chiffrées de bout en bout tant qu’elles restent confiées. Cette section dit exactement ce qui change, ce qui le protège, et comment le vérifier.

Ce qui reste chiffré de bout en bout, et ce qui ne l’est plus

N’est plus chiffré de bout en bout, pour les seules bases confiées et tant qu’elles le restent :

Ce qui n’est plus chiffré de bout en bout, par qui c’est déchiffré, et pourquoi
quoi	déchiffré par	pourquoi
toutes les lignes et toutes les colonnes des bases confiées, qu’une vue les montre ou non	le service hébergé	il gère leur clé et sert l’API depuis sa copie
ce qui s’y écrit tant qu’elles restent confiées (par vous, les membres du coffre, l’API)	le service hébergé	la clé en cours lui est transmise tant que la base reste confiée
les requêtes de vos logiciels et les réponses	le service hébergé	il sert l’API
les mêmes requêtes et réponses, en transit	le compte Cloudflare qui gère `filarr.com`, celui de l’API de Filarr, qui héberge aussi le service	l’adresse `<nom>.gate.filarr.com` est un nom de sa zone : il termine lui-même le chiffrement en transit (TLS)
la clé d’une base externe branchée sur la boîte, et ses lignes	le service hébergé	la synchronisation planifiée y tourne
les fichiers que reçoit la boîte, le temps de leur passage	le service hébergé	il les chiffre pour votre boîte de dépôt après les avoir reçus

Reste chiffré de bout en bout :

les bases que vous n’avez pas confiées, vos notes, vos fichiers et vos coffres ;
les clés de votre compte et de vos coffres : la clé d’une base confiée en est dérivée à sens unique, et ne permet pas de les retrouver ;
ce qui s’écrit dans une base après que vous en avez repris la clé : la clé change, et la nouvelle n’est jamais transmise au service ;
le dossier où sont rangés les fichiers reçus : seuls vos appareils les rangent.

L’API principale de Filarr, elle, ne traite toujours que des blocs chiffrés, des clés scellées et des compteurs. La clé qu’elle transmet au service est scellée pour la clé publique du service, que les applications de Filarr embarquent : elle n’est jamais en clair dans sa base de données, ni dans ses sauvegardes.

Nos engagements

Ne pas journaliser le contenu des bases confiées, des requêtes et des réponses.
N’utiliser ce contenu que pour servir votre API.
En garder les copies dans l’Union européenne : chaque boîte vit dans un objet durable de Cloudflare créé en juridiction UE.
Effacer la clé et la copie quand vous la reprenez, et vous remettre un reçu signé.
Ne mettre en service une version du service que depuis une étiquette signée de son dépôt public, par la chaîne d’intégration, sept jours au moins après sa publication, sauf correctif de sécurité, signalé comme tel.
N’avoir ni console, ni route d’administration qui lise le contenu, ni accès humain au contenu dans le fonctionnement courant.
Afficher « API hébergée par Filarr · pas chiffrée de bout en bout » sur chaque base confiée, pour tous ceux qui la voient, et prévenir les membres d’un coffre.
Pour les bases confiées, agir comme votre sous-traitant au sens du RGPD : annexe au DPA pour la boîte hébergée.

Ce sont des engagements de Filarr, et non une protection par le chiffrement de bout en bout.

Ce qui protège quoi, classé par force

Ce qui protège quoi, classé par force, avec sa limite exacte
force	protection	sa limite exacte
chiffrement	une base, pas le compte	la clé confiée ouvre une base, à une génération
chiffrement	reprendre la clé coupe l’avenir	ce que le service a traité avant n’est couvert que par les engagements
chiffrement	la clé n’est jamais en clair dans la base de données de l’API ni dans ses sauvegardes	cela ne couvre ni le trafic en transit, ni le service lui-même, qui détient sa clé privée
aucune	le trafic d’une boîte hébergée, en transit	il n’est pas chiffré de bout en bout : le compte qui gère `filarr.com` termine le TLS ; l’accord le dit
vérifiable	l’empreinte de code que le service annonce égale celle de la version publiée	cela vérifie ce que le service annonce, pas le code qui tourne (voir les limites)
vérifiable	tout se trace	accords, versions du service, sommeils, reprises, reçus d’effacement, au journal de l’accès
vérifiable	cela se voit	la mention sur chaque base confiée, pour tous ceux qui la voient
engagement	isolement, aucune journalisation du contenu, copies dans l’UE, aucun autre usage	voir les limites
engagement	effacement	un reçu signé prouve que le service a exécuté l’ordre, pas qu’aucune copie n’existe ailleurs

Comment vérifier

1. Le journal public des mises en service. Chaque version publiée, puis mise en service, y a sa ligne : version, étiquette, commit, empreinte du code, date de publication, date de mise en service, et, pour un correctif de sécurité, l’avis et sa gravité. Il est dans le fichier journal.jsonl de la branche release-journal du dépôt public filarr-work/filarr-gate, et l’API de Filarr le sert sur https://api.filarr.com/public/gate-host.
2. Le codeHash annoncé. Chaque boîte hébergée publie sa version et l’empreinte de son code, signées par la clé du service :
```
curl -s https://ctl.gate.filarr.com/.well-known/filarr-gate-host.json
```
Les applications de Filarr affichent cette empreinte dans Réglages › Accès API, et le journal de l’accès garde chaque version mise en service : comparez-la à celle du journal public.
3. Le fichier SHA256SUMS. codeHash vaut sha256: suivi du SHA-256 du fichier SHA256SUMS de la version. Ce fichier liste les archives publiées et le module même du service qui entre en service. Depuis un clone, à l’étiquette de la version :
```
npm ci
node scripts/pack-check.mjs release   # construit deux fois, compare, écrit release/SHA256SUMS
sha256sum release/SHA256SUMS          # « sha256: » + ceci = le codeHash annoncé
```
puis comparez release/SHA256SUMS à celui de la version publiée sur GitHub.

À la date du 27 octobre 2026 : version 0.3.1, publiée le 16 octobre 2026, mise en service le 26 octobre 2026 (UTC), codeHash sha256:8755b3858e7d6b2a0092547adc10b46a1014e3ae673abd65d61d9beeff4852b2. Correctifs de sécurité mis en service sans le délai de sept jours en 2026 : 0.

Les limites, dites telles quelles

Pas d’attestation à distance. Cloudflare Workers n’en offre pas : personne, Filarr compris, ne peut vous prouver que le code qui tourne est le code annoncé. La comparaison du codeHash vérifie ce que le service annonce. C’est ce qui justifie la mise en service par une chaîne publique, le délai de sept jours et le journal public.
L’isolement par script ne fait pas barrière à un administrateur du compte. Le service tourne dans le même compte Cloudflare que l’API de Filarr, dans un script à part, avec ses propres secrets et son propre stockage : un défaut ou une compromission du code de l’API ne les atteint pas. Un administrateur de ce compte, en revanche, peut mettre en service du code et changer la configuration. Ce qui l’encadre est la chaîne de mise en service, le journal public et notre engagement, et non une barrière technique.
Le transit n’est pas chiffré de bout en bout. Le compte qui gère filarr.com termine le TLS. Une interception par ce compte ne laisserait aucune trace publique, le certificat étant légitimement le sien.
Les copies restent dans l’UE, pas le transit. Une requête traverse le point de présence de Cloudflare le plus proche de l’appelant, qui peut être hors de l’Union européenne. Terminer le TLS dans la seule Union européenne n’est pas proposé.
Cloudflare est l’hébergeur. Les bases confiées sont déchiffrées en mémoire sur ses machines ; à son égard, leur protection repose sur ses engagements contractuels. Nos règles de zone ne couvrent pas ses journaux internes.
Le reçu prouve l’ordre, pas l’absence de copie. Il prouve que le service a exécuté l’effacement ; il ne peut pas prouver qu’aucune copie n’existe ailleurs.
La revue de sécurité externe n’a pas encore eu lieu. Elle est planifiée ; l’offre a ouvert avant elle, le 27 octobre 2026, après une revue de sécurité interne. Cette page indiquera la date de la revue externe lorsqu’elle aura été réalisée.

Comment reprendre la clé

Depuis Réglages › Accès API, sur le bureau ou le web, « Reprendre la clé… » propose deux chemins :

Révoquer simplement. L’API s’arrête tout de suite. Le service efface la clé et sa copie, et remet un reçu signé ; les clés des bases changent : ce qui s’y écrit ensuite est de nouveau chiffré de bout en bout.
Passer à votre propre boîte noire, sans interrompre vos logiciels :
1. installer Filarr Gate chez vous (serveur, poste, Docker ou votre compte Cloudflare) ;
2. recevoir un nouveau jeton, montré une fois ; la boîte hébergée transmet à la vôtre, scellés pour elle, ses réglages (clés d’application, webhooks, requêtes enregistrées) ;
3. changer l’adresse dans vos logiciels ; l’ancienne peut renvoyer 30 jours vers la nouvelle (308), sans rien lire ni garder ;
4. « Effacer et changer les clés » : le service efface la clé et sa copie, les bases passent à la génération suivante, un reçu signé s’ajoute au journal.

Les clés des bases externes ne sont pas transmises : Filarr les a tenues, changez-les chez leur fournisseur, puis donnez les nouvelles à votre boîte noire.

Le propriétaire ou un administrateur d’un coffre peut aussi retirer une base de son coffre d’une boîte hébergée, même s’il ne l’a pas créée.

Si l’abonnement n’est plus payé, si votre palier passe sous Pro ou si votre organisation interdit l’hébergement, la boîte s’endort : elle ne sert plus l’API, rien n’est effacé pendant 30 jours, et elle se réveille si la cause disparaît. Au terme de ce délai, elle est effacée, avec un reçu signé. Pendant le sommeil, vous pouvez la reprendre chez vous ou demander l’effacement immédiat.

Résidence des données

Vos fichiers sont chiffrés de bout en bout avant de quitter votre appareil : l’hébergeur ne peut rien en lire, où qu’il les range. Ils sont stockés chez Cloudflare R2, dans la région « Europe de l’Ouest » de Cloudflare — un indice de localisation, sans juridiction contraignante (cette région peut inclure le Royaume-Uni) ; la base de données des comptes est servie depuis la même région.

Cloudflare est une société américaine. L’argument déterminant n’est donc pas la localisation, mais le chiffrement de bout en bout : une injonction portant sur le contenu, y compris au titre du CLOUD Act, ne peut obtenir que des données chiffrées illisibles. Cela ne vaut pas pour les bases que vous confiez à la boîte noire hébergée : elles ne sont plus chiffrées de bout en bout.

Liste publique des sous-traitants →

Pour les données de compte (e-mail, facturation), Filarr est responsable de traitement. Pour les fichiers et métadonnées traités pour le compte d’un client professionnel, et pour les bases confiées à la boîte noire hébergée (annexe au DPA), Filarr agit comme sous-traitant : un accord de traitement (DPA, article 28 RGPD) est disponible et signable sur demande.

Droits des personnes (accès, rectification, effacement, opposition, portabilité) : écrivez à contact@filarr.com. Vous pouvez aussi supprimer un partage à tout moment depuis « Mes partages », sans compte.

Transparence sur notre maturité : Filarr est édité par une personne physique en phase de lancement. Nous ne revendiquons aucune certification que nous n’avons pas. Un audit de sécurité indépendant et, le cas échéant, une démarche ISO 27001 sont prévus à mesure que la base professionnelle se développe. Nous préférons documenter précisément l’architecture (vérifiable) plutôt que d’afficher des labels. La boîte noire hébergée a ouvert avant cette revue externe, après une revue interne : voir sa section.

Trust & Safety

Le chiffrement de bout en bout rend impossible tout scan de contenu côté serveur — nous l’assumons. Pour les bases confiées à la boîte noire hébergée, nous nous engageons à ne pas analyser leur contenu. Pour le contenu illégal, un mécanisme de signalement (aligné sur le mécanisme de notification du DSA, art. 16) est présent sur chaque page de réception et de dépôt : il agit sur l’identifiant et les métadonnées du lien, jamais sur le contenu. Un dépôt anonyme est protégé par une preuve de travail (proof-of-work) et des quotas par adresse, et tout partage peut être retiré sur signalement fondé.

Sécurité et divulgation responsable

Architecture cryptographique et modèle de menace
security.txt (divulgation responsable, RFC 9116)
Code source du client de bureau publié (BSL 1.1 → Apache 2.0 le 19 avril 2030), lisible et compilable. Le terme exact est « source available » : jusqu’à cette date, la licence restreint certains usages en production et ne répond donc pas à la définition open source de l’OSI. Le serveur et la cryptographie de Filarr Send ne sont pas publiés. Code source et licence

Une vulnérabilité ? Écrivez à contact@filarr.com. Merci de nous laisser un délai raisonnable avant toute divulgation publique.

Intégrité des binaires

Chaque version Windows est signée Authenticode (certificat SSL.com, SHA-256), et le condensat SHA-512 de l’exécutable est recalculé après signature puis publié avec la release : vous pouvez le comparer avant d’installer. Il n’existe pas encore de version macOS.

Garde-fous du stockage personnel

Quand vous branchez votre propre bucket, l’adresse que vous fournissez est validée avant toute connexion : HTTPS obligatoire, pas d’identifiants dans l’URL, et refus des adresses internes — boucle locale, plages privées RFC 1918, lien-local et points de métadonnées des hébergeurs cloud, y compris sous leurs écritures décimales ou hexadécimales et leurs équivalents IPv6. Les redirections ne sont jamais suivies, et un seul endpoint personnalisé est accepté par période de sept jours. Ces règles existent pour qu’un champ de configuration ne devienne pas un moyen de faire parler notre infrastructure.

Votre propre stockage →

Voir aussiConfidentialité CGU Mentions légales