Le contexte

Une fédération professionnelle bruxelloise utilisait un système membership construit autour de Zoho Billing et WordPress, avec une couche d'automatisation historique reposant sur des workflows Zoho natifs, des webhooks dispersés, des fonctions Deluge non documentées et des règles CRM superposées.

Résultat : un système fonctionnel mais fragile, avec des risques de désynchronisation entre les statuts d'abonnement Zoho et les accès WordPress, aucune traçabilité unifiée et une forte dépendance à l'intégrateur historique.

L'objectif

Reconstruire l'architecture d'automatisation autour d'un orchestrateur unique (n8n), avec un principe directeur simple : Zoho Billing décide, n8n exécute, WordPress applique.

L'enjeu : garantir que chaque changement de statut côté Zoho (paiement, renouvellement, annulation, expiration) se traduise par la bonne action sur WordPress, en temps réel, avec une traçabilité complète et un filet de sécurité quotidien.

L'architecture livrée

Quatre workflows n8n interconnectés, chacun avec un rôle clair et un périmètre maîtrisé :

WF1 — Subscription Lifecycle (temps réel)

Reçoit les webhooks Zoho Billing en temps réel selon une logique status-first : la décision est basée sur le statut de l'abonnement, pas sur le nom de l'événement. Cette approche élimine les ambiguïtés et garantit une cohérence systématique.

Le workflow normalise la requête, vérifie la signature de sécurité, extrait les données client et abonnement, puis détermine l'action d'accès à appliquer (activate, restrict, deactivate, pending, review) avant de transmettre la commande à WF5.

WF3 — Daily Reconciliation (filet de sécurité)

Tourne chaque nuit à 4h via CRON. Compare l'ensemble des abonnements Zoho Billing avec les utilisateurs WordPress, détecte les écarts (comptes manquants, accès incohérents, doublons) et applique soit une auto-correction sécurisée, soit remonte un rapport HTML aux administrateurs.

Cette redondance volontaire avec WF1 garantit qu'aucun écart ne reste plus de 24 heures sans détection, même en cas de webhook manqué.

WF5 — Member Access Control (exécutant)

Workflow central appelé par WF1 et WF3. C'est le seul endroit qui modifie WordPress, ce qui garantit une logique d'accès centralisée et prévisible. Il crée les comptes si nécessaire, applique les rôles (um_membre pour les membres actifs, subscriber pour les autres), envoie un email de bienvenue bilingue (FR/NL) via Resend, et protège les administrateurs via un mécanisme de no-op.

Un mode dryRun activé par défaut sécurise toutes les opérations en phase de test.

WF6 — Global Error Handler (gardien)

Workflow transverse qui capture les erreurs techniques de tous les autres workflows. Chaque erreur est normalisée, classée par sévérité (high/medium/low), stockée dans une Data Table dédiée avec une empreinte unique pour éviter les doublons, et déclenche une alerte immédiate sur un canal Discord dédié.

Les choix techniques structurants

• Source de vérité unique : Zoho Billing reste maître pour tout ce qui concerne les abonnements et paiements. WordPress devient un miroir strict, sans logique métier locale.
• Idempotence : chaque événement est identifié par une clé unique (SubscriptionID + EventType + Date), garantissant qu'un webhook reçu plusieurs fois n'est traité qu'une seule fois.
• Logique status-first : la décision d'accès dépend du statut de l'abonnement, pas de l'événement déclencheur. Plus robuste face aux variations de l'API Zoho.
• Centralisation des accès WP : WF5 est le seul workflow qui écrit sur WordPress. Tout passe par lui, ce qui simplifie le debugging et le contrôle.
• Filet de sécurité : WF3 rattrape automatiquement les écarts que les webhooks auraient pu rater.
• Périmètre maîtrisé : la solution ne duplique pas Zoho Billing. Les relances de paiement, le dunning, Stripe et GoCardless restent gérés nativement par Zoho.

Stack technique

• Orchestration : n8n (self-hosted, Docker)
• Source de vérité : Zoho Billing (API REST + webhooks)
• Frontend membre : WordPress + Ultimate Member
• Paiements : Stripe + GoCardless (via Zoho)
• Emails transactionnels : Resend (templates FR/NL)
• Monitoring : Discord (alertes temps réel) + PostgreSQL (Data Table d'historique)
• Base de données : PostgreSQL (workflows n8n + table workflow_error_events)

Le résultat

Un système d'automatisation lisible, documenté, exportable et reproductible. La fédération dispose désormais d'une infrastructure capable d'évoluer sans dépendance à un prestataire spécifique, avec une traçabilité complète de chaque action et une surveillance proactive des incidents techniques.

L'ensemble des workflows est exporté en JSON et reste la propriété du client, garantissant une portabilité totale.