Comprendre les compteurs avant de lancer
Code, CI, hébergement et données : distinguer quotas, coût inclus et facturation
Identifier la ressource facturée et le quota partagé, lire l’inclus, situer un blocage et distinguer contrôle local, CI exécutée et service publié sans promettre une gratuité illimitée.
1. Nommer la ressource avant de parler de coût
Un dépôt contient le code et son historique. Une exécution de CI utilise un environnement pour construire ou vérifier ce code. L’hébergement rend un résultat disponible aux visiteurs ; un runtime exécute du code lors des requêtes. Les fichiers, bases et autres données ont encore leur propre stockage. Un seul projet peut utiliser ces couches chez plusieurs fournisseurs, avec des compteurs et des conditions différents.
Commencez par une ligne par ressource : fournisseur, produit, propriétaire facturé, unité, période et rôle. Le volume du code ne mesure pas le temps de CI. La réussite d’un dépôt envoyé ne prouve ni construction ni mise en ligne, et un site consultable ne prouve pas qu’une API fonctionne. Le dossier ne reprend aucune donnée de compte, tarif personnel ou consommation d’un projet réel.
La documentation Cloudflare distingue les limites de construction Pages des requêtes Pages Functions, rattachées aux offres Workers. Elle distingue aussi les requêtes de fichiers statiques qui n’invoquent pas de Function. Ces frontières permettent de poser la bonne question ; elles ne rendent pas une architecture complète gratuite ou illimitée.
| Couche | Ce qui est observé | Confusion à éviter |
|---|---|---|
| Code | Référence et fichiers du dépôt | Des minutes de CI consommées du seul fait que le code existe. |
| CI ou build | Exécution, runner, résultat, artefacts | Un fichier de configuration vaut une exécution réussie. |
| Hébergement statique | Version publiée et réponse servie | Les fonctions et données sont forcément incluses. |
| Runtime/API | Requêtes et calculs du service | Un site accessible prouve toute l’API. |
| Données | Stockage et services associés | Une seule allocation couvre toutes les couches. |
2. Identifier le propriétaire et le périmètre du quota partagé
Pour les dépôts privés utilisant des runners hébergés, GitHub décrit une allocation Actions liée au compte et à son offre ; les minutes sont imputées au propriétaire du dépôt. Un projet individuel ne doit donc pas se voir attribuer une allocation entière en oubliant les autres usages du même périmètre. La personne qui déclenche une exécution et le propriétaire facturé ne sont pas nécessairement le même acteur.
Le partage dépend du compteur : GitHub indique un pool commun aux artefacts Actions et à GitHub Packages, tandis que le cache possède une allocation distincte. Côté Cloudflare, Pages Functions et Workers peuvent consommer la même allocation Workers Free. Ne généralisez pas ce partage à tous les produits ou à tous les comptes : relevez pour chaque compteur son périmètre exact.
Exercice fictif en unités de CI inventées : le compte collectif dispose de 100 unités incluses pour la période. Le projet A en a utilisé 28 et B en a utilisé 47, soit 75 ; il reste 100 − 75 = 25 unités. Une demande C de 30 unités porterait le total à 105 et sortirait de la couverture de 5 unités. Une demande de 20 porterait le total à 95 et laisserait 5 unités. Ces chiffres ne sont ni des quotas GitHub ni une conversion de durées réelles.
| Scénario fictif | Total demandé | Reste sur100unités | Lecture |
|---|---|---|---|
| A28 + B47 | 75 | 25 | Consommation commune |
| A28 + B47 + C30 | 105 | Dépassement5 | Refuser si dépassement non autorisé |
| A28 + B47 + C20 | 95 | 5 | Couverture arithmétique, autres conditions à vérifier |
3. Lire séparément usage brut, inclus et montant facturable
Un volume d’usage, son équivalent tarifaire éventuel et le montant net facturable répondent à trois questions différentes. Relevez le libellé exact, l’unité et la période. Une estimation de coût brut n’est pas automatiquement une facture ; un montant nul à un instant ne constitue pas une garantie pour la fin du cycle. Ne soustrayez pas un quota de minutes d’un montant en monnaie.
GitHub distingue notamment le stockage présent à l’instant du relevé et le stockage cumulé pendant le cycle de facturation. Une diminution du stockage courant n’efface pas l’usage déjà accumulé. Cette distinction évite de déduire la facture d’une seule taille de dossier observée à la fin du mois.
Dans l’exemple des 105 unités demandées pour 100 incluses, cinq unités sont hors couverture arithmétique. Cela ne démontre ni une facture de cinq unités monétaires ni l’autorisation d’exécuter ce surplus. Il faut encore connaître l’éligibilité de la ressource à l’allocation, la règle de prix, les crédits applicables et les barrières de dépense. Pour une politique sans dépassement payant, cette demande reste à refuser ou à réduire plutôt qu’à valoriser comme une dépense acceptée.
4. Situer le blocage sans conclure que tout le service est arrêté
Lisez ce qui est refusé : nouveau job de CI, construction d’une version, publication, requête d’une Function, accès au stockage ou opération d’administration. Un message concernant un compteur ne décrit pas automatiquement les autres couches. Conservez le produit, l’étape et le résultat observé ; ne transformez pas « construction refusée » en « code perdu » ou « hébergement supprimé ».
Les limites Pages distinguent concurrence, constructions et autres ressources. Une construction en attente, un échec technique et une limite atteinte ne sont pas une seule cause. La documentation GitHub décrit également le blocage de certains usages lorsque l’allocation est épuisée sans moyen de paiement valide. Cela ne qualifie aucun compte particulier ni la disponibilité d’un service hébergé ailleurs.
Pour le service déjà publié, conservez la version connue et vérifiez sa réponse séparément lorsque ce contrôle est autorisé. Si la nouvelle publication n’a pas abouti, ne l’annoncez pas comme disponible. Si un runtime est en échec, ne présentez pas une page statique comme preuve de sa reprise. Le guide ne promet pas qu’une ancienne version restera servie dans toutes les situations de quota, suspension ou contrat.
5. Vérifier une barrière de dépense et son champ d’application
Une alerte informe ; une barrière peut empêcher un usage supplémentaire. GitHub documente l’option « Stop usage when budget limit is reached » et précise qu’une notification seule n’arrête pas l’usage. Le périmètre compte aussi : produit, dépôt ou compte, selon les possibilités disponibles. Des budgets qui se recouvrent peuvent provoquer un blocage dès que l’un des plafonds applicables est atteint.
Si la décision est de rester dans l’inclus sans dépassement payant, vérifiez le plan concerné, les ressources éligibles, le budget applicable et l’existence d’un arrêt effectif avant de lancer une opération nouvelle. Une borne locale sur les minutes estimées peut aider à préparer cette décision, mais ne prouve pas le réglage de facturation du fournisseur. Si une condition indispensable reste inconnue, différer l’opération respecte la décision mieux qu’un essai non borné.
N’élargissez pas automatiquement une offre, un budget ou une limite pour faire disparaître un message. Ajouter un moyen de paiement, activer une option ou choisir une ressource payante peut changer le cadre de coût. Le guide n’effectue aucune de ces opérations et ne configure aucun compte. Il ne garantit aucun plafond universel ou absence de facture : les bornes et leurs effets doivent être confirmés pour les produits réellement utilisés.
6. Distinguer la preuve locale de la CI réellement exécutée
Un contrôle local traçable précise la version de source, la commande, l’environnement, les entrées utiles, le résultat et le code de sortie. Une configuration de workflow prouve qu’une procédure est décrite, pas qu’elle a tourné. Pour annoncer une CI exécutée, il faut la référence du run, la source concernée, les jobs attendus et leur conclusion ; un déclenchement seul ne suffit pas.
Écrivez les conclusions au niveau effectivement prouvé : « contrôle local passé », « CI en attente », « job ignoré », « exécution échouée » ou « CI passée sur cette version ». Un contrôle local peut avancer le travail quand un quota distant bloque, mais il ne remplace pas silencieusement les jobs propres au serveur. Inversement, ne relancez pas tous les contrôles inchangés pour obtenir une nouvelle date : ciblez les conséquences de la modification et conservez les preuves encore valides.
Préparez ensuite la livraison à partir de l’artefact qualifié et de son périmètre. La mise en ligne doit avoir sa propre preuve : cible, version et résultat public, distincts du build. Un déploiement exact ne qualifie pas à lui seul l’authentification, une API ou un parcours connecté. La fiche finale garde donc trois conclusions séparées — validation locale, CI et service publié — avec leurs limites, sans secrets, facture ou information privée de compte.
Sources
- GitHub Actions billing · GitHub Docs · vérifié le 16 octobre 2026
- Setting up budgets to control spending on metered products · GitHub Docs · vérifié le 16 octobre 2026
- Limits — Cloudflare Pages · Cloudflare Docs · vérifié le 16 octobre 2026
- Pricing — Pages Functions · Cloudflare Docs · vérifié le 16 octobre 2026