Factures France
Prévention des pertes de données
Ces contrôles limitent la copie et la perte du nom, de l'e-mail et des adresses. Ils ne sont pas une certification.
Au repos
Dans la base, le nom, l'e-mail, l'adresse de facturation et l'adresse de livraison sont chiffrés (AES-256-GCM). La clé est le secret DATA_ENCRYPTION_KEY. Elle n'est pas dans le dépôt. Sans cette clé, la production ne démarre pas.
Le numéro, la date, les montants, les lignes, le SIREN et le numéro de TVA restent lisibles : ils font partie de la pièce comptable. Le journal des lectures ne contient pas le nom, l'e-mail ni l'adresse.
En transit
Fly force le HTTPS vers l'application. Une adresse d'application en HTTP est refusée en production. Les appels à l'API Shopify et les webhooks passent par HTTPS. La sauvegarde n'est envoyée qu'à une adresse HTTPS.
Sauvegardes
Une fois par jour, la production copie prod.sqlite, chiffre cette copie avec une autre clé (BACKUP_ENCRYPTION_KEY), efface la copie en clair, et envoie le fichier chiffré dans un bucket privé. Trente fichiers sont conservés, puis les plus anciens sont effacés. La base de développement n'est pas envoyée.
Ces copies durent 30 jours, pas 10 ans. Elles servent à reprendre après une perte du volume, pas à garder une seconde archive des adresses.
Restauration
La procédure pour remettre une sauvegarde à la place de la base est dans le README du dépôt. Le contrôle automatique vérifie qu'un fichier chiffré se déchiffre et rend une base SQLite. Ce n'est pas un audit, et ce n'est pas un essai déjà fait sur la base en ligne.
Qui peut y accéder
Une seule personne administre Fly, le Partner Dashboard et GitHub : Rachid Bouhmou. L'application se lit dans l'admin Shopify, avec la session du marchand. La portée est read_orders. Le fichier de développement et le fichier de production ne sont pas interchangeables. La production n'est pas copiée sur un poste pour travailler.