Boilerplate SaaS : quelle base choisir quand on construit seul avec l’IA ?

Comparer trois bases de code sur un même besoin : prérequis, services externes, changement métier, maintenance et sortie. Une lecture des documents éditeurs, sans prétendre à un test des kits.

Un boilerplate SaaS, ou starter kit, est une base de code qui prépare des éléments communs : connexion, pages, paiement ou accès aux données. Pour choisir, regardez ce qu’il faudra ajouter à votre projet et ce que vous saurez entretenir. Une longue liste de fonctions ne dit pas à elle seule quelle base vous conviendra.

Nous comparons ici ShipFast, Makerkit et Open SaaS à partir de leurs pages officielles consultées pour ce guide. Aucun kit n’a été acheté, installé ou testé dans cette comparaison. Les difficultés de prise en main restent donc à constater ; les promesses de rapidité des vendeurs ne sont pas reprises comme des résultats.

Le fil conducteur est un projet fictif : ajouter une collecte de pièces avec les états attendu, reçu et à corriger. Une variante sert une personne seule ; l’autre accueille plusieurs agences avec leurs équipes. Le même besoin permet de poser des questions comparables aux trois solutions sans inventer un classement.

Comprendre ce que vous achetez ou récupérez

Une base de code n’est pas nécessairement une application prête à vendre. Elle fournit une structure que vous devez adapter, configurer et héberger. Les comptes chez les prestataires, les données de votre métier et les conditions de votre offre restent à préparer selon le fonctionnement retenu.

Un outil sans code propose généralement une interface pour construire et exploiter un projet. Un starter fournit du code destiné à être travaillé. Un agent IA peut aider à ce travail, mais il ne supprime pas les choix de stockage, de sécurité, de déploiement et de maintenance que cette base implique.

Commencez donc par votre mode de travail : qui relira les modifications, qui pourra résoudre un lancement bloqué et qui suivra les mises à jour ? Si personne ne sait répondre, la première étape consiste à organiser cet accompagnement. Le choix du kit ne réglera pas à lui seul ce manque.

Votre comparaison doit distinguer disponible dans la base, à configurer, à développer et non vérifié. Évitez une seule colonne « inclus » : un formulaire de connexion présent ne signifie pas que les emails partent depuis votre domaine ou que tous les parcours de votre produit sont protégés.

Définir un changement métier identique

Dans notre exemple fictif, une personne crée un dossier, ajoute une pièce attendue, marque sa réception puis demande une correction avec une explication. Elle quitte l’application et revient retrouver l’état du dossier. Ce parcours est assez petit pour être observé, mais dépasse une simple retouche de couleur.

Pour la variante individuelle, chaque personne retrouve ses dossiers autorisés. Pour la variante B2B, les dossiers appartiennent à une agence ; plusieurs membres travaillent ensemble et une personne peut participer à deux agences. Cette distinction change le modèle des données et les vérifications nécessaires.

Préparez une sortie attendue pour chaque action : quel état apparaît, ce qui est conservé et qui peut le lire. Ajoutez un refus attendu, par exemple l’impossibilité de modifier un dossier hors de son espace. Une comparaison utile regarde aussi ce que la base aide à empêcher.

N’imposez pas immédiatement votre méthode technique à l’agent. Demandez d’abord comment le kit représente ses utilisateurs, ses données et ses règles. Une adaptation qui ignore les conventions existantes risque de produire deux façons concurrentes de faire la même chose, difficiles à maintenir ensemble.

Pour comprendre · illustration du guide

ShipFast : examiner une base Next.js généraliste

La page officielle de ShipFast présente une base Next.js avec des éléments pour la connexion, les paiements, les emails, les données et les pages commerciales. L’éditeur cite plusieurs services possibles, notamment Stripe, MongoDB ou Supabase. Ce sont des indications documentaires, pas la vérification d’une configuration particulière.

Pour notre dossier individuel, la question serait : où ajouter les pièces et comment relier chaque dossier à la bonne personne ? Pour la variante agence, il faudrait vérifier ce qui couvre les organisations, invitations et droits de groupe. Nous n’avons pas établi ici l’existence d’un parcours complet correspondant à cette seconde demande.

Avant de retenir cette base, demandez un inventaire des comptes et réglages nécessaires à la version choisie. Faites préciser les exemples à retirer, la procédure de démarrage et les vérifications du premier changement. La familiarité de l’accompagnant avec Next.js peut être un critère pratique, sans démontrer une supériorité générale.

Makerkit : identifier la variante et le modèle d’équipe

Makerkit propose plusieurs bases. Pour éviter de mélanger leurs caractéristiques, notre référence est sa documentation Next.js et Supabase. Elle décrit notamment les comptes d’équipe, les règles d’accès, la facturation et le déploiement. Cette structure documentée rend la variante pertinente à examiner pour un projet destiné à des organisations.

Le guide d’installation de cette variante appartient à un parcours de développement. Il faut prévoir l’environnement demandé et les services associés. Cette documentation ne transforme pas le kit en éditeur visuel utilisable sans travail sur le code.

Pour notre agence fictive, demandez comment un dossier rejoint un compte d’équipe et quelles règles s’appliquent aux membres. L’intérêt éventuel serait de prolonger un modèle déjà présent. Il reste à vérifier que ce modèle correspond aux droits souhaités, notamment aux personnes qui appartiennent à plusieurs entreprises.

N’ajoutez pas des rôles par leur seul nom. « Administrateur » peut recouvrir des droits différents selon le produit. Écrivez les actions permises et refusées, puis demandez comment elles se traduisent dans cette version précise du kit. Les fonctionnalités d’une autre variante ne doivent pas être présumées disponibles.

Open SaaS : examiner les conventions de Wasp

La documentation d’Open SaaS présente une base ouverte fondée sur Wasp, avec React, Node.js et Prisma. Elle documente notamment l’authentification, les paiements, les emails et les fichiers. Les services externes restent à choisir et à configurer ; l’accès au code ne signifie pas que l’exploitation ne coûte rien.

Pour notre parcours de pièces, l’accompagnant devra comprendre comment Wasp décrit l’application, les données et les actions. Un agent habitué à un autre cadre doit lire ces conventions avant d’ajouter des fonctions. Demandez qu’il explique simplement où le dossier est conservé et où son accès est contrôlé.

La présence d’une connexion et d’un tableau d’administration ne permet pas de conclure que les équipes B2B souhaitées sont déjà couvertes. Pour la variante agences, les invitations, les appartenances multiples et les limites entre espaces doivent être vérifiées séparément. Leur état reste non testé dans cette comparaison.

L’intérêt de cette piste dépend donc aussi de la capacité à travailler avec Wasp dans la durée. Un dépôt accessible facilite la lecture du point de départ ; il ne prouve pas que vous saurez reprendre une personnalisation ni qu’une future mise à jour s’appliquera sans travail.

Préparer les accès avant le premier lancement

Pour chaque candidat, établissez la liste des services réellement retenus : stockage, emails, paiement, hébergement et éventuellement traitement IA. Ajoutez le propriétaire du compte, l’usage prévu et le réglage nécessaire pour l’essai. Ne créez pas tous les comptes cités par la page commerciale si votre parcours n’en a pas besoin.

Séparez les accès de test et les accès réels. Les clés confidentielles ne doivent pas être copiées dans un article, un fichier public ou une conversation inutile. Demandez où elles sont enregistrées, qui les utilise et comment les remplacer si elles ont été exposées.

Le premier lancement doit pouvoir être décrit sans mystère : télécharger la version autorisée, installer ses prérequis, préparer la configuration puis ouvrir l’application. Notez le point où une intervention humaine devient nécessaire. Une capture de la page d’accueil ne démontre pas encore que les services associés fonctionnent.

Dans la fiche de choix, laissez la difficulté vide tant que l’essai n’a pas eu lieu. Après l’essai, inscrivez les blocages rencontrés et la manière de les résoudre. Vous produirez ainsi votre propre observation au lieu de convertir un slogan de mise en route rapide en durée prévisible.

Faire travailler un agent sur une modification limitée

Donnez le parcours métier, la version exacte du kit et les documents qui la concernent. Demandez un plan court : éléments existants réutilisés, changements nécessaires et contrôles prévus. Faites relever les informations manquantes avant que l’agent construise sa propre interprétation d’un rôle ou d’un dossier.

Une consigne possible serait : « Ajoute la demande de correction d’une pièce avec un motif. Réutilise les règles d’accès du projet. Explique qui peut agir et montre le résultat après une nouvelle connexion. Signale ce qui reste non vérifié. » Elle définit un résultat et une limite sans dicter tous les fichiers à modifier.

Examinez le résultat sur des données fictives. Essayez un motif vide, un dossier inexistant et une action provenant d’un autre espace. Demandez aussi à retrouver l’état précédent si la modification doit être annulée. Ces vérifications ne constituent pas un audit de sécurité, mais évitent de juger seulement la partie visible.

Conservez une note des personnalisations. Un kit devient rapidement votre application : règles ajoutées, fonctions retirées et services remplacés. Cette trace aide la personne ou l’agent qui reprendra le travail plus tard à distinguer les choix du fournisseur de vos propres décisions.

Comprendre comment les mises à jour arriveront

Demandez ce que signifie « mises à jour incluses » : accès aux nouveautés du kit, correction de dépendances ou application automatique à votre projet ? Ces opérations ne sont pas équivalentes. Votre code personnalisé peut demander une adaptation et une nouvelle vérification même si le fournisseur publie une correction.

Le guide d’Open SaaS consacré aux mises à jour d’une application personnalisée distingue l’évolution du modèle et celle du projet construit à partir de lui. Cette question mérite d’être posée aux trois candidats : quelles modifications récupérer, comment les comparer et quels parcours rejouer ensuite ?

Préparez une petite liste des parcours à vérifier après une mise à jour : connexion, dossier, droits, envoi utile et comportement de facturation si présent. Ajoutez vos règles métier. Une page qui démarre après une modification ne suffit pas à prouver que l’ensemble du service reste cohérent.

Évaluer le coût complet et la possibilité de sortie

Comparez le coût du kit, les services externes, l’accompagnement et le temps de maintenance sur le même périmètre. Relevez les tarifs et licences au moment de votre décision ; ils ne sont pas figés dans ce guide. Une offre moins chère à obtenir peut demander davantage d’adaptation pour votre cas.

Vérifiez ce que vous pourrez conserver et exploiter selon les licences : code modifié, données, documents et configuration. Avoir une copie du code ne donne pas automatiquement une procédure de reprise. Demandez comment redémarrer ailleurs et quelles dépendances resteraient à remplacer.

Pour un projet individuel, examinez d’abord la base que votre accompagnant sait comprendre et maintenir avec le moins d’adaptations inutiles. Pour des agences avec équipes, étudiez le modèle d’organisation dès le départ. Une inscription individuelle réussie ne répond pas à cette seconde exigence.

La fiche de choix des starters SaaS rassemble les constats documentaires et le même essai à renseigner pour les trois kits. Elle ne désigne aucun gagnant universel. Retenez une base lorsque vous pouvez expliquer ce qu’elle apporte, ce qu’il reste à construire et qui pourra la faire évoluer.