Au départ, il s’agissait juste d’un lien
En bref : vous n’avez pas besoin de GitHub Actions pour publier sur Cloudflare Pages. Si votre projet Pages est relié à GitHub, Cloudflare compile et met en ligne tout seul à chaque push. Si c’est un projet en Direct Upload (envoi direct), vous compilez le site complet et vous envoyez le résultat avec Wrangler. Voici comment je l’ai compris, après pas mal de détours.
La tâche était minuscule. Pour passer la validation d’un programme d’affiliation, je devais placer un seul lien vers un disque dur externe dans un vrai article. Juste avant le lien, une mention claire : « Cette page contient des liens affiliés : le propriétaire du site peut toucher une commission si vous achetez. » J’ai créé le lien, je l’ai ajouté à l’article et j’ai fait un commit sur GitHub.
C’était réglé, pensais-je.
Mais dès que le code est arrivé sur GitHub, un malentendu est apparu.
Du code sur GitHub, ce n’est pas une page en ligne.
GitHub Actions, que j’utilisais d’habitude, n’était pas disponible. Quelqu’un a proposé d’intercepter uniquement cette URL avec un Cloudflare Worker et de servir la page depuis là. Mais avec les conditions d’utilisation de cette fois-ci, cette piste était fermée aussi.
Je voulais juste poser un lien, et me voilà en pleine réunion de déploiement : « Et la CI ? Et le Worker ? Pages est relié à Git ou en Direct Upload ? »
C’est ainsi qu’a commencé le chantier de la Sagrada Família de l’affiliation, bâtiment n° 2.
Pourtant, dès qu’on sépare chaque pièce, le problème devient beaucoup plus simple.
1. Pourquoi il fallait d’abord une vraie page publique
Sovrn Commerce demande aux sites de contenu et aux blogs de commencer par placer des liens Commerce sur le site et de générer quelques clics. Ce n’est qu’ensuite que la campagne passe en validation.[3]
Autrement dit, ce n’est pas « on vous valide, puis vous posez les liens ». La personne qui valide doit d’abord voir un exemple réel qui fonctionne.
Sovrn demande aussi de prévenir clairement les lecteurs, sur chaque page avec des liens affiliés, que vous pouvez gagner de l’argent grâce à eux. Cette mention doit apparaître avant le lien ou la promotion.[4]
Pas besoin d’un site comparateur bourré de fonctionnalités. La liste est courte :
- un vrai article existe sur le site inscrit ;
- cet article contient le lien affilié ;
- la mention apparaît avant le lien ;
- n’importe qui peut ouvrir la page via son URL publique ;
- une fois en ligne, vous pouvez générer quelques clics de test.
Le point clé, c’est l’avant-dernier : un fichier dans un dépôt GitHub n’est pas encore une page publique.
2. GitHub Actions en panne ne veut pas dire Cloudflare Pages en panne
GitHub Actions, c’est l’outil d’automatisation (CI/CD) de GitHub. Il lance les builds, les tests et les déploiements à l’intérieur de GitHub.
Cloudflare Pages, lui, a sa propre intégration Git. Vous reliez le projet Pages directement à GitHub ou à GitLab, et à chaque push sur ce dépôt, Cloudflare compile et met en ligne tout seul.[1]
Le circuit ressemble à ça :
push sur GitHub → Cloudflare Pages repère le commit → Cloudflare compile → Cloudflare met en ligne
Aucun workflow GitHub Actions n’intervient dans cette chaîne.
C’est le point essentiel. « On ne peut pas utiliser GitHub Actions » n’est pas la même chose que « GitHub ne peut pas publier sur Cloudflare ». Ce sont deux choses différentes.
Voyez-le comme ça : GitHub Actions, c’est le tapis roulant dans votre propre entrepôt. L’intégration Git de Cloudflare, c’est un transporteur qui vient chercher le colis lui-même.
Le tapis peut être à l’arrêt, le transporteur passe quand même.
3. D’abord, savoir quel type de projet Pages vous avez
Si vous sautez cette étape, Cloudflare Pages devient vite un labyrinthe.
Il existe deux grandes façons de publier :
| Type | Ce qui le déclenche | Qui compile et met en ligne | Idéal pour |
|---|---|---|---|
| Intégration Git (Git integration) | un push sur GitHub / GitLab | Cloudflare | le dépôt fait foi et vous voulez publier automatiquement |
| Direct Upload (envoi direct) | des fichiers déjà compilés | Wrangler ou le tableau de bord | vous compilez sur votre ordinateur ou dans une autre CI, puis vous envoyez le résultat |
La documentation officielle de Cloudflare précise un détail : un projet créé avec l’intégration Git ne peut pas devenir ensuite un projet Direct Upload classique. Vous pouvez quand même faire un déploiement manuel avec Wrangler sur un projet relié à Git, mais pas utiliser le glisser-déposer du tableau de bord.[1][2]
L’inverse est vrai aussi. Sur un projet créé en Direct Upload, on ne peut pas ajouter l’intégration Git après coup. Pour des déploiements automatiques depuis Git, il faut un nouveau projet Pages.[2]
La première question n’est donc pas « comment je déploie ? ».
C’est celle-ci : « Mon projet Pages actuel est-il en intégration Git ou en Direct Upload ? »
Avec cette réponse, la moitié des options disparaît.
4. Avec l’intégration Git, inutile de ressusciter GitHub Actions
Si votre dépôt GitHub est déjà bien relié à Cloudflare Pages, le chemin le plus court n’est ni un Worker ni une nouvelle CI.
Vérifiez ceci dans votre projet Pages :
- il est relié au bon dépôt GitHub ;
- la branche de production est bien celle que vous voulez publier ;
- les builds automatiques de la branche de production ne sont pas en pause ;
- la commande de build et le dossier de sortie correspondent au projet actuel ;
- après un push, un nouveau déploiement apparaît dans l’écran Deployments de Pages ;
- le nouveau contenu s’affiche sur votre adresse
pages.dev; - enfin, votre propre domaine affiche ce même nouveau contenu.
L’intégration Git de Cloudflare compile et met en ligne à partir des commits de la branche reliée.[1]
Donc, même si GitHub Actions est indisponible pour un moment, vous pouvez continuer à publier tant que le build propre à Cloudflare tourne.
Le travail ici n’est pas de monter un autre système compliqué. C’est de vérifier si la porte d’enlèvement de Cloudflare est déjà ouverte.
5. En Direct Upload, envoyez le build complet, pas une page isolée
Direct Upload, c’est confier à Cloudflare Pages un ensemble fini de fichiers statiques. La documentation officielle explique comment envoyer des fichiers déjà compilés avec Wrangler ou depuis le tableau de bord.[2]
C’est là qu’apparaît un raccourci dangereux :
« Je n’ai changé qu’un article. Pourquoi ne pas envoyer seulement ce fichier HTML ? »
Si votre site statique est compilé d’un bloc, mieux vaut éviter.
Ce que vous déployez, ce n’est pas « le fichier modifié dans Git », mais le résultat complet du build du site à cet instant. Un build régénère souvent aussi les listes de pages, le CSS, le JavaScript, les index de recherche, les images et les règles de routage. Si vous glissez une page à la main, le site en ligne ne correspond plus à votre dépôt.
En Direct Upload, le circuit de base est :
récupérer la dernière version → lancer la commande de build du projet → vérifier le dossier de sortie → déployer toute la sortie → contrôler l’URL en ligne
Par exemple, pour un site statique fait avec Node, lancez la commande du projet, comme pnpm build, puis envoyez le dossier généré, comme dist.
L’essentiel, c’est que le site en production ne devienne pas un monde parallèle mystérieux que quelqu’un a retouché à la main.
6. Si le Worker n’est pas utilisable, rayez-le du plan
Si vous devez publier une page en urgence, intercepter cette route avec un Worker peut fonctionner en théorie.
Mais si les conditions d’utilisation n’autorisent pas les Workers, comme ici, ça n’a aucun sens de construire le plan autour.
Chaque piste « peut-être que ça marche » laissée sur le plan rend l’ensemble plus dur à maintenir.
- GitHub Actions : indisponible
- Worker : indisponible
- Donc un seul choix : intégration Git de Cloudflare Pages ou Direct Upload
Et c’est tout.
Trouver la seule porte principale ouverte va plus vite que construire dix sorties de secours.
Ne construisez pas un deuxième système de déploiement juste pour publier un lien affilié.
C’est la plus grande leçon de toute cette histoire.
7. « Publié » se vérifie sur la vraie page, pas avec le hash d’un commit
Une erreur classique quand on gère un site, c’est d’appeler « terminé » une étape intermédiaire.
- le code est écrit
- le commit est sur GitHub
- le build est passé
- un déploiement est apparu sur Cloudflare
Tout ça compte, mais les lecteurs ne voient que l’URL finale.
Pour une page de validation d’affiliation comme celle-ci, le contrôle final, c’est :
- l’URL publique s’ouvre dans une fenêtre de navigation privée ;
- c’est bien la dernière version de l’article qui s’affiche ;
- la mention d’affiliation apparaît avant le lien ;
- le lien produit mène au bon endroit ;
- la page s’affiche bien sur mobile ;
- si besoin, vous générez quelques clics de test ;
- vous vérifiez dans votre compte Sovrn le nombre de clics et l’état de la validation.
Sovrn décrit ainsi le circuit des campagnes de contenu et de blog : placer les liens, générer des clics, puis validation.[3]
Donc « c’est sur GitHub, il n’y a plus qu’à attendre » ne suffit pas. Vous n’êtes sur la ligne de départ que lorsque la personne qui valide peut voir le tout fonctionner sur l’URL en ligne.
8. Plus tard, n’écrivez pas les URL affiliées en dur dans le texte des articles
Un lien posé à la main, ça va.
Mais quand vous avez des centaines ou des milliers d’articles, si quelqu’un doit décider à chaque fois « Cet article a-t-il des pubs ? Où ? Quel produit ? Pour quel pays ? », une usine à pubs pousse à côté de votre usine à contenu.
L’étape suivante, c’est de séparer le texte de l’article des données de monétisation.
Par exemple, chaque article ne porte qu’un petit bloc de réglages comme celui-ci :
article_id: example-123
affiliate: true
placement: after_solution
max_products: 3
market_mode: auto
product_theme: external-storage
Et à la publication, tout s’enchaîne ainsi :
article → décision de monétisation → choix des produits → création du lien affilié → insertion au moment de générer la page → mesure des résultats
L’article reste un actif sur le long terme. Les URL des produits, le stock, les marchands et la répartition par pays deviennent des pièces interchangeables.
Comme ça, pas besoin de reprendre le texte dans les 12 langues chaque fois qu’un lien casse ou qu’un produit change.
Le lien affilié n’est pas l’article.
Voyez-le comme un tuyau de vente que l’on branche sur l’article après coup. Sur la durée, ça tient beaucoup mieux.
9. Conclusion : si la CI lâche, cherchez la vraie entrée de Cloudflare avant de bâtir un nouveau château
Toute cette histoire en dit long.
Ça a commencé par : « Mettons un lien vers un disque dur pour la validation. »
Le lien était prêt. La mention, rédigée. Tout était sur GitHub.
Mais au moment de mettre en ligne, GitHub Actions n’était pas utilisable. Et le contournement par un Worker ne marchait pas non plus.
Si à ce moment-là vous ajoutez encore un système, l’objectif glisse sans qu’on s’en rende compte : de « publier un lien » à « agrandir la plateforme de déploiement ».
Au final, il ne faut que ces décisions :
- si votre projet Pages utilise l’intégration Git, laissez Cloudflare compiler ;
- si c’est du Direct Upload, compilez tout le site et déployez le résultat officiel ;
- si les Workers ne sont pas utilisables, rayez-les de la liste ;
- n’appelez jamais un commit sur GitHub « publié » ;
- vérifiez la mention, le lien, l’affichage de la page et les clics sur la vraie URL publique.
Le plus risqué, ce n’est pas d’avoir trop peu d’options.
C’est de garder pour toujours sur le plan des options qu’on ne peut pas utiliser.
