Stack backend d'un fondateur solo : choisir Cloudflare Workers, Supabase, Node.js et sa base de données

Le frontend de l’outil est prêt. Il faut maintenant implémenter /api/submit, /api/checkout-webhook et /api/report-cron, puis stocker users, usage_events et files. Que faut-il mettre dans Workers, confier à Supabase ou exécuter dans un service Node distinct ?

Une stack backend n’est pas une plateforme unique. Entrée des requêtes, données métier, fichiers, tâches longues, authentification et webhooks se répartissent entre plusieurs services. Workers convient à l’entrée edge et à la logique légère, Supabase porte Auth et Postgres, Node.js traite les travaux et dépendances incompatibles avec une runtime edge. Comparez le tableau suivant à votre backlog.

1. Tableau des responsabilités backend : où placer chaque élément

Commencez par la liste de vos API, webhooks, tâches cron, données et fichiers :

Ce tableau ne recommande pas de tout placer dans Workers. Workers possède des limites CPU, mémoire et subrequests, Supabase des limites d’usage et de pause, Node.js un coût d’exploitation continu. On peut retarder Node.js, mais pas ignorer son signal d’arrivée.

Décider où résident les données

• Données métier → Supabase Postgres ou autre base relationnelle pour relations, transactions, requêtes, triggers et clés étrangères.
• Fichiers → Supabase Storage ou R2 selon permissions, egress, CDN, région et chaîne d’outils.
• Cache → KV ; D1 convient à certaines données relationnelles edge, sans remplacer la source de vérité métier.

La comparaison complète D1, Postgres, R2, S3 et SQLite appartient à l’article consacré aux données. Ici, on attribue seulement chaque type.

Séparer webhook et tâche longue

Un webhook Stripe ou GitHub peut arriver dans Workers à l’edge ou dans Edge Functions au sein d’un projet Supabase. Le handler vérifie la signature, écrit un enregistrement idempotent et répond vite. Automatisation de navigateur, parsing de gros fichiers ou attentes externes en plusieurs étapes continuent dans Queue, Workflow, Container ou worker Node.js.

Sur Workers Paid, une requête HTTP dispose par défaut de 30 secondes de CPU, configurables jusqu’à 5 minutes. Un Cron Trigger exécuté au moins toutes les heures peut utiliser 15 minutes de CPU. HTTP n’a pas de limite murale fixe tant que le client reste connecté, mais déconnexions, retries, ressources et mises à jour rendent une tâche longue liée à la requête fragile.

Seuils d’alerte des offres gratuites

En juillet 2026, Workers Free inclut 100 000 requêtes par jour, 10 ms de CPU, 128 Mo de mémoire et 50 subrequests. Supabase Free inclut 50 000 MAU, 500 Mo de base par projet, 5 Go d’egress, 1 Go de fichiers et deux projets actifs.

Ces quotas sont un budget de lancement, pas une promesse d’architecture. Supabase met en pause un projet Free après une semaine d’inactivité ; une charge Workers supérieure à Free exige Paid. Avec des utilisateurs réguliers ou un paiement, ajoutez alertes d’usage, modèle de coût et stratégie dégradée.

2. Cloudflare Workers : ce qui convient et ce qui ne convient pas

Workers n’est pas un backend universel. Ses frontières viennent du CPU, de la mémoire, des subrequests et du bundle, pas de la capacité à exécuter JavaScript.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Limites Workers Free en juillet 2026

Workers Free autorise 100 000 requêtes par jour et 10 ms de CPU par invocation. Mémoire : 128 Mo ; subrequests : 50 ; Worker compressé : 3 Mo. Un dépassement CPU produit l’erreur 1102. Une requête HTTP n’a pas de durée murale fixe tant que le client reste connecté ; après réponse ou déconnexion, ctx.waitUntil() prolonge au maximum de 30 secondes.

Limites Workers Paid Standard

Workers Paid coûte au minimum 5 dollars par compte et par mois, avec 10 millions de requêtes et 30 millions de ms CPU. Le CPU HTTP est de 30 secondes par défaut et configurable jusqu’à 5 minutes. Les requêtes supplémentaires coûtent 0,30 dollar par million, le CPU 0,02 dollar par million de ms. Chaque invocation accepte 10 000 subrequests, un bundle compressé de 10 Mo et toujours 128 Mo de mémoire.

Cas adaptés

• Entrée des requêtes, proxys edge et API légères.
• Réception de webhooks, validation de signature et mise en file idempotente.
• Déclenchement et orchestration de Cron, Queues et Workflows.
• Accès KV/R2, cache headers, redirections et routage A/B.

Ces charges reposent sur I/O réseau, validation et orchestration. Elles ne chargent pas de gros fichiers en mémoire et ne lancent ni navigateur ni bibliothèque système native.

Cas inadaptés

• Calcul CPU soutenu → découper, exécuter en asynchrone ou déplacer vers Node.js/Container.
• Gros fichiers entièrement bufferisés → stream, upload direct ou service de fichiers.
• Longues tâches navigateur → Node.js avec Playwright/Puppeteer ou navigateur géré.
• Dépendances hors bundle/runtime → service Node.js ou conteneur.

La compatibilité Node.js de Workers couvre de nombreuses API, mais « compilable » ne veut pas dire « adapté ». Consommation, retries, durée et observabilité tranchent.

Seuil de coût

Avec 5 ms CPU en moyenne, 10 millions de requêtes dynamiques consomment environ 50 millions de ms CPU. Après les 30 millions incluses, le supplément est d’environ 0,40 dollar. KV, Queues, R2 et d’autres produits peuvent s’ajouter.

Le vrai seuil n’est pas ce petit montant : c’est une fonction essentielle qui ne tient que dans le quota gratuit. Si un dépassement détruit marge ou disponibilité, préparez rate limiting, cache et fallback.

3. Supabase : limites d’Auth, Postgres, Storage et Edge Functions

Supabase ne se limite pas à Postgres. Il regroupe Auth, Storage, Realtime et Edge Functions, chacun avec ses limites.

Limites Supabase Free en juillet 2026

Supabase Free fournit 500 Mo de base par projet, 50 000 MAU, 5 Go d’egress, 5 Go d’egress caché et 1 Go de fichiers. Une organisation conserve deux projets Free actifs. Après une semaine d’inactivité, le projet est mis en pause : l’offre sert à valider, pas à garantir une disponibilité de production.

Quotas Supabase Pro

Supabase Pro commence à 25 dollars par mois avec 100 000 MAU, 8 Go de disque par projet, 250 Go d’egress, 250 Go d’egress caché et 100 Go de fichiers. Les offres payantes incluent 10 dollars de crédits compute. Projets, compute, trafic, stockage et options supplémentaires augmentent la facture.

Cas adaptés

• Authentification : e-mail, OAuth, sessions et permissions RLS.
• Données métier : relations, contraintes, transactions et requêtes Postgres.
• Fichiers : uploads, images et exports protégés par des policies.
• Triggers, fonctions et migrations Postgres.
• Edge Functions liées à Auth, Postgres et Storage.

Quand la logique écrit les données d’un utilisateur, actualise des lignes liées par trigger ou enregistre des métadonnées d’upload, Supabase réduit le nombre de composants à exploiter.

Limites Edge Functions

Supabase Edge Functions utilise une runtime compatible TypeScript/Deno pour webhooks, intégrations et API du projet. Limites actuelles : 256 Mo de mémoire, 2 secondes de CPU par requête et 150 secondes d’idle timeout. La durée murale maximale est 150 secondes en Free et 400 secondes en Paid.

La durée murale inclut l’attente I/O, ce n’est pas un budget CPU. Navigateur, bibliothèques natives multithread, vidéo et gros fichiers vont dans un worker ou service dédié. Les background tasks gardent les mêmes limites CPU, mémoire et durée.

Choisir Edge Functions ou Workers

• Colle applicative liée à Supabase Auth/Postgres/Storage → Edge Functions.
• Entrée edge ou proxy peu lié à Supabase → Workers.

Un webhook Stripe qui modifie les abonnements et Auth est direct dans Edge Functions. Pour vérifier, limiter et transférer, Workers est une entrée indépendante. Le travail long part toujours en file.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Mise en pause du projet

Supabase pause un projet Free après une semaine d’inactivité. Un outil interne occasionnel peut attendre sa reprise à la prochaine requête. Un produit payant régulier doit évaluer Pro, sauvegardes et migration. Free n’est pas une garantie durable.

4. Node.js : quand un service traditionnel reste pertinent

Serverless et edge réduisent la maintenance, sans supprimer le besoin de runtime complète, dépendances système et processus persistants.

Quand Node.js reste utile

• Automatisation avec Playwright ou Puppeteer.
• Gros fichiers, parsing complexe et tâches utilisant un disque temporaire.
• Modules natifs ou dépendances npm incompatibles avec l’edge.
• Consumers de queue persistants, WebSockets et API d’administration.
• Backend partagé avec processus, observabilité et ressources uniformes.

Captures web, PDF, collecte, transcodage vidéo et parsing important exigent souvent plus de CPU, mémoire, processus ou système de fichiers. Node.js, un conteneur ou une plateforme de tâches convient mieux.

Signaux indiquant Node.js

Évaluez Node.js quand les tâches heurtent régulièrement CPU, mémoire, durée, bundle ou compatibilité de Workers/Edge Functions, ou exigent navigateur, modules natifs, connexions persistantes ou consommation fiable de queues.

« Plus de 30 secondes » ne suffit pas comme critère. Workers Paid, Cron, Queues, Workflows, Containers et Supabase Functions ont des limites différentes. La question est la fiabilité dans le modèle de ressources, retries, idempotence et observabilité choisi.

Quand Node.js n’est pas nécessaire

• Simple transfert d’API ou routage edge.
• Validation et écritures légères dominées par I/O.
• Aucun gros fichier, module natif ou connexion persistante.
• Pas encore de besoin justifiant l’exploitation d’un serveur.

Workers ou Supabase Edge Functions couvrent ces cas sans service Node distinct.

Node.js n’est pas obsolète

L’edge échange des contraintes contre peu d’exploitation et une distribution mondiale. Node.js échange du travail d’infrastructure contre compatibilité, contrôle des ressources et processus persistants. Ce sont des rôles différents. Workers + Supabase ferment d’abord API, webhooks, Auth et données ; Node.js arrive quand navigateur, fichiers ou dépendances deviennent réels.

5. Workers avec Supabase : client API ou Hyperdrive

Workers et Supabase forment souvent une stack « entrée edge + identité et données métier » plutôt que deux concurrents.

Combiner Workers et Supabase

Workers gère transfert, validation, rate limit et cache. Supabase Auth et Postgres portent identité, données et policies. Cette combinaison convient aux requêtes légères et écritures validées d’un premier produit sans serveur.

Pour Auth, Data API ou Storage, supabase-js suffit. Pour SQL, transactions ou ORM fréquents, utilisez un driver et un pool plutôt qu’une nouvelle connexion directe par invocation edge.

Tableau des connexions

Hyperdrive prend en charge Supabase Postgres et réduit latence et pression de connexions des Workers distribués. Ce n’est pas un système d’autorisation : rôle, droits de tables et comportement RLS viennent toujours des identifiants et policies Postgres.

Avertissement sur la service role key

Les service role keys et secret keys serveur de Supabase sont très privilégiées et peuvent contourner RLS. Ne les exposez jamais au navigateur, mobile, dépôt public ou log ; gardez-les comme secrets dans un backend fiable.

Créez un client Supabase serveur séparé pour l’administration afin qu’une session utilisateur ne remplace pas le header Authorization et le comportement RLS. Webhooks, batchs et administration demandent privilèges minimaux et audit propre, pas une clé universelle.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Frontière entre Edge Functions et Workers

• Forte dépendance à Supabase Auth, Postgres ou Storage → Edge Functions.
• Entrée edge indépendante, proxy, rate limiting et routing → Workers.

La frontière n’est pas absolue. Décidez selon le centre des données et droits, le besoin des fonctions edge Cloudflare et l’endroit où unifier logs et déploiement. Une clé privilégiée reste secrète des deux côtés.

6. Propriété des données : métier, fichiers et cache

D1, Postgres, KV et R2 stockent des données, mais ne résolvent pas le même problème.

Tableau de propriété des données

Utilisateurs, commandes, abonnements, projets et droits affectent facturation ou accès. Ils vont dans une base métier avec contraintes, migrations et sauvegardes. Postgres apporte requêtes complexes, clés étrangères, triggers, intégrité transactionnelle et MVCC. D1 peut porter des données relationnelles légères, après évaluation de cohérence, scale et limites.

Ne partagez pas les fichiers selon un seuil arbitraire de 1 Go. Supabase Storage convient aux fichiers liés à Auth/RLS, R2 aux objets intégrés au trafic et CDN Cloudflare. Policy, egress, upload, transformations et SDK décident.

Le cache va à l’edge, mais n’est pas la base métier. KV convient à la configuration et aux lectures reconstruisibles. Si commandes ou droits n’existent que dans le cache, expiration, retard de synchro ou suppression change le véritable état métier.

Le comparatif complet D1, Postgres, R2, S3 et SQLite viendra dans l’article stockage. Ici, seules les catégories sont attribuées.

7. Suite de la série

Cet article répartit les responsabilités backend. La suite couvre déploiement, bases et stockage, paiement, authentification et autorisation.

Articles BetterLink associés

Pour vérifier les limites, consultez le déploiement Cloudflare Pages, Cloudflare Free Plan Limits 2026, le proxy API Workers, Supabase pour débuter et Supabase Edge Functions.

Construire d’abord votre tableau

Listez cinq actions backend à livrer cette semaine. Marquez « réponse immédiate / identité et accès / fait métier / fichier / tâche asynchrone / secret », puis attribuez Workers, Supabase, Node.js ou report. Les plateformes ne sont que des moyens ; responsabilités et chemins d’échec déterminent la fiabilité du premier backend.