Comment fonctionne un SaaS :explication simple

Comment fonctionne un SaaS : chaque produit SaaS — Gmail, Slack, Notion, le vôtre — est fait de quatre parties : un frontend que voient les utilisateurs, un backend qui réfléchit, une base de données qui se souvient de tout, et une API qui transporte les messages entre eux. Si vous savez imaginer un restaurant, vous pouvez comprendre comment fonctionne un SaaS. Et dès que vous le comprenez, vous pouvez diriger l'IA pour en construire un.

Vous n'avez plus besoin d'écrire du code pour construire un produit logiciel. Mais il vous faut un modèle mental de ce que vous construisez — sinon vous prompt-ez dans le noir. Voici ce modèle, sans aucun jargon.

Comment fonctionne un SaaS : l'analogie du restaurant

Imaginez que vous dirigez un restaurant. Chaque partie d'un produit SaaS correspond à quelque chose que vous comprenez déjà :

La salle, ce sont les tables, l'éclairage, la carte — l'ambiance sur laquelle les clients vous jugent. La cuisine, ce sont les chefs qui suivent des recettes et gèrent plusieurs commandes à la fois. Le livre de recettes et l'inventaire détiennent le savoir : recettes, stock d'ingrédients, préférences des clients, historique des commandes. Et les serveurs portent les commandes à la cuisine et rapportent les plats à table.

C'est toute l'architecture. Tout le reste est détail.

Ce qui se passe quand quelqu'un clique sur « S'inscrire »

Suivons un vrai parcours à travers le restaurant, du clic au résultat :

1. Action de l'utilisateur (salle). Un visiteur remplit votre formulaire d'inscription et clique sur « Créer un compte ». Le frontend vérifie les bases — l'e-mail est-il bien formaté, le mot de passe assez long ? Comme un client qui dit au serveur qu'il veut le saumon.
2. Requête API (serveur). Le frontend envoie la requête — e-mail, mot de passe, détails — à travers Internet jusqu'à votre backend. Le serveur note la commande et l'apporte en cuisine.
3. Traitement par le backend (cuisine). Le backend vérifie si cet e-mail existe déjà, chiffre le mot de passe et applique vos règles métier. Le chef vérifie que les ingrédients sont disponibles et suit la recette.
4. Opération en base de données (livre de recettes). Le backend demande à la base d'enregistrer le nouvel utilisateur, et la base confirme. Le chef consigne la commande dans le registre de cuisine.
5. Réponse (retour du serveur). Un succès ou une erreur polie remonte au frontend. Le serveur apporte le plat — ou s'excuse s'il n'y en a plus.
6. L'utilisateur voit le résultat (salle). Un nouveau tableau de bord apparaît, ou un message « cet e-mail existe déjà ». Le client savoure son repas, ou fait un autre choix.

Chaque fonctionnalité de chaque produit SaaS que vous avez utilisé — publier un tweet, réserver sur Airbnb, envoyer un message Slack — est une variation de cette exacte boucle.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Les trois couches — et ce que chacune ne doit jamais faire

La force de ce modèle n'est pas seulement de savoir ce que fait chaque couche. C'est de savoir ce que chacune ne doit jamais faire — car c'est là que les constructions déraillent.

Le frontend affiche ; il ne décide pas. Il capte la saisie et réagit instantanément aux clics, mais il ne doit jamais stocker de données de façon permanente ni détenir de logique métier sensible. Il est aussi sans état : chaque fois qu'un utilisateur rafraîchit la page, le frontend oublie tout — comme une salle remise à zéro après chaque service. Si une information doit survivre, elle appartient à la base de données.

Le backend est le gardien. Ne faites jamais confiance au frontend. Chaque requête doit être validée, authentifiée et autorisée en cuisine — comme une bonne cuisine vérifie chaque commande, même si le serveur s'est trompé. Un utilisateur mal intentionné peut contourner vos jolis formulaires entièrement ; c'est le backend qui vous protège vraiment.

La base de données stocke ; elle ne réfléchit pas. Elle garde les données en sécurité, les retrouve vite et maintient les relations entre les choses. Elle ne prend pas de décisions métier, ne met pas les données en forme pour l'affichage et n'envoie pas d'e-mails. C'est le livre de recettes, pas le chef.

L'API est un contrat. Elle définit exactement comment frontend et backend se parlent — et si vous changez le contrat, vous cassez le code existant. Le serveur et la cuisine doivent s'accorder sur le format de la commande.

Pourquoi la base de données est reine

Voici l'intuition que la plupart des débutants ratent : la structure de vos données détermine tout le reste. Si la conception de la base est mauvaise, aucun joli frontend ni backend astucieux ne peut vous sauver. Mauvaise fondation, maison de travers — pour toujours.

Cela renverse l'instinct de s'obséder d'abord sur l'interface. Le site n'est pas le produit ; c'est l'interface du produit. Le vrai produit, c'est votre modèle de données plus votre logique métier. Une interface peut être redessinée n'importe quel week-end. Restructurer une base qui contient déjà des données clients est vraiment pénible. Concevez donc la fondation d'abord — j'ai détaillé exactement comment dans les bases de données expliquées aux fondateurs non techniques.

Une idée fausse de plus à tuer : backend et base de données ne sont pas la même chose. Le backend, c'est de la logique. La base de données, c'est du stockage. Deux métiers totalement différents, et quand vous parlerez de votre produit à l'IA, vous devrez nommer le bon.

Pourquoi ce modèle mental compte quand on construit avec l'IA

L'IA écrit le code désormais — les outils pour construire un vrai produit coûtent quelques centaines d'euros par mois, pas le salaire d'une équipe de développeurs. Mais l'IA a besoin de direction, et diriger exige de savoir de quelle couche on parle :

• « Ajoute un bouton » → frontend
• « Vérifie que les e-mails sont uniques » → backend
• « Enregistre les préférences de l'utilisateur » → base de données

Le modèle vous dit aussi où vivent les problèmes. Page lente à charger ? Cela peut venir du frontend ou d'une requête du backend. Mauvaises données à l'écran ? Cela peut venir du contrat d'API ou de la base. Les fondateurs sans cette carte finissent par prompter à l'aveugle, en acceptant tout ce que produit l'IA — ce qui est précisément la façon de tomber dans le piège du vibe coding. Ceux qui l'ont prennent de vraies décisions d'architecture : faut-il calculer ceci dans le frontend ou le backend ? Est-ce une nouvelle table ou une nouvelle colonne ?

Vous n'apprenez pas à cuisiner. Vous apprenez assez sur le fonctionnement d'un restaurant pour en être le propriétaire.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Questions fréquentes

Quelle est la différence entre le frontend et le backend ?

Le frontend s'exécute dans le navigateur de l'utilisateur et regroupe tout ce qu'il voit et sur quoi il clique — la salle. Le backend s'exécute sur un serveur et réfléchit : il applique les règles, vérifie les permissions, traite les requêtes — la cuisine. Les utilisateurs ne voient jamais le backend, mais c'est là que se fait le vrai travail.

Où sont réellement stockées les données de mon SaaS ?

Dans la base de données — la seule couche où les données survivent durablement. Le frontend oublie tout au rafraîchissement, et le backend traite les requêtes sans les conserver. Comptes utilisateurs, commandes, paramètres : tout vit dans des tables de la base, comme les recettes et l'inventaire dans le livre du restaurant.

Dois-je comprendre le code pour construire un SaaS avec l'IA ?

Non — mais il vous faut ce modèle mental. L'IA écrit l'implémentation ; vous décidez à quelle couche appartient une fonctionnalité, vous relisez ce qui revient, et vous repérez quand quelque chose est au mauvais endroit. C'est une compétence de propriétaire, pas un diplôme d'ingénieur.

Dois-je concevoir d'abord l'interface ou la base de données ?

La base de données. Vos données survivent à votre code — l'interface peut être redessinée à l'infini, mais changer un modèle de données qui contient déjà de vrais enregistrements clients est pénible. Réussissez d'abord la fondation et chaque couche au-dessus devient plus facile.