Sécurité
Dernière mise à jour : 26 juillet 2026
Cette page décrit les mesures réellement en place, et celles qui ne le sont pas encore. Un document de sécurité qui ne parle que de ce qui va bien n'apprend rien à personne.
L'isolement des comptes
La séparation est appliquée par la base de données, pas par le code.
Chaque table porte une politique qui restreint la lecture et l'écriture aux lignes du compte connecté. Une erreur de filtre dans le code applicatif ne suffirait donc pas à exposer les données d'un autre usager : la base refuserait la requête.
Le principe vaut aussi pour les fichiers. Le dossier de stockage porte l'identifiant du compte en premier segment, et la politique du bucket compare ce segment à l'usager connecté.
Cette isolation a été éprouvée : deux comptes de test, chacun avec son contenu, chacun aveugle à celui de l'autre.
Les fichiers produits
Le stockage est privé. Aucune image n'est accessible par une adresse publique.
Les visuels sont servis par des liens signés valables une heure, régénérés à chaque consultation. Les liens ne sont jamais conservés en base — seuls les chemins le sont. Un lien qui fuiterait expire de lui-même.
L'intégrité des fichiers déposés est vérifiée : la taille reçue est comparée à la taille envoyée. Un transfert altéré est signalé au lieu de passer inaperçu.
Les mots de passe
Ils ne sont jamais stockés en clair ni chiffrés de façon réversible. Seule une empreinte cryptographique est conservée, par Supabase Auth. L'éditeur ne peut pas lire le mot de passe d'un usager, ni le lui rappeler — seulement lui permettre d'en choisir un nouveau.
Les clés d'accès
La clé qui contourne les protections de la base n'existe que côté serveur. L'application refuse de démarrer si elle est exposée au navigateur : la vérification est faite au chargement, et une clé mal configurée arrête le service plutôt que de le laisser fonctionner en étant vulnérable.
Les fonctions sensibles — celles qui décomptent les quotas — ne sont exécutables que par le serveur, jamais depuis un navigateur.
La facturation interne
Un crédit est réservé avant toute production, consommé seulement au succès, rendu sur tout échec. Cette réservation est atomique : deux demandes simultanées ne peuvent pas franchir ensemble le plafond.
Les fonctions de décompte résistent au rejeu : un appel répété par erreur ne facture pas deux fois et ne rend pas un crédit deux fois.
Le contenu produit
Le modèle a interdiction d'inventer une statistique, un chiffre ou une citation que l'idée de l'usager ne fournit pas. Une consigne écrite par l'usager peut orienter le sujet et le ton, mais ne peut pas lever ces interdictions — ce serait une porte dérobée dans les règles de sûreté.
Ces garde-fous réduisent le risque d'une affirmation fausse. Ils ne le suppriment pas : la relecture avant publication reste indispensable.
Ce qui n'est pas encore en place
- Journalisation des accès administratifs — aucune trace n'est conservée
- des consultations effectuées par l'éditeur sur la base
- Chiffrement applicatif des contenus — le chiffrement au repos de
- l'hébergeur s'applique, mais rien ne s'y ajoute
- Audit de sécurité externe — aucun n'a été mené
- Authentification à deux facteurs — non proposée
- Politique de sauvegarde documentée — celle de l'hébergeur s'applique,
- ses délais restent à vérifier et à publier
Ces manques sont énoncés parce qu'ils existent. Ils seront comblés par ordre d'exposition réelle, et cette page suivra.
Signaler une faille
Si vous découvrez une vulnérabilité, écrivez à [COURRIEL DE SÉCURITÉ] avant toute divulgation publique. Les signalements de bonne foi sont accueillis avec reconnaissance et sans poursuite.
Une question sur ce document ? Écris à [COURRIEL DE CONTACT].