Vous avez créé une base de données dans phpMyAdmin, déployé WordPress et, une semaine plus tard, vous constatez que vos tables affichent du texte illisible au lieu de caractères normaux. Vous ouvrez les paramètres et voyez latin1_swedish_ci. Toute personne travaillant avec Laragon sous Windows finit par rencontrer cette surprise.

Le problème vient du fait que la version de MySQL installée par défaut par Laragon hérite d’un paramétrage ancien: latin1 comme jeu de caractères et latin1_swedish_ci comme interclassement. Pour le russe, c’est une catastrophe: les caractères cyrilliques s’affichent sous forme de points d’interrogation ou de charabia, le tri des chaînes ne fonctionne plus et les plugins plantent avec des erreurs.

Voici deux modifications dans un seul fichier qui résoudront ce problème de manière permanente. Cela prend trois minutes. Fonctionne avec Laragon 6, 5 et même l’ancienne version 4.

💡 Aperçu rapide:

• Ouvrez my.ini via le menu de Laragon et ajoutez deux lignes dans la section [mysqld]
• Choisissez utf8mb4_unicode_ci comme option optimale pour WordPress en 2026 (nous vous expliquons pourquoi)
• Sauvegardez le fichier, redémarrez MySQL et vérifiez le résultat dans phpMyAdmin
• Bonus: comment modifier l’encodage d’une base de données existante sans perdre de données

Pourquoi l’encodage par défaut est important

MySQL fonctionne avec un système d’héritage à plusieurs niveaux: serveur → base de données → table → colonne. Si latin1_swedish_ci est défini au niveau du serveur, chaque nouvelle base de données en héritera, sauf indication contraire lors de sa création.

Pour WordPress, c’est critique, car:

• Le cœur, les thèmes et la plupart des plugins stockent le contenu en utf8mb4
• Lors de la création automatique d’une base de données via wp-config.php, WordPress ne remplace PAS la valeur par défaut du serveur
• Un décalage d’encodage entre le serveur et les tables produit des erreurs «obscures»: ??? dans le panneau d’administration, caractères cassés dans l’API REST JSON, plantages lors de l’export

Selon les données de W3Techs, WordPress équipe 43,5% de tous les sites web dans le monde, et le CMS lui-même exige utf8mb4 depuis la version 4.2 pour une prise en charge complète des emojis. Laragon est l’un des serveurs locaux les plus populaires sous Windows, mais sa version de MySQL est livrée avec un paramétrage conservateur pour des raisons de compatibilité ascendante. D’où le conflit.

Étape 1: Ouvrir my.ini via le menu de Laragon

Le moyen le plus simple d’accéder au fichier de configuration de MySQL est d’utiliser le menu intégré de Laragon:

• Faites un clic droit sur l’icône de Laragon dans la barre des tâches
• Sélectionnez Menu → MySQL → my.ini

Le Bloc-notes (ou votre éditeur par défaut) s’ouvrira avec la configuration complète de MySQL. Le fichier est divisé en sections entre crochets: [client], [mysqld] et [mysqldump]. C’est la section [mysqld] (les paramètres du démon MySQL) qui nous intéresse.

Si, pour une raison quelconque, le menu n’ouvre pas le fichier, localisez-le manuellement: C:\laragon\bin\mysql\<version>\my.ini. Dans les versions de Laragon 6, le chemin peut être C:\laragon\bin\mysql\mysql-8.0.30-winx64\my.ini, selon la version installée.

Étape 2: Ajouter deux lignes dans la section [mysqld]

Faites défiler jusqu’à la section [mysqld] et ajoutez les deux lignes suivantes à la fin (avant la section suivante, s’il y en a une):

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Ce qui se passe ici:

• character_set_server = utf8mb4 indique au serveur d’utiliser l’encodage UTF-8 Multilingual Version 4 par défaut, qui prend en charge TOUS les caractères Unicode, y compris les emojis, le cyrillique et les hiéroglyphes
• collation_server = utf8mb4_unicode_ci définit la règle de comparaison des chaînes: _unicode_ signifie «selon le standard Unicode», _ci signifie comparaison insensible à la casse

Vous devez ajouter ces lignes spécifiquement dans [mysqld], pas dans [client] ni [mysqldump]. Se tromper de section est la raison la plus fréquente pour laquelle «rien n’a changé».

La section complète après modification devrait ressembler à ceci:

1
[mysqld]
2
port=3306
3
socket=/tmp/mysql.sock
4
key_buffer_size=256M
5
max_allowed_packet=512M
6
character_set_server = utf8mb4
7
collation_server = utf8mb4_unicode_ci

Étape 3: Sauvegarder le fichier et redémarrer MySQL

Sauvegardez my.ini (Ctrl+S) et redémarrez MySQL. Dans Laragon, cela se fait via le même menu:

• Faites un clic droit sur l’icône de Laragon dans la barre des tâches
• Menu → MySQL → Stop
• Attendez 3 à 5 secondes
• Menu → MySQL → Start

Vous pouvez aussi cliquer sur Menu → Redémarrer, et Laragon arrêtera puis redémarrera tous les services en une seule fois.

Après le redémarrage, les nouvelles bases de données seront créées avec utf8mb4_unicode_ci par défaut. Les bases de données existantes ne sont PAS modifiées automatiquement. Lisez la section «Foire aux questions» ci-dessous pour savoir comment convertir une base existante.

Étape 4: Vérifier le résultat dans phpMyAdmin

Ouvrez phpMyAdmin via le menu de Laragon (Menu → MySQL → phpMyAdmin) et créez une base de données de test:

• Cliquez sur «Créer une base de données»
• Saisissez un nom quelconque
• Regardez la liste déroulante «Interclassement»: elle devrait maintenant proposer utf8mb4_unicode_ci par défaut

Si la liste déroulante affiche encore latin1_swedish_ci, vérifiez que les lignes character_set_server et collation_server ont bien été ajoutées dans la section [mysqld] (pas [client]) et qu’il n’y a pas d’espaces superflus entre le nom du paramètre et le signe =.

Vérification rapide via une requête SQL (à exécuter dans phpMyAdmin, dans l’onglet SQL):

1
SHOW VARIABLES LIKE 'character_set_server';
2
SHOW VARIABLES LIKE 'collation_server';

Les deux variables doivent renvoyer respectivement utf8mb4 et utf8mb4_unicode_ci.

Quel encodage choisir: comparatif des options

L’encodage MySQL a accumulé beaucoup de mythes, alors passons en revue trois options actuelles et une obsolète:

Pourquoi nous recommandons utf8mb4_unicode_ci pour le développement local avec Laragon:

• Laragon est livré avec différentes versions de MySQL (de 5.7 à 8.0+), et utf8mb4_0900_ai_ci n’est apparu qu’avec MySQL 8.0 et est absent de MariaDB, souvent présent dans les versions alternatives
• utf8mb4_unicode_ci fonctionne partout à partir de MySQL 5.5.3 (2010)
• La différence de qualité de tri entre unicode_ci et 0900_ai_ci est négligeable pour un site WordPress typique
• Les offres d’hébergement mutualisé utilisent souvent MySQL 5.7. Si vous développez en local avec 0900_ai_ci mais qu’il est absent en production, vous obtiendrez une erreur lors de la migration

Si vous savez avec certitude que votre serveur de production tourne sous MySQL 8.0+ et que votre Laragon local utilise MySQL 8.0, optez pour utf8mb4_0900_ai_ci. C’est le standard moderne recommandé par Oracle, avec un meilleur support du tri multilingue.

Qu’en est-il de utf8_general_ci? C’était pertinent il y a une dizaine d’années, quand utf8mb4 n’était pas encore largement supporté. Aujourd’hui, il présente deux défauts rédhibitoires: il ne peut pas stocker les emojis (WordPress les utilise activement dans le panneau d’administration) et il trie incorrectement les caractères étendus. Il n’y a aucune raison de l’utiliser en 2026.

Vidéo: comment changer l’encodage d’une base MySQL via phpMyAdmin

Les instructions écrites sont très bien, mais il est parfois plus facile de voir la manipulation une fois. Cette vidéo de 4 minutes montre le processus complet de modification de l’encodage d’une base de données existante via l’interface de phpMyAdmin, de la sélection des tables à la vérification finale:

⁉️🤔 Foire aux questions

J’ai déjà une base de données en latin1_swedish_ci. Comment changer son encodage?

La méthode la plus sûre est de passer par phpMyAdmin. Sélectionnez la base de données à gauche, allez dans l’onglet «Opérations», choisissez utf8mb4_unicode_ci dans le bloc «Interclassement» et cliquez sur «Exécuter». phpMyAdmin générera des requêtes ALTER pour chaque table. Avant cette opération, assurez-vous de faire une sauvegarde: onglet «Exporter» → format SQL → «Exécuter».

J’ai modifié my.ini, redémarré MySQL, mais phpMyAdmin affiche toujours latin1_swedish_ci. Qu’est-ce qui ne va pas?

Les trois causes les plus fréquentes: (1) les lignes ont été ajoutées dans [client] au lieu de [mysqld]. Vérifiez dans quelle section entre crochets elles se trouvent. (2) MySQL n’a pas redémarré. Ouvrez le Gestionnaire des tâches de Windows et vérifiez que le processus mysqld.exe a bien disparu puis est réapparu. (3) Il y a plusieurs sections [mysqld] dans my.ini. Cela arrive parfois après plusieurs mises à jour de Laragon. N’en conservez qu’une seule.

Qu’est-ce qui est mieux pour WordPress: utf8mb4_unicode_ci ou utf8mb4_general_ci?

Pour WordPress, la différence est minime. utf8mb4_unicode_ci trie le contenu multilingue de manière plus précise (par exemple, le «ß» allemand = «ss»), tandis que utf8mb4_general_ci est légèrement plus rapide sur de gros volumes, mais la différence se compte en millisecondes. Choisissez unicode_ci et ne vous en préoccupez plus.

Puis-je simplement spécifier l’encodage dans wp-config.php?

define('DB_CHARSET', 'utf8mb4') et define('DB_COLLATE', 'utf8mb4_unicode_ci') dans wp-config.php affectent UNIQUEMENT les tables que WordPress crée lui-même lors de l’installation. La valeur par défaut du serveur reste inchangée, et toute base de données créée manuellement via phpMyAdmin héritera de latin1_swedish_ci. C’est pourquoi la modification de my.ini reste nécessaire.

Après avoir changé l’encodage, certains textes du site se sont transformés en points d’interrogation. Est-ce réversible?

Oui, mais il faut procéder avec précaution. Les points d’interrogation apparaissent lorsque les données ont été écrites en latin1 mais sont lues en utf8. La solution: exportez la base de données avec l’option --default-character-set=latin1, puis importez avec --default-character-set=utf8mb4. La commande exacte dépend de votre version de MySQL, consultez donc la documentation officielle.

En résumé: ce qu’il faut ajouter à my.ini dès maintenant

Si vous utilisez Laragon pour le développement local WordPress, les deux lignes ci-dessous résoudront le problème d’encodage une fois pour toutes:

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Cette option fonctionne sur toute version de MySQL de 5.5 à 8.4 et sur toutes les versions actuelles de MariaDB. Elle stocke correctement le cyrillique, les emojis et ne crée pas de surprises lors de la migration de la base de données du local vers la production, quel que soit l’hébergement sur lequel tourne votre serveur de production.

Vous avez des questions sur une version spécifique de Laragon ou une configuration non standard? Consultez le fil de discussion sur le forum Laragon, où les développeurs abordent les nuances de configuration de l’encodage, y compris les builds Docker et les ports personnalisés. Et si cet article vous a fait gagner une soirée, partagez-le avec vos collègues qui bataillent encore avec latin1_swedish_ci.