Conception et développement d’applications SaaS : comptes et rôles, abonnements, tableaux de bord, mise en service. De l’architecture à l’exploitation, en remote.
Un SaaS est une application accessible depuis un navigateur, sans installation : vos clients ouvrent un compte, s’abonnent, utilisent. Vous facturez de façon récurrente et vous corrigez pour tout le monde à la fois.
La contrepartie est qu’il n’y a pas de date de fin. Un SaaS s’exploite : il se surveille, se sauvegarde, se met à jour. C’est ce qui distingue le produit du site, et c’est ce qui décide de son architecture dès le premier jour.
L’abonnement remplace la vente unique. Le chiffre d’affaires devient prévisible, mais il se mérite chaque mois : ce qui ne fonctionne pas se voit dans les résiliations.
Vous corrigez à un endroit, tout le monde en bénéficie le jour même. Il n’y a pas de parc de versions installées à maintenir en parallèle.
Un navigateur suffit, sur ordinateur comme sur téléphone. Le coût d’entrée pour vos clients tombe à une adresse et un mot de passe.
La même architecture doit tenir à dix comptes et à dix mille. C’est une contrainte de conception, pas une option qu’on ajoute quand le trafic arrive.
Inscription, connexion, réinitialisation, connexion par fournisseur tiers, double facteur. Rôles et droits par ressource, équipes et organisations quand le produit est vendu à des entreprises. Les droits sont vérifiés côté serveur, jamais seulement masqués dans l’interface.
Plans, périodes d’essai, changements de formule en cours de route, crédits à l’usage, portail de facturation. Les webhooks de paiement sont traités comme la source de vérité : c’est eux qui décident de ce qu’un compte a le droit de faire.
Les écrans qui donnent à vos clients une raison de revenir : état de leur activité, historique, filtres, exports. Conçus pour se lire d’un coup d’œil avant de se creuser.
Connexion aux outils déjà en place, import et export de données, synchronisations planifiées avec des services tiers. Les échecs de synchronisation sont visibles et rejouables, pas silencieux.
Confirmation d’inscription, relance de paiement, alertes métier. Rédigés, gabarités et testés en même temps que la fonctionnalité qui les déclenche — c’est le premier endroit où un produit paraît bâclé.
Intégration continue, environnement de recette séparé, secrets hors du dépôt, sauvegardes de la base, journalisation des erreurs. Ce qui fait la différence entre un produit en ligne et un produit exploitable.
Next.js — App Router, Server Components, Tailwind. Rendue côté serveur : le contenu existe dans le HTML avant tout script.
Server Actions et route handlers. Toute entrée est validée avant d’atteindre quoi que ce soit — la validation du navigateur est un confort, jamais une barrière.
PostgreSQL, accédé par Prisma ou par Supabase. Le schéma s’écrit avant le premier écran : c’est lui qui décide de ce que le produit saura faire dans six mois.
Auth.js ou Supabase Auth selon l’architecture. Session, rôles, appartenance à une organisation — revérifiés à chaque requête côté serveur.
Stripe. L’état de l’abonnement est reconstruit depuis les webhooks et fait autorité : ni l’interface, ni le client, ne décident de ce qui est payé.
GitHub Actions, environnement de recette, secrets hors du dépôt, sauvegardes, journalisation. Hébergement sur serveur dédié, en France.
Rien d’exotique, et c’est volontaire : chaque couche est un choix documenté, pratiqué par beaucoup de monde, que quelqu’un d’autre que moi peut reprendre. Une architecture originale se paie à la première reprise.
Plateforme photo événementielle
En production
Livrer les photos d’un événement par lien de transfert n’a ni marque, ni mémoire : le fichier expire et le photographe disparaît avec.
Les invités d’un événement scannent un QR code, prennent des photos depuis leur navigateur et retrouvent la galerie commune, qui ne s’ouvre qu’après la soirée. Comptes photographes, crédits à l’usage, affichage en direct sur écran, likes et vote du meilleur photographe.
Moteur de réservation pour hébergements
Développé, pas encore ouvert
Recopier ses disponibilités d’une plateforme à l’autre coûte des heures par semaine et finit toujours par produire une double réservation.
Réservation en direct pour des propriétaires de gîtes : synchronisation des calendriers des plateformes de location par iCal, paiement en ligne, gestion de plusieurs biens, notifications automatiques.
Périmètre du premier jalon, rôles utilisateurs, modèle économique, modèle de données. Rien n’est codé avant que ces quatre points soient écrits.
LivrableDocument d’architecture et modèle de données
Chaque module est développé, testé et démontrable seul. Vous suivez l’avancement réel plutôt qu’un pourcentage annoncé.
LivrableEnvironnement de recette accessible en continu
Les flux dont une défaillance coûte de l’argent ou de la confiance : inscription, droits, encaissement, notifications. Ce sont eux qui sont couverts en priorité.
LivrableTests sur l’authentification, l’encaissement et les notifications
Production configurée, intégration continue en place, sauvegardes vérifiées, documentation remise. Accompagnement les premières semaines d’exploitation.
LivrableProduction configurée, documentation, passation
Des comptes, des droits, des paiements : les trois surfaces qu’un attaquant cherche, réunies dans le même produit. Chaque SaaS livré dans ce cadre passe par une revue de sécurité applicative selon le référentiel OWASP avant sa mise en service — pas après le premier incident.
Il n’y a pas de tarif affichable, et un chiffre posé ici serait faux dans les deux sens. Un premier jalon utilisable — comptes, encaissement, deux ou trois fonctionnalités qui font le produit — représente couramment deux à quatre mois de développement. Le devis est établi par module après le cadrage, ce qui permet d’arbitrer avant de s’engager plutôt qu’après.
Les deux. Le code est documenté, et l’environnement de production est configuré : intégration continue, environnement de recette, variables et secrets, sauvegardes de la base, journalisation des erreurs. Vous récupérez un produit en ligne, pas un dépôt à faire déployer par quelqu’un d’autre.
C’est la norme sur un SaaS, pas l’exception. Quand les spécifications ne sont pas stabilisées, la régie est le mode honnête ; sur un périmètre écrit, le forfait par module l’est davantage. Tout ajout hors périmètre est chiffré et validé avant d’être développé — jamais découvert sur la facture.
Oui, intégralement, et le dépôt est chez vous dès le premier jour. Je ne conserve aucun droit sur ce qui est produit pour votre projet, et rien n’est hébergé sur des comptes qui ne sont pas les vôtres.
Oui, à condition qu’il soit en React, Next.js ou Node. La reprise commence par une lecture du code et un relevé écrit — dette, points de rupture, risques de sécurité — avant toute proposition de développement. On sait alors ce qu’on corrige et ce qu’on reconstruit.
Un SaaS concentre exactement ce qui s’attaque : des comptes, des droits et des paiements. La revue de sécurité applicative selon le référentiel OWASP fait partie de la mise en service, pas d’une prestation qu’on vend séparément une fois le produit en ligne.
Un premier échange pour cadrer le périmètre du premier jalon et vous dire, honnêtement, ce qu’il représente en temps de développement.