Pourquoi Inner Gallery fonctionne sans serveur
Inner Gallery n'a pas de backend, pas de comptes, pas de cloud. Pourquoi c'est un choix d'architecture délibéré et ce que ça implique pour la vie privée.
Inner Gallery n'a pas de serveur parce qu'il n'en a pas besoin. Les photos sont chiffrées sur l'appareil avec CryptoKit, stockées localement, et jamais transmises nulle part. Pas de serveur signifie pas de fuites de données, pas de comptes, pas de coûts récurrents, et aucune raison de facturer un abonnement. La synchronisation cloud chiffrée est prévue — mais même alors, le serveur ne détiendra jamais vos clés de déchiffrement.
La plupart des apps ont des serveurs. Les serveurs stockent vos données, gèrent votre compte, traitent les paiements, envoient des notifications et collectent des analytics. Ils sont si omniprésents qu'une app « sans serveur » semble incomplète.
Inner Gallery est conçu autour d'une question : et si le serveur était le problème ?
Ce que fait un serveur dans une app coffre-fort classique
Dans la plupart des apps coffre-fort photo, le serveur remplit plusieurs rôles :
- Gestion des comptes : créer un compte, se connecter, récupérer son mot de passe. Le serveur stocke les identifiants et gère l'authentification.
- Stockage des photos : vos photos sont uploadées vers le cloud de l'entreprise. Le serveur les stocke, parfois chiffrées avec des clés que l'entreprise détient.
- Traitement des paiements : gestion des abonnements, validation des reçus, vérification des droits.
- Analytics : suivi d'utilisation, données comportementales, rapports de crash. C'est là qu'interviennent les SDK comme Amplitude, Firebase et Facebook.
- Synchronisation : accès multi-appareils aux photos via le serveur.
Chacun de ces éléments crée une dépendance — et un point potentiel de défaillance ou d'exploitation.
Le problème de chaque fonction serveur
Les comptes impliquent la récupération de mot de passe, qui implique l'accès aux clés
Si une app coffre-fort propose la récupération « mot de passe oublié », quelqu'un — l'entreprise, leur serveur, un agent de support — peut réinitialiser vos identifiants et accéder à vos données. Le vrai chiffrement de bout en bout est incompatible avec la récupération de mot de passe. La clé de chiffrement doit être dérivée de quelque chose que seul l'utilisateur connaît. Si l'entreprise peut la réinitialiser, elle détient une clé.
Le stockage cloud signifie une surface d'attaque
Chaque serveur stockant des données utilisateur est une cible. Les fuites de données en 2024 ont affecté des milliards d'enregistrements dans tous les secteurs. Une app coffre-fort stockant des photos sur un serveur crée une cible centralisée — des millions de photos privées au même endroit.
Le stockage cloud signifie aussi que l'entreprise peut accéder à vos photos, sauf si elle utilise un vrai chiffrement de bout en bout où elle ne détient pas les clés. Comme documenté dans Les apps coffre-fort photo sont-elles vraiment sûres ?, la plupart des apps coffre-fort n'implémentent pas ça.
Les analytics signifient du tracking
Si l'app inclut des SDK d'analytics, elle collecte des données comportementales. Vues d'écran, durée de session, utilisation des fonctionnalités, informations sur l'appareil. Même si les analytics ne touchent pas directement vos photos, elles construisent un profil de votre comportement à l'intérieur d'une app de « confidentialité ».
La relation de Keepsafe avec Amplitude — suivant 6 milliards d'événements et utilisant les données comportementales pour optimiser les prix — est un exemple public de comment ça fonctionne en pratique.
Les serveurs impliquent des coûts récurrents, qui impliquent des abonnements
Faire tourner des serveurs coûte de l'argent. Hébergement cloud, bande passante, stockage, ingénierie pour maintenir l'infrastructure. Ces coûts sont récurrents mensuellement, c'est pourquoi les apps dépendantes d'un serveur facturent des abonnements. Les 9,99 $/mois ne sont pas que du profit — ils financent les serveurs qui stockent vos photos.
Cela crée une incitation mal alignée : l'app a besoin que vous continuiez à payer, donc elle a besoin de garder vos photos sur ses serveurs. Arrêtez de payer, et vos photos deviennent inaccessibles — ou supprimées. Pour en savoir plus sur cette dynamique, voir Pourquoi les apps coffre-fort facturent des abonnements.
Comment Inner Gallery fonctionne sans serveur
Inner Gallery élimine le serveur entièrement. Voici ce qui remplace chaque fonction :
Pas de comptes
Pas de connexion, pas d'email, pas de mot de passe. Chaque espace dans l'app est protégé par son propre PIN, utilisé pour dériver la clé de chiffrement localement. Aucune récupération de PIN n'existe — par design. Si l'entreprise ne peut pas récupérer votre PIN, l'entreprise ne peut pas accéder à vos données.
Pas de stockage cloud
Les photos restent sur l'appareil. Chacune est chiffrée individuellement avec ChaCha20-Poly1305 via le framework natif CryptoKit d'Apple. Les fichiers chiffrés existent dans le sandbox de l'app sur le stockage local de l'iPhone, protégés à la fois par le chiffrement du coffre-fort et la protection de fichiers iOS.
Pas d'analytics
Zéro SDK de tracking. Pas d'Amplitude, pas de Firebase, pas de Facebook SDK, pas d'Adjust, pas d'AppsFlyer. L'app ne demande même pas de permissions réseau. Il n'y a aucune télémétrie, aucun service de rapport de crash, aucun analytics d'utilisation. Si une fonctionnalité est plus utilisée qu'une autre, les développeurs ne le savent pas — et c'est intentionnel.
Pas de serveur signifie pas de coûts récurrents
Sans serveurs à faire tourner, il n'y a pas de coût d'infrastructure permanent. C'est pourquoi Inner Gallery peut proposer un modèle d'achat unique : tier gratuit (2 espaces, 50 médias), packs d'extension à 9,99 €, Pro Bundle à 24,99 €, Lifetime à 99,99 €. Pas d'abonnement. Une fois acheté, les fonctionnalités marchent pour toujours.
Validation des paiements
Les achats intégrés sont validés localement via le framework StoreKit d'Apple. L'iPhone gère la vérification d'achat directement avec les serveurs d'Apple — l'app elle-même n'a pas besoin de son propre serveur pour ça.
Et les sauvegardes ?
C'est le compromis honnête. Sans serveur, il n'y a pas de sauvegarde cloud automatique. Si l'appareil est perdu, endommagé ou effacé, les photos stockées localement sont perdues.
Stratégies d'atténuation :
- Sauvegarde chiffrée iTunes/Finder : une sauvegarde complète de l'appareil inclut les données du sandbox de l'app. Avec une sauvegarde chiffrée, les données du coffre-fort sont incluses dans la couche de chiffrement de la sauvegarde.
- Sauvegarde iCloud : si la sauvegarde iCloud est activée, les données de l'app peuvent être incluses dans la sauvegarde de l'appareil (chiffrées avec les clés iCloud, ou E2EE avec la Protection avancée des données activée).
La synchronisation chiffrée est prévue
La feuille de route inclut la synchronisation cloud chiffrée — répliquer les données du coffre-fort entre appareils sans que le serveur n'ait jamais accès aux clés de déchiffrement. Le serveur de sync ne stockerait que des blobs chiffrés, utilisant un protocole d'échange de clés où les clés sont dérivées du PIN de l'utilisateur sur chaque appareil. Le serveur serait un simple tuyau, transportant des données chiffrées qu'il ne peut pas lire.
Cette approche donne les avantages de sauvegarde du stockage cloud tout en maintenant l'architecture zero-knowledge. Le serveur ne verrait jamais de photos non chiffrées, ne détiendrait jamais de clés de déchiffrement, et pourrait être compromis sans exposer les données utilisateur.
L'architecture en pratique
Voici ce que le design sans serveur signifie au quotidien :
| Fonctionnalité | Coffre-fort avec serveur | Inner Gallery |
|---|---|---|
| Fonctionne hors ligne | Parfois | Toujours |
| Fonctionne sans internet | Rarement | Toujours |
| Compte requis | Oui | Non |
| Récupération de mot de passe | Oui (le serveur détient la clé) | Non (par design) |
| Fuite de données possible (côté serveur) | Oui | Pas de serveur à compromettre |
| Photos accessibles au développeur | En général | Jamais |
| Abonnement requis | En général | Non |
| Analytics/tracking | En général | Aucun |
Un serveur est une responsabilité quand l'objectif est la confidentialité. Chaque fonction serveur dans une app coffre-fort — comptes, stockage, analytics, sync — peut être remplacée par une approche local-first qui garde l'utilisateur en contrôle total. Le compromis est la responsabilité des sauvegardes, que la sync chiffrée résoudra.
Pourquoi c'est important pour la question du chiffrement
Comme exploré dans Chiffrement de photos sur iPhone : ce que ça veut dire concrètement, la question critique en matière de chiffrement est toujours : qui détient la clé ?
Dans un coffre-fort avec serveur, la réponse est souvent « l'utilisateur et l'entreprise ». Dans Inner Gallery, la réponse est « seulement l'utilisateur ». Il n'y a pas de serveur vers lequel envoyer la clé, pas de système de compte pour la stocker, pas de mécanisme de récupération qui pourrait l'exposer.
C'est ce que l'architecture zero-knowledge signifie en pratique. Les développeurs savent que l'app existe sur votre téléphone. Ils ne savent pas ce qu'elle contient. Ils ne peuvent pas le savoir, parce que l'architecture rend ça impossible.