Détecter le risque de churn client avec un score de risque IA dans n8n

La plupart des équipes découvrent qu’un client est sur le point de résilier au moment où il l’annonce — trop tard pour agir. Le signal existait pourtant des semaines plus tôt, dispersé entre l’outil de facturation, le CRM et les tickets support, mais personne n’a le temps de croiser ces trois sources compte par compte, chaque semaine. Un workflow n8n qui agrège ces signaux et calcule un score de risque par IA change cette dynamique : au lieu de découvrir le churn a posteriori, l’équipe reçoit une alerte pendant qu’il est encore possible d’agir.

Ce guide couvre le churn volontaire — un client qui se désengage puis résilie consciemment. Pour le churn involontaire (carte expirée, prélèvement refusé), la logique est différente et déjà détaillée dans notre article sur les relances de paiement échoué avec n8n et Stripe : les deux pipelines sont complémentaires, pas redondants.

Pourquoi un score composite plutôt qu’un seul indicateur

Une étude de Dias & António (2025), Predicting customer churn using machine learning: A case study in the software industry, publiée dans Journal of Marketing Analytics (page Google Scholar), a comparé plusieurs modèles de prédiction de churn sur les données d’un éditeur logiciel. Le résultat le plus utile pour construire un pipeline n’est pas le modèle le plus performant (XGBoost, dans leur cas), mais les facteurs qui pèsent le plus dans la prédiction : le délai de résolution des tickets support, l’ancienneté de la licence, le type d’application et le nombre d’incidents ouverts par le client. Aucun de ces signaux pris isolément ne suffit à prédire un départ — c’est leur combinaison qui produit un score fiable. C’est exactement ce qu’un pipeline n8n peut reproduire, sans modèle de machine learning entraîné sur mesure : un AI Agent qui pondère plusieurs signaux structurés en s’appuyant sur des règles explicites.

Vue d’ensemble du pipeline

Quatre briques : collecte planifiée des signaux par compte, calcul du score par un AI Agent avec sortie structurée, routage selon le niveau de risque, puis journalisation pour suivre l’évolution dans le temps. C’est une architecture proche de celle du scoring de tickets support, appliquée ici non pas à un ticket isolé mais à un compte client dans son ensemble, recalculée périodiquement plutôt qu’à chaque événement.

Étape 1 — Collecter les signaux de risque, compte par compte

Un node Schedule Trigger (n8n-nodes-base.scheduleTrigger), une fois par nuit ou une fois par semaine selon le volume de comptes, démarre le workflow sur la liste des abonnements actifs. Pour chaque compte, trois sources se croisent :

• Abonnement — via le node Stripe natif ou un HTTP Request sur l’API Stripe : ancienneté de l’abonnement, plan souscrit, historique récent de invoice.payment_failed, changement de plan à la baisse (downgrade).
• CRM — via le node HubSpot ou Pipedrive, comme décrit dans notre guide de synchronisation CRM avec n8n : dernière interaction commerciale, statut du compte, éventuelle mention de mécontentement dans les notes.
• Support — nombre de tickets ouverts sur les 30 derniers jours et délai moyen de résolution, exactement les signaux mis en avant par l’étude citée plus haut. Si votre support tourne déjà sur le pipeline de scoring de tickets, ces données sont probablement déjà journalisées dans une table Supabase et une simple requête suffit à les récupérer.

Un node Merge rassemble ces trois flux par identifiant de compte, puis un Set normalise le tout en un objet unique : id_compte, anciennete_jours, plan, paiements_echoues_90j, tickets_ouverts_30j, delai_resolution_moyen_h, derniere_interaction_commerciale.

Étape 2 — Calculer le score avec un AI Agent et une sortie structurée

Un node AI Agent (@n8n/n8n-nodes-langchain.agent) reçoit cet objet normalisé et produit un score via un Structured Output Parser (@n8n/n8n-nodes-langchain.outputParserStructured). Si le node AI Agent vous est encore peu familier, notre guide pour débuter avec les nodes IA de n8n couvre sa configuration de base. Le schéma de sortie attendu :

• score_risque — entier de 0 à 100
• niveau — enum fermé (faible, moyen, eleve, critique)
• facteurs — liste des signaux ayant le plus pesé dans le score
• action_recommandee — une phrase factuelle (relance informative, appel CSM, aucune action)

Le prompt système doit fixer un barème explicite, à l’image de ce que révèle l’étude : un délai de résolution qui s’allonge, une ancienneté encore courte combinée à des tickets répétés, ou un downgrade récent pèsent plus lourd qu’un simple silence commercial. Précisez aussi que le modèle doit justifier chaque score dans le champ facteurs — un score critique sans justification claire doit rester suspect pour l’équipe qui relit la file, exactement comme pour le scoring de tickets.

Étape 3 — Router selon le niveau de risque

Un node Switch dirige selon niveau :

• critique ou eleve — une alerte Slack part vers le canal Customer Success avec le score, les facteurs et un lien direct vers la fiche compte CRM ; en parallèle, une tâche est créée dans HubSpot ou Pipedrive pour qu’un CSM humain prenne le relais. C’est le même réflexe que l’alerte d’urgence du Pack Inbox IA (79 €) — router l’attention humaine vers ce qui compte, sans automatiser la décision elle-même.
• moyen — une séquence de relance informative automatique (contenu d’aide, invitation à un appel de suivi) peut partir sans intervention humaine, sur le même principe que les relances automatiques de dossiers incomplets du Pack Conformité & Audit.
• faible — le score est simplement journalisé, aucune action déclenchée.

Aucune de ces branches ne doit appliquer une remise, un geste commercial ou une modification de contrat automatiquement : ce type de décision reste entre les mains d’un humain, avec le pattern d’approbation humaine via un node Wait et Slack si vous voulez tout de même préparer une proposition avant validation.

Étape 4 — Journaliser pour suivre l’évolution, pas seulement l’instant T

Un score isolé dit peu de chose ; sa tendance en dit beaucoup plus. Chaque exécution écrit le score du jour dans une table Supabase (historique_scores_churn : id_compte, score, niveau, date), comme décrit dans notre guide de connexion n8n à Supabase. Avant d’envoyer une alerte, le workflow interroge cette table pour vérifier qu’aucune alerte n’a déjà été envoyée récemment pour ce compte, ou que le score a suffisamment progressé pour justifier une nouvelle relance — sans quoi un compte à risque stable en eleve finirait par générer une alerte identique chaque semaine, jusqu’à ce que plus personne ne les lise.

Cette table sert aussi de piste d’audit : qui a été alerté, quand, sur quels facteurs. Le même réflexe de traçabilité que celui détaillé dans notre article sur la piste d’audit RGPD avec n8n et Supabase, particulièrement utile puisque ces données croisent facturation, support et informations commerciales sur des personnes identifiées.

Limites à connaître avant la mise en production

• Le score est une aide à la décision, pas un verdict. Un compte scoré critique mérite un appel humain qui confirme ou infirme le diagnostic, pas une action automatique irréversible.
• La qualité du score dépend de la qualité des données sources. Un CRM mal renseigné ou un outil de ticketing mal branché produit un score bruité ; commencez par fiabiliser la collecte avant d’ajuster le prompt.
• Un modèle générique n’est pas un modèle de machine learning entraîné sur votre historique de churn réel. Cette approche par AI Agent et règles explicites offre un bon point de départ, rapide à mettre en place ; si votre volume de comptes le justifie, un modèle statistique dédié (comme ceux comparés dans l’étude citée) peut affiner encore le score par la suite.

Check-list de mise en route

• Schedule Trigger nocturne ou hebdomadaire selon le volume de comptes actifs.
• Trois sources croisées au minimum : abonnement (Stripe), CRM, support — usage produit en bonus si disponible.
• AI Agent avec sortie structurée : score, niveau, facteurs justificatifs, action recommandée.
• Switch qui alerte un humain sur les niveaux élevés, sans jamais automatiser une décision commerciale.
• Historique des scores journalisé dans Supabase, avec anti-doublon d’alerte sur les comptes déjà signalés récemment.

Un score de risque de churn bien construit ne remplace pas une équipe Customer Success — il lui évite de découvrir un départ après coup, en lui donnant le même point de départ qu’un CSM chevronné qui croise ces signaux instinctivement. La même architecture — collecte multi-source, AI Agent structuré, routage, journalisation — se retrouve dans les workflows des packs FlowKit ; le Bundle FlowKit Complet (269 € au lieu de 347 €) réunit les trois packs si vos automatisations couvrent aussi les emails entrants et la conformité documentaire.