Sauvegarde d'émulateur perdue : pouvez-vous récupérer votre progression ?

Si votre sauvegarde d'émulateur a disparu dans un émulateur fonctionnant dans un navigateur, la réponse courte est la suivante : la récupération est rarement possible. Les émulateurs en ligne stockent les données de sauvegarde dans IndexedDB — une base de données clé-valeur structurée, intégrée à votre navigateur — et non sous forme de fichier sur votre disque dur. Lorsque ce stockage est effacé, ou lorsque les données n'ont tout simplement jamais été écrites, elles sont définitivement perdues.

IndexedDB fait partie de la spécification Web Storage et est cloisonné par origine (protocole + domaine + port) ainsi que par profil de navigateur. Cela signifie que les sauvegardes créées sur https://retrogamespace.com dans Chrome sont totalement distinctes de celles enregistrées dans Firefox, Safari, ou même dans un autre profil Chrome sur la même machine. Le navigateur ne propose aucune interface native permettant à l'utilisateur de parcourir ou d'exporter ces données ; leur gestion incombe entièrement à l'application web qui s'exécute dans l'onglet.

Du point de vue de l'émulateur, l'écriture d'une sauvegarde est simple : lorsque le jeu émulé vide sa SRAM (mémoire de sauvegarde alimentée par pile), l'émulateur sérialise cette région mémoire et la consigne dans IndexedDB. Au chargement de la page, l'émulateur la relit. Tout fonctionne correctement tant qu'IndexedDB conserve cet enregistrement — or il existe plusieurs raisons courantes pour lesquelles ce n'est pas le cas.

Il existe quatre causes distinctes à la disparition d'une sauvegarde dans un navigateur, et chacune présente une probabilité de récupération différente. Identifier laquelle vous concerne détermine la marche à suivre.

• Suppression des données de navigation : Chrome, Firefox, Edge et Safari proposent tous une option permettant de supprimer les « données de site » ou les « cookies et données de site ». IndexedDB est classé comme donnée de site. Si vous avez sélectionné cette option — même en visant uniquement les cookies — toutes les bases IndexedDB pour chaque origine ont été effacées simultanément. C'est la cause la plus fréquente sur ordinateur de bureau, et elle ne déclenche aucun avertissement.
• Mode navigation privée ou incognito : les navigateurs ne conservent explicitement pas IndexedDB sur le disque lorsqu'une fenêtre de navigation privée est fermée. Toute sauvegarde effectuée au cours de cette session n'existait qu'en RAM et a été supprimée au moment où vous avez fermé la fenêtre. Il n'en reste aucune copie récupérable.
• Éviction du quota de stockage dans Safari sur iOS : le moteur WebKit d'Apple sur iOS applique, sous certaines conditions, une règle d'inactivité de 7 jours au stockage des sites, et le système d'exploitation peut supprimer les données d'un site lorsque l'espace de stockage de l'appareil est dangereusement bas. Safari sur iPhone et iPad est l'environnement le plus souvent cité en cas de perte inexpliquée de progression dans un émulateur.
• Changement de profil ou de navigateur : étant donné qu'IndexedDB est limité par origine et par profil, passer de votre profil Chrome professionnel à votre profil Chrome personnel, ou de Chrome à Firefox, vous donne accès à une base de données entièrement vide. Vos anciennes sauvegardes existent toujours — dans l'autre profil — et peuvent être récupérées simplement en y retournant.

Un cinquième cas limite mérite d'être mentionné : certaines extensions de navigateur qui se présentent comme des outils de « protection de la vie privée » ou « anti-pistage » effacent périodiquement le stockage des sites selon un calendrier défini. Si vous ne parvenez pas à identifier l'une des quatre causes mentionnées ci-dessus, vérifiez dans vos extensions installées si l'une d'elles dispose d'un comportement d'effacement du stockage.

Pour tenter de récupérer des données de sauvegarde d'émulateur, au moins l'une des conditions suivantes doit être remplie. Aucune d'entre elles ne s'applique de manière universelle ; lisez donc chacune attentivement avant d'y consacrer du temps.

1. Vous avez exporté un fichier .srm avant la perte : si vous avez précédemment utilisé la fonction d'exportation ou de téléchargement de l'émulateur pour enregistrer un fichier .srm (copie de la SRAM) sur votre appareil, ce fichier se trouve toujours sur votre disque dur. Le réimporter via la fonction d'importation de l'émulateur restaurera votre progression jusqu'au point capturé lors de l'exportation.
2. Vos sauvegardes se trouvent dans un autre profil de navigateur : ouvrez le sélecteur de profils du navigateur et recherchez d'autres profils. Accédez au site de l'émulateur dans chacun d'eux. Si vos données de sauvegarde y apparaissent, exportez-les immédiatement en fichier .srm, puis réimportez-les dans votre profil principal.
3. Vous disposez d'une sauvegarde dans le nuage ou d'une synchronisation : si l'émulateur que vous utilisiez est intégré à un service de synchronisation dans le nuage, consultez l'interface web ou l'application de ce service pour y rechercher des états de sauvegarde ou des fichiers SRAM stockés. La synchronisation dans le nuage pour RGS est prévue dans une prochaine version — consultez le blog du site pour connaître la disponibilité actuelle.
4. Vous êtes sur Android avec Chrome et n'avez pas redémarré l'appareil : Chrome sur Android met en cache les écritures IndexedDB en mémoire avant de les valider sur le disque. Dans l'intervalle étroit entre un plantage et un redémarrage, une synchronisation forcée déclenchée en revisitant la page peut permettre de récupérer la dernière session. Il s'agit d'un cas limite peu fiable, sur lequel il ne faut pas compter.

Il n'existe aucune méthode permettant d'extraire des données IndexedDB directement depuis les entrailles du navigateur sans recourir aux outils de développement, et encore, uniquement à condition que la base de données n'ait pas été supprimée. Dans Chrome, vous pouvez ouvrir les DevTools (F12), puis accéder à Application → Storage → IndexedDB, et vérifier si une base de données associée au site existe toujours. Si des entrées y apparaissent, les outils d'import/export intégrés à l'émulateur constituent la bonne façon de les récupérer — n'essayez en aucun cas de modifier les fichiers LevelDB bruts utilisés en interne par Chrome, car vous risqueriez de corrompre d'autres données du navigateur.

La vérité, aussi difficile soit-elle à accepter, est que dès lors qu'un enregistrement IndexedDB a été supprimé, il n'existe ni corbeille, ni copie fantôme, ni sauvegarde côté serveur sur laquelle se rabattre. Contrairement à un fichier effacé depuis votre bureau, les données IndexedDB ne transitent pas par le pipeline de suppression de fichiers du système d'exploitation d'une manière accessible à l'utilisateur.

Plus précisément, la récupération est impossible dans les situations suivantes : l'option « Effacer les données du site » ou son équivalent a été utilisée dans le navigateur ; la session s'est déroulée dans une fenêtre privée ou de navigation incognito ; iOS Safari a expulsé les données en raison d'une inactivité prolongée ou d'une pression sur l'espace de stockage ; ou encore une extension de confidentialité a supprimé le stockage selon un calendrier automatique. Dans ces quatre cas de figure, les octets sous-jacents ont été écrasés ou n'ont jamais été consignés dans un stockage persistant.

Les outils de récupération forensique de disques (tels que ceux utilisés pour restaurer des fichiers supprimés) ne sont d'aucun secours ici. Chrome, Firefox et Safari stockent tous IndexedDB sous des formats binaires compacts (LevelDB dans le cas de Chrome) qui sont continuellement réécrits lors du fonctionnement normal du navigateur. Au moment où vous constatez l'absence de la sauvegarde, les secteurs physiques qui contenaient autrefois ces données ont presque certainement déjà été écrasés.

Nous ne saurions vous recommander les utilitaires tiers de « récupération IndexedDB » qui circulent en ligne. Ceux que nous avons examinés se contentent, soit de rechercher des signatures de fichiers génériques qui n'ont aucun rapport avec les données de sauvegarde de jeux, soit d'exiger que vous confiiez les données internes de votre navigateur à une application à code source fermé. Aucune de ces approches n'est fiable pour ce cas d'usage, et toutes deux comportent des risques réels.

La seule protection véritablement fiable contre la disparition d'une sauvegarde de navigateur consiste à conserver une copie de vos données de sauvegarde en dehors d'IndexedDB. Cela implique d'exporter un fichier .srm à intervalles réguliers — idéalement après chaque session de jeu significative — et de le stocker dans un emplacement qui n'est pas soumis à l'effacement des données du navigateur.

• Exportez régulièrement vos fichiers .srm : Utilisez la fonction d'export de l'émulateur après chaque session et enregistrez le fichier obtenu dans un dossier sur votre disque dur ou dans un espace de stockage en nuage. Un fichier .srm est léger (généralement 8 Ko pour un jeu Super Nintendo avec une SRAM standard) et ne prend que quelques secondes à télécharger.
• Conservez au moins deux copies datées : Nommer les fichiers avec un suffixe de date (par exemple zelda-lttp-2024-11-03.srm) facilite le retour à un point de contrôle antérieur si une sauvegarde venait à être corrompue. Une sauvegarde récente vaut mieux qu'aucune ; deux sauvegardes datées vous offrent un point de restauration même si la dernière exportation en date présente un problème.
• Ne jouez jamais en navigation privée pour les jeux qui vous tiennent à cœur : La navigation privée convient pour des tests ou des sessions ponctuelles. Elle n'est pas adaptée à une partie de RPG de plusieurs heures, car le navigateur effacera inconditionnellement toutes les données de stockage à la fermeture de la fenêtre.
• Sur iOS, visitez le site de l'émulateur au moins une fois tous les 7 jours : Le minuteur d'expulsion du stockage WebKit d'Apple se réinitialise à chaque visite. Une activité régulière réduit — sans pour autant éliminer complètement — le risque qu'iOS efface vos données.
• Guettez l'arrivée de la fonctionnalité de synchronisation en nuage de RGS : Lorsque la synchronisation en nuage sera disponible, elle permettra de stocker les sauvegardes côté serveur et de les synchroniser entre différents appareils. En attendant, l'export .srm demeure la seule méthode de sauvegarde multiappareil disponible sur ce site. Consultez le blog de RGS pour les annonces de lancement.
• Évitez les extensions de navigateur qui effacent les données des sites : Si vous utilisez une extension de confidentialité, vérifiez ses paramètres pour détecter tout calendrier d'effacement automatique du stockage, puis désactivez cette fonctionnalité ou ajoutez retrogamespace.com à sa liste d'autorisation.

Une remarque propre à la plateforme, à l'intention des utilisateurs iOS : depuis iOS 17, il est possible d'ajouter un site web à votre écran d'accueil en tant qu'application web progressive (Progressive Web App). Le stockage créé au sein d'une PWA installée sur l'écran d'accueil est maintenu dans un conteneur de quota distinct de celui du navigateur standard et n'est pas soumis à la même règle d'expulsion de 7 jours appliquée aux onglets Safari. Si vous jouez fréquemment sur iPhone ou iPad, ajouter le site à votre écran d'accueil constitue une amélioration structurelle significative — mais pas une solution définitive. Vous devriez tout de même continuer à exporter vos fichiers .srm, car le conteneur PWA peut toujours être effacé manuellement ou lorsque l'application est retirée de l'écran d'accueil.