Retirer l’ID des URL PrestaShop : le coût réel.

Sur une boutique PrestaShop, l’adresse d’un produit ressemble à /12-chaussure-de-ville-noir-42. Le nombre en tête est l’identifiant de la fiche, et il n’est pas décoratif : c’est lui qui rend l’adresse unique et stable. Une famille de modules propose de le retirer pour obtenir /chaussure-de-ville-noir-42, au motif que ce serait « meilleur pour le référencement ».

Ce raisonnement échange un risque réel contre un gain qui n’a jamais été démontré. Cet article chiffre le risque — le nombre de références qui se retrouvent avec la même adresse, et le nombre de redirections à maintenir chaque année — puis examine ce que l’on sait effectivement de l’effet des identifiants sur le référencement. Il donne aussi la requête qui permet de mesurer, sur votre propre catalogue, combien de collisions vous attendent avant d’installer quoi que ce soit.

Ce que l’identifiant garantit, et que rien d’autre ne garantit

L’identifiant apporte trois propriétés, et chacune disparaît avec lui.

• L’unicité. Deux fiches peuvent porter le même nom — c’est courant sur les déclinaisons et sur les produits de marques différentes. Avec l’identifiant, leurs adresses diffèrent. Sans lui, elles entrent en conflit, et la boutique doit inventer une règle de départage, généralement un suffixe numérique qui réintroduit ce qu’on voulait supprimer.
• La stabilité. Renommer un produit ne change pas son identifiant. Avec l’identifiant dans l’adresse, le cœur de PrestaShop sait retrouver la fiche même si le libellé a changé, et redirige. Sans lui, l’ancienne adresse ne correspond plus à rien.
• La résolution directe. Le routeur lit l’identifiant et va chercher la fiche par sa clé primaire. Sans identifiant, il faut résoudre un libellé, ce qui suppose un index sur le libellé et une décision en cas d’ambiguïté.

Mesure — combien de références vont porter la même adresse

Le nombre de collisions ne dépend pas de la taille du catalogue mais du rapport entre cette taille et la variété de votre nomenclature : combien de libellés différents votre façon de nommer les produits peut réellement produire. Appelons cette variété K. Si vos noms combinent vingt familles, huit marques, sept couleurs et douze tailles, K vaut treize mille quatre cent quarante. Si vos noms ne portent que la famille et la couleur, K vaut cent quarante — et deux cents références produiront forcément des doublons.

Le calcul est celui du paradoxe des anniversaires : en tirant N références dans un espace de K libellés, le nombre d’adresses distinctes vaut K × (1 − (1 − 1/K)^N), et tout le reste est en doublon.

Références en doublon d’adresse, selon la variété de la nomenclature

Références	K = 500	K = 2 000	K = 10 000	K = 50 000
200	35 (18 %)	10 (5 %)	2 (1 %)	0
500	184 (37 %)	58 (12 %)	12 (2 %)	2
1 000	568 (57 %)	213 (21 %)	48 (5 %)	10 (1 %)
2 000	1 509 (75 %)	736 (37 %)	187 (9 %)	39 (2 %)
5 000	4 500 (90 %)	3 164 (63 %)	1 065 (21 %)	242 (5 %)
10 000	9 500 (95 %)	8 013 (80 %)	3 679 (37 %)	936 (9 %)

Le seuil à partir duquel un pour cent du catalogue est en doublon tombe très bas :

À partir de combien de références apparaît 1 % de doublons

Variété de la nomenclature	Seuil
K = 500 — famille et couleur seulement	dès 12 références
K = 2 000	dès 42 références
K = 10 000 — famille, marque, couleur	dès 203 références
K = 50 000 — avec la taille dans le nom	dès 1 008 références
K = 200 000 — noms très distinctifs	dès 4 028 références

Ce tableau explique pourquoi le module « fonctionne » sur une boutique de démonstration et casse sur la vôtre. Douze produits de test ne collisionnent jamais. Deux mille références nommées de façon régulière collisionnent systématiquement.

Mesurez votre propre catalogue avant d’installer quoi que ce soit

Inutile de faire des hypothèses sur K : votre base contient la réponse. La requête compare le nombre de fiches au nombre d’adresses distinctes qu’elles produiraient sans identifiant.

SELECT COUNT(*) AS fiches,
       COUNT(DISTINCT link_rewrite) AS adresses_distinctes,
       COUNT(*) - COUNT(DISTINCT link_rewrite) AS doublons
  FROM ps_product_lang
 WHERE id_lang = 1;

-- et la liste des libellés qui collisionnent, pour juger de leur nature :
SELECT link_rewrite, COUNT(*) AS n
  FROM ps_product_lang WHERE id_lang = 1
 GROUP BY link_rewrite HAVING n > 1
 ORDER BY n DESC LIMIT 30;

Si la troisième colonne de la première requête n’est pas nulle, la question est tranchée : ces fiches ne pourront pas coexister sans identifiant, et la boutique devra leur fabriquer des suffixes. Adaptez le préfixe des tables et l’identifiant de langue à votre installation ; sur une boutique multilingue, la requête est à passer pour chaque langue, parce que les collisions ne sont pas les mêmes d’une langue à l’autre.

Le second coût : les redirections que le renommage impose

Un catalogue vit. Les libellés changent : une faute corrigée, une marque ajoutée, une reformulation commerciale, une harmonisation de nomenclature. Avec l’identifiant dans l’adresse, ces changements sont sans conséquence sur les liens existants. Sans lui, chaque renommage crée une adresse nouvelle et abandonne l’ancienne.

Redirections à créer et à maintenir, selon le rythme de renommage

Catalogue	Renommages par an	Redirections par an	Après cinq ans
500 références	10 %	50	250
2 000 références	10 %	200	1 000
5 000 références	15 %	750	3 750
20 000 références	15 %	3 000	15 000

Quinze mille règles de redirection à porter sur une boutique de vingt mille références, uniquement pour avoir retiré un nombre de l’adresse. Et ces règles sont rarement créées : le renommage se fait dans l’interface d’administration, sans que personne ne pense à la redirection, et l’ancienne adresse tombe en erreur silencieusement. C’est le mécanisme par lequel une boutique perd, sur deux ans, une part de ses pages indexées sans qu’aucune alerte ne se déclenche.

Et le gain de référencement, alors ?

C’est la question qui justifie l’installation, et elle mérite une réponse précise plutôt qu’une opinion.

Ce qui est documenté par Google sur les adresses relève du confort : une adresse simple, lisible, dont les mots décrivent le contenu, aide les utilisateurs à comprendre où ils vont — et une adresse lisible se partage mieux, s’affiche mieux dans les résultats, se retient. Rien, dans cette documentation, ne présente la présence de chiffres comme un handicap. Les adresses de boutiques parmi les mieux positionnées du monde comportent des identifiants.

Autrement dit : le bénéfice invoqué est un bénéfice de lisibilité, et il est réel mais marginal — un identifiant de deux à cinq chiffres en tête d’une adresse par ailleurs descriptive ne rend pas l’adresse illisible. Le coût, lui, est mesurable et se matérialise à coup sûr, comme le montrent les deux tableaux ci-dessus.

Il y a un cas où la question se pose autrement : une boutique dont les adresses ne sont pas descriptives du tout — /12-p12 — a un vrai problème de lisibilité. La réponse n’est alors pas de retirer l’identifiant, mais d’écrire des libellés dignes de ce nom. C’est un travail de catalogue, pas un module.

Le troisième risque, qui ne se voit qu’à la montée de version

Un module de ce type ne se contente pas de changer un format d’affichage : il se greffe sur la réécriture d’adresses, c’est-à-dire sur le mécanisme qui transforme une adresse en fiche à afficher. C’est un des points les plus sensibles du cœur applicatif, et l’un de ceux qui bougent d’une version majeure à l’autre.

Trois conséquences, dans l’ordre de gravité :

1. À la montée de version, si le module n’a pas de version compatible, toutes vos adresses changent d’un coup. Pas quelques-unes : toutes. Vous vous retrouvez à devoir produire des milliers de redirections en urgence, ou à rester sur une version ancienne — donc sans correctifs de sécurité.
2. La désinstallation n’est pas symétrique. Retirer le module rétablit le format d’origine, ce qui invalide toutes les adresses qui circulent depuis son installation : liens entrants, signets, campagnes, pages indexées.
3. Le diagnostic devient difficile. Quand une fiche ne s’affiche plus, la question « est-ce le produit, le cache, le routeur ou le module » prend un temps qu’un identifiant dans l’adresse aurait fait économiser.

C’est le raisonnement général que nous appliquons aux modules : on n’installe pas un module qui touche au routage, au panier ou au paiement pour un gain de confort. Le sujet est développé dans notre retour d’expérience après quinze ans de PrestaShop, et la question de la compatibilité aux montées de version dans notre guide de migration vers PrestaShop 9.

Ce que le cœur fait avec l’identifiant, et qu’on perd sans lui

Le détail technique vaut d’être connu, parce qu’il explique pourquoi la perte n’est pas rattrapable par un réglage.

Quand une adresse contient l’identifiant, le routeur le lit, va chercher la fiche par sa clé primaire, puis compare le libellé de l’adresse au libellé courant du produit. S’ils diffèrent — parce que le produit a été renommé —, il répond par une redirection permanente vers l’adresse à jour. C’est un comportement natif, gratuit, et qui fonctionne pour les milliers de renommages que connaîtra votre catalogue sur dix ans.

Sans identifiant, cette comparaison est impossible : il n’y a plus rien à comparer, seulement un libellé à résoudre. Deux conséquences en découlent, et aucune n’est un défaut du module — ce sont des conséquences logiques.

• La redirection automatique disparaît. Elle doit être remplacée par une table de correspondance, tenue à jour à chaque renommage, dans laquelle il faut conserver l’historique de tous les libellés qu’un produit a portés. Personne ne tient cette table.
• La résolution devient ambiguë. Quand deux fiches partagent un libellé, il faut choisir. Les modules choisissent en ajoutant un suffixe — le plus souvent un nombre — ce qui rétablit exactement ce qu’on voulait supprimer, en moins lisible : /chaussure-de-ville-noir-42-2 au lieu de /12-chaussure-de-ville-noir-42.

Ce dernier point est le plus ironique du dossier. Le module installé pour retirer un nombre de l’adresse en remet un, à un endroit où il ne veut rien dire. Le numéro en tête désignait la fiche ; le suffixe en queue ne désigne que l’ordre d’arrivée dans la collision.

Le multi-langue et le multi-boutique aggravent tout

Deux configurations changent l’ampleur du problème, et elles sont fréquentes.

Le multi-langue. Le libellé d’adresse est traduit, donc les collisions ne sont pas les mêmes d’une langue à l’autre. Un catalogue sans collision en français peut collisionner en allemand, où les composés raccourcissent les libellés, ou en anglais, où les couleurs se réduisent à un mot. La requête de contrôle donnée plus haut doit donc être passée langue par langue, et le pire résultat décide.

Le multi-boutique. Une même fiche peut porter des libellés différents selon la boutique, et deux boutiques peuvent partager un domaine avec des préfixes distincts. Sans identifiant, la résolution doit d’abord déterminer la boutique, puis résoudre le libellé dans son contexte — une couche supplémentaire d’ambiguïté, sur le composant le plus sensible du routage.

Dans ces deux configurations, notre position n’est pas une préférence : nous refusons de poser ce type de module, parce que le coût d’un incident de routage sur une boutique multilingue se compte en journées de diagnostic, pour un gain qui reste celui de la lisibilité d’une adresse.

Ce qu’il faut faire à la place

La bonne réponse au problème réel — des adresses peu lisibles — n’est pas de retirer l’identifiant, mais d’écrire les libellés correctement. Quatre règles, qui coûtent une journée de travail sur le catalogue et rapportent la lisibilité recherchée sans rien sacrifier.

1. Un libellé d’adresse court et distinctif, différent du nom commercial si celui-ci est verbeux. La fiche peut s’appeler « Chaussure de ville Novaris cuir pleine fleur noir 42 » et porter l’adresse /12-derby-cuir-noir-42. Le champ est distinct du nom, précisément pour cela.
2. Pas de mots vides ni de ponctuation. Les articles, les prépositions et les mentions commerciales — « nouveau », « promo », « best seller » — n’ont rien à faire dans une adresse, d’autant qu’ils changeront.
3. Jamais de référence interne dans l’adresse si elle ne veut rien dire pour le client. /12-ref-a4471-b n’est pas plus lisible que /12-p12.
4. Un libellé figé après la mise en ligne. C’est la règle la plus importante et la moins suivie : on peut renommer le produit autant qu’on veut, on ne touche plus à son libellé d’adresse sans raison sérieuse. Avec l’identifiant, l’ancienne adresse continue de fonctionner — mais chaque changement dilue les liens entrants et brouille les statistiques.

Appliquées ensemble, ces quatre règles donnent des adresses lisibles, stables et uniques. Le nombre en tête reste, et personne ne s’en est jamais plaint dans un tunnel de commande.

Le tableau de décision

Faut-il retirer l’identifiant de vos adresses produits ?

Votre situation	La réponse
Moins de cent références, libellés très distinctifs, une seule langue	possible sans dommage immédiat — mais sans gain mesurable non plus
Catalogue avec déclinaisons ou libellés réguliers	non : la requête de contrôle vous dira combien de collisions vous attendent
Multi-langue ou multi-boutique	non : la résolution devient ambiguë sur le composant le plus sensible
Catalogue qui change de libellés régulièrement	non : chaque renommage devient une redirection à créer à la main
Vos adresses sont réellement illisibles	travaillez les libellés, gardez l’identifiant
Le module est déjà installé	voir la sortie en quatre étapes ci-dessous — surtout, ne pas désinstaller brutalement

Si le module est déjà installé

La pire décision est de le retirer brutalement : cela invalide toutes les adresses en circulation. La sortie se fait en quatre étapes, dans cet ordre.

1. Mesurer l’état réel. Les deux requêtes ci-dessus donnent le nombre de collisions actuelles. S’il y en a, certaines fiches portent déjà des suffixes artificiels, et il faut les identifier avant de bouger.
2. Relever les adresses qui reçoivent des visites. Les journaux du serveur sur douze mois, et les données de la console de recherche. Ce sont celles qu’il faudra rediriger ; les autres peuvent disparaître.
3. Construire le plan de redirections de l’ancien format vers le nouveau, une règle par adresse relevée. La méthode est la même que pour une refonte : elle est détaillée dans notre article sur le plan de redirections.
4. Désinstaller, puis vérifier que chaque adresse relevée répond en un seul saut, et que le plan de site ne déclare plus aucune adresse redirigée.

Comptez un à trois jours selon la taille du catalogue, dont l’essentiel passe dans l’étape 2. C’est le prix de la sortie, et il est à mettre en face du gain de lisibilité qui avait motivé l’entrée.

Ce qu’il faut retenir

Retirer l’identifiant d’une adresse produit PrestaShop échange trois garanties — unicité, stabilité, résolution directe — contre un gain de lisibilité marginal. Le coût se calcule : avec une nomenclature de variété moyenne, un pour cent du catalogue est déjà en doublon d’adresse à partir de deux cents références, et plus d’un tiers à partir de dix mille. Votre propre chiffre s’obtient en une requête, et il est préférable de l’obtenir avant l’installation.

Le second coût est récurrent : chaque renommage de produit crée une adresse nouvelle et abandonne l’ancienne. Sur cinq mille références renommées à quinze pour cent par an, cela fait 750 redirections par an et 3 750 au bout de cinq ans — que personne ne crée, parce que le renommage se fait dans l’administration sans que rien ne le rappelle.

Enfin, le module se greffe sur la réécriture d’adresses. Le jour où il n’a pas de version compatible avec la montée de version majeure, ce ne sont pas quelques pages qui changent d’adresse : c’est tout le catalogue, en une fois.