Un score de santé client que personne n'a jamais confronté aux départs réels est une opinion pondérée. Il peut paraître sensé, produire des couleurs crédibles et n'avoir aucun pouvoir de détection — c'est même le cas le plus courant, puisqu'une majorité d'équipes déclare que son score ne prédit pas fiablement le churn.
Le rétro-test est l'exercice qui tranche. Il coûte quelques jours, il ne demande aucun outil particulier, et il répond à la seule question qui compte : si ce score avait tourné l'an dernier, aurait-il désigné les comptes qui sont effectivement partis, et assez tôt pour qu'on puisse agir ?
Qu'est-ce qu'un rétro-test ?
Un rétro-test consiste à recalculer le score sur une période passée, en n'utilisant que les données disponibles à cette date, puis à comparer le classement obtenu avec ce qui s'est réellement produit ensuite. La démarche tient en cinq étapes.
- Choisir une date d'observation — par exemple le 1er janvier de l'année dernière.
- Choisir une fenêtre de résultat — les six ou douze mois qui suivent cette date.
- Reconstituer l'état des données à la date d'observation, et rien d'autre.
- Calculer le score de chaque compte à cette date.
- Comparer les comptes que le score aurait signalés et ceux qui sont effectivement partis pendant la fenêtre.
La troisième étape est celle qui fait échouer la plupart des rétro-tests, et c'est aussi celle qu'on croit avoir réussie.
Les trois façons de tricher sans le savoir
1. La fuite temporelle
C'est l'erreur principale. Elle consiste à laisser entrer dans le calcul une information qui n'existait pas encore à la date d'observation. Les formes les plus fréquentes :
- Un champ mis à jour depuis. Le statut du compte dans le CRM porte aujourd'hui « perdu ». Si le calcul lit ce champ, le score « prédit » le départ parce qu'il le connaît déjà.
- L'ARR actuel plutôt que l'ARR d'alors. Un compte dont le contrat a été réduit après la date d'observation apparaît en baisse alors qu'il ne l'était pas encore.
- Les échanges postérieurs à la date. Le mail de résiliation du mois de mars ne doit pas exister dans un calcul arrêté au 1er janvier.
La vérification est simple à formuler et pénible à réaliser : chaque donnée utilisée doit porter une date, et cette date doit être antérieure à la date d'observation. Un champ sans horodatage est un champ à exclure. C'est aussi la raison pour laquelle un suivi sous tableur qui écrase ses valeurs rend tout rétro-test impossible.
2. Choisir le seuil après avoir vu le résultat
On lance le rétro-test, le seuil à 60 donne un résultat médiocre, on essaie 55, puis 52, et on garde celui qui donne le meilleur chiffre. Le score n'a alors pas été testé : il a été ajusté aux réponses.
La parade est de figer les règles avant de regarder quoi que ce soit, et, si vous avez assez de comptes, de calibrer sur une période et de vérifier sur une autre.
3. Ignorer le taux de base
Si 5 % de vos comptes partent chaque année, un score qui déclare tout le monde en bonne santé a raison 95 % du temps. Le taux de bonnes réponses est donc une mesure vide.
La question utile n'est jamais « à quelle fréquence le score a-t-il raison », mais « parmi les comptes qu'il a signalés, combien sont réellement partis, et parmi ceux qui sont partis, combien avait-il signalés ».
Pourquoi un taux de détection seul est un mensonge
Deux mesures comptent, et elles s'opposent.
| Mesure | Ce qu'elle répond | Comment on la gonfle artificiellement |
|---|---|---|
| Rappel (taux de détection) | Parmi les comptes partis, quelle part le score avait-il signalés ? | En signalant tout le monde. Un score qui met 100 % du portefeuille en alerte a un rappel parfait. |
| Précision | Parmi les comptes signalés, quelle part est réellement partie ? | En ne signalant que les cas désespérés. La précision monte, mais on détecte trois comptes sur cent. |
Annoncer l'une sans l'autre ne veut rien dire. Un éditeur qui met en avant un taux de détection de 90 % sans préciser la part du portefeuille qu'il faut mettre en alerte pour l'atteindre ne vous a rien dit. Demandez systématiquement les deux, plus la taille de la liste rouge que ça implique.
Le critère d'arbitrage est opérationnel, pas statistique : une liste d'alertes n'a de valeur que si l'équipe qui la reçoit peut la traiter. C'est la logique qui gouverne aussi le placement des seuils rouge et orange.
Le délai d'anticipation : détecter ne suffit pas
Un score qui signale un compte trois semaines avant l'échéance a techniquement raison et pratiquement tort. À ce stade, la décision est prise chez le client et le budget est réalloué.
Mesurez donc, pour chaque compte correctement détecté, le nombre de jours entre la première alerte et le départ effectif, et regardez la médiane. C'est souvent le chiffre le plus instructif du rétro-test, et le plus rarement publié.
- Moins de 30 jours — le score constate, il n'alerte pas.
- 60 à 120 jours — fenêtre exploitable pour une action de rétention.
- Plus de 180 jours — confortable, mais vérifiez la précision : un score qui alerte très tôt alerte souvent sur beaucoup de monde.
Combien d'historique faut-il ?
- Assez de départs pour que le résultat signifie quelque chose. En dessous d'une dizaine de churns avérés dans la fenêtre, un compte de différence fait bouger le taux de plusieurs points : le chiffre n'est pas interprétable.
- Assez de profondeur avant la date d'observation — six à douze mois d'échanges, faute de quoi aucune tendance n'existe et le score ne repose que sur des niveaux.
- Des données horodatées, sur toute la période. C'est la contrainte qui bloque le plus souvent : beaucoup d'équipes ont l'historique des tickets mais pas celui des échanges, ou l'ARR actuel sans ses variations.
Ce qu'un rétro-test ne prouve pas
Il ne prouve pas que le score aurait sauvé les comptes. Il montre qu'ils auraient été désignés, ce qui est une condition nécessaire et pas une condition suffisante. Signalé n'est pas sauvé : entre l'alerte et le renouvellement, il reste tout le travail de l'équipe.
Il ne prouve pas non plus que le résultat tiendra. Un modèle vérifié sur l'année dernière décrit le portefeuille de l'année dernière ; un changement d'offre, de segment ou de modèle de service peut le périmer. Un rétro-test se refait.
Enfin, il ne dit rien des comptes que le score aurait signalés et qui sont restés parce qu'on est intervenu. C'est la limite structurelle de l'exercice : comptabilisés comme faux positifs, ces cas sont pourtant exactement ce qu'on cherche à produire.
À retenir
- Un score jamais confronté aux départs réels est une opinion pondérée.
- Chaque donnée du calcul doit être horodatée antérieurement à la date d'observation.
- Figez les seuils avant de regarder les résultats, jamais après.
- Le taux de bonnes réponses est vide : demandez précision et rappel ensemble.
- Mesurez le délai médian entre l'alerte et le départ : c'est lui qui dit si le score sert.
- Signalé n'est pas sauvé. Un rétro-test mesure la détection, pas la rétention.
Questions fréquentes
Quelle durée de fenêtre choisir pour un rétro-test ?
Six à douze mois après la date d'observation, selon la durée de vos contrats. Une fenêtre plus courte que votre cycle de renouvellement contient trop peu de départs pour être interprétable.
Peut-on rétro-tester sans données historiques complètes ?
Partiellement, en limitant le test aux dimensions dont vous avez l'historique horodaté et en le disant explicitement. Un rétro-test mené sur des données incomplètes reste utile s'il annonce sa couverture ; il devient trompeur s'il la cache.
Un bon taux de détection suffit-il à valider un outil ?
Non. Demandez toujours la précision associée et la part du portefeuille qu'il faut placer en alerte pour atteindre ce taux. Un rappel de 90 % obtenu en signalant 60 % des comptes ne produit aucune priorisation.
À quelle fréquence refaire un rétro-test ?
Une fois par an, et systématiquement après un changement d'offre, de segment cible ou de modèle de service. Un score validé sur un portefeuille ne reste pas valide sur un portefeuille qui a changé de nature.
Sources et méthode. Cet article décrit une méthode d'évaluation, sans données chiffrées externes. Les repères de délai d'anticipation sont des ordres de grandeur issus de la pratique, à vérifier sur votre propre cycle de renouvellement.
Philippe Kanaan est le fondateur de marsā. Basé à Marseille.