Le projet en un coup d’œil
Aster portait les références, les prix et la disponibilité ; PrestaShop devait recevoir des fiches marchandes structurées sans imposer une reprise manuelle de chaque produit.
Dawap a construit une application Symfony dédiée à la lecture Aster, à la transformation des produits et à leur écriture contrôlée dans PrestaShop.
Les tâches planifiées, états et erreurs donnent aux équipes un point de contrôle commun sur les flux de catalogue, de stock, de médias et de commandes.
Art’Sacs commercialisait des cartouches, toners et consommables d’impression. Pour alimenter sa boutique, l’entreprise devait faire circuler des données détenues par Aster vers PrestaShop : références, marques, couleurs, rendements, imprimantes compatibles, prix, disponibilité et visuels. La difficulté ne résidait pas dans un simple transfert de champs, mais dans la traduction de deux modèles conçus pour des usages différents.
Dawap a développé une application Symfony placée entre les interfaces Aster et PrestaShop. Elle récupère les produits fournisseur, construit un modèle intermédiaire, applique les règles de la boutique puis choisit de créer ou de mettre à jour la fiche correspondante. La même logique relie ensuite la référence au stock, aux images et aux lignes de commande.
Le projet a été réalisé entre le 23 décembre 2019 et le 28 janvier 2020 pour Art’Sacs. France Appro a repris l’activité en décembre 2023 ; le double nom conserve à la fois l’origine de la réalisation et la continuité actuelle de l’activité.
Cette mission illustre une intégration API sur mesure : isoler les contrats externes, rendre les transformations explicites et donner aux équipes les moyens de suivre chaque traitement au lieu de dépendre d’une synchronisation opaque.
1. Un catalogue riche, partagé entre fournisseur et boutique
Préserver les données utiles à la vente sans dupliquer les opérations
Une fiche de consommable ne se résume pas à un nom et à un prix. La référence constructeur, la marque, la couleur, le rendement, le conditionnement et la liste des imprimantes compatibles participent tous à la décision d’achat. Une donnée perdue pendant l’échange diminue immédiatement la qualité du catalogue.
Aster intervient comme source fournisseur et partenaire d’exécution. PrestaShop porte la présentation marchande et les commandes. Le middleware assume la traduction entre ces responsabilités afin que chaque système conserve son propre vocabulaire sans imposer ses structures à l’autre.
L’objectif opérationnel était clair : rendre les mises à jour répétables, garder une clé de rapprochement stable et donner de la visibilité sur les tâches exécutées. Cette approche protège le catalogue des doublons et rend une anomalie plus facile à localiser.
2. Construire le flux par responsabilités métier
Source, transformation, écriture et suivi avancent ensemble
Le premier jalon a posé l’environnement Symfony, les clients Aster et PrestaShop ainsi que le modèle de traitements. L’équipe a ensuite concentré le travail sur la collecte des produits et la traduction de leurs attributs.
Les services de création et de mise à jour PrestaShop ont été complétés par la synchronisation des quantités et le traitement des images. Les commandes ont reçu leur propre modèle avec client, adresse, paiement et lignes afin de préparer leur passage vers le partenaire dropshipping.
En parallèle, les tâches, leurs états et leurs erreurs ont été persistés puis rendus accessibles dans une interface interne. La chaîne d’intégration exécute 44 tests de services avant la construction des images applicatives.
3. Faire travailler ensemble une source fournisseur et une boutique
Deux systèmes portent deux parties différentes de la réalité produit
Aster connaît la référence article, sa disponibilité et ses données fournisseur. PrestaShop doit présenter une fiche lisible, la classer, lui associer un fabricant, appliquer sa fiscalité et permettre sa commande. Une synchronisation fiable doit préserver les données de source tout en respectant les règles du canal de vente.
Sans couche dédiée, chaque différence devient une opération manuelle ou une règle dispersée. Dawap a donc isolé l’échange dans une application responsable de la collecte, de la transformation et du suivi.
4. Isoler les interfaces externes dans un middleware Symfony
Les contrats Aster et PrestaShop restent séparés des décisions métier
L’application s’appuie sur Symfony 4.4, Doctrine et la bibliothèque de services web PrestaShop. Un client Aster, un client PrestaShop et des services spécialisés prennent en charge produits, stocks, images et commandes.
Doctrine conserve commandes, clients, adresses, lignes, traitements, tâches et erreurs. Cette mémoire donne au connecteur un état propre et alimente les écrans de pilotage sans dépendre uniquement de la réponse instantanée des APIs.
Expose les produits, attributs et disponibilités fournisseur.
Normalise les données utiles sans perdre leur origine.
Résout référence, fabricant, catégorie, prix et activation.
Reçoit les fiches, stocks et médias préparés.
Conserve tâches, états et erreurs pour chaque traitement.
5. Conserver treize attributs utiles à la fiche marchande
La référence fournisseur devient une clé, pas un simple texte affiché
Le produit intermédiaire conserve disponibilité, marque, couleur, code client, description, code article, référence constructeur, rendement, conditionnement, prix, imprimantes compatibles, date de lecture et entrepôt.
Chaque attribut possède une responsabilité. Le code article sert au rapprochement, la marque résout le fabricant, les compatibilités enrichissent la description et la disponibilité alimente la quantité vendable.
6. Choisir entre création et mise à jour à partir d’une clé stable
Une même règle protège le catalogue des doublons
Après collecte, le service recherche la fiche PrestaShop par référence fournisseur. Une correspondance conduit à une mise à jour ; une absence prépare une création avec son nom, sa description, son fabricant, sa catégorie et ses données commerciales.
Le produit nouvellement créé reste désactivé avant validation. Cet arbitrage laisse à l’équipe la maîtrise de la publication tout en automatisant la préparation de la fiche.
7. Synchroniser la disponibilité et enrichir les fiches
Quantité et image suivent des traitements spécialisés
Le service de stock retrouve la ressource PrestaShop associée à la référence, puis lui transmet la quantité issue d’Aster. La même clé relie ainsi produit et disponibilité.
Le traitement média télécharge l’image fournisseur et l’ajoute lorsque la fiche ne possède pas déjà de visuel principal. Cette condition évite d’écraser systématiquement une image déjà travaillée dans la boutique.
8. Préparer la commande pour le dropshipping
Reconstituer client, destination et lignes hors de la boutique
Le connecteur sait lire une commande PrestaShop et conserver sa référence, son paiement, son client, son adresse de livraison et ses lignes. Chaque ligne garde la quantité et la référence attendue par le fournisseur.
Ces données forment l’ordre de dropshipping destiné à Aster : référence de commande, entrepôt, destination, articles et quantités. La traduction reste séparée de la lecture e-commerce, ce qui rend les règles plus faciles à faire évoluer.
9. Donner une mémoire aux traitements planifiés
Tâches, états et erreurs deviennent consultables
Chaque traitement peut produire des tâches et enregistrer ses erreurs. Des vues internes listent les opérations planifiées, leurs exécutions et les commandes concernées.
L’équipe dispose ainsi d’un point d’entrée pour localiser le domaine en cours, retrouver un échec et reprendre l’action utile sans relancer aveuglément l’ensemble des échanges.
10. Tester les services aux frontières des deux APIs
Quarante-quatre tests intégrés à la chaîne de construction
Les contrôles automatisés couvrent les services Aster et PrestaShop : lecture, création, mise à jour et transformation. Ils protègent les opérations où un écart de contrat peut modifier une fiche ou une quantité.
La chaîne d’intégration construit les images PHP et Nginx, exécute ces tests puis prépare l’image applicative. Le packaging reste ainsi aligné sur les mêmes services que ceux utilisés par les traitements.
11. Ce que le connecteur change pour l’exploitation
Moins de règles dispersées, davantage de décisions explicites
L’équipe catalogue dispose d’une transformation rejouable entre les attributs fournisseur et la fiche PrestaShop. L’équipe e-commerce conserve la validation finale des nouveaux produits et retrouve une disponibilité reliée à la même référence.
L’équipe technique peut faire évoluer séparément les clients externes, les règles de traduction et l’interface de suivi. Cette séparation réduit le risque qu’un changement de format se transforme en correction diffuse dans toute la boutique.
Le projet de pilotage des synchronisations Aster–PrestaShop prolonge cette réalisation en détaillant la visibilité donnée aux traitements, aux tâches et aux erreurs.
12. Une intégration utile traduit le métier, pas seulement le format
Le catalogue devient un flux gouvernable entre Aster et PrestaShop
France Appro / Art’Sacs montre comment transformer une donnée fournisseur détaillée en catalogue e-commerce administrable. La solution réunit la collecte Aster, la composition des fiches, le rapprochement par référence, la résolution des fabricants, la disponibilité et les médias dans une même chaîne cohérente.
Le modèle intermédiaire constitue l’arbitrage central. Il empêche les structures de l’API fournisseur de se répandre dans toute la boutique et permet aux règles PrestaShop d’évoluer dans une couche clairement responsable.
Pour une entreprise confrontée à un fournisseur, un ERP ou un partenaire logistique, Dawap applique aujourd’hui la même discipline : cartographier les données, expliciter les règles, tester les frontières et rendre l’exploitation observable. Découvrez nos expertises en API PIM et catalogue et en intégration e-commerce.
