Sauvegarde & restauration
/admin/applications/backup — export et restauration des données. Accessible depuis le
menu d'administration (groupe Plateforme & supervision → Sauvegarde & Restauration).
L'avancement de chaque opération est suivi en temps réel (rafraîchissement périodique du statut).
Deux onglets, Exporter et Restaurer, opèrent toujours sur le compte de l'administrateur connecté (en pratique un administrateur local / chef d'établissement) et sont accessibles à tout administrateur. Un troisième onglet, Établissement, réservé au super-administrateur, sauvegarde plusieurs comptes à la fois — voir Établissement plus bas.
La restauration ne réimporte que les applications dont l'utilisateur possède le workflow (un super-administrateur, sans droit applicatif, ne pourrait rien restaurer). entcore n'expose pas d'import « vers un utilisateur cible » : l'archive est toujours réimportée dans le compte de celui qui lance l'opération.
Exporter
L'onglet Exporter produit une archive .zip téléchargeable du compte connecté, pour les
modules sélectionnés (Blog, Wiki, Espace documentaire, Messagerie, Pages, Carte mentale,
Exercices…). Le bouton « Sauvegarder mon compte » lance l'opération.
Chaque export apparaît dans l'historique des exports avec son demandeur, ses modules, sa
date et son statut (en attente, en cours, terminé, erreur). Une archive terminée se télécharge
puis se supprime depuis ce tableau. Le Manifest.json de l'archive porte la version de
chaque application exportée, ce qui permet le contrôle de compatibilité à l'import.
L'historique est cloisonné : un administrateur local voit ses propres demandes et celles des comptes rattachés à ses établissements ; un super-administrateur voit toutes les lignes. Seul le demandeur peut télécharger ou supprimer sa demande — entcore ne sert une archive qu'à son propriétaire.
Restaurer
L'onglet Restaurer importe une archive .zip (issue d'un export) dans le compte de
l'administrateur connecté. La restauration ajoute les données importées : le contenu
existant n'est pas effacé. La fonction enchaîne automatiquement les trois étapes natives de
l'import entcore : upload de l'archive → analyse (applications restaurables détectées) →
lancement de l'import.
Une archive sans version dans son manifeste (export ancien) reste importable ; le contrôle
minimum-import-version ne s'applique qu'aux archives qui portent une version.
Structure du .zip, rôle du Manifest.json et de la signature, contrôles appliqués à la
restauration : voir Formats d'archive (import / export).
Établissement
Concerne :Super-administrateurL'onglet Établissement sauvegarde plusieurs comptes à la fois — une classe, un groupe de profil, un établissement entier groupe par groupe. entcore n'exportant que par compte, cette fonction répète l'export personnel pour chaque compte du groupe choisi et assemble les archives obtenues en un lot ; elle ne remplace donc pas un export applicatif global, qui n'existe pas côté entcore (voir Périmètre).
Avant de lancer quoi que ce soit, l'écran affiche un tableau des groupes de l'établissement sélectionné (nom, type, effectif, volume estimé d'après l'espace documentaire) avec des cases à cocher. Le lot porte sur les groupes cochés — un groupe coché = une archive ; un compte présent dans plusieurs groupes cochés est signalé (il ne serait sinon compté qu'une fois dans le volume total, mais bien exporté deux fois). Les modules à exporter se choisissent ensuite, comme pour l'onglet Exporter, puis « Lancer » démarre un lot par groupe coché.
Un lot lancé apparaît dans l'historique des exports de l'onglet Exporter, étiqueté « Établissement », avec le nom du groupe comme demandeur. Son téléchargement et sa suppression suivent des règles propres au lot (réservées au super-administrateur, sans suppression automatique au téléchargement) plutôt que celles d'un export personnel.
Le .zip produit contient un sous-dossier par compte du groupe, chacun au format d'une archive
personnelle standard (son propre Manifest.json, sa propre signature), plus un
Batch-Manifest.json qui dit quel dossier appartient à quel compte. C'est ce manifeste qui permet
de le redéposer entier dans l'onglet Restaurer un lot ci-dessous. Pour ne restaurer qu'un
compte, on peut toujours extraire son sous-dossier et le re-zipper seul — voir
Sauvegarde d'un établissement (lot)
pour le détail du format.
Restaurer un lot
Concerne :Super-administrateurL'onglet Restaurer un lot redépose un lot entier : chaque compte y est restauré dans son propre compte, et non dans celui de la personne qui dépose le fichier. C'est toute la différence avec l'onglet Restaurer, qui importe dans le compte connecté.
Ce pouvoir n'est pas délégable : il est réservé au super-administrateur, là où la sauvegarde d'un établissement s'ouvre aussi aux administrateurs de collectivité. Écrire dans le compte d'autrui n'est pas du même ordre que le lire.
Le lot est analysé avant d'être restauré
Déposer le fichier ne restaure rien : l'écran affiche d'abord un inventaire compte par compte, avec un verdict pour chacun. Trois vérifications indépendantes encadrent chaque dossier :
| Ce qui est vérifié | Pourquoi |
|---|---|
Le Batch-Manifest.json déclare un compte pour ce dossier | c'est le seul lien entre un dossier et un compte |
| Le nom du dossier se termine par ce même identifiant de compte | deux sources qu'il faudrait falsifier de concert |
| Le compte existe encore dans l'annuaire et n'est pas en attente de suppression | on ne restaure pas dans le vide |
Le motif de refus est affiché en clair pour chaque compte : archive absente, sauvegarde qui n'avait pas abouti, compte supprimé depuis, dossier ne correspondant pas au compte annoncé.
C'est délibéré. Restaurer la moitié d'une classe laisserait l'établissement dans un état que personne ne saurait décrire — ni l'administrateur, ni les familles. Mieux vaut refuser, dire quels comptes posent problème, et laisser corriger.
Pendant et après
Les comptes sont traités un par un, jamais en parallèle : un import mobilise tous les modules de l'ENT, et une classe entière lancée d'un coup les saturerait. L'écran suit l'avancement (comptes traités sur le total) et l'actualise tout seul.
Comme pour une archive personnelle, l'import est additif : il ajoute des ressources, il n'efface rien. Le revers est qu'il ne faut pas rejouer deux fois le même lot — les contenus seraient dupliqués, pas remplacés.
Un compte dont l'import ne répond pas au bout d'une demi-heure est marqué en erreur et la restauration passe au suivant : un module muet ne fige pas le lot entier.
Couverture de tests
Tests e2e — voir le détail
Interface apps/dashboard-e2e/src/modules/03_admin/10_sauvegarde_restauration.spec.ts
- page accessible — bandeau, onglet « Exporter » (modules + « Sauvegarder mon compte »)
- onglet « Restaurer » — sélecteur de fichier
.zip, import dans son propre compte
Round-trip blog apps/dashboard-e2e/src/modules/03_admin/11_sauvegarde_blog_round_trip.spec.ts
- profil chef d'établissement : crée un blog → l'exporte → télécharge l'archive (manifeste versionné) → supprime le blog → restaure → vérifie qu'il est revenu (puis nettoyage).
- SKIP propre pour un profil sans workflow applicatif (ex. super-administrateur).
Établissement apps/dashboard-e2e/src/modules/03_admin/14_sauvegarde_etablissement.spec.ts
- profil super-administrateur : onglet « Établissement » visible, estimation par groupe affichée (effectif, volume), sélection d'un groupe → total dédoublonné, sélecteur de modules et bouton de lancement actifs (aucun lot n'est réellement lancé).
- tout autre profil admin (chef d'établissement) : onglet « Établissement » absent.