Brancher ton propre stockage S3 sur Filarr (BYOS) : le guide pas à pas

La plupart des apps de notes te donnent un bout de cloud et te disent merci. Tes fichiers vivent sur leurs serveurs, dans leur bucket, sous leur facture. Avec le mode BYOS (Bring Your Own Storage) de Filarr, tu inverses ce rapport : la sync continue de marcher sur tous tes appareils, mais les octets atterrissent dans un bucket S3 que tu possèdes, chez le fournisseur que tu choisis, à tes conditions. Ce guide montre comment le configurer de bout en bout, sans y laisser une demi-journée.

Quick Answer. Pour brancher ton propre stockage sur Filarr, crée un bucket chez un fournisseur S3-compatible (AWS S3, Backblaze B2, Wasabi, DigitalOcean Spaces, Cloudflare R2 ou MinIO auto-hébergé), génère une paire de clés (Access Key ID + Secret Access Key), puis ouvre Réglages puis Fournisseur de stockage dans Filarr, clique sur Ajouter un fournisseur et renseigne l'endpoint, la région, le nom du bucket et tes deux clés. Teste la connexion, définis le fournisseur par défaut, et la sync commence. Chaque fichier est chiffré en AES-256-GCM sur ta machine avant d'être envoyé : ton fournisseur ne stocke que des blobs opaques qu'il ne peut pas lire.

Pourquoi utiliser ton propre bucket (et pour qui)

Avant de parler endpoints et clés, la vraie question : qu'est-ce que ça change dans ta journée ?

Trois situations concrètes où le BYOS devient évident. D'abord, tu as déjà un compte cloud pro (AWS, Backblaze, DigitalOcean) et tu veux que toutes tes données tombent au même endroit, avec une seule facture et une seule politique de sauvegarde. Ensuite, tu es dans un contexte où la localisation des données compte : un bucket en Europe chez un hébergeur européen, c'est un argument RGPD que tu peux documenter. Enfin, tu veux éviter le lock-in : si un jour tu quittes Filarr, tes fichiers sont déjà chez toi, tu n'as rien à rapatrier.

Le BYOS vise donc les self-hosters, les freelances et cabinets qui gèrent des données clients, et toute personne qui préfère contrôler l'infrastructure plutôt que la louer en aveugle. Si tu veux juste que la sync marche sans y penser, la sync cloud gérée de Filarr (sur R2, à partir de 4 euros par mois) fait très bien le travail. Le BYOS, c'est pour quand tu veux la main sur le stockage lui-même.

Point important à garder en tête tout du long : brancher ton propre S3 ne remplace pas le chiffrement, ça s'ajoute par-dessus. Filarr chiffre chaque fichier localement avant l'envoi. Ton fournisseur S3, même si c'est toi qui le contrôles, ne voit jamais le contenu en clair. On y revient plus bas, mais c'est la raison pour laquelle tu peux utiliser un bucket AWS sans trahir le modèle zero-knowledge. Si le principe t'intéresse, j'explique la mécanique complète dans l'article sur la sync zero-knowledge de Filarr.

Étape 1 : choisir un fournisseur S3-compatible

Filarr parle le protocole S3, pas une API maison. Tout service qui expose une API S3-compatible fonctionne. Les principaux candidats, avec leurs compromis honnêtes :

• Backblaze B2. Le meilleur rapport prix/simplicité pour un usage perso. Stockage très bon marché, egress gratuit jusqu'à un certain volume. Endpoint du type https://s3.us-west-004.backblazeb2.com.
• Wasabi. Tarif unique au stockage, pas de frais d'egress ni de requêtes. Pratique si tu syncs beaucoup. Attention à leur politique de rétention minimale (tu paies un volume pendant 90 jours même si tu le supprimes avant).
• AWS S3. La référence, ultra fiable, mais la facture d'egress peut surprendre si tu télécharges souvent de gros fichiers. Endpoint standard : https://s3.<region>.amazonaws.com.
• DigitalOcean Spaces. Simple, prix prévisible, bon compromis. Endpoint du type https://<region>.digitaloceanspaces.com.
• Cloudflare R2. Pas de frais d'egress du tout, ce qui en fait un excellent choix. C'est d'ailleurs le backend de la sync gérée de Filarr, mais rien ne t'empêche d'utiliser ton propre compte R2 en BYOS.
• MinIO (auto-hébergé). Si tu veux vraiment tout garder chez toi, sur ton NAS ou ton serveur. Tu obtiens une API S3 locale complète. C'est le choix le plus souverain, et aussi le plus exigeant côté maintenance.

Mon conseil si tu débutes : Backblaze B2 ou Wasabi pour le cloud, MinIO si tu es déjà à l'aise avec Docker et que tu veux du 100 pour 100 maison. Il n'y a pas de mauvais choix, juste des arbitrages entre prix, egress et effort d'administration.

Étape 2 : créer le bucket et les clés d'accès

La procédure exacte varie d'un fournisseur à l'autre, mais la logique est toujours la même. Tu crées un bucket, tu le gardes privé, et tu génères une paire de clés d'accès que Filarr utilisera pour lire et écrire.

1. Crée un bucket privé. Donne-lui un nom explicite, par exemple filarr-storage. Ne le rends surtout pas public : le contenu est chiffré, mais un bucket privé évite même d'exposer la liste des objets. Note la région exacte (eu-west-1, us-west-004, etc.), tu en auras besoin.
2. Génère une Access Key ID et une Secret Access Key. Chez AWS, ça passe par IAM. Chez Backblaze, par les Application Keys. Chez Wasabi et DigitalOcean, par la section Access Keys. Idéalement, restreins la clé à ce seul bucket plutôt que de donner un accès global à ton compte.
3. Récupère l'URL de l'endpoint. C'est l'adresse du service S3 de ta région. Pour AWS, Filarr sait la deviner à partir de la région, mais pour tous les autres fournisseurs tu dois la fournir explicitement. Copie-la depuis le tableau de bord de ton provider.

Garde la Secret Access Key en lieu sûr le temps de la configuration : la plupart des fournisseurs ne te la montrent qu'une seule fois à la création. Si tu la perds, pas de drame, tu en regénères une et tu mets à jour Filarr.

Option : provisionner un bucket AWS en une commande

Pour les utilisateurs AWS, le repo de Filarr inclut un script d'aide, scripts/setup-s3.sh, qui crée le bucket, active le versioning, le chiffrement côté serveur, une politique de cycle de vie et teste la connexion. C'est purement pour provisionner l'infrastructure : la configuration dans l'app reste manuelle. Il gère AWS, MinIO, et te guide pour DigitalOcean, Backblaze et Wasabi.

Étape 3 (recommandée) : durcir ton bucket

Cette étape est optionnelle, mais c'est ce qui sépare un bucket vite fait d'un stockage dont tu seras content dans six mois. Trois réglages valent le détour.

Active le versioning. Si un fichier est écrasé ou supprimé par erreur, tu peux revenir en arrière. Combiné au chiffrement par fichier de Filarr, chaque version reste un blob chiffré indépendant. C'est un filet de sécurité qui coûte quelques centimes.

Active le chiffrement côté serveur (SSE). Oui, Filarr chiffre déjà tout avant l'envoi, donc techniquement c'est une ceinture par-dessus les bretelles. Mais ça ne coûte rien, ça coche une case de conformité, et ça protège les éventuels fichiers de test ou métadonnées qui traîneraient. Le script setup-s3.sh l'active en AES256 par défaut.

Pose une politique de cycle de vie. Au minimum, supprime les uploads multipart incomplets après quelques jours pour ne pas payer des fragments orphelins. Tu peux aussi archiver les anciennes versions vers une classe de stockage froide (type Glacier) après 90 jours. Attention : un fichier en Glacier n'est pas récupérable instantanément, donc ne fais ça que pour des versions anciennes, jamais pour les données actives.

Un mot sur le CORS : les tutoriels S3 insistent souvent dessus. Pour l'app desktop Filarr (Electron), tu n'en as pas besoin, car les requêtes partent du processus principal, pas d'un navigateur soumis à la politique d'origine. Ne perds pas de temps à configurer du CORS pour le desktop.

Étape 4 : ajouter le fournisseur dans Filarr

Maintenant la partie qui se passe dans l'app. Ouvre les Réglages, puis la section Fournisseur de stockage. C'est là que vit toute la configuration BYOS. Clique sur Ajouter un fournisseur, et tu tombes sur un formulaire avec les champs suivants :

• Nom du fournisseur. Un libellé pour toi, par exemple « Backblaze perso » ou « MinIO NAS ». Purement cosmétique.
• Type de fournisseur. Le service que tu utilises (AWS, Backblaze, etc.).
• URL du endpoint. L'adresse récupérée à l'étape 2. Pour AWS tu peux la laisser vide, Filarr la déduit de la région ; pour tous les autres, colle-la.
• Région. La région exacte de ton bucket.
• Bucket. Le nom du bucket, tel quel.
• Access Key ID. La clé publique de ta paire.
• Secret Access Key. La clé secrète.

Un détail technique utile : dès que tu renseignes un endpoint personnalisé (donc tout sauf AWS pur), Filarr bascule automatiquement en mode « path-style » pour les URLs S3. C'est ce dont MinIO, Backblaze et compagnie ont besoin. Tu n'as rien à cocher, c'est géré.

Quand tu enregistres, voici ce qui se passe côté coulisses, et c'est important pour comprendre où vivent tes secrets. La configuration du fournisseur (nom, endpoint, région, bucket, Access Key ID) est stockée dans un fichier byos-providers.json dans le dossier de ton profil. La Secret Access Key, elle, n'y est jamais écrite en clair : elle part dans un coffre à part, credentials.enc, chiffré en AES-256-GCM avec une clé dérivée de ta clé maître locale via PBKDF2-SHA512 (600 000 itérations), et le fichier est posé sur disque avec des permissions restreintes (lecture/écriture pour toi uniquement). Autrement dit, même ta clé d'accès S3 est protégée au repos sur ta propre machine. Si le sujet des hiérarchies de clés t'intéresse, je détaille le mécanisme KEK/FEK dans cet article sur le chiffrement par fichier.

Étape 5 : tester et activer

Avant de tout basculer, utilise le bouton Tester la connexion. Filarr envoie une requête légère vers ton endpoint et te renvoie la latence et le statut. Si tu obtiens une connexion réussie, tu es bon. Même une réponse de type « accès refusé » signifie en réalité que l'endpoint est joignable, ce qui est déjà une bonne nouvelle, mais vérifie quand même tes clés dans ce cas.

Si le test échoue, les coupables habituels, dans l'ordre : une région qui ne correspond pas au bucket, un endpoint mal copié (un https:// oublié, un suffixe de région erroné), ou une Secret Access Key tronquée au copier-coller. Reprends ces trois points avant toute chose.

Une fois le test passé, clique sur Définir par défaut. À partir de là, la sync de Filarr écrit dans ton bucket. Les fichiers y sont rangés selon un schéma simple et prévisible : {idDossier}/{idFichier}/{nomFichier}. Tu peux ouvrir la console de ton fournisseur et voir apparaître les objets, mais rappelle-toi qu'ils sont chiffrés : tu verras des noms et des tailles, pas du contenu lisible.

Ce que ton fournisseur voit réellement

C'est le cœur du modèle, donc soyons précis. Filarr chiffre le contenu de chaque fichier en AES-256-GCM sur ta machine, avec une clé par fichier, avant qu'un seul octet ne quitte l'appareil. Le client S3 qui parle à ton bucket ne manipule que des buffers déjà chiffrés. Résultat : ton fournisseur S3, qu'il s'agisse d'AWS ou de ton propre MinIO, stocke des blobs opaques. Il ne peut pas lire tes notes, même s'il le voulait, même sous réquisition.

Ce n'est pas magique, et il faut être honnête sur les limites. Ton fournisseur voit quand même des métadonnées : le nombre d'objets, leur taille, les dates de modification, et la structure des clés (les identifiants de dossiers et de fichiers). Ça ne révèle pas le contenu, mais ça révèle une activité. Si ton modèle de menace inclut l'analyse de trafic, garde-le en tête. Pour comprendre exactement ce que chiffrement au repos, de bout en bout et zero-knowledge recouvrent, et ce qu'ils ne protègent pas, j'ai écrit un comparatif dédié des trois notions.

Et comme le chiffrement se fait avec tes clés dérivées de ton mot de passe maître, pense à ta phrase de récupération de 24 mots. Perdre ton mot de passe sans cette phrase, c'est perdre l'accès aux données, y compris celles dans ton propre bucket. Avoir le contrôle du stockage ne te dispense pas d'avoir une stratégie de sauvegarde des clés, que je détaille dans le guide sur sauvegarder ses notes chiffrées sans casser le zero-knowledge.

Pièges courants et bonnes pratiques

Le mismatch région/endpoint. De loin l'erreur numéro un. Le bucket est dans une région, mais tu renseignes l'endpoint d'une autre. Vérifie que les deux pointent vers le même datacenter.

Le bucket laissé public. Le contenu est chiffré, mais un bucket public expose la structure et invite au scraping. Garde-le privé, toujours.

Les clés trop permissives. Évite d'utiliser tes identifiants racine ou une clé avec accès à tout ton compte. Crée une clé limitée au bucket Filarr. Si elle fuite, les dégâts sont contenus.

Oublier les coûts d'egress. Sur AWS et certains autres, télécharger beaucoup de données coûte cher. Si tu syncs de gros volumes sur plusieurs appareils, un fournisseur sans frais d'egress (R2, Wasabi, Backblaze dans une certaine limite) t'évitera des surprises.

Déplacer ou renommer les objets à la main. Ne touche pas aux objets dans la console de ton fournisseur. Filarr s'appuie sur le schéma de clés {idDossier}/{idFichier}/{nomFichier} pour retrouver ses petits. Renommer un objet côté S3 casse la correspondance.

Perdre la clé de chiffrement locale. Le coffre credentials.enc dépend de ta clé maître. Si tu réinstalles le système sans ta phrase de récupération, tu devras reconfigurer le fournisseur et tu perdras l'accès au contenu déjà chiffré. Sauvegarde ta phrase de 24 mots hors ligne.

Côté bonnes pratiques, active le versioning dès le départ, teste une restauration une fois pour de vrai (rien ne vaut un test réel), et documente quelque part ta région, ton endpoint et l'identifiant de ta clé. Le futur toi te remerciera.

FAQ

Mon fournisseur S3 peut-il lire mes fichiers ? Non. Filarr chiffre chaque fichier en AES-256-GCM sur ta machine avant l'upload. Ton fournisseur ne reçoit que des blobs chiffrés et des métadonnées (tailles, dates, structure des clés), jamais le contenu en clair. C'est vrai même si le fournisseur, c'est toi.

Le BYOS est-il gratuit dans Filarr ? Filarr est gratuit pour toujours en usage local. La sync cloud gérée démarre à 4 euros par mois. Le BYOS consiste à utiliser ton propre bucket plutôt que le stockage géré : tu paies alors ton fournisseur S3 directement. Vérifie dans l'app quelle offre donne accès au stockage personnalisé, car cette fonction peut dépendre de ton plan.

Quels fournisseurs sont compatibles ? Tout service exposant une API S3-compatible : AWS S3, Backblaze B2, Wasabi, DigitalOcean Spaces, Cloudflare R2, et MinIO pour l'auto-hébergement. Le script setup-s3.sh du repo couvre explicitement AWS, MinIO, DigitalOcean, Backblaze et Wasabi.

Puis-je auto-héberger le stockage avec MinIO ? Oui. MinIO expose une API S3 locale complète. Lance-le (le script fournit une commande Docker prête à l'emploi), crée un bucket, puis renseigne son endpoint local dans Filarr. Tu obtiens un workspace chiffré dont les données ne quittent jamais ton réseau.

Que se passe-t-il si je perds ma Secret Access Key ? Aucun souci côté données : regénère une nouvelle paire de clés dans la console de ton fournisseur, puis mets à jour le fournisseur dans les Réglages de Filarr. Tes fichiers chiffrés dans le bucket ne sont pas affectés, puisqu'ils ne dépendent pas de la clé S3 mais de ta clé de chiffrement.

Faut-il configurer du CORS sur le bucket ? Pas pour l'app desktop. Les requêtes partent du processus Electron, pas d'un navigateur, donc la politique CORS ne s'applique pas. Tu ne configures du CORS que si tu accèdes au même bucket depuis un contexte web.

Conclusion

Brancher ton propre S3 sur Filarr prend une quinzaine de minutes : un bucket privé, une paire de clés, six champs à remplir dans Réglages puis Fournisseur de stockage, un test de connexion. Ce que tu gagnes est durable : tes fichiers vivent sur une infrastructure que tu possèdes, chiffrés avant même de partir de ta machine, sans lock-in et sans intermédiaire qui peut lire ton contenu. Commence simple avec Backblaze ou Wasabi si tu débutes, ou vise MinIO si tu veux du 100 pour 100 maison. Puis active le versioning, note ta phrase de récupération, et oublie-les : la sync fait le reste, dans ton bucket, à tes conditions.