10 tâches à automatiser avec l’API d’administration PrestaShop 9
PrestaShop 9 a introduit une nouvelle API d’administration basée sur API Platform 3, OAuth2 et l’architecture CQRS de PrestaShop.
C’est important, car l’automatisation du commerce électronique fonctionne mieux lorsque les systèmes externes interagissent avec la boutique au moyen d’opérations métier stables, plutôt qu’en modifiant directement les tables de la base de données.
Une installation PrestaShop moderne peut devoir communiquer avec :
- les fournisseurs ;
- ERP;
- PIM;
- CRM;
- les systèmes d’entrepôt ;
- les logiciels de comptabilité ;
- les places de marché ;
- les plateformes d’analyse ;
- les applications SaaS.
L’API d’administration offre aux développeurs une meilleure base pour ces intégrations.
Cet article présente dix scénarios d’automatisation pratiques et explique comment les concevoir de manière sûre.
Note sur les versions : L’API d’administration évolue activement. Consultez toujours la documentation OpenAPI générée pour la version exacte de PrestaShop 9 que vous intégrez. Les exemples ci-dessous présentent des modèles d’architecture, sans garantir que chaque opération métier existe comme point de terminaison natif dans toutes les versions 9.x.
Pourquoi la nouvelle API d’administration est importante
L’ancienne API Webservice de PrestaShop repose principalement sur des opérations CRUD et sur le fonctionnement historique d’ObjectModel.
L’API d’administration de PrestaShop 9 est conçue autour de :
- OAuth2;
- des portées d’autorisation ;
- API Platform;
- commandes et requêtes CQRS ;
- l’extensibilité par les modules.
Elle est donc mieux adaptée à une automatisation maîtrisée.
Une bonne automatisation doit être :
- authentifiée ;
- autorisée ;
- observable ;
- idempotente ;
- compatible avec les nouvelles tentatives ;
- limitée en charge.
L’API fournit le point d’accès, tandis que les tâches longues peuvent toujours être traitées par des files d’attente et des workers CLI.
1. Automatiser la synchronisation des informations produit
Un PIM peut gérer :
- les noms de produits ;
- les descriptions ;
- les références ;
- les marques ;
- les caractéristiques ;
- les dimensions ;
- les identifiants.
Au lieu de copier manuellement les données dans PrestaShop, un service de synchronisation peut envoyer les modifications approuvées.
La question essentielle de conception est :
Quel système fait autorité pour chaque champ ?
Par exemple :
Le PIM est responsable de :
- titre
- description
- caractéristiques
L'ERP est responsable de :
- coût
- stock
PrestaShop est responsable de :
- texte de merchandising
- classement local en catégories
Sans règles de propriété, les systèmes écrasent leurs modifications mutuellement.
Utiliser les mises à jour incrémentielles
Ne réécrivez pas tous les produits chaque heure.
Utilisez :
- les dates de modification ;
- les empreintes des sources ;
- les événements de changement.
Si un produit n’a pas changé, ignorez-le.
2. Automatiser la synchronisation des stocks
Les stocks sont l’une des cibles les plus utiles pour l’automatisation.
Les mises à jour manuelles des stocks provoquent :
- la vente de produits indisponibles ;
- l’annulation de commandes ;
- la frustration des clients.
Un entrepôt ou un ERP peut synchroniser les stocks vers PrestaShop.
Utilisez des identifiants stables pour :
- les produits ;
- les combinaisons ;
- les entrepôts.
Ne vous fiez jamais aux seuls noms.
Gérer les données périmées
Supposons qu’un instantané de stock ait été généré à :
10:00
mais arrive après une mise à jour plus récente générée à :
10:05
L’intégration doit savoir quel instantané est le plus récent.
Stockez des horodatages ou des numéros de séquence.
N’appliquez pas aveuglément les mises à jour dans leur ordre d’arrivée.
3. Automatiser les mises à jour de prix
Les systèmes des fournisseurs ou ERP peuvent définir :
- le prix de base ;
- le coût ;
- les marges ;
- les règles promotionnelles.
L’automatisation des prix doit pouvoir être auditée.
Enregistrez :
ancienne valeur
nouvelle valeur
source
horodatage
motif
Cela permet d’enquêter rapidement sur un prix incorrect.
Éviter les réécritures de tout le catalogue
Si seuls 400 prix sur 100 000 ont changé, n’en mettez à jour que 400.
Réduire les écritures améliore :
- les performances ;
- la clarté des audits ;
- la stabilité du cache.
4. Automatiser la création de nouveaux produits
Découvrir de nouveaux produits est différent de mettre à jour ceux qui existent.
Une architecture utile est :
Flux fournisseur
→ découverte
→ validation
→ file de création
→ PrestaShop
Avant de créer un produit, vérifiez :
- la correspondance des catégories requises ;
- la correspondance des marques ;
- les règles fiscales ;
- les attributs des combinaisons ;
- les images requises ;
- une référence unique.
Si les données sont incomplètes, marquez le produit comme bloqué.
Ne laissez pas un seul produit fournisseur invalide arrêter tout le catalogue.
5. Automatiser l’exportation des commandes
Les commandes doivent souvent quitter PrestaShop.
Destinations possibles :
- ERP;
- un entrepôt ;
- un prestataire logistique ;
- un logiciel de comptabilité.
L’exportation doit utiliser un état de synchronisation explicite.
Par exemple :
nouveau
en cours de traitement
exporté
nouvelle tentative
échec
Ne confondez pas l’état de synchronisation externe avec l’état de commande PrestaShop visible par le client.
Rendre les nouvelles tentatives idempotentes
Si un délai réseau expire après la création de la commande dans l’ERP, une nouvelle tentative ne doit pas créer une seconde commande.
Utilisez une clé de commande externe, par exemple :
prestashop-shop2-order-54883
Le système destinataire doit reconnaître les doublons.
6. Automatiser la synchronisation CRM
Un CRM peut recevoir :
- les événements des comptes clients ;
- les récapitulatifs de commandes ;
- les données des segments de clients.
Minimisez les données.
N’envoyez pas chaque champ de la base simplement parce qu’il existe.
N’envoyez que les données nécessaires au CRM pour l’objectif métier défini.
Pour les processus marketing, respectez le consentement et les obligations de confidentialité applicables.
7. Automatiser les contrôles de qualité du catalogue
L’automatisation n’a pas toujours à modifier les données.
Elle peut détecter des problèmes.
Exemples :
- produit sans image ;
- description manquante ;
- prix nul ;
- EAN invalide ;
- catégorie non associée ;
- référence fournisseur dupliquée ;
- combinaison aux attributs incomplets.
Un service de qualité peut créer un rapport ou une file de vérification.
Utiliser des niveaux de confiance
Certains problèmes peuvent être corrigés automatiquement.
Par exemple :
supprimer les espaces de fin
D’autres nécessitent une vérification humaine.
Par exemple :
choisir entre deux catégories fournisseur contradictoires
Séparez les corrections déterministes des décisions ambiguës.
8. Automatiser les rapports et l’entrepôt de données
Une base de données de production ne doit pas devenir un entrepôt analytique.
Les rapports complexes peuvent parcourir des années de données et concurrencer le trafic du paiement.
Exportez plutôt les données opérationnelles incrémentielles vers :
- un entrepôt de données ;
- un système BI ;
- une base de données de reporting.
Utilisez des points de reprise.
Par exemple :
identifiant de la dernière commande exportée
ou :
horodatage de la dernière modification
Ne demandez ensuite que les enregistrements les plus récents.
9. Automatiser les procédures de maintenance
L’API d’administration peut participer à l’orchestration du déploiement et de la maintenance.
Un système de déploiement contrôlé peut :
- mettre les imports en pause ;
- vérifier l’état de la boutique ;
- déployer le code ;
- vider certains caches ;
- exécuter les migrations de base de données ;
- vérifier l’état de l’API ;
- réactiver les tâches en arrière-plan.
Les opérations dangereuses doivent disposer de permissions restreintes.
Ne créez pas un client API disposant d’un contrôle illimité simplement parce que l’automatisation est pratique.
10. Créer des intégrations SaaS propres aux modules
L’extensibilité par les modules est l’une des fonctionnalités les plus intéressantes de l’API d’administration.
Les modules peuvent ajouter des classes de ressources API dans :
src/ApiPlatform/Resources
Les modules commerciaux peuvent ainsi exposer leur propre API structurée.
Exemples :
- état de l’analyse de sécurité ;
- état de la file d’import ;
- état des licences ;
- rapports de modules ;
- tâches planifiées.
Au lieu de scripts personnalisés tels que :
/modules/example/run.php?token=SECRET
vous pouvez utiliser le modèle OAuth2 et les scopes de la plateforme.
Exemple : architecture d’automatisation des fournisseurs
Une intégration fournisseur peut utiliser :
API/XML fournisseur
↓
Téléchargeur
↓
Analyseur en flux
↓
Validation
↓
File d'attente
├── créer des produits
├── mettre à jour les prix
├── mettre à jour les stocks
└── traiter les images
L’API peut exposer :
GET /supplier/jobs
POST /supplier/jobs
GET /supplier/jobs/{id}
POST /supplier/jobs/{id}/retry
Les traitements longs restent dans le système de workers.
L’API reste rapide.
L’API ne remplace pas Cron
L’API d’administration est une interface.
Cron détermine quand les tâches récurrentes s’exécutent.
Par exemple :
cron toutes les 5 minutes
→ le processus appelle le fournisseur
→ le processus met à jour PrestaShop
ou :
planificateur externe
→ API d'administration
→ crée une tâche
→ la file traite la tâche
Les deux approches peuvent être valables.
Utiliser les identifiants client OAuth2
Pour les intégrations de machine à machine, PrestaShop décrit le flux Client Credentials.
Un client demande un jeton à l’aide de :
- l’identifiant client ;
- le secret client ;
- le type d’autorisation ;
- les scopes.
Il appelle ensuite l’API avec :
Authorization: Bearer ACCESS_TOKEN
Limiter les scopes
Si un système de reporting lit seulement les produits, il ne doit pas disposer d’un accès en écriture.
Créez des clients distincts pour :
- ERP;
- PIM;
- l’analyse ;
- un entrepôt.
Cela simplifie la gestion des permissions et la rotation des identifiants.
Utiliser OpenAPI comme contrat
PrestaShop peut générer une documentation API.
Utilisez la spécification OpenAPI pour :
- générer des clients ;
- créer des tests ;
- comparer les versions ;
- vérifier les modifications des points de terminaison.
Pour une intégration commerciale, conservez les spécifications API de chaque version de PrestaShop prise en charge.
Concevoir la pagination
Ne demandez jamais à l’API de renvoyer tout le catalogue en une seule réponse.
Utilisez :
page
limit
cursor
filters
Dans les grandes boutiques, la pagination protège l’API et la base de données.
Préférer les tâches asynchrones pour les traitements lourds
Une requête ne doit pas rester ouverte pendant l’import de 100 000 produits.
Utilisez :
POST /jobs
→ identifiant de tâche
GET /jobs/{id}
→ progression
Le worker traite la tâche séparément.
Enregistrer la progression
Les processus longs doivent exposer :
total
traités
modifiés
ignorés
échec
restants
Cela rend les opérations visibles.
Un état indiquant seulement :
en cours
est insuffisant pour un import de trois heures.
Distinguer les nouvelles tentatives des échecs permanents
Problèmes temporaires :
- délai dépassé ;
- HTTP 503;
- interblocage de base de données.
Ils peuvent faire l’objet de nouvelles tentatives.
Problèmes permanents :
- identifiant invalide ;
- catégorie non associée ;
- définition de combinaison dupliquée.
Ces éléments doivent être bloqués pour vérification.
Utiliser des identifiants de corrélation
Attribuez un ID unique à chaque exécution.
Exemple :
IMPORT-20260922-00152
Incluez-le dans :
- les journaux API ;
- les journaux des workers ;
- les journaux d’erreurs.
Cela accélère considérablement le dépannage.
Surveiller la santé de l’automatisation
Suivez :
- la dernière exécution réussie ;
- la durée ;
- les enregistrements traités ;
- les échecs ;
- les nouvelles tentatives ;
- l’âge de la file d’attente.
Déclenchez une alerte lorsque :
- une tâche attendue ne s’est pas exécutée ;
- la file cesse de se vider ;
- le taux d’échec augmente fortement ;
- la durée double.
Liste de contrôle de sécurité
- HTTPS
- un client par intégration
- permissions minimales
- secrets hors du code source
- ne jamais journaliser les jetons
- limiter les nouvelles tentatives
- valider les entrées
- authentifier les points de terminaison des tâches
- conserver les journaux d’audit
Liste de contrôle de conception de l’automatisation
- définir la source de vérité
- identifiants externes stables
- écritures idempotentes
- mises à jour incrémentielles
- pagination
- tâches asynchrones pour les travaux lourds
- progression persistante
- nouvelles tentatives explicites
- surveillance
- plan de retour arrière ou de rapprochement
Questions fréquentes
L’API d’administration peut-elle remplacer les tâches cron ?
Non. L’API donne accès aux opérations. Cron ou un autre planificateur détermine toujours quand les tâches récurrentes s’exécutent.
Puis-je importer 100 000 produits dans une seule requête API ?
Ce n’est pas une bonne conception. Créez une tâche et traitez-la de façon asynchrone, par lots.
Les modules peuvent-ils ajouter des points de terminaison personnalisés ?
Oui. L’API d’administration de PrestaShop 9 est explicitement conçue pour être étendue par les modules.
OAuth2 est-il obligatoire ?
La nouvelle API d’administration utilise OAuth2 pour l’authentification et l’autorisation.
Toutes les intégrations doivent-elles partager un seul client API ?
Non. Des clients séparés rendent les scopes, la révocation et l’audit plus sûrs.
Quelle est la règle la plus importante de l’automatisation ?
Rendez les opérations idempotentes. Une nouvelle tentative ne doit pas créer d’effets métier en double.