Développement d'applications web, SaaS et MVP

Ce que comprend un projet d'application web ou de MVP#

Nous adaptons la mission au besoin réel. La proposition précise lesquels de ces livrables sont inclus, qui fournit les éléments nécessaires et comment chacun est validé.

• Périmètre de la première version : workflow central, rôles et ce qui attend
• Écrans clés conçus avec leurs états vide, de chargement et d'erreur
• Modèle de données, règles d'accès côté serveur et tests qui cherchent à les mettre en défaut
• Comptes, rôles et invitations d'équipe
• Paiements ou abonnements confirmés par des callbacks vérifiés du prestataire de paiement
• Interface d'administration, événements d'analytics produit et suivi des erreurs
• Déploiement, documentation et transfert du dépôt de code et des comptes

Application web, site web ou conception produit : par quoi commencer ?#

Choisissez cette option lorsque des clients ou des collaborateurs doivent se connecter et accomplir un travail dans le produit : acheter, réserver, soumettre, valider ou gérer quelque chose. Si vous avez besoin d'un site qui présente et vend votre offre, le développement web est plus adapté. Si le workflow n'est pas encore arrêté, commencez par la conception produit et développez une fois les écrans clés testés avec des utilisateurs.

Comment se construit une première version#

Nous commençons par une phase de cadrage : les utilisateurs et les rôles, l'unique workflow que la première version doit mener à bien, les données créées à chaque étape et les décisions qui font varier le coût, comme les paiements, les intégrations et les permissions. Le résultat : un cahier de cadrage écrit, des écrans clés cliquables et un plan de livraison qui indique ce qui est reporté.

Nous développons ensuite par cycles courts sur un environnement de préproduction que vous pouvez utiliser. Le premier jalon est une tranche fine du workflow central qui fonctionne de bout en bout, avec une vraie connexion et de vraies règles de données, avant de compléter les autres écrans. Le lancement comprend la supervision en production, une procédure de retour arrière et le transfert à votre nom du dépôt de code, de l'hébergement, de la base de données et des comptes de paiement et d'analytics.

Que faut-il mettre dans la première version d'un MVP ?#

Une première version doit contenir tout ce qu'il faut pour qu'un vrai utilisateur accomplisse un workflow, et rien qui ne compte qu'à une échelle que vous n'avez pas atteinte. Concrètement, cinq éléments : des comptes avec les rôles dont le workflow a besoin, le workflow central lui-même, une interface d'administration pour que votre équipe consulte et corrige les données sans développeur, des paiements si le modèle économique facture dès le premier jour, et des événements d'analytics qui montrent où les utilisateurs s'arrêtent.

Reportez ce qui peut se faire à la main ou s'acheter plus tard : une application mobile native, l'authentification unique pour les clients grands comptes, une matrice de permissions configurable, une deuxième intégration, un chat intégré et des rapports que personne n'a demandés. Chaque élément reporté garde une ligne dans le périmètre, afin que le modèle de données lui laisse de la place.

La plupart des produits sont assemblés à partir de modules connus. Deux méritent une remarque : la réservation et la planification, et un pipeline de prospects pour une petite entreprise qui suit aujourd'hui ses demandes à la main. Tous deux paraissent simples et cachent des décisions sur les fuseaux horaires, les statuts et les responsabilités, qu'il est moins coûteux de trancher sur le papier.

Quelle stack Dardo utilise-t-il, et quand en choisit-il une autre ?#

Notre choix par défaut est TypeScript de bout en bout : Astro pour les pages rendues côté serveur et les îlots interactifs, Cloudflare Workers pour l'hébergement et les API, Cloudflare D1 ou Postgres pour les données, et PostHog pour l'analytics et les expériences. Superame fonctionne avec Astro et son classement est stocké dans Neon Postgres. Un seul langage et une seule cible de déploiement permettent de garder un petit produit simple à exploiter et à transmettre.

Nous faisons un autre choix lorsque le produit l'exige. Une interface dense, ouverte toute la journée, peut justifier une application React côté client, comme dans le prototype Shiimain. Des tâches longues, un traitement de données lourd ou une équipe interne qui travaille déjà avec un autre framework changent aussi la réponse. Si vos développeurs reprennent le code après le lancement, leur stack l'emporte généralement.

Le contrôle d'accès est la première chose que nous testons. L'OWASP Top 10:2025 maintient Broken Access Control à la première place et indique que toutes les applications testées présentaient une forme de cette faille. Nous appliquons les permissions côté serveur pour chaque requête, refusons par défaut, limitons chaque requête à l'organisation de l'utilisateur connecté et écrivons des tests automatisés qui tentent de lire les données d'un autre client.

Comment gérer les paiements dans une application web ?#

C'est le prestataire de paiement qui confirme un paiement, côté serveur ; le retour du navigateur après le paiement ne le fait jamais. Superame, un classement public de projets présent dans les réalisations publiées de Dardo, illustre ce schéma. Les acheteurs paient sur la page de paiement hébergée par Dodo Payments : les données de carte n'atteignent donc jamais l'application. Le prestataire envoie ensuite un rappel signé (callback) ; le serveur vérifie la signature et contrôle les détails du paiement avant d'ajouter du crédit.

Les remboursements et les litiges suivent le même chemin. Chaque événement du prestataire n'est appliqué qu'une seule fois : un callback reçu en double, en retard ou dans le désordre ne peut donc pas ajouter ni retirer du crédit deux fois. Superame ne publie aucun chiffre d'adoption ni de revenus ; il illustre la façon dont la logique de paiement est construite, pas des ventes.

• Un acheteur qui ferme l'onglet avant la redirection est quand même crédité à l'arrivée du callback.
• Un callback rejoué ou falsifié est rejeté.
• Un remboursement ou un litige annule exactement ce que le paiement initial avait accordé.
• Les limites du forfait sont vérifiées sur le serveur, et pas seulement masquées dans l'interface.
• Les clés de test et de production sont des secrets distincts, jamais stockés dans le dépôt.

Laissez vos clients utiliser leurs propres domaines#

Les clients des SaaS B2B veulent souvent le produit sur leur propre adresse, par exemple portal.theircompany.com. Cloudflare for SaaS gère cela avec des noms d'hôte personnalisés : les forfaits Free, Pro et Business en incluent 100, chaque nom d'hôte supplémentaire coûte 0,10 $, et le maximum est de 50 000. Les noms d'hôte personnalisés avec caractère générique (wildcard) sont réservés à l'offre Enterprise.

Votre client ajoute un enregistrement CNAME pointant vers votre cible. Utiliser un enregistrement A pour pointer vers cette cible, ce que nécessiterait un domaine racine, n'est pas pris en charge par défaut, et le proxy sur l'apex est une option Enterprise : la plupart des clients devraient donc utiliser un sous-domaine. Les certificats sont validés par HTTP, TXT ou e-mail, ou avec Delegated DCV, un enregistrement unique qui permet à Cloudflare de les renouveler automatiquement. Ils sont émis par Let's Encrypt, Google Trust Services ou SSL.com.

Le travail produit autour compte autant : seuls les forfaits payants peuvent connecter un domaine, un écran d'intégration affiche l'enregistrement exact à ajouter, le statut de vérification explique en langage clair les états en attente et en échec, et une surveillance alerte votre équipe lorsqu'un certificat ne peut pas être renouvelé parce qu'un client a modifié son DNS. Les autres hébergeurs fixent des limites différentes : Vercel autorise 50 domaines par projet sur Hobby et un nombre illimité sur Pro et Enterprise, avec des limites souples de 100 000 et 1 000 000 ; Netlify recommande de ne pas dépasser 50 alias de domaine par site.

Vos questions avant de choisir#

Sur le blog#

• Domaines personnalisés pour SaaS : laissez vos clients utiliser leur propre domaine avec Cloudflare for SaaS

  Permettez à vos clients de pointer leur propre domaine vers votre SaaS avec Cloudflare for SaaS : fonctionnement de la validation, tarifs en octobre 2026 et limites.