Les règles, tarifs, programmes et données peuvent changer. La section « Sources et limites » précise le fondement de cette page.
Une architecture légère peut suffire à un comparateur, calculateur, guide ou prototype : le code vit dans GitHub, un processus de build produit les fichiers et Cloudflare sert les actifs ou exécute un petit Worker lorsque du code serveur est nécessaire.
Structure recommandée
- dépôt GitHub comme source de vérité;
- branche principale protégée par des validations;
- secrets uniquement dans les variables du fournisseur, jamais dans le dépôt;
- build reproductible;
- déploiement automatique après fusion;
- journal d'erreurs et métriques minimum.
Quand le « gratuit » cesse de l'être
Les limites gratuites peuvent évoluer. Surveillez surtout bande passante, fonctions serveur, bases de données, stockage, appels API et temps de build. Une architecture statique garde généralement les coûts faibles plus longtemps qu'une application qui exécute du calcul à chaque visite.
Un déploiement reproductible plutôt qu'un copier-coller
Le dépôt doit contenir tout ce qui est nécessaire pour reconstruire le site, sauf les secrets. Documentez la version du langage, les dépendances, la commande de build et le dossier de sortie. Une nouvelle machine ou un service d'intégration continue devrait pouvoir produire le même résultat sans dépendre de fichiers cachés sur votre ordinateur.
Branches et environnements
Gardez la branche principale comme version déployable. Pour une grosse modification, utilisez une branche et, lorsque la plateforme le permet, un aperçu de déploiement. Testez les liens, formulaires et scripts avant de fusionner. Cela permet de conserver le site public stable même si le prototype est incomplet.
Secrets et variables
Une clé API ne doit jamais être inscrite dans un fichier JavaScript livré au navigateur ni commitée dans Git. Les secrets nécessaires à un Worker ou à une fonction serveur doivent être configurés dans l'environnement d'exécution et accessibles seulement côté serveur.
Quand ajouter un Worker
Restez statique tant que possible. Ajoutez du code serveur seulement pour un besoin qui ne peut pas être exécuté de façon sûre dans le navigateur : secret d'API, logique d'accès, traitement centralisé ou écriture dans une base de données. Chaque composant serveur ajoute du coût potentiel, de la surveillance et des scénarios de panne.
Enfin, configurez un domaine et les redirections canoniques une fois l'URL de production choisie. Un projet commercial doit aussi prévoir sauvegardes, politique de confidentialité et méthode pour mettre à jour les dépendances.
Sources et limites
Sources : GitHub Docs et Cloudflare Developers. Vérifiez les quotas actuels avant de dimensionner un service.
Une source devenue inaccessible, une règle différente dans votre municipalité ou une donnée dépassée peut être signalée avec le bouton « Signaler une erreur ».