Le projet de développement d'une application web dédiée avec Supabase et Cloudflare

Bonjour, je suis Ōtsuka, CTO chez Liberogic.

Les cyberattaques visant les sites web et les systèmes des entreprises se multiplient, et une grave vulnérabilité de PHP fait également parler d'elle depuis avant-hier.

L'architecture dont nous parlons ici pour le développement d'applications web permet de réduire autant que possible la charge liée à ces mesures de sécurité et à l'exploitation. Cela dit, nous souhaitons aborder le sujet de la sécurité lors d'une autre occasion.

La combinaison de Supabase et Cloudflare est celle que nous utilisons régulièrement pour construire des applications web sur mesure, adaptées aux activités de chaque entreprise : workflows de demandes et d'approbations, espaces membres, portails pour partenaires commerciaux, gestion du temps de travail, etc.

Auparavant, il fallait construire séparément des composants sur AWS, tels qu'EC2, RDS, S3 et Cognito, ou installer soi-même des serveurs Linux et y déployer les serveurs web, les middlewares et les frameworks. Chaque élément, qu'il s'agisse de la base de données, de l'authentification, de l'API ou du stockage de fichiers, demandait un effort considérable en matière de construction et d'exploitation.
Avec Supabase et Cloudflare, ces fondations sont confiées aux services eux-mêmes, ce qui permet de se concentrer sur les fonctionnalités réellement nécessaires à chaque application.

Cet article présente brièvement le type d'application web dédiée que l'on peut créer en combinant Supabase et Cloudflare.

Qu'est-ce qu'une application web dédiée ?

Ici, une « application web dédiée » désigne une application web développée spécifiquement pour une entreprise et ses activités.
Par exemple :

• Système interne de demandes et d'approbations
• Espace membre
• Portail dédié aux partenaires
• Gestion des charges et des présences
• Gestion de projets
• Gestion des demandes de contact
• Système de gestion pour boutiques et sites
• Système de partage et de validation de fichiers
• Gestion des enquêtes et des résultats de diagnostic
• Interfaces d'administration pour divers besoins métiers

Lorsque nous recevons ce type de demande, nous commençons par examiner si une solution SaaS ou un progiciel existant peut répondre au besoin. Pour les processus métiers courants, cette approche permet souvent un déploiement plus rapide et moins coûteux.

En pratique, lorsque nous répertorions les exigences, il est rare de trouver un produit qui corresponde exactement à ce que l'on souhaite faire.
Il existe souvent un circuit de validation propre à l'entreprise, des informations à afficher différemment selon les services ou les sites, ou encore un besoin d'intégration avec un système existant.

Dans ce cas, plutôt que d'adapter le métier à un SaaS et de devoir ensuite assurer la maintenance en permanence, il est souvent plus judicieux de développer une application web dédiée aux besoins du métier. C'est une proposition qui permet au client de fonctionner plus fluidement, et c'est la conclusion à laquelle nous arrivons dans de nombreux cas.

Supabase regroupe les fondations de données d'une application web

Supabase est un service qui regroupe les fonctionnalités backend nécessaires à une application web.

Au niveau mondial, c'est un service en forte croissance, utilisé par plus de 10 millions de développeurs. Y Combinator, l'accélérateur de startups américain bien connu, a annoncé que 55 % de la dernière promotion avait adopté Supabase, qui s'impose ainsi comme un choix privilégié pour le backend des nouveaux services.

Ces réalisations concernent principalement des services BtoC comptant un grand nombre d'utilisateurs. Nous utilisons toutefois cette approche en considérant qu'elle s'applique telle quelle aux applications web métier destinées à un usage interne ou aux partenaires commerciaux, c'est-à-dire des applications web « à usage intranet ».

Parmi ses principales fonctionnalités :

• Database (base de données PostgreSQL managée)
• Auth (authentification et connexion des utilisateurs)
• API générée automatiquement (une fois les tables définies, une API REST est immédiatement utilisable)
• RLS (Row Level Security : contrôle des droits au niveau de chaque ligne)
• Storage (stockage de fichiers)
• Realtime (communication en temps réel)
• Edge Functions (traitements d'API sans serveur)

etc.

Pour une application métier, les informations utilisateur, les données de projet, les données de demande et l'historique des opérations peuvent être gérés dans la base de données Supabase.

Avec Supabase Auth, la fonctionnalité de connexion peut également être intégrée directement. Ce module convient particulièrement aux applications métier, car il prend en charge la connexion avec un compte Microsoft ou un compte Google.

Si votre entreprise utilise déjà Microsoft 365 ou Google Workspace, les collaborateurs peuvent se connecter avec le compte qu'ils utilisent au quotidien. Il n'est pas nécessaire de créer et distribuer de nouveaux identifiants et mots de passe dédiés à l'application, et la gestion des comptes lors des arrivées et départs peut s'appuyer sur les systèmes existants.

Auparavant, il était courant de mettre en place séparément une base de données et un système d'authentification, puis de les relier entre eux. Avec Supabase, les données et l'authentification sont regroupées au sein d'une seule plateforme.

Grâce à RLS (Row Level Security),

• chaque utilisateur ne voit que ses propres données
• Afficher uniquement les données de la même base
• Les administrateurs peuvent tout voir

Ces contrôles peuvent également être mis en place côté base de données.

Dans les applications métier, ce contrôle des droits est particulièrement important.

Utiliser Cloudflare pour la diffusion du frontend

En revanche, Supabase seul ne suffit pas à tout faire. Il ne gère pas l'« hébergement du site web (frontend) ».
Même si la base de données et les API peuvent être hébergées sur Supabase, les écrans que les utilisateurs consultent dans leur navigateur doivent être diffusés depuis un autre emplacement.

Les principaux services de diffusion sont Vercel et Cloudflare. Nous avons choisi Cloudflare, pour plusieurs raisons.

• Gestion centralisée, de la DNS, du CDN et du WAF jusqu'à la diffusion de l'application, depuis Cloudflare
• Cloudflare Workers permet non seulement de diffuser le frontend, mais aussi de gérer le traitement des API et les connexions avec des services externes
• Des services annexes bien adaptés aux applications métier sont disponibles, comme R2 (stockage) et Access (contrôle d'accès)
• Une tarification simple à la quantité de transfert, avec un budget facile à anticiper

Cloudflare est souvent associé au CDN et au DNS, mais le service peut aujourd'hui aussi servir de plateforme d'exécution pour ce type d'application web.

Cloudflare vu sous l'angle d'une agence de création

Dans cette architecture, Cloudflare prend en charge la réception des accès utilisateurs et la délivrance des écrans et des API, tandis que Supabase gère les données, l'authentification et le contrôle des droits d'accès.

Associer Supabase et Cloudflare

Voici un exemple d'architecture.

Une application sur Cloudflare Workers reçoit les accès des utilisateurs et renvoie les écrans et les API, tandis que Supabase assure la gestion des données et de l'authentification.

Si nécessaire, SendGrid peut être utilisé pour l'envoi d'e-mails, des fichiers peuvent être stockés sur un service de stockage externe comme Box, et des intégrations API peuvent être mises en place avec d'autres systèmes métier.

L'un des avantages de cette architecture est qu'elle repose sur des technologies standard et qu'elle n'est pas liée à un écosystème particulier.
Tout service compatible avec les API peut être connecté, qu'il s'agisse d'un système central existant ou d'un SaaS déjà utilisé. Il n'y a pas non plus de contraintes du type « ce produit ne peut se connecter qu'à ○○ », fréquentes avec les progiciels.

Exemples d'applications métier réalisables

Application interne de demande et d'approbation

Une application permettant aux différents sites et aux responsables de déposer des demandes, que les supérieurs hiérarchiques et les administrateurs peuvent ensuite approuver.
Selon l'utilisateur connecté, il est possible de :

• n'afficher que ses propres demandes
• afficher les demandes du site
• afficher l'ensemble des demandes pour les administrateurs

…et bien d'autres contrôles d'accès.
L'idée est de transformer en application web des processus jusqu'ici gérés par e-mail et Excel, sans en changer le fonctionnement.

Portail dédié aux partenaires

Un identifiant de connexion est attribué à chaque partenaire, permettant :

• la consultation de documents
• le dépôt de fichiers
• Suivi de l'avancement
• Contact
• Consultation des informations contractuelles

Il est également possible de créer un portail permettant d'effectuer ces opérations.
Il est relativement simple de contrôler les informations affichées selon chaque partenaire commercial.

Gestion des charges et des présences

Une application permettant à chaque employé de saisir ses heures de travail et son temps passé, avec un calcul par projet et par collaborateur.
Lorsque des règles métier spécifiques ou une méthode de calcul propre à l'entreprise sont nécessaires, une application web dédiée s'avère souvent plus adaptée qu'un SaaS de gestion du temps standard.

Pour ce type de processus, adapter un produit standard peut parfois s'avérer plus contraignant que prévu.

Système de gestion multi-sites

Également adapté aux applications web permettant à un siège de centraliser et gérer les données saisies par les magasins et agences réparties sur l'ensemble du territoire.

Des outils internes utilisés par quelques personnes aux applications métier déployées sur plusieurs sites, nous pouvons répondre à une grande variété de besoins.
Supabase ne se limite pas aux petits projets.
Avec une conception adaptée, il peut couvrir un large éventail d'usages.

Voici quelques exemples d'applications que nous avons développées.

Système de gestion des réseaux sociaux « TOYOTA Social Hub » pour Toyota Motor Corporation : conception UI/UX et développement système

Quand choisir une application web sur mesure plutôt qu'un SaaS

Jusqu'ici, nous avons présenté les avantages d'une application web sur mesure, mais elle n'est pas toujours la bonne solution.
Voici les repères que nous utilisons, à partir des demandes que nous recevons, pour déterminer quand il est judicieux de la développer.

• Les contournements sont devenus la norme
  Les circuits de validation varient d'un service à l'autre, les exceptions sont nombreuses, et le flux de travail s'écarte du modèle prévu par le SaaS. Les paramétrages ne suffisent plus à absorber ces écarts.
• Les droits d'accès et l'affichage doivent être finement contrôlés
  Vous souhaitez afficher des informations différentes selon le service, le site ou le partenaire, mais les droits proposés par le SaaS manquent de granularité.
• Le travail passe par plusieurs outils
  Vous jonglez entre Excel, la messagerie et plusieurs SaaS, et la ressaisie ou le copier-coller sont devenus quotidiens.
• Les champs de gestion et les règles de calcul sont nombreux et spécifiques
  Vos données propres sont forcées dans les champs génériques d'un SaaS.
• L'outil a trop de fonctions, ou il en manque
  Un SaaS généraliste entraîne une interface complexe que les équipes n'utilisent pas, ou il ne propose pas les fonctions dont elles ont réellement besoin.

Si un ou deux de ces points correspondent à votre situation, un ajustement du paramétrage ou des pratiques suffit souvent à s'en sortir.
En revanche, lorsque plusieurs points se cumulent et que les « petites contraintes » quotidiennes s'accumulent, nous pensons qu'il est temps d'envisager une application web sur mesure, adaptée à votre activité.

En pratique, les projets d'application web sur mesure commencent souvent par des demandes du type : « Nous voulons numériser les informations gérées dans Excel », « Nous voulons automatiser les demandes envoyées par e-mail », ou « Nous voulons regrouper en un seul outil un processus réparti sur plusieurs SaaS ».

Commencer petit, puis faire évoluer l'outil à l'usage

Jusqu'ici, nous avons parlé de l'architecture technique, mais ce que je voudrais surtout vous transmettre pour finir, c'est la manière de mener le projet, plus que les fonctionnalités de Supabase ou de Cloudflare elles-mêmes.

« Ce qu'il faut construire » ne ressort pas forcément du cahier des charges

Le développement logiciel classique commence par la définition des besoins. On commence par formaliser les processus métier existants dans un document, puis on conçoit un système qui y répond.

Cette approche présente toutefois une faiblesse. Un document peut couvrir l'ensemble des processus métier, tout en laissant de côté des questions essentielles : l'interface sera-t-elle réellement agréable à utiliser ? Cette fonctionnalité est-elle vraiment nécessaire ? Les exigences s'accumulent alors souvent sans que ces points soient vérifiés.
En particulier, pour une personne chargée de la transformation numérique qui n'est pas spécialiste du développement de systèmes, il est très difficile d'évaluer la pertinence des exigences à partir de textes et de tableaux seuls.

C'est pourquoi chez Liberogic, nous ne figeons pas d'emblée un épais cahier des charges. Nous réalisons plutôt des maquettes (des prototypes d'écrans réellement utilisables) avec des outils comme Figma, v0 ou Claude Code, et nous avançons en les faisant tester.

Contrairement à un cahier des charges rédigé, manipuler réellement l'écran permet de vérifier « ce que ça donne à l'usage » avec un niveau de concret bien plus élevé. Il est alors intéressant de constater que la discussion passe du simple examen d'un document à l'amélioration des processus : « Avec cet écran, cette partie du travail deviendrait beaucoup plus simple », « Et si on automatisait aussi cette autre tâche que nous faisons à part ? »

Pour une application Web dédiée, l'élément souvent sous-estimé est justement cette question de « ce qu'il faut construire ». Selon nous, elle ne se dégage pas dans la documentation, mais au fil du partage d'une image commune à travers les maquettes.

Implémenter d'abord les fonctions de base, puis lancer

Nous ne suivons pas un modèle en cascade (dit « waterfall »), qui consiste à fixer toutes les exigences en amont puis à tout construire d'un bloc. Une fois la direction validée avec les maquettes, nous implémentons d'abord les fonctions de base (connexion, saisie de données, affichage des listes et écran d'administration), puis nous lançons.

Ensuite, à partir de l'utilisation réelle, nous vérifions l'ergonomie et les retours du terrain, puis nous ajoutons progressivement les fonctions de validation, les notifications par e-mail, la gestion des fichiers ou les intégrations d'API externes.
Une architecture Supabase et Cloudflare s'accorde très bien avec cette démarche par étapes.

Une application qui évolue avec votre budget et la valeur métier

« Commencer petit et étendre selon les besoins » est aussi une question de budget. Par exemple,

• nous développons progressivement les fonctionnalités en fonction du budget annuel disponible
• en lançant d'abord une version réduite, puis en investissant davantage pour enrichir l'application une fois que sa valeur métier devient visible

. Cette approche permet de disposer d'une application métier sans avoir à réunir un budget de développement important dès le départ. Nous estimons que les applications métier réussissent souvent mieux lorsqu'elles sont améliorées à l'usage, plutôt que définies de manière exhaustive dès le début.

Conclusion

En combinant Supabase et Cloudflare, il est possible de créer une application web dédiée dotée de l'authentification, d'une base de données, du contrôle des droits, d'API et de la distribution de fichiers, avec une architecture relativement légère. Elle peut évoluer selon les usages, depuis un petit outil métier interne jusqu'à un portail destiné aux partenaires ou un système utilisé sur plusieurs sites.

Cependant, l'essentiel ne tient pas aux outils eux-mêmes, Supabase ou Cloudflare, mais à la méthode de travail.

• Commencer par une maquette pour partager une image concrète de l'usage et identifier ce qu'il faut réellement construire
• Développer uniquement les fonctions de base et lancer rapidement
• Faire évoluer l'application à l'usage, en fonction du budget et de la valeur métier

Cette approche n'était autrefois pas réaliste. Le coût de mise en œuvre des logiciels comme celui de la construction de l'infrastructure étaient élevés, il fallait donc tout définir à l'avance avant de commencer à développer.

Aujourd'hui, grâce à des stacks technologiques modernes comme Supabase et Cloudflare, ainsi qu'au développement et au prototypage assistés par des agents IA, il est possible de mener les projets de manière plus proche de l'idéal : « créer d'abord quelque chose de concret, puis le faire évoluer en l'utilisant ». C'est précisément cette approche dans laquelle Liberogic excelle.

« Ce processus que nous gérons avec Excel et des e-mails, pourrait-on le passer en ligne ? » « Nous avons essayé un SaaS, mais il ne correspond pas vraiment à notre activité. » Vous pouvez nous contacter dès ce stade. Nous réfléchirons ensemble à une configuration adaptée à votre activité, n'hésitez donc pas à nous contacter.