Noqta
écrits/blog/2026/05
● Blog16 mai 2026·6 min

Salla à l'échelle : quand l'API plafonne — le pattern Middleware pour les marchands saoudiens 2026

Salla pèse 44% des boutiques en Arabie saoudite et 13,3 Md$ de GMV. Au-delà de 1 000 commandes/jour, l'API touche trois murs. Voici le pattern middleware éprouvé.

Anis Marrouchi
·EN · FR · AR

Salla n'est plus seulement une plateforme e-commerce — c'est l'infrastructure qui propulse plus de 68 000 marchands actifs dans le Royaume, avec 13,3 milliards de dollars de GMV traités et près de 44,11% des boutiques saoudiennes, en croissance de ~45% YoY en 2025. Un acheteur en ligne saoudien sur deux a déjà commandé sur une boutique Salla.

Ce succès produit un problème d'ingénierie très précis : dès que votre boutique dépasse ~1 000 commandes/jour, ou que vous y branchez plus de trois systèmes externes (ERP, entrepôt, outil marketing, ZATCA), l'API Salla se comporte comme toute API SaaS à la limite — les rate limits sautent, les webhooks arrivent en retard ou en double, et la synchro stock entre en collision entre canaux.

La réponse n'est pas de quitter Salla. La réponse est d'intercaler une fine couche middleware entre vous et la plateforme : routage, retries, idempotency, et adaptateurs vers vos systèmes externes. Cet article quantifie le problème, nomme les trois murs, puis livre l'architecture de référence que nous déployons sur des stacks marchands saoudiens réels.

Pourquoi Salla plafonne à l'échelle

Salla est un SaaS multi-tenant fermé qui sert 68 000 marchands sous des règles partagées — et c'est la bonne décision de leur côté. Des rate limits et quotas webhook uniformes protègent les tenants les uns des autres. Mais côté marchand en croissance, trois contraintes apparaissent que vous devez gérer architecturalement, pas en espérant qu'elles disparaissent :

  1. Rate limits. La synchro complète de l'inventaire ou la récupération de l'historique commandes atteint vite 429 Too Many Requests. Un retry naïf aggrave la situation.
  2. Fiabilité des webhooks. Salla émet des webhooks pour chaque événement (nouvelle commande, mise à jour stock, retour). Mais aucun SaaS — Salla ou autre — ne garantit la livraison exactly-once. Vous recevrez le même événement deux fois, ou pas du tout si votre endpoint tombe cinq minutes.
  3. Pas d'intégrations natives profondes. La marketplace d'apps Salla est large, mais il n'existe pas d'intégration officielle profonde bi-directionnelle avec Odoo, Zoho Books ou Salesforce. Les apps tierces couvrent 70% des cas et vous laissent le reste.

À cela s'ajoute que Salla, en tant que SaaS fermé, ne publie pas de base CVE publique. Ce n'est pas un défaut — la plupart des SaaS fonctionnent ainsi (Shopify, BigCommerce) — mais cela signifie que la couche défensive entre Salla et vos systèmes internes est votre responsabilité.

Mur n°1 : les rate limits

Cas réel : un marchand de pièces auto à Riyad, 12 000 SKUs, pousse des mises à jour de stock depuis un WMS interne toutes les 15 minutes. Le code de synchro tente de mettre à jour 12 000 produits via PUT /products/{id} dans une fenêtre serrée. Résultat : 429, retry immédiat, 429 à nouveau, et un long cool-down de rate limit.

Ce qui ne résout rien : retry sans backoff, ou multiplier les workers parallèles sur la même API key.

Ce qui le résout architecturalement :

  • Un token bucket au niveau du middleware qui plafonne les requêtes/minute avant qu'elles n'atteignent Salla.
  • Exponential backoff avec jitter sur 429 — en respectant l'en-tête Retry-After quand Salla l'envoie.
  • Batching via les endpoints en bulk quand ils existent, ou delta sync au lieu d'une full sync (ne pousser un produit que s'il a réellement changé).
  • Une priority queue : les événements de nouvelles commandes passent avant les mises à jour de description produit.

Mur n°2 : la fiabilité des webhooks

Salla émet des webhooks pour chaque événement : order.created, order.updated, product.updated. Les propriétés connues :

  • Pas de garantie exactly-once — le même événement peut arriver deux fois.
  • Si votre endpoint est lent (timeout au-delà de quelques secondes) ou répond en 5xx, la plateforme peut redélivrer ou sauter l'événement.
  • L'ordre n'est pas garanti — order.updated peut précéder order.created.

Tout endpoint qui écrit directement dans votre ERP ou envoie un email client depuis le handler du webhook est un bug qui attend la production. AWS décrit le principe sous-jacent dans Best Practices for Idempotent APIs.

Le fix :

  1. Le webhook receiver écrit l'événement brut dans une queue et retourne 200 OK en moins de 200 ms.
  2. Chaque événement porte une clé d'idempotency (par exemple order_id + event_type + timestamp) stockée dans Redis avec un TTL d'une semaine.
  3. Un worker séparé dépile la queue, vérifie la clé, puis exécute la logique métier.

Les rejeux d'événements deviennent sûrs et votre endpoint cesse de cascader quand un ERP est offline une heure.

Mur n°3 : les intégrations externes profondes

Les apps de la marketplace Salla sont bonnes pour les cas simples. Mais si vous avez besoin de :

  • Synchro commandes/retours avec Odoo (mapping SKU, comptes de taxes, centres de coûts).
  • Push de factures vers Zoho Books générant une facture conforme ZATCA Phase 2.
  • Mises à jour de stock depuis un WMS custom ou un entrepôt SAP.
  • Push des événements d'achat vers Meta Conversions API et Google Ads avec enhanced conversions.

…vous trouverez que chaque app tierce résout une tranche, casse une autre, et entre en conflit avec la suivante. Votre middleware devient la single source of truth pour ce qui sort de Salla et ce qui y rentre.

Architecture de référence : le pattern event-router

C'est l'architecture que nous déployons pour les marchands saoudiens :

                ┌─────────────────────────────┐
                │           Salla              │
                │  (Webhooks + REST API)       │
                └──────────┬───────────────────┘
                           │ HTTPS Webhooks
                           ▼
┌──────────────────────────────────────────────┐
│  1. Webhook Receiver  (HTTP, < 200 ms)       │
│     - valide la signature HMAC               │
│     - écrit l'événement brut dans la queue   │
│     - retourne 200 OK immédiatement          │
└──────────┬───────────────────────────────────┘
           │
           ▼
┌──────────────────────────────────────────────┐
│  2. Event Queue (SQS / Redis Streams)        │
│     - durable, ordonnée par partition        │
│     - DLQ pour les événements échouant N fois│
└──────────┬───────────────────────────────────┘
           │
           ▼
┌──────────────────────────────────────────────┐
│  3. Event Router + Idempotency Cache (Redis) │
│     - vérifie la clé, bloque les rejeux      │
│     - dispatch vers les adaptateurs concernés│
└──┬──────────────┬──────────────┬─────────────┘
   ▼              ▼              ▼
┌─────────┐  ┌─────────┐  ┌──────────────┐
│  ERP    │  │ WMS /   │  │  Marketing    │
│ Adapter │  │ Stock   │  │  Adapter      │
│ (Odoo / │  │ Adapter │  │ (Meta, Google,│
│  Zoho)  │  │         │  │  Klaviyo)     │
└─────────┘  └─────────┘  └──────────────┘
   │              │              │
   └──────────────┴──────────────┘
              │
              ▼
       ┌──────────────┐
       │  ZATCA Phase │
       │  2 Submitter │
       │  (Fatoora)   │
       └──────────────┘

Propriétés essentielles :

  • Receiver stateless : scale horizontalement sans coordination.
  • Queue durable : les événements survivent au crash d'un worker.
  • Idempotency au niveau opération métier : une facture n'est pas comptabilisée deux fois dans Odoo même si l'événement arrive trois fois.
  • Adaptateurs isolés : une panne Odoo n'arrête pas le push Meta Conversions API.
  • Observability : chaque événement porte un trace ID suivi de Salla jusqu'au dernier adaptateur.

Les choix techniques varient. Courant : Node.js / Hono ou Python FastAPI pour le receiver, Redis Streams ou AWS SQS pour la queue, PostgreSQL pour l'état, Docker sur un VPS en région saoudienne pour la conformité PDPL.

Cinq choses à faire AVANT d'écrire une seule ligne de middleware

Se précipiter dans le middleware crée une dette technique pire que le problème initial. Avant de commencer :

  1. Auditez l'usage actuel de l'API. Récupérez 90 jours de logs d'usage auprès de votre équipe ou de votre partenaire Salla. Quels endpoints consomment le plus ? Quand atteignez-vous 429 ?
  2. Cartographiez le modèle de données. Classez les entités — produit, commande, client, stock. Pour chaque : qui est le system of record (Salla, Odoo, WMS) ? L'ambiguïté ici est à l'origine de 80% des bugs de synchro.
  3. Définissez les clés d'idempotency. Pour chaque événement : quelle clé garantit qu'un rejeu ne double pas l'effet ? order_id pour les events commande, order_id + line_id pour les events au niveau ligne.
  4. Fixez un SLA interne. Combien de secondes acceptables entre un webhook Salla et l'apparition de la commande dans Odoo ? Cinq secondes ? Une minute ? Une heure ? Cela décide du nombre de workers et de la taille Redis.
  5. Planifiez ZATCA Phase 2 dès maintenant. La Vague 24 de l'e-invoicing couvre les entités à chiffre d'affaires SAR 375k–750k et arrive le 30 juin 2026. Si vous y êtes éligible, le submitter ZATCA doit faire partie du middleware dès le jour un. Voir notre guide ZATCA Phase 2 et le portail officiel ZATCA.

Brancher Salla aux systèmes d'entreprise est un prolongement naturel d'une stratégie d'intégration de bout en bout, et permet ensuite d'ajouter des couches AI comme le smart retail et l'AI commerce en MENA.

FAQ

Q : Ai-je vraiment besoin d'un middleware ? Les apps de la marketplace Salla ne suffisent-elles pas ? R : Sous 500 commandes/jour et avec deux intégrations externes seulement, généralement non. Au-delà de 1 000 commandes/jour, ou dès que vous câblez ERP + WMS + ZATCA + outil marketing, généralement oui. La raison n'est pas « Salla ne suffit pas » — c'est que toute API SaaS demande une couche retry/idempotency/observability à ce volume.

Q : Le middleware viole-t-il les conditions d'utilisation de Salla ? R : Non. Vous consommez l'API officielle via la doc Salla Developers. Le middleware est simplement un client API plus intelligent.

Q : Combien de temps pour le construire ? R : Un MVP (webhook receiver + queue + un adaptateur Odoo) : 3–4 semaines. La version complète avec quatre adaptateurs, submitter ZATCA et observability : 8–12 semaines.

Q : Et pour ZATCA Phase 2 ? L'option intégrée à Salla ne suffit-elle pas ? R : Pour les petites vagues à besoins simples, généralement oui. Mais si vous avez besoin d'un plan comptable personnalisé, de plusieurs journaux, ou de brancher ZATCA sur un ERP qui émet les vraies factures, le middleware est la maison naturelle du submitter.

Q : Faut-il un hébergement saoudien pour le middleware ? R : Pour la conformité PDPL complète et minimiser la latence avec Salla et ZATCA, oui — nous recommandons un VPS en région saoudienne (Riyadh) chez un prestataire agréé.

Étape suivante

Nous avons livré cette couche sur des stacks marchands saoudiens réels traitant des milliers de commandes par jour et des dizaines de milliers de SKUs, branchée sur Odoo, Zoho Books et ZATCA Phase 2.

Offre gratuite : une session de revue d'architecture de 30 minutes. Nous regardons votre usage API actuel, vos points de douleur, et esquissons votre blueprint middleware — sans engagement.

Contactez-nous pour réserver la revue.