Au départ, il ne fallait publier qu’un seul lien
La tâche initiale était minuscule : placer dans un véritable article un lien affilié vers un disque dur externe afin qu’une plateforme d’affiliation puisse examiner l’implémentation du site.
La page devait contenir un contenu utile, une mention claire de la rémunération potentielle avant le lien commercial, et un lien fonctionnel. Le lien a été créé et l’article a été commit sur GitHub.
Puis le vrai problème est apparu.
Un code présent sur GitHub ne signifie pas que la page est publiée sur Internet.
La voie habituelle utilisant GitHub Actions n’était pas disponible. Une autre idée consistait à intercepter uniquement cette URL avec un Cloudflare Worker, mais cette voie n’était pas non plus utilisable dans les contraintes opérationnelles actuelles.
Un seul lien d’affiliation s’est transformé en réunion sur CI, Workers, Pages, Git integration et Direct Upload.
Nous étions à deux doigts de commencer la construction de la Sagrada Família de l’affiliation, bâtiment numéro 2.
Une fois les mécanismes de déploiement correctement séparés, la situation devient pourtant beaucoup plus simple.
1. Pourquoi fallait-il d’abord une vraie page publique ?
Le guide d’onboarding de Sovrn Commerce pour les sites de contenu et les blogs indique qu’une campagne doit implémenter les liens Commerce et générer des clics avant d’être examinée pour approbation.[3]
Le processus n’est donc pas seulement « approbation d’abord, liens ensuite ». L’équipe de revue doit pouvoir observer une implémentation réelle.
Sovrn explique également que les pages contenant des liens affiliés doivent signaler clairement la relation de rémunération, et que la disclosure doit apparaître avant le lien ou la promotion.[4]
Pour une page de revue basique, les exigences sont modestes :
- un véritable article existe sur le site soumis ;
- l’article contient le lien affilié ;
- la disclosure apparaît avant le lien ;
- l’URL publique est réellement accessible ;
- quelques clics de vérification peuvent être générés après l’implémentation.
Le point essentiel est simple : un fichier dans un repository n’est pas encore une page publique.
2. L’indisponibilité de GitHub Actions ne signifie pas celle de Cloudflare Pages
GitHub Actions est le système CI/CD de GitHub permettant d’exécuter build, tests et déploiements.
Cloudflare Pages possède aussi sa propre Git integration. Un projet Pages peut être relié directement à GitHub ou GitLab ; lorsqu’un push arrive sur le repository connecté, Cloudflare peut effectuer lui-même le build et le déploiement.[1]
Le flux peut donc être :
push vers GitHub → Cloudflare Pages détecte le commit → Cloudflare build → Cloudflare deploy
Aucun workflow GitHub Actions n’est requis pour cette chaîne.
Ainsi, « GitHub Actions n’est pas utilisable » n’est pas synonyme de « GitHub ne peut plus publier automatiquement vers Cloudflare ».
Si GitHub Actions est le convoyeur interne, la Git integration de Cloudflare ressemble plutôt au transporteur qui vient chercher directement le colis à l’entrepôt.
Le convoyeur peut être arrêté tandis que l’enlèvement continue.
3. Il faut d’abord identifier le type du projet Pages existant
Cloudflare Pages propose deux grands modèles de déploiement.
| Modèle | Déclencheur | Où se font build/deploy | Cas adapté |
|---|---|---|---|
| Git integration | push GitHub/GitLab | Cloudflare | le repository est la source de vérité et le déploiement doit être automatique |
| Direct Upload | sortie de build déjà produite | Wrangler ou dashboard | le site est construit localement ou dans un autre CI puis envoyé directement |
Cloudflare documente une limite importante : un projet créé avec Git integration ne peut pas simplement être transformé ensuite en projet Direct Upload classique. Les projets intégrés à Git peuvent encore recevoir un déploiement manuel via Wrangler, mais le drag-and-drop du dashboard n’est pas disponible pour ces projets Git déjà existants.[1][2]
L’inverse est également important : un projet commencé en Direct Upload ne peut pas recevoir Git integration dans le même projet. Pour passer au déploiement Git automatique, il faut créer un nouveau projet Pages.[2]
La première question ne devrait donc pas être « quelle astuce de déploiement tenter ? »
Mais : « Le projet Pages actuel est-il Git-integrated ou Direct Upload ? »
Cette réponse élimine la moitié du labyrinthe.
4. Avec Git integration, inutile de ressusciter GitHub Actions
Si le repository est déjà correctement connecté à Cloudflare Pages, la voie la plus courte n’est ni un Worker ni un nouveau service CI.
Il faut vérifier dans Pages :
- que le bon repository GitHub est connecté ;
- que la production branch est bien celle publiée ;
- que les builds automatiques de cette branch ne sont pas désactivés ;
- que build command et output directory correspondent au projet actuel ;
- qu’un nouveau deployment apparaît après le push ;
- que
pages.devaffiche le nouveau contenu ; - que le custom domain affiche la même version.
La Git integration de Cloudflare est précisément conçue pour build et deploy à partir des commits du repository connecté.[1]
Si cette voie fonctionne, une limitation temporaire de GitHub Actions ne justifie pas une nouvelle architecture de déploiement.
Avant de creuser un autre tunnel d’urgence, mieux vaut vérifier si la porte principale est déjà ouverte.
5. Avec Direct Upload, on déploie le build complet, pas une page bricolée
Direct Upload reçoit des assets déjà construits. Cloudflare prend en charge Wrangler et le drag-and-drop du dashboard pour les projets Direct Upload.[2]
Une idée tentante est : « Je n’ai modifié qu’un article, pourquoi ne pas envoyer un seul HTML ? »
Pour un site statique généré, c’est généralement le mauvais modèle mental.
L’unité de déploiement est la sortie complète du build, pas le source file qui vient de changer. Le build peut également régénérer le routing, le CSS, le JavaScript, l’index de recherche, les metadata et d’autres assets.
Un flux plus sûr est :
récupérer le source récent → lancer le build du projet → vérifier l’output directory → déployer toute la sortie → vérifier l’URL réelle
Dans un projet Node, le build peut ressembler à pnpm build et produire un dossier comme dist.
Le but est d’éviter que la production devienne un univers manuel séparé du repository.
6. Si Worker n’est pas disponible, il faut le retirer du plan
Router une seule URL urgente avec un Worker peut être techniquement valable.
Mais si l’environnement actuel ne permet pas d’utiliser Workers, conserver cette solution comme principal plan de secours ne fait qu’ajouter de la complexité.
La décision se réduit à :
- GitHub Actions indisponible ;
- Worker indisponible ;
- utiliser la Git integration Pages existante ou le chemin Direct Upload valide.
Dix sorties de secours ne sont pas nécessairement meilleures qu’une porte dont on sait qu’elle s’ouvre.
Inutile de construire une deuxième plateforme de déploiement pour publier un seul lien affilié.
7. « Publié » se prouve sur la vraie page, pas avec un SHA
Écrire le code, créer un commit, réussir un build et générer un deployment sont des étapes intermédiaires.
La vérification finale doit se faire sur l’URL réellement vue par le lecteur.
Pour une page de revue d’affiliation, il faut vérifier :
- que l’URL publique s’ouvre dans une session propre ;
- que le contenu le plus récent est affiché ;
- que la disclosure apparaît avant le lien affilié ;
- que le lien produit mène vers la destination attendue ;
- que l’affichage mobile fonctionne ;
- si nécessaire, que quelques clics de vérification sont générés ;
- que Sovrn enregistre le trafic ou fait évoluer l’état de revue.
Sovrn décrit le flux content/blog comme implémentation, génération de clics, puis revue.[3]
Le vrai point de départ n’est donc pas « le code est dans GitHub », mais « le reviewer peut inspecter l’implémentation en ligne ».
8. À grande échelle, mieux vaut ne pas graver les URL affiliées dans le texte éditorial
Un lien manuel est acceptable.
Des centaines ou milliers d’articles changent le problème. Si chaque article exige une décision humaine sur la monétisation, la position, le produit et le marché, la fabrique de contenu finit par construire une seconde fabrique publicitaire.
Une meilleure architecture sépare le contenu éditorial des metadata commerciales.
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
Le flux peut ensuite devenir :
article → monetization gate → product candidates → affiliate link generation → renderer insertion → performance measurement
L’article reste un actif durable. URL produit, stock, merchant et routing pays deviennent des composants remplaçables.
Le système affilié devrait ressembler à une tuyauterie commerciale raccordée à l’article, pas au béton coulé dans ses fondations.
9. Conclusion : quand CI est indisponible, trouver d’abord la vraie entrée Cloudflare
Tout a commencé avec un seul lien affilié pour un HDD.
Le lien existait. La disclosure existait. Le source était dans GitHub.
Puis la voie CI habituelle est devenue indisponible et le détour Worker l’était aussi.
Ajouter encore un mécanisme aurait transformé l’objectif de « publier un lien » en « construire une nouvelle plateforme de déploiement ».
L’arbre de décision utile est très petit :
- si Pages utilise déjà Git integration, utiliser le build Git natif de Cloudflare ;
- si le projet est Direct Upload, build le site complet et déployer la sortie complète par la voie supportée ;
- si Workers sont indisponibles, les retirer des options ;
- ne pas confondre Git commit et déploiement production ;
- vérifier disclosure, lien, rendu et clics sur l’URL publique réelle.
L’architecture la plus dangereuse n’est pas celle qui offre trop peu de choix.
C’est celle qui conserve indéfiniment dans son schéma des choix devenus inutilisables.
