PrestaShop 9.2 : vos champs métier ont enfin une place, pas encore une migration

Une référence ERP n’est pas une description produit. Une consigne de préparation n’est pas un message destiné au client. Pourtant, ces informations finissent parfois dans le même champ libre, dans une table de module oubliée ou dans un export que seule une personne sait relancer.

PrestaShop 9.2, annoncé disponible le 30 septembre 2026, introduit Extra Properties pour structurer ces données supplémentaires. La nouveauté mérite mieux qu’une ligne dans une liste de fonctionnalités : elle peut changer la manière dont une boutique conserve et échange ses informations métier. Mais créer un nouveau champ ne récupère ni ses anciennes valeurs, ni les règles de votre connecteur.

Le bon point de départ n’est donc pas « quels champs pouvons-nous ajouter ? ». C’est : « quelles données devons-nous retrouver, qui les utilise, et où ne doivent-elles jamais apparaître ? »

Ce que la version stable apporte réellement

Extra Properties permet d’attacher des champs typés aux entités de PrestaShop : produits, déclinaisons, clients, commandes, entre autres. Une définition précise le type, les règles de validation, la valeur par défaut et les emplacements où la donnée est disponible. Le stockage repose sur des colonnes SQL dans des tables dédiées, sans ajouter vos colonnes aux tables métier centrales.

Un module peut enregistrer ses propres définitions. L’annonce de la version stable indique aussi que le marchand peut créer et gérer des champs depuis le back-office, dans Advanced Parameters > Extra Properties ; le libellé affiché dépend de la traduction installée. Les propriétés appartenant à un module sont regroupées sous son espace de noms, tandis que les propriétés gérées par le cœur ont leur propre regroupement.

Cette base commune peut éviter de réécrire la même mécanique de stockage dans chaque développement. Elle ne supprime pas le besoin de définir le sens du champ, d’adapter un connecteur ou de vérifier le thème. Un emplacement prévu dans une fiche d’administration n’est pas une preuve que votre ancienne page personnalisée saura l’afficher.

Un détail compte pour le devis de maintenance : la documentation marque encore le code Extra Properties comme expérimental dans PrestaShop 9.2 et réserve la possibilité d’une rupture de compatibilité si aucune autre solution n’existe. La version de PrestaShop est stable ; cela ne rend pas chaque nouveau composant définitivement figé. Prévoyez donc le suivi de cette dépendance dans un accompagnement PrestaShop, surtout pour une intégration spécifique à votre entreprise.

Deux champs suffisent à révéler les vrais choix

Prenons un cas fictif : un distributeur français vend aux particuliers et aux professionnels, avec deux boutiques et un catalogue traduit en français et en anglais. Il veut reprendre une référence ERP et une consigne interne de préparation. Ce n’est pas un résultat client, mais un exemple de cadrage.

La référence ERP : une chaîne, même si elle ressemble à un nombre

Une référence comme 001284-A doit conserver ses zéros et son suffixe. La transformer en entier au cours d’un import détruirait son identité. Il faut aussi choisir la bonne entité : si chaque taille d’un produit possède une référence distincte dans l’ERP, une seule valeur sur le produit parent ne suffit pas. La donnée appartient alors à la déclinaison concernée.

Si les deux boutiques utilisent réellement la même référence, une valeur commune peut convenir. Si chacune correspond à un établissement ERP avec ses propres identifiants, il faut étudier une valeur par boutique et vérifier que l’entité accepte cette portée. Traduire le libellé « Référence ERP » ne signifie pas que la référence elle-même doit être différente en anglais.

Enfin, désignez le système qui fait autorité. Si l’ERP est maître de cette valeur, une correction dans PrestaShop risque d’être écrasée à la synchronisation suivante. Le contrat du connecteur doit décrire le sens de circulation et le traitement des conflits, pas seulement annoncer « synchronisation bidirectionnelle ».

La consigne de préparation : interne et attachée au bon moment

« Contrôler le conditionnement avant expédition » peut aider l’équipe logistique sans être destiné à la vitrine. Mais le champ d’un panier et celui d’une commande ne sont pas interchangeables. La documentation précise que les valeurs supplémentaires du panier ne sont pas recopiées automatiquement sur la commande. Un module qui en a besoin après l’achat doit organiser cette copie, par exemple au moment de la validation de commande.

Ne supposez pas non plus qu’une portée par boutique est disponible partout. Les commandes et paniers, liés à une boutique par leur colonne id_shop, n’acceptent que des propriétés de portée commune selon la documentation consultée. Une commande reste liée à son contexte de boutique ; le mot « commune » ne signifie pas que toutes les commandes partagent une seule consigne.

Le test utile suit donc la donnée jusqu’au préparateur : saisie prévue, commande créée, valeur conservée, accès du connecteur, document de préparation. Une fiche produit qui s’affiche correctement ne valide aucune de ces étapes.

Le dictionnaire de reprise à joindre au devis

Avant tout import, documentez chaque champ. Pour nos deux exemples, le registre peut commencer ainsi :

Ce tableau n’est que le début du livrable. Ajoutez le nom technique, le module propriétaire ou la propriété gérée par le cœur, les langues concernées, la valeur par défaut, les droits des consommateurs, le format d’export, la règle de migration et le responsable de validation. Une colonne inconnue doit rester à résoudre, pas recevoir une valeur supposée.

La différence entre absence, chaîne vide et valeur par défaut mérite sa propre décision. Une valeur affichée par défaut ne prouve pas qu’une ancienne donnée a été importée. Si vous attribuez « standard » à toutes les commandes sans valeur, vous devez pouvoir distinguer ce choix de repli d’une consigne réellement présente dans l’ancien système.

Pour un catalogue multilingue, vérifiez les accents, les apostrophes et les retours à la ligne dans l’export. Pour une référence, contrôlez les zéros initiaux. Pour une règle numérique, testez le format attendu par le connecteur, sans confondre la virgule affichée à un opérateur français et le format technique transmis. Ces cas simples produisent des critères de recette bien plus utiles qu’un « import réussi ».

Masqué sur le site ne veut pas dire inaccessible à tous

La documentation distingue les surfaces. Le réglage displayFront filtre les propriétés accessibles côté front-office. Les formulaires et grilles d’administration ont leurs propres emplacements. L’Admin API utilise une liste d’opérations ciblées, avec éventuellement des méthodes HTTP précises : il ne faut pas déduire l’exposition API du seul nom de l’entité.

L’annonce de présentation indique que les permissions API suivent celles de l’entité parente. Ne présentez donc pas Extra Properties comme un système autonome de droits par champ. Pour une donnée interne, vérifiez à la fois les opérations auxquelles elle est exposée et les droits du client API qui appelle ces opérations. Pouvoir lire une donnée et pouvoir la modifier sont deux besoins différents.

Autre piège pour un ancien connecteur : la documentation classe le webservice historique et les scripts ou tâches lancés par HTTP avec les points d’entrée qui ne voient que les propriétés displayFront. Ce comportement diffère de celui de l’Admin API ou de la ligne de commande. Ne rendez pas une consigne publique pour faire fonctionner un export : identifiez le canal utilisé et adaptez l’intégration dans un périmètre revu.

Même au sein de l’Admin API, la forme de la réponse compte. Sur une ressource individuelle, les données sont regroupées dans extraProperties. Dans une liste, la documentation décrit des champs à plat portant un préfixe. Un importateur qui ne teste que la lecture d’un produit peut donc échouer sur l’export du catalogue. Faites vérifier les opérations réellement utilisées, leur version et le contexte de boutique ou de langue.

Une répétition de migration, pas un saut dans le vide

La reprise doit d’abord se dérouler sur une copie isolée, avec des données adaptées aux tests et sans déclencher de vrais emails, paiements ou échanges logistiques. Les règles ci-dessous sont des recommandations de recette, pas des opérations que nous aurions exécutées sur votre boutique.

Figer la correspondance. Rapprochez chaque ancienne ligne avec l’entité cible au moyen d’une clé fiable. Une référence commerciale réutilisée ou un nom traduit ne constitue pas forcément une clé unique. Les lignes sans correspondance et les doublons doivent sortir dans un rapport d’exception, sans écrasement silencieux.

Importer un échantillon qui peut échouer. Incluez une déclinaison, un champ absent, une référence avec zéros, une traduction, deux contextes de boutique et une valeur invalide. La documentation précise que l’indicateur required n’ajoute pas, à lui seul, de contrôle serveur empêchant les valeurs vides : une contrainte telle que NotBlank est nécessaire lorsque c’est la règle voulue. Testez le refus d’une valeur incorrecte autant que l’acceptation d’une valeur correcte.

Relire par les vrais consommateurs. Le gestionnaire catalogue, le préparateur et le connecteur doivent retrouver la même information utile. Contrôlez aussi son absence là où elle ne doit pas sortir, puis le refus attendu avec un accès non autorisé. Pour chaque essai, conservez le contexte, le résultat attendu, le résultat observé, une preuve expurgée et la décision du responsable métier. La documentation signale une limite de la grille des commandes : les colonnes supplémentaires y restent vides et leurs filtres ne fonctionnent pas. N’utilisez donc pas cette grille comme seule preuve de reprise ; convenez d’une autre lecture vérifiable.

Répéter sans multiplier les données. Une reprise interrompue puis relancée doit avoir un comportement défini : mise à jour des lignes déjà traitées, rejet des conflits et comptage des exceptions. Comparez les valeurs, pas seulement le nombre total d’enregistrements. Puis simulez une synchronisation ERP après l’import pour repérer un éventuel écrasement.

La bascule réelle doit enfin tenir compte des commandes et modifications arrivées depuis la copie de test. Décidez qui arrête temporairement les écritures concernées, comment reprendre ce delta et qui autorise la remise en service. Un retour arrière qui restaure aveuglément une ancienne base peut perdre les nouvelles commandes : le plan doit couvrir les données créées pendant la bascule. Ce travail fait partie de la gestion technique et des sauvegardes, pas d’un simple changement d’affichage.

Ce que vous pouvez décider avant de migrer

Faut-il supprimer le module qui stockait les champs ? Non, pas sur la seule foi de cette nouveauté. Le module peut encore gérer des calculs, des exports ou une copie panier-commande. Inventoriez ses fonctions et conservez les données tant que la reprise et le retour sont à prouver. La suppression d’une définition peut supprimer sa colonne de stockage ; ce n’est pas un nettoyage anodin.

Créer les champs dans le back-office suffit-il pour connecter l’ERP ? Non. Cela définit un emplacement et des règles ; il reste à adapter le mapping, les opérations API, les formats et les droits du connecteur. L’annonce stable ne promet pas la migration automatique des données de vos modules existants.

Peut-on reporter la reprise des champs sans ignorer la maintenance ? Oui, le chantier de structuration peut être séparé du plan de maintenance de la boutique. La décision dépend de votre version, des correctifs nécessaires et de vos dépendances. N’ajoutez pas une migration de données improvisée à une intervention urgente ; ne repoussez pas non plus un correctif nécessaire au seul motif que ce dictionnaire n’est pas prêt.

Le livrable à demander est concret : un dictionnaire validé, un mapping de reprise, un rapport d’exceptions, des preuves de lecture et un scénario de retour compatible avec les nouvelles commandes. Si ces éléments manquent, la fonction est disponible, mais votre migration n’est pas encore définie.

Vous préparez PrestaShop 9.2 avec des données spécifiques ? Décrivez à 1Design deux champs représentatifs et les outils qui les utilisent. Nous pourrons cadrer une revue limitée de leur stockage, de leurs échanges et des tests nécessaires, puis définir le périmètre à chiffrer. Pas de promesse de compatibilité sans examen du connecteur ni de migration incluse par défaut.

Sources et périmètre

Sources officielles consultées le 2 octobre 2026 :

• Annonce de PrestaShop 9.2 stable, publiée le 30 septembre 2026.
• Présentation officielle d’Extra Properties.
• Documentation technique Extra Properties : stockage, exposition, validation et limites.

La documentation technique actuelle précise certains comportements que l’annonce générale résume. Cet article explique comment préparer une décision et une recette ; il ne certifie ni la compatibilité d’un module particulier ni le résultat d’une migration en production.