Étude de cas 07 · Automatisation · E-commerce
SMM Panel
Les commandes Shopify payées partent seules chez le fournisseur ; statuts, refills et marges sont suivis.
- Rôle
- Conception et développement complet
- Catégorie
- Automatisation · E-commerce
- Stack
- Laravel 13 · Vue 3 · Webhooks
- Qualité
- 33 tests
01 — Contexte
Une boutique Shopify vend des services de visibilité pour les réseaux sociaux (abonnés, vues, mentions J'aime), exécutés par un fournisseur externe via son API. Chaque commande payée devait être rapprochée du bon service, transmise à la main avec le bon lien et la bonne quantité, puis suivie jusqu'à la livraison, sans vue d'ensemble sur les marges ni sur les commandes bloquées.
02 — Problème
Chaque commande devait être rapprochée du bon service, transmise à la main puis suivie jusqu'à la livraison.
03 — Solution
Shopify signale chaque commande payée par un webhook signé. L'application vérifie la signature, enregistre la commande une seule fois, retrouve le service fournisseur associé à chaque produit et transmet la commande en arrière-plan. Les statuts sont synchronisés toutes les cinq minutes ; annulations et refills se pilotent depuis l'interface, et les demandes de refill des clients sont lues directement dans la boîte e-mail. Tout ce qui sort du cas prévu passe « à traiter » et déclenche une alerte.
04 — Fonctionnalités
Webhooks signés
Signature HMAC comparée en temps constant, webhooks en double ignorés.
Correspondances produits
Chaque produit ou variante relié à un service, avec multiplicateur de quantité et champ du lien cible.
Envoi en arrière-plan
Trois tentatives espacées (30 s, 2 min, 5 min) ; un refus du fournisseur n'est pas relancé.
Suivi des statuts
Synchronisation groupée par fournisseur toutes les cinq minutes, sans exécutions simultanées.
Annulations et refills
Depuis la fiche commande, ou à partir des demandes clients reçues par e-mail.
Tableau de bord
Chiffre d'affaires, coût fournisseur, marge, taux de réussite et alerte de solde bas.
05 — En images
Détail d'une commande avec actions de synchronisation et de refill
06 — Architecture
- Shopifywebhook commande payée · HMAC
- Laravel · Inertiacorrespondances · interface Vue
- Files de tâchesenvoi · synchronisation · refill
- API fournisseurcommande · statut · annulation · refill
- Base relationnellecommandes · coûts · historique
Le webhook se contente de vérifier la signature et de confier la commande à une file : Shopify obtient sa réponse tout de suite, et le traitement peut être rejoué sans créer de doublon.
Les échanges avec le fournisseur passent par une interface commune et des objets typés ; les clés API sont chiffrées en base et jamais renvoyées à l'interface.
07 — Défis techniques
Défi
Ne jamais envoyer deux fois la même commande.
Solution
Webhooks idempotents, une seule commande fournisseur par article et vérification de l'identifiant fournisseur avant tout envoi.
Défi
Distinguer une panne passagère d'un refus du fournisseur.
Solution
Relances espacées pour les erreurs techniques ; un refus (solde, lien invalide) passe directement « à traiter » avec une alerte e-mail.
Défi
Traiter les demandes de refill envoyées par formulaire.
Solution
Lecture de la boîte e-mail, extraction des champs et tolérance aux fautes de frappe sur le réseau social (distance de Levenshtein).
08 — Mon intervention
- Architecture et modèle de données
- Intégration Shopify (webhooks, OAuth) et API fournisseur
- Files de tâches, planificateur et alertes
- Interface d'administration Vue 3 / Inertia
- Sécurité (signatures, clés chiffrées, limitation de débit) et tests
09 — Stack
- Backend
- PHP 8.3, Laravel 13, Laravel Queues, Scheduler
- Frontend
- Vue 3, Inertia.js, Tailwind CSS 4
- Intégrations
- Shopify (webhooks, OAuth), API fournisseur SMM, IMAP
- Données
- MySQL
- Qualité
- PHPUnit
10 — Résultats
33
tests et 101 assertions réussis
5 min
entre deux synchronisations des statuts fournisseur