Étude de cas · Automatisation WhatsApp

Comment l'automatisation RSVP a évolué pour 3 000+ membres

Un système RSVP WhatsApp en production pour un grand club de badminton de l'ouest londonien, construit avec une automatisation auto-hébergée, un historique d'audit PostgreSQL et une boucle d'intention IA auto-améliorante.

Grand club de badminton · Ouest de Londres
Conception et déploiement directs

Lancer le brief Retour aux systèmes récents

Défi

La gestion manuelle des RSVP était devenue coûteuse à exploiter.

Des sessions hebdomadaires sur plusieurs sites de l'ouest londonien généraient un flux constant de réponses WhatsApp qu'il fallait lire, interpréter et enregistrer manuellement avant de savoir si une place était prise.

Les membres écrivaient dans tous les formats imaginables : oui mercredi, je viens avec ma sœur, annule vendredi, de retour la semaine prochaine. L'objectif était d'automatiser tout le processus sans demander aux membres de changer de comportement ni de quitter WhatsApp.

Architecture

Le système a été construit entièrement autour d'outils opérationnels auto-hébergés.

L'API WhatsApp Business gérait la messagerie côté membres. n8n orchestrait les workflows. PostgreSQL stockait les fiches membres, l'historique RSVP, les versions de prompts et les données de correction. Un modèle local exécuté via Ollama gérait la détection d'intention. L'ensemble tournait dans Docker et était exposé de façon sécurisée via Cloudflare Tunnel.

Cela a permis de garder une stack légère en licences, contrôlée localement et exploitable sans dépendre d'une couche SaaS coûteuse pour chaque partie du workflow.

La boucle en quatre étapes

La boucle en quatre étapes a rendu l'automatisation progressivement plus fiable.

Lorsqu'un message arrivait, un webhook n8n le transmettait au modèle local, qui classait l'intention en RSVP, LIST, SESSIONS ou MENU. Le système pouvait ainsi gérer les variations du langage naturel au lieu de dépendre de règles à mots-clés fragiles.

Quand un message était mal interprété, la correction était enregistrée dans PostgreSQL. Un workflow planifié analysait ensuite les corrections récurrentes, générait un prompt amélioré, l'enregistrait dans une table de versions puis le passait en usage actif. Le système progressait en apprenant du comportement réel des membres plutôt qu'à partir d'hypothèses statiques.

Détails d'ingénierie

Plusieurs cas limites opérationnels ont dû être résolus avant que le système soit fiable.

Les réservations avec invité ne créaient au départ qu'un seul enregistrement RSVP lorsqu'un membre indiquait venir accompagné. Le workflow a été mis à jour pour itérer sur la taille du groupe détectée et créer des enregistrements distincts pour chaque participant.

Le statut d'opt-out provenant de l'API WhatsApp arrivait sous forme de chaîne plutôt que de booléen, donc un nœud de code le normalise désormais avant l'envoi de messages sortants. Les campagnes volumineuses sont limitées par lots pour rester dans les contraintes API. La synchronisation des contacts a aussi été réécrite avec des requêtes batchGet, faisant passer une synchro de 30 minutes à moins de deux minutes.

Résultat

L'expérience membre est restée identique pendant que le modèle opérationnel changeait complètement.

Les membres écrivent toujours au même numéro WhatsApp, reçoivent leurs confirmations en quelques secondes et peuvent réserver, annuler ou consulter les sessions en langage naturel. L'interface n'a pas changé ; le travail derrière, si.

Cela a transformé un travail de coordination répétitif en système de messagerie auditable, prêt pour la production. Le même schéma s'applique aux clubs, salles de sport et autres organisations gérant un fort volume de communication membres.

Prochaine étape

Besoin de quelque chose de similaire ?

Si votre activité est noyée sous les messages répétitifs, les confirmations de réservation ou la coordination de membres, cette même architecture peut être adaptée à votre workflow.

Lancer le brief Retour aux systèmes récents