> For the complete documentation index, see [llms.txt](https://docs.flycode.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flycode.com/docs/fr/guides/priority-recovery-and-dynamic-recovery-handling-high-value-failed-invoices.md). # Récupération prioritaire et récupération dynamique : gestion des factures impayées à forte valeur {% hint style="info" %} **TL;DR :** Toutes les factures impayées ne méritent pas le même effort. Priority Recovery met en avant les factures en échec qui valent le plus (évaluées selon l’ARR, la valeur vie client, l’ancienneté et le coût d’acquisition) et les récupère par e-mail, SMS et alertes adressées au responsable de compte. Dynamic Recovery prolonge la fenêtre de recouvrement pour les clients qu’il vaut la peine de poursuivre plus longtemps, traite toutes les factures ouvertes d’un client comme un seul effort et évite de créer des factures en double. Les règles de Subscription Lifecycle déterminent ensuite, par produit et par segment, ce qui se passe lorsque le recouvrement échoue : annuler, invalider ou laisser en souffrance. {% endhint %} *Par l’équipe FlyCode. Dernière révision en septembre 2026.* {% hint style="success" %} **Points clés à retenir** * Un calendrier de relance fixe et une date d’annulation fixe traitent de la même manière un abonnement mensuel à 29 dollars et un contrat annuel à 30 000 dollars. Le recouvrement fondé sur la valeur ne le fait pas. * Priority Recovery attribue un score à chaque facture en échec selon l’ARR, la LTV, l’ancienneté et le CAC, puis transmet le haut de la liste au suivi humain tandis que l’automatisation gère le reste. * Dynamic Recovery allonge ou raccourcit la fenêtre de recouvrement selon le client, regroupe plusieurs factures ouvertes en un seul recouvrement et empêche le problème de factures en double créé par les relances manuelles. * Les règles de cycle de vie sont définies sans code, par produit et par segment, afin qu’un plan entreprise puisse rester en souffrance pendant 60 jours tandis qu’un plan grand public est annulé après 21. {% endhint %} ## Le problème d’un même calendrier pour tout le monde Les paramètres par défaut du processeur appliquent un seul calendrier de relance et une seule règle d’annulation à chaque abonnement. C’est acceptable pour un produit grand public homogène, et inadapté à quiconque propose des plans mixtes. Il en résulte trois modes d’échec : * **Les factures à forte valeur reçoivent la même attention que celles à faible valeur.** Une facture d’entreprise annuelle en échec se retrouve dans la même file qu’un module complémentaire à 9 dollars en échec, avec les mêmes trois e-mails. * **Le recouvrement s’arrête à une date du calendrier, pas selon la probabilité.** Les clients fidèles depuis longtemps, avec un bon historique de paiement, sont annulés au 21e jour comme tout le monde, alors même que leur probabilité de recouvrement est bien plus élevée. * **L’intervention manuelle crée des doublons.** Lorsqu’un responsable de la réussite client remarque une facture en échec et demande à la facturation d’« envoyer une nouvelle facture », le client se retrouve avec deux factures ouvertes et n’en paie aucune. ## Priority Recovery Priority Recovery classe les factures ouvertes en échec selon leur valeur pour l’entreprise et dirige les premières de la liste vers les canaux les plus susceptibles de les clôturer. | Entrée du score | Pourquoi c’est important | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **ARR de l’abonnement** | Le revenu direct en jeu. | | **Valeur vie client** | La valeur restante prédite, de sorte qu’un client au début d’une longue relation soit mieux classé qu’un client susceptible de churner rapidement. | | **Ancienneté** | Les clients de longue date se récupèrent à des taux plus élevés et méritent une intervention humaine. | | **CAC** | Perdre un client qui a coûté cher à acquérir est plus coûteux que ne le suggère la facture. | Actions dans la liste prioritaire : les séquences automatisées d’e-mails et de SMS se poursuivent, et le responsable de compte ou le customer success manager reçoit une alerte avec la facture, le motif du refus et l’étape suivante recommandée, afin que la prise de contact puisse être personnalisée (un appel, un message Slack au champion du client, une correction du bon de commande) pendant que le reste du portefeuille est géré automatiquement. ## Dynamic Recovery Dynamic Recovery modifie la durée et l’étendue du recouvrement pour chaque client. 1. **Des fenêtres prolongées pour les bons clients.** Au lieu d’un nombre de jours fixe, la fenêtre de recouvrement est prolongée pour les clients dont la valeur et l’historique de paiement le justifient, et raccourcie lorsque le modèle ne voit aucune voie de recouvrement (par exemple un refus ferme sans moyen de paiement de secours et sans engagement par e-mail). 2. **Un seul effort sur chaque facture ouverte.** Lorsqu’un client a plusieurs factures ouvertes (un renouvellement plus des frais d’utilisation, ou deux mois d’échecs), le recouvrement les traite comme un seul cas : une seule séquence de messages, un seul lien de mise à jour de carte, et le règlement de toutes les factures ouvertes lorsqu’un moyen de paiement fonctionne. 3. **Pas de factures en double.** Les relances et les paiements sont effectués sur la facture ouverte existante ; aucune nouvelle facture n’est créée pour « relancer », de sorte que le client ne voit jamais deux factures pour une même période. ## Règles de Subscription Lifecycle Lorsque le recouvrement est épuisé, quelque chose doit arriver à l’abonnement. Les règles de cycle de vie rendent cette décision explicite, par produit et par segment, sans code : | Résultat | Quand l’utiliser | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Annuler** | Les plans grand public et les abonnements à faible valeur pour lesquels l’accès continu sans paiement représente un coût. | | **Invalider la facture** | Les cas où vous préférez conserver l’abonnement et abandonner la période plutôt que perdre le client (par exemple un client de longue date pendant un remplacement de carte). | | **Laisser en souffrance** | Les plans B2B et entreprise où les délais d’achat sont fréquents et où l’accès doit se poursuivre pendant que la finance règle le paiement. | Les règles peuvent différer selon le produit (entreprise versus en libre-service), selon le segment (ancienneté, région, valeur du plan) et selon le type de refus, et elles s’appliquent de manière cohérente au lieu de dépendre de la personne qui a remarqué l’échec. ## Mise en pratique : un exemple B2B Un renouvellement annuel de 24 000 dollars échoue avec `do_not_honor` sur une carte d’entreprise. La facture se classe tout en haut de la liste prioritaire. L’automatisation réessaie au meilleur moment prévu et envoie un e-mail personnalisé au contact de facturation ; le gestionnaire de compte reçoit une alerte et contacte le champion du client, qui explique que la limite de carte a été atteinte. Le client ajoute un prélèvement bancaire comme moyen de secours via le lien de mise à jour ; la facture ouverte est payée, aucune facture en double n’a été créée et, comme la règle de cycle de vie pour les plans entreprise est « laisser en souffrance pendant 60 jours », l’accès n’a jamais été interrompu. ## FAQ ### Priority Recovery est-il réservé aux plans entreprise ? Non. Il classe toutes les factures en échec ; la différence concerne ce qui se passe en haut de la liste. Les entreprises grand public l’utilisent pour repérer des concentrations inhabituelles (une grande cohorte qui échoue en même temps) et leurs abonnés à la plus forte LTV. ### Le fait de prolonger la fenêtre de recouvrement enfreint-il les limites de relance des réseaux de cartes ? Non. Le nombre de relances reste conforme aux règles de Visa et Mastercard, quelle que soit la durée de la fenêtre. Une fenêtre plus longue répartit moins de tentatives, mieux synchronisées, et s’appuie davantage sur des moyens de secours et sur la prise de contact. Voir [les règles de nouvelle tentative du réseau de cartes](/docs/fr/read-more/card-network-retry-rules-for-failed-payments-visa-and-mastercard.md). ### Les règles de cycle de vie peuvent-elles être différentes pour les essais ? Oui. Les conversions d’essai sont un cas courant pour une fenêtre plus courte et un résultat d’annulation, tandis que les renouvellements payants conservent une fenêtre plus longue. ## Connexe * [Comment fonctionne FlyCode](/docs/fr/guides/how-flycode-works-architecture-of-the-recovery-engine.md) * [Coût des paiements échoués et ROI du recouvrement](/docs/fr/failed-payment-cost-recovery-roi.md) * [Guide 2026 de gestion des relances](/docs/fr/dunning-management-2026-guide.md) * [Gestion des paiements échoués](https://help.flycode.com/handling-failed-payments) dans le centre d’aide --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.flycode.com/docs/fr/guides/priority-recovery-and-dynamic-recovery-handling-high-value-failed-invoices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.