Un développeur explore les alternatives aux backends cloud centralisés pour la propriété des données utilisateur

Dans une réflexion récente publiée le 26 octobre 2026, le développeur Brandon expose les défis architecturaux majeurs liés à la création d'applications web qui privilégient la propriété des données par l'utilisateur. L'auteur décrit sa tentative de construire Cheapskate, un outil de suivi financier, sans recourir aux fournisseurs backend-as-a-service centralisés comme Supabase. La tension fondamentale identifiée réside dans la nécessité d'offrir une fonctionnalité fluide et multi-appareils tout en garantissant que les données personnelles sensibles restent exclusivement sous le contrôle de l'utilisateur, plutôt que stockées sur les serveurs d'un fournisseur.

Ce qui s'est passé

L'auteur a commencé à développer Cheapskate avec l'intention d'éviter la pratique courante consistant à confier l'authentification et la gestion de la base de données à des services tiers. Tout en reconnaissant la commodité d'outils comme Supabase pour gérer l'infrastructure standard, le développeur a soutenu que ce modèle est fondamentalement défaillant pour les applications traitant des informations financières sensibles. La question centrale posée était de savoir s'il est possible d'offrir le même niveau de durabilité, de synchronisation multi-appareils et de capacités de partage que ceux trouvés dans les stacks cloud modernes, tout en gardant les données locales à l'utilisateur.

Pour répondre à cette interrogation, le développeur a systématiquement évalué plusieurs approches techniques prétendant soutenir les modèles de données « local-first » ou appartenant à l'utilisateur. Chaque option a été testée selon des critères spécifiques : facilité de mise en œuvre, accessibilité multi-appareils, capacités de partage et compatibilité navigateur. L'enquête a révélé que la plupart des solutions existantes imposent un compromis, soit en enfermant les utilisateurs dans des écosystèmes spécifiques, soit en manquant de fonctionnalités collaboratives matures, soit en exigeant des connaissances techniques bien au-delà de celles possédées par les utilisateurs finaux typiques. La conclusion fut qu'aucune solution prête à l'emploi actuelle ne remplace adéquatement la commodité des bases de données SQL centralisées pour ce cas d'usage spécifique.

Détails clés

• localStorage : Rejeté car il ne permet pas l'accès aux données sur plusieurs appareils ni le partage avec d'autres utilisateurs.
• showDirectoryPicker : Écarté en raison d'une prise en charge incomplète par les navigateurs et du besoin de services externes comme Dropbox pour gérer le partage de fichiers.
• CloudKit Private Database : Exclu car il nécessite l'identification unique Apple (Apple single sign-on), un abonnement payant pour développeurs, et manque de support de bibliothèque JavaScript pour le partage.
• SQLite dans Google Drive : Jugé techniquement pénible à configurer tant pour les développeurs que pour les utilisateurs, tout en imposant une dépendance au compte Google.
• Bring-your-own DynamoDB : Considéré comme fonctionnel mais peu pratique, car demander aux utilisateurs de gérer des clés AWS pour se connecter est déraisonnable.
• remoteStorage et CRDTs : Identifiés comme des concepts prometteurs mais actuellement dépourvus d'outillage mature pour la collaboration et de garanties claires en matière de confidentialité.

Contexte

Les plateformes Backend-as-a-Service (BaaS) comme Supabase sont devenues la norme dans le développement web moderne car elles abstraitent les tâches d'infrastructure complexes. Elles fournissent une authentification gérée, des bases de données temps réel et du stockage, permettant aux développeurs de se concentrer sur la logique frontend. Cependant, cette commodité implique un compromis : le fournisseur de service héberge et contrôle les données sous-jacentes. Pour les applications traitant des données non sensibles, cela pose rarement problème. Pour les applications financières ou liées à la santé, certains développeurs et utilisateurs préfèrent un modèle où les données résident sur des appareils contrôlés par l'individu, souvent qualifié d'architecture « local-first » ou « user-owned ».

Le logiciel local-first vise à conserver les données sur l'appareil de l'utilisateur, ne se synchronisant que lorsque c'est nécessaire. Des technologies comme les Conflict-free Replicated Data Types (CRDTs) aident à gérer la cohérence des données entre les appareils sans qu'un serveur central agisse comme source unique de vérité. Malgré les avantages théoriques pour la confidentialité, l'écosystème pour construire ces applications est moins mature que celui des modèles client-serveur traditionnels. Les développeurs font souvent face à un outillage fragmenté, à des API de navigateur incohérentes et à un manque de protocoles standardisés pour une collaboration sécurisée pair-à-pair.

Pourquoi c'est important

Pour les équipes exécutant des logiciels auto-hébergés ou développant des produits pour des marchés soucieux de la vie privée, cette analyse met en évidence un fossé critique dans le paysage actuel des outils. De nombreuses organisations choisissent l'auto-hébergement pour maintenir le contrôle sur leurs données, mais continuent de s'appuyer sur des architectures centralisées au sein de leur propre infrastructure. La difficulté à mettre en œuvre de vrais modèles de données appartenant à l'utilisateur signifie que même les applications axées sur la confidentialité ont tendance à stocker les données par défaut sur les serveurs de l'entreprise. Cela crée des problèmes de responsabilité et de confiance, car les utilisateurs doivent croire que l'opérateur protégera leurs données, au lieu de disposer de garanties cryptographiques ou architecturales attestant qu'ils en sont propriétaires.

L'absence d'un « Firebase pour CRDTs » ou d'une API universelle simple pour les requêtes SQL contrôlées par l'utilisateur force les développeurs à faire des choix difficiles. Ils peuvent soit construire des couches de synchronisation personnalisées complexes, ce qui augmente la charge de maintenance et la surface d'exposition aux bugs, soit accepter les compromis en matière de confidentialité liés au stockage centralisé. Pour les petites et moyennes entreprises, cela signifie qu'offrir une véritable souveraineté des données aux clients est actuellement plus coûteux et techniquement risqué que d'utiliser des fournisseurs cloud standards. Tant que l'outillage n'aura pas mûri, les fonctionnalités centrées sur la confidentialité pourraient rester une capacité de niche plutôt qu'une offre standard.

Ce que vous pouvez faire

• Évaluez si votre application nécessite réellement une synchronisation temps réel multi-appareils avant de vous engager dans des architectures local-first complexes.
• Si vous utilisez un stockage centralisé, implémentez des politiques strictes de rétention des données et des mécanismes de consentement utilisateur clairs pour atténuer les risques liés à la vie privée.
• Suivez le développement des bibliothèques remoteStorage et CRDT, car ces écosystèmes évoluent rapidement et pourraient bientôt offrir des solutions viables.
• Envisagez des modèles hybrides où les données sensibles sont chiffrées côté client avant d'être stockées sur vos serveurs, donnant ainsi aux utilisateurs le contrôle des clés.
• Documentez votre architecture de données en toute transparence pour les utilisateurs, en expliquant où résident les données et qui y a accès.
• Engagez-vous avec les communautés open source travaillant sur les protocoles local-first pour partager des retours et accélérer la maturité de l'outillage.