ADR-0041 — Un programme qui paie, une page : /network/referral redirige vers /network/affiliate

Statut

Accepté · 2026-09-25

Remplace : ADR-0015

Piliers : growth-web, billing

Contexte

L'ADR 0015 a aligne les deux pages qui paient sur un seul jeu de conditions : 30 % du net, 12 factures payees, 60 jours d'attribution, 30 jours de retention, tous lus dans src/config/affiliate.ts, un seul ledger (AffiliateCommission). Cette partie de la decision tient et n'est pas rouverte.

Elle gardait pourtant deux pages : /network/referral pour le client qui presente un marchand, /network/affiliate pour le createur qui publie. Sa seule raison ecrite : ce sont « deux funnels deja construits et indexes », et une redirection « supprime un funnel d'acquisition indexe ».

Cette premisse ne tenait pas. L'audit de nettoyage avant indexation du 2026-09-25 (docs/audits/2026-09-25-nettoyage-avant-indexation.md, decision D4, ligne 27 de l'audit d'architecture) part d'un site peu indexe : il n'y avait pas de classement a proteger. Il y avait en revanche un defaut que l'indexation allait aggraver : deux pages indexables, meme ledger, memes termes, memes FAQ a une phrase pres, qui se disputaient la meme requete (« programme d'affiliation Shopify », « parrainage BoostEcom »). Chacune renvoyait vers l'autre dans sa FAQ (« Referral or affiliate: which one is mine? », « How is this different from the referral programme? ») : la seule question que la separation creait etait celle de savoir laquelle lire.

Et le cout d'une fusion croit avec le temps : une redirection aujourd'hui, six quand la langue entrera dans l'URL (ADR 0038).

Décision

Un programme qui paie, une page. /network/affiliate porte le programme, avec deux sections d'audience sur les memes conditions : les clients qui parrainent un marchand qu'ils connaissent, et les createurs ou affilies qui publient pour une audience. /network/referral repond 308 vers /network/affiliate, dans next.config.mjs, et n'a plus de fichier de route.

L'URL gardee est /network/affiliate parce qu'elle est deja le nom du reste du systeme : /legal/affiliate, le ledger AffiliateCommission, les constantes AFFILIATE_*, le tableau de bord d'affiliation.

Alternatives écartées

Conséquences

Ce que ca coute. Une redirection permanente a garder pour toujours : l'URL a circule dans le prompt noyau d'@Atlas, llms.txt, le sitemap, la FAQ de la home et le menu. Et une page plus longue : deux publics lisent la meme, chacun passe la section de l'autre.

Ce qu'on accepte sciemment. Le formulaire de mise en relation (NetworkApplyForm, program="referral") reste le seul formulaire de la page, dans la section clients. Le composant pose des id fixes, donc deux formulaires sur une page seraient deux fois les memes id : le createur qui veut parler a une personne passe par /contact?topic=network. Le formulaire « Tell us about your audience » de l'ancienne page affiliation disparait avec elle.

Le signal qui indiquerait de revisiter. Deux publics qui demandent des conditions differentes, ce qui serait alors un second programme, donc un second ledger (la sortie deja chiffree et ecartee). Tant que l'argent est le meme, la page est la meme.

Comment c'est appliqué

• next.config.mjs, bloc wave2:D : /network/referral → /network/affiliate, permanent: true.
• src/test/network-pages-render-one-set-of-terms.test.ts refuse qu'un fichier de route revienne sous (marketing)/network/referral (il repondrait 200 avant que la redirection ne soit lue) et que la redirection disparaisse ou change de cible. Il continue de refuser tout chiffre ecrit a la main dans la page.
• src/test/affiliate-copy.test.ts lit les termes du programme sur les cles de la page unique (marketingPages.network.affiliate.*, …programs.affiliate.*), dans les six locales.
• src/test/llms-txt-targets.test.ts refuse deja qu'une surface llms.* pointe une URL qui redirige : l'entree « Referral program » a disparu de llms.txt, llms.json et llms-full.txt, fusionnee dans « Affiliate program ».