ADR 0002 : Stratégie de récupération des adresses email manquantes (Shopify & Shifter)

• Statut : Proposé
• Date : 2026-07-13
• Auteur : Antigravity

Contexte

Le fichier de suivi logistique Tencent Docs contient des numéros de commande (Platform order number) et des numéros de tracking, mais la colonne email du client n'est pas ou peu renseignée. Pour envoyer la notification d'expédition par email, n8n doit enrichir la ligne logistique avec l'email du client. Les commandes proviennent de deux canaux de vente distincts : la boutique en ligne (gérée via Shopify) et la boutique physique (gérée via le logiciel de caisse Shifter).

Options étudiées

Option 1 : Enrichissement dynamique à la volée via requêtes API Shopify et Shifter dans n8n

À chaque déclenchement, pour chaque ligne sans email, n8n interroge en temps réel l'API de Shopify ou l'API de Shifter selon la provenance de la commande.

• Avantages :
  • Données toujours à jour issues directement des sources de vente.
  • Pas de base de données intermédiaire nécessaire pour le stockage des profils clients.
• Inconvénients :
  • Performance dégradée si le volume de commandes sans email est élevé (plusieurs milliers d'appels HTTP séquentiels).
  • Dépendance forte envers la disponibilité des API Shopify et Shifter au moment de l'exécution.
  • Risque de dépassement des limites de requêtes (rate limiting) des API externes.

Option 2 : Base de données locale de correspondance (PostgreSQL) alimentée en amont (Recommandé)

Stockage des correspondances clients dans la base de données PostgreSQL locale. n8n interroge cette table interne en priorité. Si l'email est manquant localement, n8n effectue un appel API de secours vers Shopify/Shifter, enregistre le résultat en base pour les fois suivantes, puis envoie la notification.

• Avantages :
  • Performances optimales (les données déjà connues sont lues localement en quelques millisecondes).
  • Résilience en cas d'indisponibilité temporaire des API Shopify ou Shifter.
  • Réduction drastique du nombre d'appels API vers les services tiers.
  • Permet de conserver l'historique des emails modifiés manuellement par l'équipe.
• Inconvénients :
  • Nécessite la création et le maintien d'une table clients ou correspondances_commandes en plus de la table des notifications.

Décision

L'Option 2 (Base de données locale avec fallback API) est retenue. n8n effectuera une vérification locale dans PostgreSQL. Si l'email n'est pas trouvé :

1. n8n recherchera la commande dans l'API de Shopify.
2. Si non trouvée, n8n recherchera la commande dans l'API de Shifter.
3. Si l'email est récupéré, il est inséré dans PostgreSQL pour enrichir les futures transactions et éviter les requêtes redondantes.
4. Si l'email reste introuvable, le statut est marqué comme "email_manquant" et une notification interne est générée.

Conséquences

• Positives :
  • Rapidité d'exécution du workflow n8n.
  • Robustesse de l'intégration et réduction du couplage avec les API tierces.
  • Centralisation des données de contact client dans PostgreSQL (exploitable par l'application client).
• Négatives :
  • Légère complexification de la logique du workflow n8n (ajout de branches conditionnelles et de requêtes d'insertion).
  • Nécessité d'obtenir et de configurer des clés API pour Shopify et Shifter.