Accents dans les URL : faut-il les garder ?

Google sait parfaitement indexer une URL qui contient un é, un è ou un ç. Le vrai sujet n'est donc pas « est-ce pénalisé ? » mais « que se passe-t-il concrètement quand cette URL voyage ? ». Car une adresse comme /café-de-spécialité n'existe jamais sous cette forme à l'écran et sur le réseau en même temps : le navigateur l'affiche joliment, mais il l'envoie au serveur sous une forme encodée, et chaque maillon de la chaîne (messagerie, réseau social, outil d'analytics, CMS, CDN) peut la réécrire à sa façon.

Cet article traite uniquement de ce cas propre aux sites francophones : faut-il conserver les caractères accentués dans les chemins d'URL, et que penser d'un nom de domaine accentué (IDN) comme café.fr ? Nous verrons comment l'encodage fonctionne, où il crée des doublons ou des liens cassés, ce que vous verrez dans vos rapports, et comment décider sans dogmatisme. La rédaction d'un bon slug en général est un autre sujet ; ici, on s'intéresse aux octets.

Ce qui se passe réellement quand une URL contient un accent

Une URL, au sens strict de la norme, ne peut contenir que des caractères ASCII. Tout le reste doit être représenté par une suite d'octets encodés en pourcentage. Pour les sites modernes, ces octets sont ceux de l'UTF-8. Le é, par exemple, occupe deux octets en UTF-8 (C3 et A9) et devient donc %C3%A9 dans la requête réellement envoyée. Le è devient %C3%A8, le ç devient %C3%A7, le à devient %C3%A0 et le ê devient %C3%AA.

Ainsi, l'adresse https://exemple.fr/café voyage sur le réseau sous la forme https://exemple.fr/caf%C3%A9. Les navigateurs récents décodent ce texte pour l'afficher dans la barre d'adresse, ce qui donne l'impression que l'accent est « dans » l'URL. C'est une présentation, pas la réalité. Quand vous copiez l'adresse depuis la barre, le presse-papiers contient généralement la version encodée, ce qui explique pourquoi un lien collé dans un document ou un mail devient soudain illisible.

Les deux écritures désignent la même ressource, et Google les traite comme telles : sa documentation recommande d'ailleurs d'encoder en UTF-8 les caractères non ASCII dans les URL. Le problème ne vient donc pas du moteur de recherche, mais de tout ce qui manipule l'adresse avant ou après lui. Plus il y a d'intermédiaires, plus il y a de chances qu'un d'eux décode, ré-encode, tronque ou double-encode le lien.

Les cas où l'accent vous coûte vraiment quelque chose

Les incidents réels se concentrent sur quelques scénarios, tous liés à la circulation des liens plutôt qu'au classement.

Le premier est la messagerie et les éditeurs de texte. Certains clients mail ou outils de notes coupent le lien au premier caractère qu'ils ne reconnaissent pas comme faisant partie d'une URL. Le lien cliquable s'arrête alors avant l'accent, et le destinataire arrive sur une page introuvable. Le comportement s'est beaucoup amélioré, mais il reste des cas en impression, en SMS sur d'anciens appareils et dans des logiciels métiers.

Le deuxième est le double encodage. Un script qui reçoit déjà %C3%A9 et le ré-encode produit %25C3%25A9, une adresse que votre serveur ne sait plus faire correspondre à une page. Cela arrive dans des redirections écrites à la main, des paramètres de suivi, des passerelles entre outils et des plugins de traduction.

Le troisième est l'ancien encodage. Des liens historiques, créés à l'époque d'ISO-8859-1 ou de Windows-1252, encodent le é en %E9 au lieu de %C3%A9. Un serveur qui n'attend que de l'UTF-8 renvoie une erreur ou une page vide pour ces anciens liens, et les sites très anciens en contiennent plus qu'on ne l'imagine.

Le quatrième, plus discret, concerne la casse de l'encodage. La norme demande de comparer %c3%a9 et %C3%A9 comme équivalents, mais un serveur ou une règle de réécriture mal configurés peuvent distinguer les deux et servir deux pages identiques sous deux adresses. Un lien externe en minuscules hexadécimales suffit à créer un doublon que vous ne voyez pas en naviguant.

Normalisation Unicode : le doublon invisible

Le piège le moins connu est celui des deux manières d'écrire un même é. En Unicode, il existe un caractère précomposé (U+00E9, forme NFC) et une séquence composée du e suivi d'un accent aigu combinant (U+0065 puis U+0301, forme NFD). À l'écran, les deux sont identiques. Dans l'URL, ils sont différents : le premier donne %C3%A9, le second donne e%CC%81.

D'où viennent les formes NFD ? Historiquement, de certains systèmes de fichiers Apple qui stockent les noms de fichiers sous cette forme décomposée, et de quelques chaînes d'outils qui copient ces noms tels quels. Si vos slugs ou vos noms de fichiers d'images passent par un import depuis un Mac, il peut arriver qu'une URL existe dans deux formes visuellement indiscernables, et que l'une des deux renvoie une erreur 404 car elle ne correspond à rien en base.

Le réflexe défensif consiste à normaliser en NFC à l'entrée, c'est-à-dire au moment où le slug est créé ou reçu, et à faire la comparaison côté serveur sur une version normalisée. Si vous constatez des 404 sur des URL accentuées qui semblent correctes, comparez octet par octet l'adresse demandée et celle en base : la différence est souvent là.

Accents dans le chemin ou dans le nom de domaine : deux sujets différents

Il faut bien distinguer les deux cas, car ils ne relèvent pas du même mécanisme. Le chemin (ce qui suit le nom de domaine) utilise l'encodage en pourcentage décrit plus haut. Le nom de domaine, lui, utilise le Punycode, un système qui convertit un nom contenant des caractères Unicode en une chaîne ASCII préfixée par xn--. Le domaine café.fr devient xn--caf-dma.fr au niveau du DNS. C'est ce qu'on appelle un IDN, pour nom de domaine internationalisé.

Les extensions comme le .fr acceptent les caractères accentués du français depuis plusieurs années, si bien qu'enregistrer un domaine contenant un é ou un ç est tout à fait possible. Techniquement, Google indexe ces sites sans difficulté. Les inconvénients sont d'ordre pratique, et ils sont plus lourds que pour un chemin.

En voici les principaux :

• Saisie : sur un clavier étranger, dans un appel téléphonique ou sur un support imprimé, l'accent est un obstacle. Les gens tapent la version sans accent, qui n'est pas votre domaine, et arrivent chez quelqu'un d'autre ou nulle part.
• Adresses e-mail : beaucoup de systèmes refusent encore les adresses dont le domaine est accentué, ou les convertissent en Punycode illisible. Un formulaire d'inscription qui rejette contact@café.fr est un problème commercial, pas un problème SEO.
• Affichage : pour des raisons de sécurité (attaques par homographes), les navigateurs peuvent afficher la forme Punycode brute, xn--caf-dma.fr, dans la barre d'adresse selon leurs règles et la combinaison d'alphabets, ce qui ruine l'effet de marque recherché.
• Outils tiers : certains outils d'analyse, de suivi de liens ou de gestion de réseaux sociaux affichent, filtrent ou rejettent la version Punycode, ou stockent les deux formes comme deux sites distincts.

Ce que vous verrez dans Search Console et dans vos analytics

L'affichage des URL accentuées varie d'un outil à l'autre, et c'est une source classique de confusion au moment de croiser les données. Search Console présente généralement les adresses sous une forme lisible dans l'interface, alors que les exports et les API peuvent renvoyer la version encodée. Selon l'outil de tableur ou d'analyse que vous utilisez ensuite, vous pouvez vous retrouver avec deux lignes qui désignent la même page.

Dans un outil d'analytics, la forme enregistrée dépend de ce que le navigateur envoie et de la manière dont l'outil stocke le chemin de la page. Il peut arriver que la même page apparaisse sous deux écritures, décodée et encodée, en particulier si des liens entrants ou des campagnes utilisent des formes différentes, ou si une balise envoie le chemin après un décodage partiel. Le résultat est un rapport de pages vues fragmenté : le chiffre réel est la somme de deux lignes.

Pour éviter de comparer des lignes qui ne correspondent pas, décodez systématiquement les URL avant tout rapprochement entre sources. Dans un tableur, une fonction de décodage d'URL ou une petite fonction dans un script suffit. Faites aussi attention aux paramètres de campagne : une valeur de utm_campaign contenant « été » ou « Noël » sera encodée, et deux personnes qui la saisissent différemment créent deux campagnes.

Un dernier réflexe utile : dans les outils de crawl, filtrez les URL contenant %25. Ce motif trahit presque toujours un double encodage, donc un lien défectueux à corriger.

Garder ou retirer les accents : un arbre de décision pratique

Il n'y a pas de bonne réponse universelle, mais il y en a une bonne pour votre situation. Voici comment je raisonnerais.

Si votre site existe déjà et que ses URL accentuées sont indexées et reçoivent des liens, le plus raisonnable est de ne rien changer. Une migration d'URL est toujours un risque (redirections, liens internes, signaux consolidés, perte temporaire) et le gain d'une URL sans accent est marginal. Corrigez plutôt les défauts d'encodage, les doublons et les redirections, qui sont les vrais coûts.

Si vous construisez un nouveau site francophone, retirer les accents des slugs est le choix le plus prudent : la translittération (é en e, ç en c, œ en oe) est sans surprise, l'adresse se dicte et se tape partout, et vous évitez toute la catégorie de problèmes décrite plus haut. Vous perdez très peu de lisibilité, car les moteurs comprennent parfaitement que « cafe » et « café » relèvent du même sujet. Le titre et le contenu de la page, eux, doivent naturellement rester correctement accentués.

Pour un nom de domaine, la prudence est encore plus forte : préférez une version sans accent. Si le nom de marque comporte un accent, enregistrez aussi la variante sans accent et redirigez-la vers la version principale, ou l'inverse, mais choisissez consciemment quelle est la version canonique.

Dans tous les cas, appliquez la même règle partout : un seul format, décidé une fois, appliqué à tous les slugs, et jamais de mélange de pages accentuées et non accentuées pour un même type de contenu.

• Site ancien, URL indexées avec des liens : conserver, corriger l'encodage et les doublons.
• Nouveau site ou nouvelle section : slugs sans accent, contenu accentué.
• Nom de domaine : version sans accent comme adresse principale, variante accentuée en redirection si elle vous appartient.
• Site multilingue : translittérer proprement dans chaque langue et ne jamais mélanger les conventions.

Migrer d'URL accentuées vers des URL sans accent sans dégâts

Si vous décidez de retirer les accents d'un site existant, la procédure est celle de toute migration d'URL, avec quelques attentions propres à l'encodage.

Commencez par lister toutes les URL concernées à partir du sitemap, d'un crawl et de l'export des pages les plus visitées et les plus liées. Pour chacune, calculez la nouvelle adresse par translittération, puis vérifiez qu'il n'y a pas de collision : deux titres qui ne diffèrent que par un accent produiraient le même slug.

Mettez en place des redirections 301 de chaque ancienne URL vers la nouvelle. Écrivez la règle en tenant compte de l'encodage réel reçu par le serveur : la source à faire correspondre est la forme encodée, %C3%A9, ou la forme décodée selon la configuration, et il faut tester les deux. Ajoutez, si votre historique le justifie, les formes héritées en %E9. Une règle qui ne correspond qu'à une seule écriture laisse passer les autres.

Mettez ensuite à jour les liens internes pour qu'ils pointent directement vers les nouvelles adresses, sans passer par la redirection, puis le sitemap, les balises canoniques et les attributs hreflang, qui doivent tous contenir la même forme. Une canonique qui indique l'ancienne adresse accentuée contredit votre redirection et brouille le signal.

Enfin, surveillez les semaines suivantes : le rapport d'indexation des pages dans Search Console, les erreurs 404 sur des URL contenant %, et les chaînes de redirections. Gardez les redirections actives longtemps, car elles servent autant aux liens externes qu'aux robots.

Vérifications à faire dès aujourd'hui sur un site accentué

Quelle que soit votre décision, quelques contrôles rapides révèlent l'état réel de vos URL accentuées.

Testez une adresse accentuée avec un outil en ligne de commande qui montre la requête brute, en envoyant la version encodée puis la version en minuscules hexadécimales, et comparez les codes de réponse. Vous devez obtenir soit le même contenu avec une canonique identique, soit une redirection vers la forme standard, mais pas deux pages distinctes.

Copiez une URL accentuée dans un mail envoyé à vous-même, dans une note et dans un message instantané, puis cliquez. Le test est sommaire mais il révèle vite un client qui coupe le lien.

Comparez, dans votre outil d'analytics, le chemin d'une même page consultée depuis une recherche, depuis un lien interne et depuis une campagne : s'il apparaît sous plusieurs écritures, corrigez la collecte ou ajoutez une étape de décodage dans vos rapports.

Enfin, vérifiez que la balise canonique, le sitemap et les liens internes utilisent exactement la même forme. C'est la cohérence, bien plus que la présence ou l'absence de l'accent, qui détermine si les signaux se concentrent sur une seule adresse.