Sauvegarde et restauration
Politique de sauvegarde des environnements clients opérés par Alpene et procédure de restauration associée.
Périmètre
Cette politique couvre :
- les services opérés par Alpene dans le cadre d'un suivi ;
- les actifs explicitement inclus dans B3.3 ;
- les sauvegardes nécessaires avant une migration ou une opération risquée ;
- la restitution des données à la fin du suivi.
Sans suivi, Alpene peut configurer et documenter la sauvegarde, mais le client ou son prestataire devient responsable de son exécution, de sa supervision et de ses restaurations après la livraison.
B4 n'entre pas dans cette politique, sauf pour les documents d'inventaire et de livraison déjà conservés dans le socle documentaire du client.
Définitions
| Terme | Définition |
|---|---|
| RPO | Perte de données maximale acceptable entre la dernière sauvegarde exploitable et l'incident |
| RTO | Durée cible entre le lancement de la restauration et le retour du service dans un état utilisable |
| Rétention | Durée pendant laquelle une sauvegarde est conservée |
| Restauration | Remise à disposition de données ou d'un service à partir d'une sauvegarde |
| Sauvegarde indépendante | Copie stockée en dehors de l'environnement de production et non dépendante de son fonctionnement |
La réplication, la synchronisation, l'historique de versions ou la corbeille d'un service ne remplacent pas automatiquement une sauvegarde indépendante.
Objectifs de référence
La baseline vise :
- un RPO de 24 heures ;
- un RTO de 8 heures ouvrées ;
- une sauvegarde avant toute migration ou mise en production risquée ;
- une copie séparée de l'environnement de production ;
- un chiffrement des sauvegardes ;
- une localisation en France ou dans l'Union européenne lorsque le besoin ou le fournisseur le permet.
Ces objectifs sont adaptés avec le client lorsque la criticité, la volumétrie, les contraintes réglementaires ou l'architecture l'exigent. Ils deviennent contractuels uniquement lorsqu'ils sont explicitement confirmés dans le cadrage ou le suivi.
Rétention standard
Sauf décision différente avec le client, Alpene conserve :
- 7 sauvegardes quotidiennes ;
- 2 sauvegardes hebdomadaires ;
- 3 sauvegardes mensuelles.
Les sauvegardes préalables à une migration ou une opération risquée sont conservées jusqu'à la validation de l'opération et pendant la durée nécessaire au rollback.
Une durée légale ou métier plus longue doit être identifiée séparément. La sauvegarde ne doit pas devenir un moyen de conserver indéfiniment des données qui auraient dû être supprimées.
Stack de référence
| Actif | Référence | Règle |
|---|---|---|
| Microsoft 365 | Veeam Backup for Microsoft 365 | Copie indépendante des boîtes, sites et espaces inclus |
| Serveurs, fichiers et exports | Restic vers Scaleway Object Storage | Dépôt chiffré et séparé de la production |
| Bases PostgreSQL | Export quotidien et mécanisme natif du fournisseur lorsqu'il existe | Restauration vérifiée avant toute opération destructive |
| Code et documentation | Dépôt Git | Historique et branches protégées selon le besoin |
| Fichiers applicatifs | Scaleway Object Storage | Versioning ou export indépendant selon la criticité |
| Secrets partagés | Bitwarden | Export ou procédure de récupération réservée aux administrateurs habilités |
L'utilisation d'un snapshot fournisseur peut compléter la sauvegarde, mais ne constitue pas l'unique copie lorsqu'une défaillance du compte, du tenant ou du fournisseur pourrait rendre les deux indisponibles.
Politique par offre
B1, site vitrine
Le dépôt Git constitue la sauvegarde de référence :
- sources du site ;
- contenus versionnés ;
- configuration ;
- historique des modifications ;
- procédure de build.
Les déploiements Netlify facilitent le rollback, mais le dépôt reste la source de vérité. Aucune copie indépendante supplémentaire du dépôt n'est imposée dans la baseline.
Les secrets, données de formulaire et contenus stockés dans un service externe suivent leur propre politique. Ils ne sont pas sauvegardés par le seul dépôt Git.
B2, plateforme
Sont sauvegardés selon le périmètre :
- base PostgreSQL ;
- fichiers stockés dans Scaleway Object Storage ;
- configuration non secrète ;
- migrations Drizzle ORM ;
- code et documentation dans Git ;
- paramètres nécessaires à la reconstruction du service ;
- journaux d'audit lorsque leur conservation est requise.
Une sauvegarde est réalisée avant toute migration destructive. Les fichiers persistants ne reposent jamais uniquement sur le système de fichiers du conteneur Docker.
B3, socle IT
B3.3 s'appuie sur :
- Veeam Backup for Microsoft 365 pour les boîtes, sites et espaces convenus ;
- Restic vers Scaleway Object Storage pour les serveurs et fichiers ;
- synchronisation des dossiers de travail vers OneDrive pour les postes administrés ;
- export ou connecteur dédié pour les autres services SaaS.
La synchronisation OneDrive protège contre la perte d'un poste, mais ne remplace pas une sauvegarde indépendante si le risque inclut la suppression, le chiffrement malveillant ou la compromission du tenant.
A2, agents et automatisation
Sont sauvegardés pour chaque client :
- workflows et configuration de l'orchestrateur ;
- base de données de l'instance ;
- fichiers de travail qui doivent être conservés ;
- paramètres des connecteurs, sans exposer les secrets ;
- scripts et conteneurs versionnés dans Git ;
- sources documentaires nécessaires à une réindexation ;
- configuration du quota et de la passerelle d'inférence.
Les clés et secrets restent dans Bitwarden ou le mécanisme prévu. Une exportation de workflow sans clé de chiffrement ou sans procédure de réassociation des identifiants n'est pas considérée comme restaurable.
A3, chat IA souverain
Sont sauvegardés selon les règles de conservation du client :
- comptes et configuration applicative ;
- conversations dont la conservation est autorisée ;
- paramètres de la passerelle d'inférence ;
- configuration des quotas ;
- documents sources de la base de connaissance ;
- index ou procédure de réindexation ;
- configuration de l'environnement dédié lorsqu'il existe.
Les poids des modèles hébergés par un fournisseur ne sont pas sauvegardés par Alpene. La restauration repose sur la possibilité de redéployer un modèle compatible ou de basculer vers un fournisseur qualifié.
Un index vectoriel peut être reconstruit à partir des documents sources et du modèle d'embedding documenté. Les documents sources restent donc prioritaires par rapport à l'index seul.
Sécurité des sauvegardes
- Les sauvegardes sont chiffrées pendant le transport et au repos.
- Les clés de chiffrement ne sont pas stockées uniquement avec les données chiffrées.
- Les accès sont nominatifs, limités et protégés par MFA lorsque le service le permet.
- Les dépôts de sauvegarde sont séparés des identifiants de production.
- Les journaux de sauvegarde n'enregistrent pas inutilement les données métier.
- Les suppressions et changements de rétention sont réservés aux administrateurs habilités.
- Les fournisseurs et régions sont documentés dans le dossier client.
- Une exception de localisation est documentée et validée avant utilisation.
Surveillance des sauvegardes
Chaque exécution produit un statut exploitable : réussite, réussite partielle ou échec.
Alpene surveille :
- absence d'exécution attendue ;
- échec ou interruption ;
- volume anormalement faible ou élevé ;
- dépôt indisponible ;
- espace ou limite atteinte ;
- clé ou accès expiré ;
- rétention non appliquée ;
- durée anormale.
Un échec déclenche une alerte Alpene. Le client est informé lorsque l'échec dure plus de 24 heures ou remet en cause le RPO convenu.
Une réussite technique ne garantit pas que la sauvegarde contient tout le périmètre attendu. L'inventaire et la configuration sont donc revus après toute évolution importante du service.
Tests de restauration
Une restauration est testée :
- lors de la mise en place initiale de B3.3 ;
- après un changement important de l'outil, du dépôt ou de la méthode de sauvegarde ;
- avant une migration risquée lorsque le retour arrière dépend de la sauvegarde ;
- lorsqu'un incident fait douter de l'intégrité des copies ;
- à la demande du client dans le périmètre convenu.
Aucune fréquence trimestrielle ou annuelle supplémentaire n'est imposée par défaut.
Le test porte sur un échantillon représentatif et vérifie :
- accès au dépôt ;
- disponibilité de la clé ;
- intégrité de la sauvegarde ;
- restauration effective ;
- droits et structure des données ;
- durée observée ;
- capacité à relancer le service ou ouvrir les fichiers restaurés.
Le résultat est consigné avec la date, le périmètre, la durée, les écarts et les corrections nécessaires.
Demande de restauration
Une demande précise :
- client et service concernés ;
- données ou période recherchées ;
- cause de la demande ;
- urgence ;
- environnement cible ;
- risque d'écrasement ;
- personne autorisée à valider.
Une restauration de données métier nécessite l'accord du client avant tout écrasement ou remplacement de données existantes.
Procédure de restauration
- qualifier la demande et vérifier l'autorité du demandeur ;
- identifier la sauvegarde utilisable ;
- protéger l'état actuel par une copie ou un export si possible ;
- restaurer dans un emplacement isolé ;
- contrôler l'intégrité, les droits et les cas représentatifs ;
- présenter le résultat au client lorsque des données métier sont concernées ;
- valider la remise en production ;
- remplacer ou réinjecter les données ;
- contrôler le service ;
- documenter l'opération.
Une restauration directe en production reste exceptionnelle. Elle est réservée aux situations où l'isolement préalable est impossible ou incompatible avec l'urgence.
Incident majeur
En cas d'indisponibilité complète :
- le responsable Alpene qualifie l'incident ;
- les écritures sont suspendues si elles risquent d'aggraver la perte ;
- la dernière sauvegarde exploitable est identifiée ;
- le client est informé de la perte potentielle et du délai estimé ;
- la restauration est réalisée selon l'ordre de priorité convenu ;
- le service est contrôlé avant réouverture ;
- un compte rendu identifie la cause et les mesures correctives.
Le RPO décrit la perte maximale visée. Le RTO décrit un objectif de retour en service, pas une garantie absolue en dehors d'un engagement contractuel explicite.
Fin du suivi
À la fin du suivi :
- Alpene prépare les exports et sauvegardes prévus ;
- le client confirme le canal et les destinataires ;
- les données sont remises avec les informations nécessaires à leur lecture ;
- la réception est confirmée ;
- les copies Alpene sont conservées pendant 30 jours ;
- les copies sont ensuite supprimées ;
- la suppression est consignée.
Une obligation légale, un litige ou un accord écrit peut modifier cette durée. Le client en est informé.
La sortie complète est coordonnée avec le runbook d'offboarding.
Checklist
- Actifs inclus et exclus inventoriés.
- RPO et RTO confirmés.
- Fréquence et rétention configurées.
- Région et fournisseur documentés.
- Chiffrement et clés vérifiés.
- Accès nominatifs et MFA activés.
- Alertes configurées.
- Première sauvegarde réussie.
- Restauration initiale testée lorsque B3.3 est souscrit.
- Procédure de restauration remise.
- Responsables et canal de demande identifiés.
- Conditions de sortie documentées.
Décisions validées
- La politique couvre les services opérés par Alpene et les actifs inclus dans B3.3.
- Veeam Backup for Microsoft 365 est la référence pour Microsoft 365.
- Restic vers Scaleway Object Storage est la référence pour les serveurs, fichiers et exports.
- B2, A2 et A3 utilisent une sauvegarde quotidienne et une copie avant les opérations risquées.
- La rétention standard comprend 7 copies quotidiennes, 2 hebdomadaires et 3 mensuelles.
- La baseline vise un RPO de 24 heures et un RTO de 8 heures ouvrées.
- Les sauvegardes sont chiffrées et localisées en France ou dans l'Union européenne lorsque le besoin ou le fournisseur le permet.
- Aucun test périodique supplémentaire n'est imposé après la validation initiale, sauf changement important, incident ou besoin convenu.
- Le client autorise toute restauration qui écrase ou remplace des données métier.
- Le client est informé si un échec dépasse 24 heures ou remet en cause le RPO.
- Les sauvegardes Alpene sont conservées 30 jours après la fin du suivi, puis supprimées.
- Pour B1, le dépôt Git constitue la sauvegarde de référence.