Encodage UTF-8 : tout pour mener votre projet à bien

Allez, ça fait 5 ans que je n'ai rien écrit sur ce site.

Problèmes de codage (« encodage » est un anglicisme) ? Les « é » sont trop « Ã© » à votre goût ? Vous n'êtes pas fan des « � » ? C'est normal. On est tous passés par là.

Sur un projet web standard, l'encodage intervient à de multiples endroits :
- l'encodage du document
- la déclaration d'encodage du document
- la configuration serveur
- l'encodage de la base de données, de ses tables, ses champs et du texte
- les scripts

Voici quelques astuces à suivre pour rétablir un bon codage sur vos projets.

Déjà, téléchargez Notepad++ si ce n'est pas déjà fait.
Aussi, utilisez l'UTF-8 dans tous les cas. Quel que soit votre langage de balisage, requête ou programmation. UTF-8 est entièrement compatible avec le standard Unicode, et largement majoritaire sur les projets web mondiaux.

Les autres codages que vous rencontrez majoritairement sont :

> ISO-8859-1, ou Latin-1
Souvent par défaut, sur un nouveau document Notepad++ ou en base de données MySQL.
Lui, il transformera votre « é » en « Ã© » (ou votre « Ã© » en « ÃƒÂ© » si double mauvais encodage, on peut aller très loin comme ça).

> Windows-1252, ou CP1252 (ou ANSI, bien que ce nom soit abusif)
Extension de ISO-8859-1, il en est donc très proche quant à la table des caractères. Si vous voulez en savoir plus sur les petites différences, suivez ce lien.
À l'instar de ISO-8859-1, il transformera votre « é » en « Ã© », votre « € » en « â‚¬ » ou votre « œ » en « Å“ ».
C'est ce codage qui sera utilisé par défaut pour les logiciels Windows / Microsoft, notamment Notepad (Bloc-notes) et Excel. Mais nous y reviendrons.

> ASCII
Norme informatique vieillissante de codage de caractères (seulement 95 imprimables). En gros avec, vous n'avez que les 26 lettres majuscules et minuscules, les chiffres, et les caractères spéciaux les plus courants, de ponctuation notamment.

> Les entités caractère de XML et HTML (ou "XML and HTML character entity" en anglais)
Indispensables aujourd'hui au moins dans les emails marketing pour assurer une compatibilité totale.
Depuis HTML5, vous en avez trois formes :
- & est une référence de caractère nommée
- & est une référence de caractère numérique décimale
- & est une référence de caractère numérique hexadécimale
Le numéro après le « # » pour les deux derniers correspond au numéro de l'Unicode en décimal ou en héxadécimal avec le « x ».
Dans tous les cas ils sont délimités par un « & » et un « ; ».
Vos « é » seront transformés en « é ».

Plus d'infos à ce lien.

Première étape : vérifiez l'encodage du document avec Notepad++.

Accessible dès le menu en haut de l'outil

Alors. Par où commencer.

Déjà, ne négligez pas cette étape. Qui n'a l'air de rien comme ça, mais vous pouvez avoir tout bien paramétré partout (serveurs, base de données, fonctions d'encodage, etc.) alors qu'en ajustant simplement ce paramètre, votre problème sera résolu !

Ensuite, notez que vous avez deux notions : « Encoder » et « Convertir ». Avec principalement UTF-8 et ANSI. Nous y reviendrons.

Premier écart dans mes explications :
Selon la version de Notepad++ que vous avez, vous aurez dans les propositions soit « UTF-8 / UTF-8 (sans BOM) », soit « UTF-8 / UTF-8 (avec BOM) ». Le BOM est une séquence d'octets (byte, ou « multiplet » en français) au début d'un flux de texte qui permet au lecteur (de code, dans le sens informatique... pas vous qui lisez du code dans un éditeur de texte), de deviner de manière plus fiable qu'un fichier est codé en UTF-8.
Plus d'infos à ce lien.
Excepté si vous travaillez sur des cas très, très particuliers, comme du texte en Hébreu avec pour objectif une conversion vers du fichier Excel, choisissez toujours la version sans BOM. Ou vous pourriez avoir quelques soucis sans en comprendre la provenance.

Cas 1 : vous créez un nouveau document tout neuf tout beau.
Rien de plus simple. Anticipez et choisissez « Encoder en UTF-8 » (sans BOM).

Cas 2 : vous êtes sur un document existant, comportant des caractères spéciaux, qui sont correctement affichés. Par exemple, la phrase « Ça va ? » s'affiche bien codée.
Ici, assez simple à nouveau. « Convertir en UTF-8 » (sans BOM). Normalement, votre document restera inchangé en apparence (vous ne voyez pas de texte se transformer) mais dans le codage il sera désormais en UTF-8.

Cas 3 : vous êtes sur un document existant, comportant des caractères spéciaux, et tout s'affiche n'importe comment !
/!\ ATTENTION : prévoyez toujours une copie de votre fichier original avant d'effectuer les manipulations ci-dessous. Au cas où.
Le sous-cas le plus répandu, c'est celui cité dès le début. Vos « é » s'affichent « Ã© ».

Double conversion ANSI

Vous avez alors deux possibilités :
> Soit votre document est déjà codé en ANSI, vous n'avez alors qu'à cliquer sur « Encoder en UTF-8 » (vous réattribuer alors le vrai codage du document, sans conversion).
> Soit votre document est codé en UTF-8, alors que son vrai codage est de l'ANSI. Dans ce cas, si vous cliquez sur « Encoder en ANSI », vous allez réencoder en ANSI des caractères ANSI, ce qui va « doubler » l'encodage ANSI et changer les « Ã© » (initialement « é ») en « ÃƒÂ© ». À la place, cliquez d'abord sur « Convertir en ANSI » (et rétablir le vrai encodage). Vous constaterez que votre texte n'a pas changé. Puis cliquez sur « Encoder en UTF-8 ». Et là, magie.

Texte rétabli dans le bon encodage

Dans ce dernier cas, il arrive aussi d'avoir des caractères encore plus louches dans Notepad++, où l'on voit comme une suite de 3 caractères entourés de noir. À y regarder de plus près, on retrouve la référence de caractère numérique hexadécimale des entités caractères HTML : un « x » suivi de deux caractères héxadécimaux. Ce n'est pas un hasard, il s'agit de la même référence héxadécimale. Par exemple, ici, le « xE9 » correspond à un « é », et idem en entités caractère HTML : « &xE9; » correspond au « é ».

Double conversion UTF-8

Le plus souvent, on est dans le cas inverse du précédent, à savoir un « double » encodage UTF-8. Ce cas-là est déjà plus problématique car rarement résoluble. Tentez un « Encoder en ANSI » puis un « Convertir en UTF-8 ». Si vous faîtes un « Convertir en ANSI » directement, vos caractères spéciaux seront remplacés par des points d'interrogation et il ne sera plus possible de revenir en arrière (d'où l'intérêt de garder le fichier original avant les manipulations).

Derniers sous-cas : vous avez un mélange entre des caractères bien encodés et mal encodés, ou un mélange entre différents caractères mal encodés, ou encore des points d'interrogation là où devraient être des caractères spéciaux... Dans ce cas, il ne faut pas se voiler la face : le fichier ou document sur lequel vous travaillez est pourri. Il vous faudra retourner à la source : sur le service de téléchargement => changer le format de sortie, venant d'un intervenant extérieur => demander un fichier plus « propre », etc.

Cas des CSV :
J'avais commencé une grosse parenthèse sur les CSV, qui ne concerne pas le codage, mais c'était trop long alors j'ai décidé d'en faire un article à part. Focus sur le codage, donc.
Si vous ouvrez un CSV avec Excel (comme c'est le cas par défaut sur la plupart des postes avec Windows), alors il faudra que ce CSV soit encodé en ANSI pour que les caractères spéciaux s'affichent correctement. Autrement le texte sera « cassé ». Oui car rappelez-vous, Excel par défaut utilise le codage Windows-1252, parfois abusivement appelé « ANSI ». En fait, pour bien encoder votre CSV, il faut surtout savoir comment vous comptez le traiter ensuite.
S'il s'agit d'un CSV voué à être échangé dans des flux de données, mieux vaut qu'il reste en UTF-8. La plupart des langages de programmation type PHP auront moins de souci à traiter le fichier s'il est en UTF-8. Même si c'est votre interlocuteur aura peut-être besoin d'un codage ANSI de son côté, mais dans ce cas-là vous le saurez bien assez tôt.
S'il s'agit d'un CSV récupéré quelque part (en UTF-8) et voué à être analysé et retraité dans Excel, là il faudra le convertir en ANSI. De toutes manières, vous le saurez bien assez tôt en ouvrant le CSV avec Excel : si les caractères spéciaux s'affichent bizarrement, fermez Excel sans enregistrer le fichier, éditez le CSV en convertissant l'encodage en ANSI, et rouvrez le fichier avec Excel.

Deuxième étape : vérifiez la déclaration d'encodage du document.

HTML
Dans la balise <meta> dans le <head> :
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

CSS
Ajouter une ligne au début de votre fichier :
@charset "UTF-8";

Cela permet de dire au navigateur de lire le fichier CSS en UTF-8 dans le cas où vous auriez dedans des caractères spéciaux (en commentaire notamment) et pas seulement des caractères ASCII.

JavaScript
Ajouter à la fin de la balise d'insertion du script, dans le HTML :
<script src="script.js" type="text/javascript" charset="utf-8" />

Il n'y a, à ma connaissance, rien à préciser dans le fichier .js lui-même.

PHP
Ajouter au tout début de votre document :
header('content-type: text/html; charset=utf-8');

Il existe aussi des fonctions pour remplir ce rôle, mais nous y reviendrons (j'ai l'impression de beaucoup écrire cette phrase dans cet article).

Troisième étape : vérifiez la configuration du serveur.

> Soit vous avez accès au serveur Apache (je n'en connais pas d'autres) avec les droits administateurs, comme sur un localhost.
Dans ce cas, éditez le httpd.conf et ajoutez à la fin :
AddDefaultCharset UTF-8

Le jeu de caractères sera établi pour les ressources de type text/plain et text/html.

Vous pouvez aussi ajouter une ligne pour préciser l'encodage pour les fichiers CSS et JS, dans le cas où les manipulations précédentes ne suffisent pas :
AddCharset UTF-8 .htm .html .css .js

Le jeu de caractères sera établi pour tous les autres types de ressource : ici text/css, application/javascript. Les .htm et .html ne sont pas vraiment nécessaires si vous avez rajouté la première ligne, mais cela ne coûte rien de les laisser.

Vous pouvez encore checker du côté de la configuration PHP elle-même, dans le fichier php.ini.
Par défaut, PHP est toujours configuré en UTF-8, mais checkez si la ligne suivante n'est pas commentée ou avec une valeur différente :
default_charset="UTF-8"

Enfin, vous pouvez checker les lignes suivantes qui seront certainement commentées et/ou sans valeur, et éventuellement les mettre à jour. Mais personnellement je n'ai jamais eu besoin de le faire, ce n'est donc pas quelque chose que je recommanderais.
iconv.input_encoding = UTF-8 iconv.internal_encoding = UTF-8 iconv.output_encoding = UTF-8 mbstring.language = UTF-8 mbstring.internal_encoding = UTF-8 mbstring.http_input = UTF-8 mbstring.http_output = UTF-8

N'oubliez pas de redémarrer votre serveur après cela.

> Soit vous n'avez pas accès au fichier serveur, vous pouvez alors ajouter une ligne dans le .htaccess :
IndexOptions +Charset=UTF-8

Vous pouvez également utiliser la ligne AddDefaultCharset dans le .htaccess, mais cela n'affectera pas les listes de répertoires générées par Apache.

Quatrième étape : vérifier la base de données SQL.

L'étape la plus énorme. Elle combine énormément de couches. Dans les explications suivantes, je me baserai sur le sytème de gestion MySQL.

Si jamais vous avez accès au fichier de configuration MySQL (my.ini), vous allez peut-être trouver des lignes ressemblant à ceci (ici sur XAMPP en local) :
## UTF 8 Settings #init-connect=\'SET NAMES utf8\' #collation_server=utf8_unicode_ci #character_set_server=utf8 #skip-character-set-client-handshake #character_sets-dir="C:/xampp/mysql/share/charsets"

Le « # » devant implique que ces lignes sont commentées. Personnellement, je n'ai jamais eu besoin d'y toucher, mais peut-être trouverez-vous votre réponse là-dedans. Soit en décommentant (enlever les « # »), soit en ajoutant les lignes suivantes à la fin du fichier (puis en redémarrant MySQL) :
default-character-set=utf8 default-collation=utf8 collation_server=utf8_general_ci character_set_server=utf8 skip-character-set-client-handshake

Autrement, les réponses se trouveront sûrement ailleurs. Pour tout ce qui suit, je vous suggère fortement de faire un dump (une copie) de votre base de données... Et ainsi faire vos manipulations sans risque.

Tout dans votre base de données a un encodage : votre base elle-même, les tables, les champs des tables (contenant du texte : CHAR, VARCHAR, ENUM, etc.), et la donnée (les textes).

Premièrement, lorsque vous créez votre table (via phpMyAdmin), veillez bien à mettre le bon interclassement.

Liste déroulante des interclassements disponibles lors de la création de la base de données

Parenthèse 1 : quelle différence entre jeu de caractères et interclassement ?
Par exemple, dans utf8_general_ci, utf8 est le jeu de caractères (charset en anglais), un peu comme la « catégorie », et « utf8_general_ci » est l'interclassement (collation en anglais).
L'interclassement servira à définir des règles de requête sur un jeu de caractères donnés. Par exemple, avec « utf8_general_ci », avec une requête SQL de ce type :
SELECT * FROM `contacts` WHERE `prenom` LIKE "%a%";

Vous aurez dans vos résultats des prénoms ne tenant pas compte de la casse (les majuscules / minuscules), comme « laurent », « LAURENT », « lAurent » ou encore « LaURENT ».

Parenthèse 2 : lequel choisir ?
Globalement, trois options :
- utf8_bin
- utf8_general_ci
- utf8_unicode_ci
Tout dépend de comment votre base de données est organisée, mais aussi comment vous comptez exploiter les résultats en aval. Je vous recommanderais un utf8_general_ci, c'est celui qui a le plus de chances de fonctionner tel que vous l'attendez. Si besoin de plus d'informations, je vous invite à lire ce lien.

Parenthèse 3 : pourquoi MySQL propose latin1_swedish_ci par défaut ?
Jeu de caractères latin1 parce que c'est la norme historique.
Interclassement swedish probablement car MySQL AB, entreprise créatrice et propriétaire de MySQL, est suédoise.

Vous pouvez aussi créer votre base de données via une requête SQL :
CREATE DATABASE `db_name` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

Si votre table est déjà créée, vous pouvez modifier le charset via phpMyAdmin :
Cliquez sur la table (à la racine), allez dans « Opérations » dans les onglets du haut, puis tout en bas vous avez l'interclassement en liste déroulante. phpMyAdmin propose l'option « Changer les interclassements de toutes les tables », ce n'est pas quelque chose que je recommanderais, je jouerais plutôt la prudence, en identifiant les tables visées.

Ou bien modifier le charset via une requête SQL :
ALTER DATABASE `db_name` CHARACTER SET utf8 COLLATE utf8_general_ci;

Normalement, vous ne prenez pas de risque à effectuer cette manipulation. Idem pour transformer des tables qui seraient dans un encodage différent.

Deuxièmement, l'interclassement lors de la création de tables.

Même principe qu'avec la base de données elle-même.
> Soit dans phpMyAdmin, penser à préciser le bon interclassement.
> Soit via requête SQL (version simplifiée) :
CREATE TABLE `table_name` CHARSET=utf8 COLLATE=utf8_general_ci;

Idem, pour la modification :
> phpMyAdmin
> Requête SQL :
ALTER TABLE `table_name` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

Si vous avez besoin de connaître toutes vos tables qui sont potentiellement concernées par de la modification de charset, voici une requête SQL :
SELECT `TABLE_SCHEMA`, `TABLE_NAME`, `COLUMN_NAME`, `CHARACTER_SET_NAME`, `COLLATION_NAME`, `COLUMN_TYPE` FROM `information_schema`.`COLUMNS` WHERE `TABLE_SCHEMA` = "db_name" AND `CHARACTER_SET_NAME` IS NOT NULL;

Troisièmement, l'interclassement lors de la création des champs.

Toujours le même principe :
> Le préciser dans la liste déroulante dans phpMyAdmin.

Remplissage des caractéristiques d'un nouveau champ dans phpMyAdmin

> Le faire en requête SQL :
ALTER TABLE `table_name` ADD `field_name` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_general_ci;

Et pour modifier :
> phpMyAdmin
> SQL :
ALTER TABLE `table_name` CHANGE `field_name` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_general_ci;

Normalement, changer l'interclassement du champ ne changera pas l'encodage de la donnée (du texte).
Par exemple :
Vous avez une base de données. Une table « contacts » dont le champ « prénom » est encodé en latin1, et le texte est encodé en latin1, avec les caractères qui sont mal encodés : « HervÃ© » (pour « Hervé »).
Vous modifiez l'interclassement du champ en utf8_general_ci, vous aurez toujours « HervÃ© » dans votre donnée.

Pour modifier votre donnée elle-même, c'est une autre paire de manches.
C'est le quatrièmement.

Soit vous avez de la chance et tout est « mal encodé » mais de la même façon : en latin1.
Tentez alors votre chance avec une formule de ce type :
UPDATE `table_name` SET `field_name` = CONVERT(CONVERT(CONVERT(`field_name` USING latin1) USING binary) USING UTF8);

Attention toutefois à vérifier que vous ne subissez pas de perte de données.

Soit vous avez une base de données très crade comme j'ai pu en voir chez certains clients, et il y a de tout : des encodages, réencodages, de plusieurs interclassements, etc. Et là vous êtes bons pour commencer un vrai travail de reprise de données, via une combinaison de PHP et SQL pour arriver à vos fins. Plus votre base est grande (nombre de tables, et de lignes par table, et de champs de type texte), plus vous aurez de travail.
Pistes de résolution :
- REPLACE imbriqués en SQL
- Utilisation des fonctions HEX et UNHEX en SQL pour isoler et convertir dans leur forme hexadécimale certains caractères « impossibles »

Cinquième (et dernière) étape : vérifier les scripts.

On va différencier deux types : les scripts de connexion à la base de données, et les autres. Mais il s'agira de PHP dans les deux cas.

Connexion à la BDD

Il s'agit ici de spécifier qu'on veut faire communiquer PHP et SQL en UTF-8.

> Vous êtes sur du mysql
$link = mysql_connect('localhost', 'user', 'password'); mysql_set_charset('utf8', $link); $db_selected = mysql_select_db('table_name', $link); $query = "SELECT * FROM `table_name`"; mysql_query($query);

Si votre version de PHP ne vous permet pas de faire cette commande, vous pouvez passer par cette méthode :
mysql_query("SET NAMES 'utf8'");

Ceci avant de faire votre query, mais après vous être connecté à votre base de données.

Vous trouverez parfois cette version :
mysql_query("SET CHARSET 'utf8'");

Mais je ne la recommanderais pas, parce que quittes à l'utiliser, autant passer par le premier exemple.

Attention, ne combinez jamais du SET NAMES et du set_charset.

> Vous êtes sur du mysqli
// (objet) $mysqli = new mysqli('localhost', 'my_user', 'my_password', 'db_name'); $mysqli->set_charset("utf8") // (procédural) $link = mysqli_connect('localhost', 'my_user', 'my_password', 'db_name'); mysqli_set_charset($link, "utf8")

La fonction suivante vous donne le charset en cours :
// (objet) $mysqli->character_set_name() // (procédural) mysqli_character_set_name($link)

Avec mysqli (comme mysql d'ailleurs), c'est la meilleure façon de modifier le jeu de caractères. Il n'est pas recommandé d'utiliser la fonction mysqli_query() pour le définir (comme avec la requête SET NAMES utf8), comme expliqué sur la page officielle de PHP.

> Vous êtes sur PDO
$dsn = 'mysql:host=localhost;dbname=db_name;charset=utf8'; $dbh = new PDO($dsn, 'user', 'pass');

Attention, petite précision : la plupart du temps, en PHP comme en SQL, UTF-8 est toujours écrit sans trait d'union : « UTF8 » ou « utf8 ».

Les autres scripts

Des fois, malgré tous vos efforts, et la suivi d'un tutoriel ma foi fort complet, vous continuez à avoir des problèmes de codage, notamment dans des transmissions de flux. Il existe quelques fonctions natives en PHP qui permettent de faire tout un tas de conversions.
Pensez à vérifier votre version de PHP et la version nécessaire pour faire tourner chaque fonction !

utf8_encode : Convertit une chaîne ISO-8859-1 en UTF-8
Comme le dit le top commentaire de php.net, un nom plus approprié pour cette fonction serait « iso88591_to_utf8 ». Si votre texte n'est pas codé en ISO-8859-1, vous n'avez pas besoin de cette fonction. Si votre texte est déjà en UTF-8, vous n'avez pas besoin de cette fonction.

utf8_decode : Convertit une chaîne UTF-8 en ISO-8859-1
Comme ils l'expliquent sur le site, utf8_decode suppose que la chaîne est au format UTF-8, et la convertit au format ISO-8859-1. Les octets dans la chaîne qui ne sont pas valide en UTF-8 et les caractères UTF-8 qui n'existe pas en ISO-8859-1 sont remplacé par « ? ».
Comme la précédente fonction, son nom, par son unicité, devrait être « utf8_to_iso88591 ».

Deux fonctions plus puissantes encore :
iconv et mb_convert_encoding

iconv dispose des options // TRANSLIT et // IGNORE pour traiter les caractères non convertibles.
mb_convert_encoding() serait plus fiable à utiliser si vous voulez supporter différentes plates-formes (Windows, Linux...).
Globalement, les différences entre ces deux fonctions viennent de leur origine et leur structure même. Vous pouvez lire quelques réponses sur cette page.

Leur syntaxe est différente :

iconv c'est « jeu de caractères d'entrée », « jeu de caractères de sortie », « chaîne »
Autrement dit, conversion de chaîne de ISO-8859-1 vers UTF-8 :
echo iconv("ISO-8859-1", "UTF-8", $str);

mb_convert_encoding c'est « chaîne », « jeu de caractères de sortie », « jeu de caractères d'entrée »
Autrement dit, conversion de chaîne de ISO-8859-1 vers UTF-8 :
echo mb_convert_encoding($str, "UTF-8", "ISO-8859-1");

mb_convert_encoding fait partie d'un ensemble de fonctions dédiées à l'encodage (« fonctions sur les chaînes de caractères multi-octets »), listées ici qui vous apporteront potentiellement certaines réponses.

Enfin, j'ai vu des personnes résoudre leurs problèmes avec les fonctions htmlentities et htmlspecialchars, par exemple :
htmlentities($texte, ENT_QUOTES, 'UTF-8') htmlspecialchars($texte, ENT_QUOTES, 'UTF-8')

Ces fonctions convertissent une chaîne de caractères en entités HTML. Vous pouvez avoir deux utilités de ces fonctions :
- un affichage correct d'un texte sur une page web (il n'y aura plus de vraie notion de codage de caractères, ils seront transformés en entités)
- identifier des caractères spéciaux inconnus... transformés en entités, vous aurez peut-être plus de moyens de les identifier

La différence entre les deux ?
echo htmlentities('<Il était une fois un être>.');
transformera en :
<Il était une fois un être>.

Alors que
echo htmlspecialchars('<Il était une fois un être>.');
transformera en :
<Il était une fois un être>.

Comme vu dans l'exemple précédent, vous pouvez les coupler avec des flags en paramètres. Par exemple, ENT_QUOTES convertit les guillemets doubles et les guillemets simples.

À noter qu'il existe bien entendu deux fonctions qui font l'inverse :
html_entity_decode et htmlspecialchars_decode.

Dernière parenthèse, méfiez-vous des guillemets (simples et doubles) et apostrophes, on en trouve de tout type, et ils peuvent être responsables de malheur dans l'encodage :
« » ‹ › “ ” „ ‘ ’ ‚ " ' ` < >

En plus de tout cet article, vous pouvez aussi jeter un coup d'oeil sur cette page sur laquelle je suis tombé pendant l'écriture, où l'auteur a eu la même idée que moi, en peut-être moins complet, mais aussi moins brouillon !

Il y a aussi cette page qui contient des notes en vrac sur l'UTF-8 sur un projet précis, mais qui témoigne du nombre de paramètres auxquels il faut réfléchir pour le codage de caractères.

Bon cette fois je crois avoir fait le tour. Si avec tout ça vous ne réglez pas vos problèmes... Résolvez-les par quelqu'un d'autre !
Tentez aussi de me contacter (adresse email présente en footer).
Et si vous avez vu quelque chose de faux, discutable, ou manquant, n'hésitez pas non plus !