fastdigital.
SERVICE — SAAS / WEB APP

Plateformes exigeantes, livrées en production.

On construit des SaaS multi-comptes, des tableaux de bord analytiques et des plateformes métier en TypeScript strict. Code propre, doc d'architecture, tests, monitoring. Pas de technologies maison obscures.

8k CHF
Plancher
15 — 35k
Sweet spot
8 — 20 sem.
Délai type
100%
TypeScript
POUR QUI

On bosse avec.

Startups seed / série A

Vous validez un MVP (version minimale viable) ou faites monter votre produit en charge. Code propre, documentation, transmission possible.

PME software / éditeurs

Vous ajoutez un module métier, un back-office ou refondez une partie technique.

Scale-ups en croissance

Vous renforcez l'équipe sur un projet ponctuel sans diluer la qualité du code.

Agences créatives

Vous sous-traitez la partie serveur / architecture pour un client final exigeant. NDA possible.

CE QU'ON LIVRE

Concrètement, ça donne.

01

Architecture multi-comptes

Isolation par schéma PostgreSQL ou sécurité au niveau des lignes selon vos besoins de souveraineté.

02

Connexion & permissions

OAuth, liens magiques, rôles fins, équipes, invitations. Sessions sécurisées.

03

Tableaux de bord analytiques

Filtres, exports CSV, graphiques interactifs (Recharts, D3) avec données temps réel.

04

Paiements Stripe / Twint

Abonnements, plans, facturation à l'usage, factures PDF, webhooks robustes.

05

API REST ou tRPC

Schémas typés bout en bout, OpenAPI documenté, limitation de débit, journaux d'audit.

06

Tests & CI

Vitest pour l'unitaire, Playwright pour l'E2E, GitHub Actions sur chaque PR.

07

Monitoring

Sentry, Datadog ou OpenTelemetry. Alertes, tableaux de bord d'erreurs, traces distribuées.

08

Déploiement cloud

Vercel, AWS ECS ou Kubernetes. Rollbacks atomiques, environnements de preview par PR.

STACK & APPROCHE

Outils choisis.

Stack technique

  • Next.js 15 / App Router
  • TypeScript strict
  • Node.js / tRPC
  • PostgreSQL / Prisma
  • Redis / BullMQ
  • Tailwind CSS
  • Vercel / AWS

Comment on bosse

On démarre par un sprint de discovery (1 — 2 semaines) : on comprend votre métier, on cadre le périmètre, on livre un document d'architecture qui justifie chaque choix de technologie et chaque arbitrage. Vous savez pourquoi on prend Postgres plutôt que Mongo, pourquoi tRPC plutôt que REST, et combien ça coûte.

Phase build en sprints de 1 semaine. Livraison continue sur un environnement de pré-production. Vous voyez le produit grandir chaque vendredi. Code review interne, TypeScript strict partout, tests automatisés sur les parcours critiques. Pas de magie : tout est dans le repo, tout est documenté.

À la livraison, vous avez un produit en production, une CI verte, des tableaux de bord de monitoring, et une doc API à jour. Optionnel : 2 semaines de support post-livraison incluses, puis bascule sur un contrat TMA (maintenance applicative) si vous voulez qu'on continue.

PRICING

Tarif transparent.

Plancher
8 000 CHF
Sweet spot
15 — 35k CHF

Inclus dans la prestation

  • Sprint de discovery + document d'architecture
  • Design system et maquettes Figma sur les écrans clés
  • Interface Next.js + partie serveur Node / tRPC ou REST
  • Base de données PostgreSQL et migrations versionnées
  • Tests unitaires et E2E sur les parcours critiques
  • Déploiement en production + monitoring Sentry
  • 2 semaines de support post-livraison
PROCESS

Quatre étapes.

01

Discovery

Cadrage métier, périmètre, choix de technologies, document d'architecture livrable.

02

Design

Design system, maquettes des écrans clés, prototype interactif.

03

Build

Sprints de 1 semaine, livraisons continues sur pré-production, tests automatisés.

04

Livraison

Mise en production, monitoring branché, doc à jour, 2 semaines de support.

EN DÉTAIL

Pourquoi développer un SaaS sur mesure plutôt qu'un no-code

Webflow, Bubble, Adalo et consorts sont d'excellents outils pour valider une idée, pousser un MVP en quelques semaines ou prototyper un parcours utilisateur. Sur un produit simple — formulaires, CRUD basique, paywall standard — un builder fait le travail. Nous recommandons même cette voie quand l'objectif est uniquement de tester un marché en moins de 30 jours, sans engagement technique.

Le problème arrive quand le produit grandit. La logique métier dépasse vite les capacités d'un visual builder : règles de pricing complexes, workflows conditionnels, calculs serveur, intégrations tierces non standard. La multi-tenancy non triviale (isolation stricte des données, permissions granulaires par organisation, facturation par tenant) est presque impossible à modéliser proprement dans Bubble. Les performances se dégradent au-delà de 10 000 utilisateurs actifs : les requêtes deviennent lentes, le cache mal contrôlé, et l'on découvre qu'on ne peut pas optimiser ce que l'on ne possède pas. Les coûts d'hébergement explosent à mesure que la base utilisateurs grossit, sans qu'il soit possible de migrer ailleurs sans tout réécrire.

Plusieurs signaux indiquent qu'il faut basculer sur du développement saas sur mesure suisse romande : multi-tenancy non triviale, logique métier qui dépasse les capacités du builder, besoin d'une API publique pour des partenaires ou clients, performances au-delà de 10 000 utilisateurs actifs, contrôle de la résidence des données en CH ou UE, et surtout l'ownership total du code. Un SaaS construit en TypeScript, avec une base de données que vous possédez et un repo Git que vous transférez à n'importe quelle équipe technique, n'a pas d'équivalent en termes de pérennité. Le no-code reste un excellent point de départ ; le sur-mesure devient nécessaire dès que le produit est validé.

Architecture multi-tenant : isoler les données proprement

Tout SaaS multi-tenant repose sur un choix d'isolation. Trois patterns dominent l'industrie, chacun avec ses arbitrages.

Le premier pattern est la database-per-tenant : chaque client a sa propre base de données. Isolation maximale, simplicité conceptuelle, conformité facile à argumenter. Le coût d'hébergement explose linéairement avec le nombre de clients, et les migrations de schéma deviennent coûteuses (il faut migrer N bases, gérer les échecs partiels). Pertinent pour un saas multi-tenant à faible volume avec des exigences de souveraineté très strictes (santé, défense, finance régulée).

Le deuxième pattern est le schema-per-tenant sur Postgres : une seule base, un schéma par client. Coût d'hébergement raisonnable, isolation logique correcte, migrations centralisées mais à appliquer sur chaque schéma. Le pooling de connexions devient un sujet au-delà de quelques centaines de tenants, et certains ORMs (dont Prisma) ne gèrent pas nativement les schémas dynamiques.

Le troisième pattern, et notre default, est la row-level security (RLS) Postgres avec un `tenant_id` injecté côté serveur depuis le JWT. Chaque table sensible porte une colonne `tenant_id`, des policies RLS filtrent automatiquement les lignes selon le contexte session, et l'application n'a même pas à se préoccuper de filtrer dans les requêtes. Le coût d'hébergement reste faible, les migrations sont simples, et la sécurité est appliquée au niveau du moteur de base de données, pas du code applicatif.

Pour la conformité Swiss data residency, nous déployons sur Vercel CH region ou AWS Zurich quand la nature des données l'exige (santé, données RH, secteur public). Les sauvegardes restent dans la même juridiction, les logs sont séparés, et nous documentons le flux des données dans un registre qui satisfait à la fois la nLPD et le RGPD pour les clients européens.

Stack technique : pourquoi Next.js + TypeScript + Postgres

Next.js App Router est aujourd'hui le standard de facto pour le développement saas suisse moderne. Les server components réduisent drastiquement le JavaScript livré au client, le streaming améliore le time-to-first-byte perçu, et l'edge runtime permet de servir des contenus dynamiques depuis des points de présence proches de l'utilisateur. Concrètement, sur une plateforme next.js typescript saas typique, les React Server Components réduisent d'environ 40% le bundle JS livré côté client par rapport à une SPA équivalente.

TypeScript strict end-to-end via Prisma garantit que le typage de la base de données remonte jusqu'à l'API et au client. Une migration qui ajoute une colonne se propage automatiquement aux types Prisma, puis aux endpoints tRPC, puis aux composants React. Une rupture de contrat est détectée à la compilation, pas en production. Cette chaîne de typage élimine une catégorie entière de bugs qui hante les stacks dynamiques.

Postgres reste notre choix de base relationnelle. Les transactions ACID sont robustes, les performances sur des datasets de plusieurs millions de lignes sont prévisibles, et le support natif du jsonb permet de stocker des champs flexibles sans renoncer à l'indexation ni aux migrations propres. Le jsonb est utile pour les configurations par tenant, les métadonnées variables ou les payloads tiers — un compromis pragmatique entre rigidité et souplesse.

Comparé à Laravel — mature, écosystème solide, mais templating PHP désuet et absence de type safety end-to-end — la stack Next.js / TypeScript / Prisma offre une meilleure intégration moderne. Comparé à Express + MongoDB — rapide à démarrer mais types fragiles, transactions limitées, agrégations vite complexes — elle apporte une rigueur de modélisation qui paie sur la durée. Nous ne fétichisons pas la stack : nous l'avons choisie parce qu'elle minimise le coût total de possession sur 3 à 5 ans.

Authentification, permissions (RBAC) et sécurité

Pour l'authentification, nous utilisons NextAuth (auth.js) ou Clerk selon les besoins. NextAuth pour les projets qui veulent garder le contrôle total et héberger les sessions ; Clerk quand le client préfère externaliser la gestion des utilisateurs et bénéficier d'un dashboard prêt à l'emploi. Les deux supportent les providers OAuth standards (Google, Microsoft, GitHub, Apple), les magic links et le SSO entreprise via SAML ou OIDC.

Le RBAC granulaire repose sur un modèle rôles + permissions : un utilisateur appartient à une organisation, hérite d'un ou plusieurs rôles, et chaque rôle porte un ensemble de permissions atomiques (read:invoices, write:users, admin:billing). Cette granularité permet de modéliser des cas complexes (un comptable qui voit les factures mais pas les contrats, un manager qui valide mais ne crée pas) sans multiplier les rôles. Tous les écrans sensibles passent par un check de permission côté serveur, et chaque action critique génère un audit log (qui, quand, depuis quelle IP, sur quelle ressource).

Côté sécurité opérationnelle : MFA via TOTP ou WebAuthn, SSO Google Workspace et Microsoft Entra pour les clients B2B, cookies httpOnly + Secure + SameSite, rotation périodique des secrets via un gestionnaire (Vault, Doppler, AWS Secrets Manager), rate limiting via Upstash Redis sur les endpoints d'authentification et les API publiques, protection CSRF par tokens, headers de sécurité stricts (CSP, HSTS, X-Frame-Options).

Conformité RGPD et nLPD

Nous implémentons les droits utilisateurs (export des données au format JSON ou CSV, suppression effective avec cascade contrôlée), un cookie consent conforme aux exigences de l'OFCOM et de la CNIL, un registre des traitements documenté côté client, et la data residency CH lorsque le secteur d'activité ou le type de données l'impose. Les sous-traitants tiers (Stripe, Sentry, etc.) sont listés dans un DPA fourni au client.

Intégration paiements Suisse : Stripe et Twint

Stripe est notre rail de paiement principal pour les cartes de crédit internationales, les abonnements récurrents, l'usage-based billing et la génération automatique de factures. L'intégration couvre les webhooks robustes (idempotence, retry, file morte), la gestion des échecs de paiement avec relance automatique, et les portails clients pour gérer les moyens de paiement. La stripe twint integration suisse permet de couvrir CB et Twint via une seule passerelle.

Twint est incontournable pour les particuliers et PME suisses. Deux voies d'intégration : directement via PostFinance pour un commerçant établi, ou via la passerelle Stripe + SIX (disponible depuis 2024) qui simplifie radicalement le setup. Nous recommandons la voie Stripe pour les SaaS B2C qui ne veulent pas gérer une seconde intégration et un second réconciliateur.

Côté facturation, nous gérons la TVA suisse au taux en vigueur (8.1% standard, 2.6% réduit, 3.8% hébergement), la génération de factures PDF avec mentions légales obligatoires (numéro IDE, adresse, conditions de paiement), et le rapprochement bancaire automatique via les exports Stripe. Pour les clients européens, le SEPA Direct Debit est branché en parallèle, avec gestion des mandats et des révocations.

Tests, CI/CD et monitoring en production

Notre pipeline de qualité repose sur Vitest pour les tests unitaires et d'intégration (couverture sur la logique métier, les fonctions pures et les endpoints critiques), Playwright pour les tests E2E sur les parcours sensibles (signup, checkout, invitation d'utilisateurs), et GitHub Actions pour orchestrer la CI sur chaque pull request. Lint, typecheck et tests doivent passer au vert avant tout merge sur main.

Le déploiement passe par Vercel quand le projet le permet : preview environment automatique par PR, prod déclenchée sur main, rollback atomique en un clic. Pour les projets qui exigent un contrôle infrastructure plus fin (workloads spécifiques, contraintes de souveraineté, intégrations VPC), nous déployons sur AWS ECS avec Terraform et un pipeline GitHub Actions équivalent.

Le monitoring production combine plusieurs couches : Sentry capture les erreurs côté client et serveur avec source maps complètes, Datadog ou Logtail centralise les logs structurés (requêtes, latences, erreurs métier), Better Stack héberge la status page publique, et les alertes critiques partent dans Slack ou PagerDuty selon la sévérité. Nous documentons les SLOs (disponibilité, latence p95) dès la mise en production.

  • Lint et typecheck à chaque commit, bloquant en CI
  • Tests unitaires sur la logique métier critique
  • E2E Playwright sur les parcours utilisateurs sensibles
  • Déploiement preview automatique par pull request
  • Monitoring erreurs temps réel via Sentry, client + serveur
  • Alertes Slack ou PagerDuty selon la sévérité de l'incident

Quand choisir une agence vs un studio dev

Les grandes agences suisses ont leurs propres forces : équipes pluridisciplinaires (designers UX, architectes, QA dédiés), comités de pilotage formels, capacité à mobiliser 5 à 15 personnes en parallèle, expertise sur transformation digitale d'entreprise. Tout cela a un coût structurel.

Un studio dev comme fastdigital a un format différent : équipe restreinte (1 à 3 personnes par projet), décisions techniques rapides, livraisons fréquentes, prix accessible. Pour un MVP de startup, un module métier de PME, ou une refonte technique sous contrainte budgétaire, ce format est souvent le plus adapté.

Pour un projet de transformation à l'échelle d'une grande entreprise (équipe de 10+ personnes mobilisée 1+ an, gros comités, gouvernance complexe), une grande agence reste pertinente. Pour tout le reste — la vaste majorité des projets web, mobile et SaaS — un studio dev avec des technologies modernes livre le même résultat technique en moins de temps et à un coût plus accessible.

Le résultat technique est équivalent côté code : TypeScript strict, tests unitaires et E2E, CI/CD, monitoring, documentation d'architecture livrée. Format différent, coût plus accessible, qualité comparable.

Cas d'usage typiques chez nos clients

Premier cas : le MVP de startup en seed ou série A. Validation de marché en 12 semaines, multi-tenancy légère, paiements Stripe avec abonnements, dashboard analytique de base, onboarding utilisateur soigné. L'exemple type est une fintech qui valide un produit B2B SMB et a besoin d'un produit présentable à des investisseurs et démontrable à des clients pilotes. Le périmètre est cadré pour atteindre product-market fit, pas pour couvrir toutes les futures fonctionnalités.

Deuxième cas : les modules métier de PME software. Un éditeur SaaS existant ajoute un dashboard analytique custom, un CRM léger pour son équipe commerciale, ou un système de facturation interne. Intégration via API avec le système central, respect du design system existant, alignement sur les conventions de code de l'équipe en place. Nous arrivons sur un terrain défini, nous livrons un module qui s'intègre proprement.

Troisième cas : les refontes techniques. Une application PHP ou Laravel legacy de 5 ans ou plus qui doit migrer vers Next.js + Postgres pour reprendre la croissance, attirer des développeurs modernes, ou simplement tenir la charge. Nous procédons généralement par migration progressive, sans freeze produit : extraction de modules un par un, strangler pattern, double-écriture transitoire si nécessaire. Le métier continue de tourner, le legacy disparaît par itérations.

FAQ technique

Le code est-il transférable à une autre équipe technique ?

Oui. Documentation d'architecture livrée dès la fin du sprint de discovery, conventions de code standard (TypeScript strict, ESLint, Prettier), README détaillé avec instructions de setup local, schéma de base de données documenté avec ses relations. N'importe quelle équipe Next.js / TypeScript reprend le code en 2 à 3 jours d'onboarding. Nous n'utilisons pas de framework maison ni de patterns ésotériques.

Que se passe-t-il si nous voulons internaliser le développement après le MVP ?

Le handover est prévu dès le départ. Le repo Git est transféré au client, la documentation complète est remise, et nous prévoyons 2 à 4 heures de session de transfert technique avec votre nouvelle équipe pour expliquer les choix d'architecture et répondre aux questions. Pas de lock-in propriétaire, pas de runtime maison : le code ownership est à 100% côté client.

Pouvez-vous accompagner le scaling après livraison ?

Oui, via un contrat TMA à partir de 800 CHF par mois, ou du consulting ponctuel à 160 CHF/h. Les choix d'architecture initiaux (Postgres avec RLS, edge runtime quand pertinent, queues asynchrones via BullMQ) supportent la croissance jusqu'à plusieurs dizaines de milliers d'utilisateurs sans refonte structurelle. Nous intervenons pour les optimisations ciblées, l'ajout de modules, ou l'audit de performance lorsque le produit décolle.

Pouvez-vous travailler avec un design system imposé ou un brand guide ?

Oui. Nous intégrons un design existant fourni en Figma, avec ou sans design tokens, ainsi qu'un design system documenté dans Storybook. Si aucun design n'est en place, nous travaillons avec un designer partenaire ou nous utilisons shadcn/ui comme base technique avant de la customiser aux couleurs et typographies de la marque. Le résultat reste cohérent avec votre identité, sans repartir d'une feuille blanche inutilement.

On en parle ?

Premier échange gratuit, 30 minutes par visio. Pas de bullshit.