Boilerplate SaaS Next.js ou développement sur mesure : ce que le kit livre vraiment, et ce qu'il coûte au premier client qui sort du cadre

---

title: "Boilerplate SaaS Next.js ou développement sur mesure : ce que le kit livre vraiment, et ce qu'il coûte au premier client qui sort du cadre" seoTitle: "Boilerplate SaaS Next.js ou sur mesure ?" description: "Un kit à 300 € livre réellement six à huit semaines de travail. Le calcul ne se joue pas là : il se joue sur la première fonctionnalité que le kit n'avait pas prévue, et sur les trois hypothèses qu'il a figées à votre place avant que vous ayez un client." seoDescription: "Ce qu'un boilerplate SaaS Next.js livre vraiment, les trois hypothèses qu'il fige, et le coût réel de la première fonctionnalité qui sort de son cadre." date: "2026-10-04" author: "Équipe Raicode" tags: ["saas", "mvp", "architecture", "développement"] category: "SaaS & MVP" keywords: ["boilerplate SaaS Next.js", "starter kit SaaS", "MakerKit supastarter Nexty", "boilerplate ou sur mesure", "coût MVP SaaS", "multi-tenant boilerplate", "Stripe abonnement Next.js", "dette technique starter kit"]

Le moment où le calcul bascule est toujours le même, et il n'arrive jamais pendant les six premières semaines. Un founder achète un boilerplate Next.js à 299 €, met son produit en ligne en un mois et demi, encaisse ses premiers abonnements. Tout fonctionne. Puis arrive le prospect qui pèse dix fois les autres : une ETI, quarante utilisateurs, un acheteur qui veut une facture annuelle sur bon de commande, un DSI qui demande l'authentification par l'annuaire maison, et une filiale belge qui doit voir ses propres données sans voir celles de la maison mère. Trois demandes banales. Le founder annonce deux semaines. Il en passera sept, dont cinq à défaire ce que le kit avait décidé pour lui.

Ce n'est pas une histoire sur la qualité des boilerplates. Les kits qui tiennent aujourd'hui le haut des résultats sur « prestataire développement SaaS Next.js » — MakerKit, supastarter, Nexty — sont du code sérieux, maintenu, souvent mieux testé que ce que produit une agence sous contrainte de budget. L'histoire porte sur autre chose : un kit ne vous vend pas du code, il vous vend des décisions d'architecture déjà prises, et la facture ne tombe pas à l'achat. Elle tombe à la première fonctionnalité qui sort du cadre.

Ce qu'un kit livre réellement

Commençons par rendre justice au produit, parce que le réflexe inverse — « ce n'est que du code générique » — est faux et coûte cher aussi.

Un boilerplate SaaS Next.js sérieux livre, en 2026 : l'authentification complète avec vérification d'email, réinitialisation de mot de passe, OAuth sur deux ou trois fournisseurs et souvent le second facteur ; un modèle de comptes multi-utilisateurs avec invitations, rôles et permissions ; l'intégration Stripe avec les abonnements, les webhooks, le portail client et la gestion des échecs de paiement ; un tableau de bord d'administration ; les emails transactionnels avec leurs gabarits ; l'internationalisation ; les tests end-to-end du parcours d'inscription ; et un pipeline de déploiement qui fonctionne.

Chiffré honnêtement, c'est six à huit semaines de travail d'un développeur expérimenté, à condition qu'il connaisse déjà la stack. À 500 € par jour, on parle de 15 000 à 20 000 € de travail vendus quelques centaines d'euros en licence perpétuelle. Personne ne devrait refuser cet arbitrage par principe, et nous l'avons déjà intégré à notre grille de comparaison dans SaaS ou développement sur mesure : la ligne « développement » d'un devis de MVP n'est plus un bloc insécable, une partie est du travail que personne ne vous paiera jamais pour refaire.

La question utile n'est donc pas « faut-il partir d'un kit ». Elle est : qu'est-ce que ce kit a décidé pour moi, et combien me coûtera la première décision que je devrai défaire ?

La propriété du code n'est pas le sujet

Il faut écarter d'emblée la comparaison dans laquelle tout le monde glisse. Le débat no-code contre sur-mesure porte sur la propriété et la réversibilité : sur une plateforme fermée, vous louez votre produit et vous sortez difficilement. Ce n'est pas le cas ici. Un boilerplate vous livre un dépôt Git, en TypeScript, que vous possédez et que vous pouvez modifier ligne à ligne dès le premier jour. La réversibilité est totale sur le papier.

Le piège est ailleurs, et il est plus subtil : vous possédez un code dont vous n'avez pas pris les décisions structurantes, et que vous n'avez pas lu. Entre « posséder » et « maîtriser » il y a l'écart qui se paie au premier écart justement. Un développeur qui a construit son modèle de données sait pourquoi chaque table est là. Un founder qui a acheté un kit découvre son schéma le jour où il doit le changer — c'est-à-dire sous pression commerciale, avec un prospect qui attend.

Les trois hypothèses qu'un kit fige à votre place

Dans tout ce que livre un boilerplate, l'essentiel se refait sans douleur. Le design se remplace, les emails se réécrivent, le tableau de bord se refond. Trois choses ne se refont pas à coût raisonnable, et ce sont exactement les trois que le kit a décidées avant que vous ayez un client. Ce sont les mêmes fondations que nous décrivons dans multi-tenant et facturation par abonnement ; la différence ici, c'est que vous ne les avez pas choisies.

1. Le modèle de tenancy

Presque tous les kits du marché partent du même postulat : un utilisateur appartient à une organisation, une organisation a un abonnement, les données portent une colonne qui référence l'organisation. C'est le modèle le plus courant et il couvre probablement 80 % des SaaS B2B.

Il casse dès que la réalité de votre marché s'écarte du postulat. Un utilisateur qui appartient à deux organisations et bascule de l'une à l'autre : supporté par certains kits, pas par tous. Une hiérarchie à deux niveaux — un groupe, ses filiales, une facturation consolidée mais des données cloisonnées : supporté par presque aucun. Une organisation qui doit partager un sous-ensemble de ses données avec une autre : jamais.

Le coût du changement n'est pas dans le schéma, où ajouter une table prend une heure. Il est dans les centaines de points du code où la frontière du tenant est appliquée : chaque requête, chaque route d'API, chaque politique de sécurité au niveau des lignes, chaque job de fond. Un kit qui applique cette frontière au niveau de la base, par des politiques RLS Postgres, se rattrape ; un kit qui la réapplique à la main dans chaque fonction de service vous oblige à relire l'intégralité du code applicatif, en sachant qu'un oubli est une fuite de données entre clients.

Comptez trois à six semaines pour passer d'un modèle plat à un modèle hiérarchique sur un produit déjà en production, avec des données à migrer et personne pour tolérer une interruption.

2. Le modèle de facturation

Le deuxième postulat est encore plus uniforme : un abonnement mensuel ou annuel, un plan, un prix par siège ou forfaitaire, géré dans Stripe Checkout, avec les droits dérivés du nom du plan.

Cette dernière partie est le vrai piège. Dans beaucoup de kits, le contrôle d'accès à une fonctionnalité s'écrit littéralement « si le plan vaut pro ». Ça marche jusqu'au jour où vous vendez un plan pro avec une option, un tarif négocié hors grille, un essai étendu à un client, ou une offre annuelle avec un quota différent. Vous devez alors introduire une notion d'entitlements — les droits réels d'un compte, découplés du nom commercial de son plan — et la réintroduire partout où le nom du plan était testé.

Ajoutez la facturation sur bon de commande, que tout premier gros client B2B français finit par demander : facture annuelle, virement, paiement à 45 jours. Stripe sait le faire, mais le kit, lui, a câblé le cycle de vie de l'abonnement sur les webhooks de paiement par carte. Un compte actif sans paiement encaissé n'existe pas dans son modèle d'états.

Comptez deux à quatre semaines pour découpler les droits du plan et introduire un second circuit de facturation, sur un produit qui encaisse déjà.

3. Le modèle d'authentification

Le troisième postulat : email et mot de passe, plus deux ou trois OAuth grand public. Suffisant pour du self-service, insuffisant au premier client dont le DSI impose l'annuaire d'entreprise.

L'ajout de SAML ou OIDC n'est pas, en soi, un travail monstrueux — les fournisseurs d'identité modernes l'industrialisent. Le problème est que la connexion par annuaire change deux choses dans la logique produit : le provisionnement des comptes n'est plus l'invitation par email que le kit a construite, et l'appartenance à l'organisation est désormais décidée par l'annuaire du client, pas par votre table d'invitations. Si votre kit a lié invitation, création de compte et rattachement au tenant dans le même flux — ce qu'ils font presque tous — vous devez découper ce flux en trois.

Comptez deux à trois semaines, plus le temps de recette avec l'annuaire du client, qui n'est jamais disponible quand vous l'êtes.

Le calcul honnête

Mettons les deux colonnes en face, sur un produit réel qui a trouvé son premier client exigeant au sixième mois.

Sur kit : 299 € de licence, six semaines pour la mise en ligne, soit environ 15 000 € de travail économisés. Puis, au premier client hors cadre, sept à treize semaines pour défaire les trois hypothèses, dans le pire des cas — rarement les trois en même temps, mais rarement une seule non plus. Appelons-le quatre à huit semaines en pratique, soit 10 000 à 20 000 € de travail, dont une partie est du travail à perte : vous payez pour retirer du code, pas pour en ajouter.

Sur mesure : douze à seize semaines pour la mise en ligne, soit 30 000 à 40 000 €, en prenant les fourchettes d'agence que nous détaillons dans comment lire un devis de MVP. Puis, au même client exigeant, une à trois semaines par demande, parce que les frontières ont été posées en connaissance de cause — à condition, précisément, qu'elles l'aient été.

Le kit reste gagnant sur le total. Mais il déplace la dépense à l'endroit le plus dangereux du cycle de vie d'un produit : le moment où vous avez un client qui attend, des utilisateurs en production et aucune marge de manœuvre sur le calendrier. Les six semaines économisées au début sont sûres ; les sept semaines dépensées au sixième mois tombent au pire moment possible et sur le contrat qui comptait. C'est exactement le type d'arbitrage que nous traitons dans la dette technique d'un MVP : la dette acceptable est celle dont vous connaissez l'échéance.

Lire un kit avant de l'acheter

Si vous partez sur un kit — et c'est souvent la bonne décision — quatre heures de lecture avant l'achat valent mieux que sept semaines de rattrapage. Les kits sérieux donnent accès à leur documentation technique complète et à une démo du code ; ceux qui refusent les deux sont une réponse en soi.

Cherchez le schéma de base de données. C'est le seul artefact qui ne ment pas. Combien de niveaux entre un utilisateur et un tenant ? Un utilisateur peut-il appartenir à plusieurs tenants ? Y a-t-il une table d'abonnement distincte de la table d'organisation ?

Cherchez où la frontière du tenant est appliquée. Faites une recherche sur l'identifiant d'organisation dans le code. S'il apparaît dans des politiques de sécurité au niveau de la base, c'est un bon signe. S'il n'apparaît que dans des conditions de requêtes applicatives, comptez un audit complet de ces points le jour où le modèle change.

Cherchez le mot « plan » dans la logique métier. Si le nom du plan est testé ailleurs que dans une couche de droits dédiée, vous savez déjà où sera votre premier chantier.

Lisez la licence. Perpétuelle ou par an, par développeur ou par projet, et surtout : nombre de projets couverts. Un founder qui lance un second produit découvre parfois qu'il doit racheter.

Regardez le rythme de mise à jour — et acceptez que vous n'en profiterez pas. C'est le coût caché le moins discuté. Au moment où vous écrivez votre première ligne métier, vous forkez. Trois mois plus tard, le kit a changé de version de Next.js, de bibliothèque d'authentification ou de client Stripe, et vous n'avez plus aucun moyen raisonnable d'absorber la mise à jour : votre code et le sien se sont mélangés dans les mêmes fichiers. Considérez qu'un kit est un instantané, pas une dépendance. La maintenance redevient la vôtre dès le premier jour, ce qui change l'argument de vente mais pas le calcul initial.

Quand le kit est le bon choix, et quand il ne l'est pas

Le kit gagne quand votre produit est du SaaS B2B self-service standard : une organisation, des utilisateurs, trois plans, paiement par carte, croissance par le haut du tunnel. Il gagne aussi quand votre objectif immédiat est de valider une demande, pas de servir un grand compte : à ce stade, six semaines de gagnées valent tous les refactorings futurs, parce que le scénario le plus probable reste que vous jetiez le produit.

Le kit perd quand une des trois hypothèses est fausse dès votre premier client cible : vous vendez à des groupes avec des filiales, votre facturation est à l'usage ou négociée au cas par cas, votre marché impose l'annuaire d'entreprise dès la première signature, ou vos données sont réglementées au point que l'isolation doit être démontrable par écrit. Dans ces cas-là, acheter un kit revient à payer 299 € pour hériter d'un chantier de réécriture, et il est moins coûteux de poser vous-même ces trois fondations — ou de les faire poser — avant d'écrire la moindre ligne de métier. C'est l'un des cadrages que nous faisons systématiquement en ouverture d'un développement de MVP SaaS, avant d'arbitrer entre socle acheté et socle construit : la question n'est pas le prix du point de départ, c'est quelle hypothèse votre marché va casser en premier.

Le cas intermédiaire, qui est le plus fréquent, est celui où une seule hypothèse est fragile. Il a une réponse intermédiaire : prenez le kit, et réécrivez cette couche-là tout de suite, pendant que le produit n'a pas d'utilisateurs. Découpler les droits du nom du plan prend trois jours avant le lancement et trois semaines après. Introduire un niveau hiérarchique dans le modèle de tenant prend une semaine sur un schéma vide et un mois sur une base vivante.

La prochaine action

Avant d'acheter, ou avant de continuer sur le kit que vous avez déjà : prenez votre liste des cinq clients que vous voulez signer dans les douze prochains mois — pas des personas, des noms d'entreprises réelles. Pour chacun, répondez par oui ou non à trois questions. A-t-il une structure à plusieurs entités ? Va-t-il exiger une facturation hors carte bancaire ? Son service informatique imposera-t-il une connexion par annuaire ?

Si vous obtenez trois « non » sur cinq entreprises, achetez le kit sans hésiter et allez chercher vos clients. Si une des trois questions reçoit un « oui » majoritaire, vous connaissez maintenant la couche à réécrire, et vous savez qu'elle coûte une semaine aujourd'hui contre un mois dans six mois. C'est toute la décision, et elle se prend en une heure.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.