Suivre les conversions d'affiliation, c'est répondre à une question précise : quel affilié a amené le client qui vient de payer ? Une erreur sur ce point, et vous payez une commission au mauvais affilié — ou vous ne payez rien du tout, et l'affilié qui vous a envoyé un client ne peut pas le prouver. La difficulté n'est pas la fraude. D'après notre expérience, les programmes d'affiliation perdent bien plus d'argent à cause de lacunes dans l'infrastructure de tracking qu'à cause de déclarations frauduleuses. La perte est silencieuse : pas d'erreur, pas d'alerte, juste une attribution qui ne s'est jamais formée. Ce guide couvre les trois méthodes pour suivre les conversions d'affiliation, comment choisir entre elles, et comment implémenter chacune avec du code concret. Si vous voulez comprendre *pourquoi* le tracking se casse — les cinq points de défaillance qui font perdre 15 à 30 % des conversions — lisez d'abord [l'article de diagnostic sur les pannes de suivi d'affiliation](/fr/blog/suivi-affiliation-fonctionnement-pannes-corrections). Cet article reprend là où celui-ci s'arrête : à l'implémentation. --- ## Les trois méthodes pour suivre les conversions d'affiliation ### Méthode 1 : le cookie first-party Un prospect clique sur un lien d'affilié. Votre serveur lit le code d'affilié dans le paramètre de l'URL et écrit un cookie first-party — émis par votre propre domaine, pas par le domaine d'une plateforme tierce — dans le navigateur. Ce cookie persiste jusqu'à son expiration ou jusqu'à ce que l'utilisateur nettoie ses données. Au moment de la conversion, votre gestionnaire d'inscription ou de paiement lit le cookie, récupère l'identifiant de l'affilié, et le stocke dans l'enregistrement utilisateur. C'est la méthode de base. Elle fonctionne de manière fiable quand l'acheteur utilise le même navigateur sur le même appareil du clic jusqu'à l'achat. Elle se casse sous Safari ITP, avec les bloqueurs de publicités, et lors des parcours multi-appareils. ### Méthode 2 : le postback serveur-à-serveur (S2S) Au lieu de s'appuyer sur le navigateur, le serveur du marchand envoie un POST HTTP directement vers l'endpoint de la plateforme d'affiliation quand un événement de conversion se déclenche. Aucun navigateur n'est impliqué. Le signal de conversion circule de serveur à serveur. Le postback S2S est le standard dans les réseaux de performance marketing. Il exige que le lien de tracking de l'affilié insère un identifiant de clic unique — `clickid` ou équivalent — dans l'URL de destination, que votre serveur capture et stocke cet identifiant à l'atterrissage, et que votre logique de confirmation puisse retrouver l'identifiant de clic au moment de la conversion pour construire l'URL de postback. Le S2S est immunisé contre les bloqueurs et ITP parce qu'aucun JavaScript ne s'exécute côté navigateur pour le signal de conversion. Sa faiblesse est la complexité de configuration et l'obligation que les identifiants de clic persistent côté serveur tout au long du tunnel. ### Méthode 3 : les métadonnées du processeur de paiement (natif Stripe) La méthode la plus robuste pour les SaaS sur Stripe consiste à porter l'identifiant de session de l'affilié directement dans l'objet de paiement Stripe en tant que métadonnées, puis à traiter les conversions depuis les événements webhook. Quand un prospect atterrit sur votre site via un lien d'affilié, un cookie stocke l'identifiant de session. Quand cette session atteint le paiement, votre backend lit l'identifiant depuis le cookie et l'attache à l'objet Stripe — PaymentIntent, Checkout Session ou Subscription — en métadonnées. Stripe déclenche un webhook à la confirmation du paiement. Votre backend lit les métadonnées dans le payload du webhook et crée la commission. L'état du navigateur au moment du paiement n'a plus d'importance. C'est le tracking server-side : l'attribution vit dans l'infrastructure Stripe, pas dans un cookie. --- ## Tableau comparatif | Méthode | Fiabilité | Résistance à Safari ITP et aux bloqueurs | Complexité d'implémentation | |---|---|---|---| | Cookie first-party | Moyenne — tombe sur Safari, bloqueurs, cross-device | Non | Faible | | Postback serveur-à-serveur | Élevée — pas de dépendance navigateur à la conversion | Oui | Moyenne | | Métadonnées Stripe (server-side) | Élevée — l'attribution vit dans Stripe | Oui | Faible à moyenne (avec un SDK) | En pratique, la configuration la plus résiliente superpose les deux premiers signaux : un cookie first-party capture la session au clic, et l'identifiant de session est écrit dans les métadonnées Stripe au paiement. Si le cookie a été bloqué, un mécanisme de secours cross-device (voir la section attribution ci-dessous) offre un deuxième chemin. --- ## Attribution : fenêtre, modèle et secours cross-device ### La fenêtre d'attribution La fenêtre d'attribution est la période durant laquelle un clic peut générer une commission. Un clic au jour 1 dans une fenêtre de 90 jours peut créditer une conversion au jour 88. Un clic au jour 1 dans une fenêtre de 30 jours ne peut pas créditer une conversion au jour 35. La fenêtre doit correspondre à votre cycle de vente, pas à une valeur par défaut de plateforme. L'[article de diagnostic sur le suivi d'affiliation](/fr/blog/suivi-affiliation-fonctionnement-pannes-corrections) rapporte un délai médian de 28 jours entre le premier clic et la première transaction payante dans les programmes SaaS B2B — mais c'est une médiane, pas un plafond. 20 % des conversions arrivent après le jour 45. Une fenêtre de 30 jours perd structurellement cette queue de distribution. RefCampaign utilise une fenêtre d'attribution de 90 jours. Le cookie first-party `_rc_sid` est posé avec une expiration de 90 jours au moment du clic. ### Le modèle d'attribution Le modèle par défaut est le dernier clic : le dernier lien d'affilié cliqué avant la conversion reçoit 100 % de la commission. Le dernier clic est simple à implémenter, facile à auditer, et aligne la commission sur l'événement de conversion. C'est le bon défaut pour la plupart des programmes SaaS. Le dernier clic a une faiblesse connue : il récompense les affiliés qui interceptent en bas du tunnel — sites de coupons, plateformes de cashback — au détriment de ceux qui ont introduit le produit. Si votre mix d'affiliés inclut une part significative de créateurs de contenu travaillant en haut du tunnel, évaluez si les incitations du dernier clic correspondent au trafic que vous voulez attirer. ### Le secours cross-device via email haché L'attribution cross-device adresse le scénario où un utilisateur clique sur un lien d'affilié depuis un appareil et complète son inscription ou son achat depuis un autre. Le cookie écrit sur l'appareil A n'existe pas sur l'appareil B. La solution consiste à relier l'enregistrement du clic à un signal d'identité indépendant de l'appareil. L'email est l'option la plus pratique. Après la connexion ou l'inscription, quand l'email de l'utilisateur est connu, votre couche de tracking hache l'email côté client et l'attache à l'enregistrement de clic d'origine. Si une conversion arrive sur un second appareil sans cookie `_rc_sid`, le système peut retrouver les enregistrements de clics précédents associés à ce hash d'email. Ce mécanisme de secours couvre le pattern B2B où les prospects recherchent sur des appareils personnels et achètent sur des postes professionnels — ce qui représente, d'après notre expérience, 8 à 12 % des conversions non attribuées dans les programmes avec des essais de plus de 14 jours. --- ## Les signaux anti-fraude La lutte anti-fraude dans le tracking d'affiliation est un problème de détection, pas de blocage. Le blocage automatique crée des faux positifs — des affiliés légitimes qui génèrent du vrai trafic depuis des patterns inhabituels se retrouvent exclus, et vous ne savez jamais que vous avez perdu la conversion. La bonne posture est de signaler les comportements suspects et de les soumettre à une revue humaine. Le marchand décide. | Signal | Ce qu'il indique | |---|---| | Clics répétés depuis la même IP à quelques secondes d'intervalle | Bot ou inflation de clics | | Une IP générant des dizaines de clics sur une courte fenêtre | Trafic automatisé | | Intervalle clic-conversion inférieur à 5 minutes | Bot complétant le tunnel d'inscription | | Taux de conversion très au-dessus de la moyenne du programme pour un seul affilié | Auto-parrainage probable ou trafic acheté | | Intervalles de clics réguliers et quasi identiques | Génération de clics scriptée | Signalement, pas blocage. Chaque conversion signalée reste dans la file. Le marchand revoit et approuve ou rejette. --- ## Implémenter le suivi de conversions avec RefCampaign Cette section détaille les quatre étapes d'implémentation. Le code est exact pour RefCampaign SDK v2 et les versions actuelles de l'API Stripe. ### Étape 1 : charger le script de tracking Placez cette balise dans le `` de votre site marketing et de votre application. Elle initialise la session de tracking au chargement de la page, capture la valeur `_rc_sid` depuis les liens d'affiliés et pose le cookie first-party. ```html ``` Le script est chargé depuis `sdk.refcampaign.com`, un sous-domaine first-party de l'infrastructure de RefCampaign. Votre domaine de tracking est séparé — le lien de tracking (`https://track.refcampaign.com/CODE_AFFILIE`) est ce que les affiliés partagent, et il pose le cookie `_rc_sid` en leur nom sur votre domaine. ### Étape 2 : transmettre la session à Stripe au paiement Lisez le cookie `_rc_sid` côté serveur au moment de la création du paiement et attachez-le à l'objet Stripe en métadonnées sous la clé `refcampaign_session`. Pour les paiements uniques via PaymentIntent : ```ts const paymentIntent = await stripe.paymentIntents.create({ amount: 2400, currency: 'eur', metadata: sessionId ? { refcampaign_session: sessionId } : {}, }) ``` Pour les abonnements via Checkout Session, attachez les métadonnées à la fois à la session et à `subscription_data` — les métadonnées de session couvrent l'événement de paiement initial, et `subscription_data.metadata` transporte la valeur jusqu'à chaque webhook de renouvellement : ```ts const sessionId = req.cookies.get('_rc_sid')?.value const metadata = sessionId ? { refcampaign_session: sessionId } : {} const checkout = await stripe.checkout.sessions.create({ line_items: [{ price: priceId, quantity: 1 }], metadata, subscription_data: { metadata }, mode: 'subscription', success_url: `${appUrl}/success`, cancel_url: `${appUrl}/pricing`, }) ``` Placez `refcampaign_session` sur la **Subscription**, pas sur l'objet Customer, pour les paiements récurrents. Chaque abonnement est lié à un parrainage d'affilié spécifique. Un client qui résilie et se réabonne via un lien d'affilié différent crée un nouvel abonnement — c'est le nouveau lien qui est crédité, pas l'original. RefCampaign traite les webhooks Stripe de manière asynchrone. Les conversions apparaissent dans le tableau de bord dans un délai d'environ 10 minutes après le déclenchement du webhook, pas en temps réel. La file de traitement relance les livraisons échouées jusqu'à 5 fois avant de marquer une conversion comme non résolvable. ### Étape 3 : suivre les conversions manuellement pour les paiements non-Stripe Si vous traitez des paiements en dehors de Stripe — via PayPal, virement bancaire, ou un système de facturation personnalisé — utilisez le SDK serveur pour soumettre les conversions directement : ```ts import { RefCampaignServer } from '@refcampaign/sdk' const rc = new RefCampaignServer(process.env.REFCAMPAIGN_SECRET_KEY!) await rc.trackConversion({ orderId: order.id, // requis — clé d'idempotence, évite les commissions dupliquées sessionId, amount: 4999, // en centimes currency: 'EUR', }) ``` Le champ `orderId` est requis depuis SDK v2. Il sert de clé d'idempotence : si votre backend soumet deux fois la même conversion (par exemple lors d'une nouvelle tentative après un timeout réseau), RefCampaign déduplique sur `orderId` et ne crée qu'un seul enregistrement de commission. `sessionId` ou `customerEmailHash` doit être fourni pour l'attribution. Sans l'un de ces deux champs, RefCampaign ne peut pas identifier quel affilié créditer. ### Étape 4 : activer l'attribution cross-device avec identify() Après la connexion ou l'inscription, une fois que vous connaissez l'email de l'utilisateur, appelez `identify()` une fois côté client. Le SDK navigateur hache l'email en SHA-256 via Web Crypto avant toute transmission — l'email brut ne quitte jamais le navigateur. Le hash est attaché à l'enregistrement de clic et permet l'attribution sur les appareils suivants où aucun cookie `_rc_sid` n'est présent. ```ts import { RefCampaignBrowser } from '@refcampaign/sdk' // À appeler une fois après la connexion ou l'inscription, quand currentUser.email est disponible RefCampaignBrowser.identify(currentUser.email) ``` `identify()` est fire-and-forget et first-write-wins : le hash d'email attaché à l'enregistrement de clic ne change pas lors des appels suivants pour la même session. Le hash est supprimé après 30 jours conformément aux exigences de minimisation des données du RGPD. --- ## Choisir la bonne configuration pour votre intégration Stripe Si vous hésitez entre intégrer RefCampaign nativement via les métadonnées Stripe ou passer par une couche d'intégration tierce, la [comparaison entre logiciel d'affiliation natif Stripe et intégration](/fr/blog/logiciel-affiliation-stripe-natif-vs-integration) couvre les compromis en détail — notamment en matière de fiabilité des webhooks et de complétude de l'attribution. En résumé : l'attribution native Stripe via les métadonnées est plus fiable que toute approche qui dépend d'un pipeline webhook séparé ou d'un signal de conversion côté navigateur, parce que l'attribution voyage à l'intérieur de l'objet de paiement Stripe plutôt qu'à côté. Pour une comparaison plus large des plateformes de tracking d'affiliation — notamment leur gestion d'ITP, du postback et de l'intégration Stripe — consultez [le comparatif des logiciels d'affiliation 2026](/fr/blog/meilleur-logiciel-affiliation-2026). --- ## Une implémentation complète en une demi-journée L'implémentation décrite ici — balise CDN, transmission des métadonnées Stripe, et appel `identify()` — peut être réalisée en une demi-journée pour un backend Next.js ou Node.js standard. L'étape des métadonnées Stripe est la plus critique : c'est elle qui fait survivre l'attribution aux limitations des navigateurs et aux parcours multi-appareils. Si votre programme génère du chiffre d'affaires mais que vous n'êtes pas certain que votre tracking l'attribue correctement, l'[article de diagnostic sur les pannes de suivi d'affiliation](/fr/blog/suivi-affiliation-fonctionnement-pannes-corrections) vous aidera à identifier quelle défaillance vous coûte des attributions. Pour mettre en place le suivi des conversions d'affiliation sur RefCampaign, [démarrez un essai gratuit](https://refcampaign.com/signup) ou [consultez les tarifs](/fr/tarifs). L'infrastructure de tracking décrite dans ce guide est active sur tous les plans.