Convertir une ancienne base SPIP de latin1 en UTF-8 (utf8mb4). Le cas Gallika

La première version publique de SPIP [1] est sortie le 1^er juillet 2001, il y a plus de vingt-cinq ans. Gallika a fait partie des premiers sites à l’adopter. Au fil des mises à jour, le logiciel a évolué et la base a conservé des textes enregistrés selon les conventions de l’époque.

En juin 2025, après une migration chez mon hébergeur, des « � » sont apparus au fur et à mesure que je vidais le cache de SPIP. J’ai restauré une sauvegarde. Un petit script qui lisait la base avec une connexion en latin1 [2] affichait correctement les textes testés. Certaines pages de SPIP, elles, présentaient encore des défauts.

Un an plus tard, les pages publiques affichaient généralement les accents correctement, mais je retrouvais des « médias » dans Adminer [3].

Comprendre ce que la base contient

Sur Gallika, les pages étaient en UTF-8 [4], alors que SPIP dialoguait avec la base en latin1. Dans la table des réglages de SPIP, cela se traduisait par « charset = utf-8 » et « charset_sql_connexion = latin1 ».

Il fallait examiner trois choses : l’encodage déclaré pour les colonnes, celui de la connexion à la base et les octets réellement enregistrés. Sur Gallika, une partie des textes semblait avoir été enregistrée en UTF-8 dans des colonnes déclarées en latin1. Le même mot pouvait donc être lisible sur le site et déformé dans Adminer.

Une conversion globale fondée sur la seule déclaration « latin1 » risquait de recoder des textes dont les octets étaient déjà en UTF-8.

Démarrer sur une copie du site

Le 11 août 2026, j’ai restauré une sauvegarde SQL [5] dans une base de test. La copie faisait 114 Mo et contenait 910 articles. Pour le travail technique, j’ai demandé à ChatGPT de préparer les diagnostics et les commandes à lancer depuis PowerShell [6]. Je les ai exécutés sur la copie, puis je lui ai transmis les résultats pour qu’il puisse ajuster la suite.

Si tu pars d’un ancien SPIP, voici comment préparer le premier essai.

• Restaure une sauvegarde dans une base distincte et branche dessus une copie de SPIP. Vérifie dans l’espace privé que cette copie utilise bien la base de test avant de lancer une commande qui modifie les données.

• Relève l’encodage déclaré pour les colonnes qui contiennent les textes, puis le réglage de connexion SQL de SPIP. Garde ces valeurs avec la sauvegarde.

• Choisis des textes dont tu connais l’écriture exacte. Un titre avec des accents, un mot-clé en grec et un passage mêlant les deux langues font de bons témoins. Note comment ils s’affichent dans Adminer, dans l’espace privé et sur le site public.

• Commence par un petit échantillon et compare les mêmes textes après l’essai. Si un résultat se dégrade, repars de la copie d’origine avant de tester une autre méthode.

Combien de temps faut-il prévoir ?

Douze jours se sont écoulés entre l’import de la copie, le 11 août, et la validation de la mise en ligne, le 23 août. Ce délai comprend les essais et quelques jours de vérification. Je n’ai pas relevé la durée d’exécution des commandes SQL. Pour organiser ta propre migration, réserve du temps pour utiliser la copie après la conversion et revenir sur les écarts que tu constates.

Sur Gallika, un contrôle a notamment signalé huit réglages de SPIP ou de ses extensions dont les données sérialisées étaient illisibles [7]. Il fallait comparer ces réglages à leur état initial pour déterminer si le problème existait déjà. Prévois donc de tester les extensions dont tu te sers, même si les articles s’affichent correctement.

Vérifier la copie avant de la mettre en ligne

Reprends les titres, les mots-clés et les passages choisis au départ. Vérifie-les dans l’espace privé et sur le site public après avoir vidé le cache de la copie. Enregistre aussi un brouillon avec des accents et, si ton site est multilingue, plusieurs alphabets. Ferme-le, puis rouvre-le pour vérifier que l’écriture et la lecture fonctionnent toutes les deux. Ouvre enfin les pages de configuration des extensions que tu utilises et essaie les fonctions qui en dépendent.

Avant de basculer, vérifie aussi si des articles ou des réglages ont été modifiés sur le site public depuis la création de la copie. Si c’est le cas, intègre ces changements à la version convertie et refais les contrôles. Garde une sauvegarde récente de la production et repère les réglages à rétablir si tu dois revenir à l’ancienne installation.

Chez Gallika, la version convertie a tourné quelques jours avant la validation définitive. Le 23 août, elle a repris le nom « spip », et j’ai conservé l’ancienne installation sous le nom « spip-old ». Après des mois à voir le même mot s’écrire de deux façons, le dernier geste aura juste été… de renommer deux dossiers.