PrestaShop 9 : la nouvelle Admin API, ce qu’elle change pour votre boutique

Depuis le 30 septembre 2026, PrestaShop 9 est en version stable. Au-delà des nouveautés déjà couvertes sur son interface de commande ou ses champs personnalisés, un changement plus discret concerne la façon dont la boutique communique avec le reste du système d’information : sa logithèque de connexion externe, l’Admin API, a été repensée en profondeur. Pour un dirigeant qui ne code pas, le sujet peut sembler technique. Il a pourtant une conséquence directe : c’est cette brique qui décide si un logiciel de comptabilité, un ERP, une marketplace ou un outil de gestion des stocks peut dialoguer avec la boutique, et dans quelles conditions de sécurité.

Ce que remplace l’Admin API

Jusqu’à présent, les logiciels externes qui devaient échanger des données avec une boutique PrestaShop passaient par des « web services » construits directement sur les objets internes du logiciel. Ce système fonctionnait, mais il mélangeait deux rôles : représenter les données telles qu’elles existent en base, et les exposer à l’extérieur. Résultat, pour un intégrateur, un accès souvent plus large que nécessaire, et peu de granularité dans les droits accordés à chaque outil connecté.

La documentation technique officielle de PrestaShop décrit la nouvelle Admin API comme construite sur « API Platform », une brique technique tierce reconnue, en version 3. Les échanges de données ne passent plus par une transposition directe des fiches internes, mais par des opérations organisées autour des besoins métier (« CQRS commands », dans le vocabulaire de l’équipe cœur) : un endpoint pour consulter un produit, un autre pour modifier un stock, un autre encore pour créer une commande, chacun pensé comme une action distincte plutôt que comme un accès brut à une table de données.

OAuth et scopes : des droits d’accès découpés par outil

Le changement le plus concret pour la sécurité tient à l’authentification. L’Admin API fonctionne avec le protocole OAuth, le même principe que celui utilisé par les banques en ligne ou les grands éditeurs de logiciels professionnels : au lieu de confier un mot de passe unique à un outil tiers, la boutique délivre un jeton d’accès limité dans le temps et dans son périmètre.

Le billet officiel « PrestaShop Core Monthly » d’octobre 2026, publié le 3 novembre sur le blog technique de l’équipe cœur, précise que chaque endpoint de l’Admin API exige désormais un « scope » attribué explicitement. Un logiciel de facturation qui n’a besoin que de lire les commandes ne peut plus, par construction, modifier les fiches produits ou les comptes clients. Le même billet mentionne aussi un travail de fond sur une décision d’architecture (l’« ADR 0023 ») qui fixe où vivent ces ressources dans le code et comment elles doivent se comporter : format de pagination commun, gestion uniforme des opérations groupées et des codes de retour. Autrement dit, une base pensée pour durer, pas un assemblage au fil des besoins.

Le même billet signale que les endpoints manquants pour les produits ont été ajoutés récemment, et que ceux concernant les pays, les clients et les types d’image ont été regroupés par domaine pour simplifier leur maintenance. Le support du multi-boutique, encore qualifié d’expérimental, dispose désormais d’une documentation dédiée. L’ensemble reste donc un chantier actif plutôt qu’un produit figé, ce qui est cohérent avec une sortie encore récente de la version 9.

Pourquoi s’y intéresser sans être développeur

Concrètement, cette évolution ne change rien à l’usage quotidien du back-office. Elle compte en revanche dès qu’une boutique veut se connecter à un autre outil : un logiciel de facturation pour générer les factures automatiquement, un ERP pour centraliser les stocks entre plusieurs canaux de vente, une marketplace pour synchroniser un catalogue, ou un outil de gestion de produits (PIM) pour centraliser les fiches. Dans tous ces cas, c’est l’Admin API qui porte l’échange, et c’est elle qui détermine le niveau de risque en cas de faille chez le prestataire tiers : avec un scope limité, un outil compromis ne donne accès qu’à ce pour quoi il a été autorisé, pas à l’ensemble de la boutique.

Le choix de la plateforme e-commerce reste un sujet à part entière, déjà traité en détail sur le comparatif entre WooCommerce, PrestaShop et Drupal Commerce. Pour une boutique déjà installée sur PrestaShop, la question n’est plus de changer d’outil mais de vérifier que ses intégrations suivent le rythme de la plateforme : la sortie de la version stable 9.2 a déjà nécessité de revérifier l’hébergement et la compatibilité des modules, comme détaillé dans ce point de vérification avant mise à jour. L’Admin API s’inscrit dans la même logique : une fondation qui évolue, et qu’il faut suivre plutôt que découvrir après coup.

La base Symfony : une échéance à connaître, pas une urgence

Cette refonte de l’API s’accompagne d’un changement plus large de fondations. La documentation officielle de PrestaShop indique que la version 9 repose sur Symfony 6.4, contre Symfony 4.4 pour la génération précédente. Symfony est le framework logiciel sur lequel est construite l’interface d’administration de PrestaShop ; ce n’est pas un détail technique anodin, car chaque version de Symfony a une durée de vie fixée par son propre éditeur, indépendante du calendrier de PrestaShop.

Or Symfony 6.4 est une version dite « LTS » (support long), dont la documentation de PrestaShop précise elle-même qu’elle « recevra des corrections de bugs jusqu’en novembre 2026 et des correctifs de sécurité jusqu’en novembre 2027 ». Cela ne signifie pas que PrestaShop 9 deviendra vulnérable à cette date : l’équipe cœur a toute latitude pour migrer vers une version plus récente de Symfony avant l’échéance, comme elle l’a déjà fait entre les versions 8 et 9. Le billet d’octobre 2026 montre d’ailleurs ce travail en cours, avec deux mises à jour des composants Symfony sur la branche 9.2.x au cours du seul mois d’octobre, à la suite des correctifs amont 6.4.48 et 6.4.49. L’échéance de 2027 reste cependant un repère utile pour comprendre pourquoi les mises à jour régulières de PrestaShop ne sont pas accessoires : elles suivent, en partie, le calendrier de maintenance d’une brique qu’une boutique ne choisit pas directement.

Ce qu’il faut vérifier côté boutique

Aucune action urgente n’est nécessaire aujourd’hui : il n’y a ni faille ni date limite immédiate. Deux réflexes sont néanmoins à intégrer dans la gestion courante de la boutique :

1. Avant toute nouvelle intégration (comptabilité, ERP, marketplace, PIM), demander explicitement au prestataire s’il utilise l’Admin API ou l’ancien web service, et privilégier la première option pour une connexion plus sûre et plus durable.
2. Dans le suivi des mises à jour, rester sur une branche 9.x activement maintenue plutôt que de figer la boutique sur une version ancienne : c’est la condition pour continuer à bénéficier des correctifs de sécurité qui accompagnent, en coulisses, le calendrier de support de Symfony.

Ce qu’il faut retenir

• PrestaShop 9 remplace ses anciens web services par une Admin API fondée sur OAuth, avec un droit d’accès (« scope ») distinct pour chaque outil connecté.
• La boutique tourne désormais sur Symfony 6.4 ; ses correctifs de sécurité s’arrêtent en novembre 2027, un repère utile pour planifier les prochaines mises à jour majeures.
• Toute nouvelle connexion (ERP, comptabilité, marketplace, PIM) mérite une question simple à l’intégrateur ou à l’agence : s’appuie-t-elle sur la nouvelle Admin API ou sur l’ancien web service ?
• Le chantier de l’Admin API reste actif : des endpoints sont encore ajoutés mois après mois, ce qui justifie de rester sur une branche 9.x maintenue.