Trame
Sécurité
Une application familiale contient l'agenda de vos enfants, votre adresse et vos dépenses. Voici, sans jargon commercial, comment ces données sont protégées — et ce qui ne l'est pas encore.
Le principe : le téléphone n'a jamais le dernier mot
L'application installée sur votre téléphone n'est pas une autorité de confiance : n'importe qui peut l'analyser, la modifier, ou parler directement au serveur sans elle. Toutes les règles d'accès de Trame sont donc appliquées dans la base de données, au niveau de chaque ligne. Une requête qui demande les événements d'un autre foyer ne reçoit pas une erreur : elle reçoit zéro ligne, parce que ces lignes n'existent pas pour elle.
Ces règles s'appuient sur des fonctions qui vivent dans un schéma non exposé par l'API : elles ne sont pas appelables depuis l'extérieur, seulement par la base elle-même.
Ce qui est en place
Isolation par foyer
Chaque table est protégée ligne à ligne. Le foyer d'appartenance d'une donnée est réécrit par la base à l'écriture : le client ne peut pas le choisir.
Rôles réels
Adulte, enfant et lecture seule ne sont pas de simples affichages : un compte enfant ne peut pas supprimer le foyer ni voir le budget, quoi qu'envoie son téléphone.
Connexion sans mot de passe
Un code à usage unique envoyé par courriel. Aucun mot de passe à retenir, à réutiliser, ni à se faire voler dans une fuite ailleurs.
Session chiffrée sur l'appareil
Le jeton de session est chiffré (AES-256) ; la clé vit dans l'enclave sécurisée du téléphone et ne quitte jamais cet appareil.
Fichiers privés
Documents et photos de profil sont stockés dans des espaces privés. L'accès passe par des liens signés à durée limitée, jamais par une adresse publique devinable.
Aucun secret dans le code
Aucune clé ni mot de passe n'est écrit dans le code, les journaux ou l'historique du dépôt. Seules l'adresse du service et une clé publique voyagent avec l'application.
Ce qui le prouve
Affirmer qu'une application est sécurisée ne vaut rien sans vérification. Trame embarque une batterie de tests d'intrusion qui rejouent, depuis un compte d'attaquant, les scénarios qu'on redoute : lire l'agenda d'un autre foyer, s'y ajouter comme membre, déplacer une donnée d'un foyer à l'autre, se promouvoir administrateur, écrire alors qu'on est en lecture seule.
Ces tests s'exécutent automatiquement à chaque modification du code, sur une base de données neuve, par intégration continue. Une règle d'accès affaiblie par mégarde fait échouer la vérification avant d'atteindre qui que ce soit.
Deux erreurs, et ce qu'elles ont appris
Le durcissement a introduit deux régressions, corrigées depuis. Elles sont documentées publiquement plutôt qu'effacées, parce qu'un rapport de sécurité qui ne contient que des succès n'est pas un rapport de sécurité.
- Un retrait de droits trop large a cassé la génération des codes d'invitation : restreindre sans cartographier les usages, c'est provoquer une panne.
- Un test d'intrusion écrit à la main portait une ambiguïté de nommage qui le faisait échouer pour une mauvaise raison : un test qui échoue mal vaut presque un test absent.
Risques assumés
Aucun système n'est parfaitement sûr, et prétendre le contraire est déjà un défaut. Aujourd'hui, les données ne sont pas chiffrées de bout en bout : l'hébergeur pourrait techniquement les lire. Un membre du foyer, par définition, voit les données du foyer. Et la sécurité d'un compte repose sur celle de la boîte courriel associée.
Signaler une faille
Si vous trouvez un problème de sécurité, écrivez à securite@trameapp.app plutôt que de le publier. Toute divulgation responsable reçoit une réponse, et un correctif si elle est fondée.