Chez WeTell Africa Group, on développe des plateformes web pour des clients un peu partout. Et pendant qu'on veillait scrupuleusement sur leurs infrastructures, notre propre projet interne, VantaArt, une plateforme dédiée à l'art et aux artistes, a payé le prix du fameux "on renouvellera plus tard". L'échéance chez l'hébergeur est passée sans qu'on la voie venir. Résultat : accès coupé, base de données envolée, et tous les fichiers uploadés (images d'œuvres, photos d'artistes, visuels d'expositions) partis avec elle. Le genre d'ironie qu'on n'apprécie qu'après coup.

Pas de backup récent. Je vous laisse imaginer la qualité du café bu ce jour-là.

Le déclic

Après le premier moment de panique, c'est au détour d'une conversation avec Minette Lontsie qu'elle a évoqué Archive.org, et c'est là que je me suis souvenu de cet outil qu'on utilise parfois pour retrouver d'anciennes versions de sites : la Wayback Machine d'Archive.org. Pour ceux qui ne connaissent pas, c'est un service qui prend régulièrement des "photos" de pages web publiques et les conserve dans le temps. L'idée m'est venue simplement : si VantaArt était visitée et indexée, peut-être qu'Archive.org en avait gardé des traces exploitables.

Sauf qu'il y a un malentendu courant à ce sujet, et je pense qu'il vaut la peine de le clarifier ici : Archive.org ne sauvegarde pas une base de données. Il n'y a pas de bouton magique "restaurer mon site" qui vous rend un fichier SQL propre. Ce que l'outil garde, c'est le rendu final des pages, le HTML que votre navigateur a affiché à un instant donné. Pour en tirer quelque chose d'utilisable, il faut reconstruire.

Ce qu'on a trouvé (et pourquoi ça a marché)

En creusant, on a identifié trois sources exploitables, et c'est là que ça devient intéressant même pour ceux qui ne codent pas.

La première, c'est l'API elle-même. VantaArt, comme beaucoup d'applications modernes, sépare le backend (qui gère les données) du frontend (qui les affiche). Or l'API du backend avait elle aussi été capturée par moments, avec des réponses au format JSON contenant les données brutes, colonnes exactes et identifiants d'origine compris. Un peu comme si, au lieu de retrouver seulement la photo d'un plat, on retrouvait aussi la recette.

La deuxième source était plus inattendue : le frontend (construit avec Nuxt) embarque dans chaque page un bloc de données techniques utilisé pour l'affichage rapide côté navigateur. Ce bloc, invisible pour un visiteur normal, contenait en réalité des informations bien plus complètes que ce qui était affiché à l'écran, notamment sur les œuvres et les artistes, qui étaient quasiment absents de l'API archivée mais bien présents dans ces pages. Sans cette source, on aurait perdu une bonne partie du catalogue.

La troisième source, ce sont les fichiers eux-mêmes : images, PDF. Et là, un coup de chance qu'on a transformé en méthode : les chemins de fichiers stockés dans la base (du type images/un-identifiant.jpg) correspondaient exactement à l'emplacement des fichiers archivés. En les replaçant au bon endroit sur le nouveau serveur, les liens redevenaient valides sans aucune modification.

La mécanique, en résumé

Concrètement, on a construit en deux temps, avec l'aide de Claude Code pour écrire et itérer sur le script. D'abord un scraper Python qui interroge l'API d'Archive.org, télécharge les trois sources, dédoublonne les informations récupérées à plusieurs endroits, et les range proprement dans des fichiers JSON, une table à la fois. Ensuite, une commande d'import côté Laravel, pensée pour être rejouée autant de fois que nécessaire sans jamais créer de doublon, en respectant l'ordre logique des dépendances entre les tables (impossible de recréer une œuvre avant l'artiste auquel elle est rattachée, par exemple).

Le tout a d'abord été testé et validé en local avant d'aller toucher quoi que ce soit en production. Une base à moitié restaurée, c'est gênant. Une prod cassée par un script mal testé, c'est une autre catégorie de problème.

Au bout du compte, on a remis la main sur 422 expositions, 191 espaces d'art, 414 artistes, 41 œuvres, 88 articles, et 672 fichiers, à partir d'environ 5300 pages archivées. La quasi-totalité du catalogue public de VantaArt était de retour.

Ce qui est resté perdu, et pourquoi c'est important de le dire

Tout n'est pas revenu, et il serait malhonnête de le passer sous silence. Les œuvres ou profils qui n'avaient jamais été publiés (donc jamais visités, donc jamais archivés) sont perdus. Certaines relations entre données ont dû être laissées incomplètes plutôt que devinées.

Ceci dit, il faut remettre cette perte en perspective. VantaArt n'était pas encore officiellement lancée : les quelques comptes utilisateurs existants n'effectuaient pas réellement d'actions sur la plateforme, la vente d'œuvres n'étant pas encore opérationnelle. Pas de commandes à reconstituer, pas de transactions, pas d'historique d'achat. La perte, aussi stressante soit-elle sur le moment, n'a donc jamais vraiment mis le projet en péril.

La vraie leçon

Cette histoire s'est bien terminée, mais elle s'est bien terminée parce que VantaArt attirait du monde. Les comptes utilisateurs restaient peu nombreux, la vente d'œuvres n'étant pas encore ouverte, mais le contenu, lui, était largement consulté sans même qu'un compte soit nécessaire : articles, fiches d'exposition, actualités sur l'art. C'est cette fréquentation de lecture qui a donné à Archive.org matière à indexer aussi richement. C'est une chance, pas une stratégie. Si le contenu avait été plus confidentiel, ou si Archive.org avait choisi de ne pas l'indexer ce mois-là, cet article n'existerait simplement pas, remplacé par un mail d'excuses.

La sauvegarde automatique régulière, celle qu'on reporte toujours à la semaine prochaine, n'a pas d'équivalent. Archive.org nous a sauvés cette fois, mais ce n'est pas un plan de secours qu'on recommande à qui que ce soit d'adopter volontairement.

On a remis en place des sauvegardes automatisées de la base et des fichiers depuis, direction un stockage externe, testées et vérifiables. Parce qu'un backup qu'on n'a jamais essayé de restaurer n'est, au fond, qu'une croyance.

Je suis Wilfried Okono, CTO chez We Tell Africa Group . Je construis des systèmes pensés pour durer dans des contextes africains exigeants, connectivité variable, équipes en croissance, Mobile Money, hébergeurs pas toujours fiables.

Si tu veux échanger sur la résilience des systèmes, les sauvegardes, ou simplement partager ta propre mésaventure d'hébergeur, les commentaires sont ouverts.