PrestaShop 9.2 : Extra Properties change la donne pour les champs personnalisés

Avec la version stable de PrestaShop 9.2, une nouveauté passée plus discrète que le nouveau tunnel de commande ou l’assistant Ask AI mérite l’attention des responsables de boutique : Extra Properties. Ce mécanisme natif permet d’ajouter des champs personnalisés aux entités du cœur de PrestaShop — produit, déclinaison, catégorie, client, commande — sans créer de table sur mesure ni modifier le code source. Pour une boutique qui dépend de modules pour enrichir ses fiches produits ou ses comptes clients, ce changement d’architecture a des conséquences directes sur la fiabilité et le coût des extensions utilisées.

Pourquoi les champs personnalisés posaient problème jusqu’ici

Avant PrestaShop 9.2, un module qui voulait ajouter un champ à une fiche produit ou à un compte client disposait de deux options, aucune pleinement satisfaisante. La première consistait à créer sa propre table en base de données et à gérer soi-même son affichage dans chaque écran concerné. La seconde reposait sur la surcharge de classes du cœur, une technique puissante mais fragile : une surcharge mal maintenue peut entrer en conflit avec une autre extension, ou casser silencieusement lors d’une mise à jour de version. Pour une boutique en production, ce second scénario se traduit par des fiches produits incomplètes ou des erreurs après une montée de version, découvertes souvent après coup.

• Table sur mesure : affichage à reconstruire manuellement dans chaque écran, y compris le multi-boutique et le multilingue.
• Surcharge de classe cœur : risque de conflit entre modules et de rupture lors d’une mise à jour majeure.
• Dans les deux cas : aucune garantie que le champ apparaisse aussi dans l’API, nécessaire pour un flux produit ou une application connectée.

Ce que permet concrètement Extra Properties

Extra Properties fournit un cadre unique pour ce besoin. Un module déclare sa propriété — son nom, son type, l’entité concernée — et PrestaShop se charge de créer la table associée, de la relier à l’entité, et de gérer la déclinaison multi-boutique et multilingue si nécessaire. La valeur du champ est ensuite accessible de façon uniforme dans le code du thème, dans les formulaires et grilles du back-office, et dans les réponses de l’API Admin. Pour une boutique qui exploite un flux produit ou qui connecte un outil tiers à son catalogue via l’API, cette dernière garantie compte autant que l’affichage côté client.

• Entités couvertes : produit, déclinaison, catégorie, client, commande, et d’autres entités du cœur.
• Gestion native du multi-boutique et du multilingue, sans code supplémentaire côté module.
• Visibilité automatique dans le back-office (formulaires et grilles), le front-office et l’API Admin.
• Une table dédiée par entité, créée et supprimée par PrestaShop lors de l’installation ou de la désinstallation du module.

La documentation officielle détaille le fonctionnement interne de Extra Properties côté développeur, et l’annonce sur le site du projet revient sur les motivations du socle de champs personnalisés. Cette nouveauté s’ajoute à celles déjà couvertes sur la sortie stable de PrestaShop 9.2 et à la liste des modules à vérifier avant une mise à jour vers cette version.

Qui enregistre un champ, et qui s’en sert au quotidien

Un point mérite d’être clarifié, car il change ce qu’une équipe peut attendre de cette fonctionnalité sans faire appel à un développeur. L’enregistrement d’une Extra Property reste un geste de module : c’est l’extension installée sur la boutique qui déclare le champ et le retire si elle est désinstallée. Le back-office, dans Paramètres avancés, offre un écran qui liste les propriétés enregistrées, mais les lignes appartenant à un module y restent en lecture seule pour la boutique : le module demeure responsable de sa propre donnée. Autrement dit, Extra Properties ne remplace pas un module de champs personnalisés en libre configuration ; il change la façon dont ces modules sont construits, au bénéfice de la boutique qui les installe.

Concrètement, cela signifie qu’un module conçu avec Extra Properties a moins de raisons de se casser lors d’une future mise à jour de PrestaShop, puisqu’il ne touche plus au code du cœur. C’est un critère à faire valoir auprès d’un prestataire ou d’un éditeur de module, au même titre que la compatibilité avec le nouveau tunnel de commande déjà abordée sur cette rubrique.

Ce qu’il faut vérifier avant de retenir un module qui s’appuie sur cette fonctionnalité

Le cœur et la documentation officielle signalent Extra Properties comme une fonctionnalité expérimentale dans cette version 9.2 : une évolution de compatibilité reste possible avant sa stabilisation complète. Pour une boutique en production, cela justifie quelques vérifications simples avant d’installer un module qui s’en sert, ou avant de planifier une migration vers PrestaShop 9.2.

• Demander à l’éditeur du module s’il s’appuie sur Extra Properties et depuis quelle version de PrestaShop il le fait.
• Vérifier en préproduction que les champs personnalisés attendus apparaissent bien dans les fiches produits, les grilles du back-office et, si la boutique l’utilise, dans les réponses de l’API.
• Garder la liste des champs personnalisés utilisés par chaque module installé, pour suivre leur disponibilité au fil des futures mises à jour de PrestaShop.
• Tester la désinstallation du module en préproduction : la table associée doit disparaître proprement, sans laisser de données orphelines.

Ce qu’il faut retenir

• Extra Properties, natif dans PrestaShop 9.2, remplace les tables sur mesure et les surcharges de code pour ajouter des champs personnalisés aux produits, clients ou commandes.
• Le champ, une fois enregistré par un module, apparaît automatiquement dans le back-office, le front-office et l’API Admin, y compris en multi-boutique et multilingue.
• L’enregistrement reste un geste de module : la boutique consulte le champ, elle ne le crée pas elle-même depuis le back-office.
• La fonctionnalité est encore expérimentale dans cette version : vérifier en préproduction avant de généraliser un module qui s’en sert.