> 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/how-flycode-works-architecture-of-the-recovery-engine.md). # Comment fonctionne FlyCode : architecture du moteur de récupération {% hint style="info" %} **TL;DR :** FlyCode se connecte à votre plateforme de facturation (Stripe, applications d’abonnement Shopify, Braintree, PayPal, Chargebee), lit chaque paiement échoué et ses signaux de refus, décide pour chaque facture de la suite à donner (nouvelle tentative à un moment précis, débit d’une carte de secours, routage vers un autre prestataire, ou contact du client), puis indique le revenu incrémental récupéré au-delà de votre base de référence précédente. Un seul système gère l’ensemble de la décision de recouvrement, donc rien ne vient se superposer aux nouvelles tentatives de votre processeur. {% endhint %} *Par l’équipe FlyCode. Dernière révision en septembre 2026.* {% hint style="success" %} **Points clés à retenir** * FlyCode remplace le moteur de nouvelles tentatives au lieu d’ajouter des essais par-dessus. Les nouvelles tentatives intégrées de votre processeur et les e-mails de relance sont désactivés afin qu’une seule couche coordonnée décide de chaque tentative sur une carte. * Les décisions sont prises par marchand, et non à partir d’une moyenne globale : le modèle est entraîné sur vos propres raisons de refus, les réponses des émetteurs, les schémas BIN, les types de cartes, la géographie et les signaux de cycle de solde, en utilisant plus de 100 points de données par transaction ainsi que les données du réseau Visa et Mastercard. * Le recouvrement silencieux passe en premier (nouvelles tentatives et moyens de paiement de secours). Les clients ne sont contactés que lorsque le réseau a réellement besoin qu’ils agissent, et chaque message est séquencé avec les nouvelles tentatives afin que personne ne reçoive d’e-mail à propos d’un débit sur le point de réussir. * La configuration prend quelques minutes, aucune intervention d’ingénierie n’est requise, et la tarification correspond à un pourcentage du revenu récupéré au-dessus de votre base de référence mesurée. {% endhint %} ## Les quatre couches Chaque paiement échoué passe par les mêmes quatre couches. Les comprendre explique pourquoi les chiffres de recouvrement de FlyCode diffèrent d’un calendrier fixe de nouvelles tentatives. | Niveau | Ce qui se passe | D’où viennent les données | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1. Entrées** | FlyCode reçoit la facture en échec, le code de refus du processeur, le code brut de réponse du réseau, l’émetteur, le BIN et le type de carte, le montant, la devise, l’historique client et le fuseau horaire. | Les webhooks de la plateforme de facturation et les lectures d’API (pour Stripe : les quatre appels listés dans le [Guide d’intégration Stripe](/docs/fr/integrations/stripe-integration-guide-for-flycode.md)) ainsi que les données du réseau de cartes. | | **2. Prise de décision** | Un modèle par marchand classe l’échec (réversible, irréversible, authentification, fraude), prédit quand et comment une nouvelle tentative a le plus de chances d’être approuvée, et évalue la facture selon sa valeur. | Votre propre historique de transactions, plus les apprentissages inter-marchands de FlyCode et les signaux du réseau Visa et Mastercard. | | **3. Actions** | Nouvelle tentative adaptative au moment choisi, tentative via un moyen de paiement de secours, orchestration du paiement vers un autre processeur, puis e-mail ou SMS de recouvrement si le client doit intervenir. | Exécuté via la plateforme de facturation afin que la facture, l’abonnement et les reçus restent synchronisés. | | **4. Reporting** | Le revenu récupéré est attribué par rapport à la base de référence d’avant FlyCode ; le tableau de bord affiche le taux de recouvrement, le recouvrement incrémental, les tentatives par recouvrement et l’entonnoir de contact. | Tableau de bord FlyCode et rapports périodiques. | ## Couche 1 : ce que lit FlyCode Un paiement échoué contient plus d’informations que le code que vous voyez dans le tableau de bord de votre processeur. La banque émettrice renvoie un code de réponse brut, le réseau le standardise, et le processeur le traduit à nouveau (par exemple `generic_decline` dans Stripe peut masquer une douzaine de décisions bancaires). FlyCode capture toute la chaîne et ajoute un contexte que le processeur n’utilise pas : l’historique de comportement de l’émetteur envers votre compte marchand, la plage BIN et le type de produit de la carte (crédit, débit, prépayée), l’historique de paiement du client chez vous, le jour du mois par rapport aux cycles de paie habituels, et l’heure locale. FlyCode ne traite jamais de numéros de carte bruts. Les débits sont exécutés par votre processeur sur les moyens de paiement déjà enregistrés chez lui. ## Couche 2 : comment la décision est prise Le cœur de FlyCode est un modèle d’apprentissage automatique par marchand. Un modèle global (du type de celui qu’exécute un processeur sur des millions d’entreprises) optimise pour le marchand moyen. Un modèle par marchand apprend, par exemple, que vos clients chez un émetteur donné approuvent à 9 h, heure locale, le deuxième jour après un échec, ou que `do_not_honor` à partir d’une plage BIN donnée se comporte comme un manque de fonds. Le modèle répond à trois questions pour chaque facture ouverte : 1. **Cette facture peut-elle être récupérée par une nouvelle tentative ?** Les refus souples (fonds insuffisants, émetteur indisponible, erreurs de traitement, la plupart des refus génériques) le sont généralement. Les refus définitifs (identifiants invalides ou remplacés, carte volée ou perdue, compte fermé) ne le sont pas, et les réessayer gaspille des tentatives réseau. La [référence des codes de refus](/docs/fr/read-more/stripe-decline-codes-reference-meaning-soft-or-hard-and-what-to-do.md) répertorie chaque code. 2. **Quel est le meilleur moment pour la prochaine tentative ?** Le moment est choisi par facture, et non selon un calendrier fixe à 3, 5, 7 jours, et toujours dans les limites de Visa et Mastercard (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)). 3. **Quelle est la valeur de la facture à poursuivre ?** L’évaluation de la valeur (ARR, valeur vie client, ancienneté, coût d’acquisition) décide de la durée du recouvrement et de savoir si la facture est transmise à un humain via [Priority Recovery](/docs/fr/guides/priority-recovery-and-dynamic-recovery-handling-high-value-failed-invoices.md). ## Couche 3 : les actions, dans l’ordre 1. **Nouvelles tentatives adaptatives.** La nouvelle tentative est programmée au meilleur moment prévu pour cette carte et cet émetteur. Le nombre de tentatives reste dans les limites du réseau et un seul calendrier coordonné remplace les nouvelles tentatives par défaut du processeur. 2. **Moyens de paiement de secours adaptatifs.** Lorsque la carte principale échoue et que le client a d’autres moyens de paiement valides enregistrés, FlyCode débite le meilleur suivant, sans action du client. Voir [Moyens de paiement de secours sur Stripe](/docs/fr/guides/backup-payment-methods-on-stripe-for-subscription-recovery.md). 3. **Orchestration des paiements.** Pour les marchands utilisant plus d’un processeur, l’agent d’orchestration sans code peut router un débit échoué vers un fournisseur ayant une probabilité d’approbation plus élevée. 4. **Contact de recouvrement.** Ce n’est que lorsque le refus nécessite une action du client (nouvelle carte requise, authentification requise) que FlyCode envoie un e-mail ou [SMS](/docs/fr/guides/recovery-sms-when-to-add-sms-to-failed-payment-outreach.md) de marque depuis votre domaine, à l’heure locale du client, avec un lien de mise à jour sans connexion. Les messages sont retenus pendant qu’une nouvelle tentative est en attente. Voir la [collection de contact du Centre d’aide](https://help.flycode.com/failed-payment-outreach). 5. **Règles du cycle de vie.** Lorsque le recouvrement est épuisé, vos règles décident de ce qui se passe par produit et par segment : annuler, invalider ou laisser en retard de paiement. Les annulations pour non-paiement peuvent déclencher [Réactivation](/docs/fr/guides/reactivation-winning-back-customers-cancelled-for-non-payment.md). ## Mesures de protection * **Pas de double relance.** Sur Recharge, Skio, Stay AI et Chargebee, des garde-fous orientent les paiements échoués vers FlyCode et synchronisent les débits récupérés en retour, afin que la relance native et FlyCode n’envoient jamais de message deux fois au même client. Détails pour Shopify dans [Comment FlyCode gère les paiements d’abonnement Shopify échoués](/docs/fr/integrations/how-flycode-handles-shopify-subscription-failed-payments.md). * **Conformité réseau.** Les volumes de tentatives et les codes de non-réessai suivent les règles Visa et Mastercard, ce qui protège votre taux d’autorisation au premier essai. * **La base de référence d’abord.** Vos performances de recouvrement avant FlyCode sont mesurées afin que le gain incrémental, et les frais, soient calculés par rapport à un chiffre réel. Voir [explication du modèle tarifaire](/docs/fr/read-more/flycode-pricing-model-explained.md). * **Contrôles de mise en production.** Les intégrations démarrent en mode surveillance ; le recouvrement est activé une fois que les paramètres côté plateforme (nouvelles tentatives natives, e-mails natifs) sont alignés. ## À quoi ressemblent les résultats Parmi les résultats publiés chez les clients, les équipes qui passent des nouvelles tentatives par défaut du processeur constatent une hausse de 16 à 25 points du taux de recouvrement et une augmentation de 5 à 9 % de l’ARR ; par rapport aux outils de relance hérités, la hausse est de 25 à 40 %. Exemples : Capsho 63 à 91 % de recouvrement, Gardencup 62 à 82 % avec une hausse de 20 % de LTV, BUBS Naturals 51 à 66 % en un mois, GitBook +8 % d’ARR. Voir [Coût des paiements échoués et ROI du recouvrement](/docs/fr/failed-payment-cost-recovery-roi.md) pour le modèle derrière ces chiffres et [les benchmarks par segment](/docs/fr/read-more/involuntary-churn-benchmarks-by-segment.md) pour la liste complète. ## FAQ ### FlyCode remplace-t-il Stripe Smart Retries ou fonctionne-t-il à leurs côtés ? FlyCode les remplace. Pendant la configuration, les nouvelles tentatives automatiques et les e-mails d’échec de paiement de Stripe sont désactivés afin qu’un seul moteur coordonné décide de chaque tentative. Des nouvelles tentatives superposées provenant de deux systèmes sont interprétées par les émetteurs comme une activité non coordonnée et peuvent faire baisser les taux d’autorisation. ### FlyCode stocke-t-il les numéros de carte ? Non. Les débits sont exécutés par votre processeur sur les moyens de paiement déjà stockés chez lui. FlyCode travaille avec des jetons, des objets facture et abonnement, ainsi que des données de refus. ### Combien de temps faut-il pour que FlyCode soit en ligne ? La plupart des marchands se connectent en quelques minutes (installation de l’application Stripe, application de marketplace Recharge ou marketplace Skio) et constatent une hausse mesurable en un à deux cycles de facturation. ### FlyCode fonctionne-t-il aussi bien pour le B2B que pour le B2C ? Oui. Comme le modèle s’adapte par marchand plutôt que par catégorie, il est utilisé par des marques d’abonnement SaaS, B2B, fintech et DTC. Hausses publiées par segment : 27 % B2C, 19 % B2B, 26 % DTC, 23 % entreprises IA (par rapport à l’outil précédent). ## Connexe * [Qu’est-ce que FlyCode ?](/docs/fr/introduction/what-is-flycode.md) * [Plateformes de paiement et d’abonnement prises en charge](/docs/fr/integrations/supported-payment-and-subscription-platforms.md) * [Guide complet de Stripe Smart Retries](/docs/fr/stripe-smart-retries-complete-guide.md) * [Référence des métriques et du reporting de recouvrement](/docs/fr/read-more/recovery-metrics-and-reporting-reference.md) * [Comment l’IA de FlyCode décide-t-elle quand réessayer ?](https://help.flycode.com/ai-powered-payment-recovery) 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/how-flycode-works-architecture-of-the-recovery-engine.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.