SYS/SAAS
Un produit, pas un stack de slides.
Création de SaaS sur mesure : CRM, portail client, outil métier
Un SaaS sur mesure, c'est un vrai produit — pas un empilement de slides ni un tableur qui déborde. On cadre le besoin, on modélise les données, on développe en Django, GraphQL et React, et on livre un outil qu'une petite équipe peut faire tourner.
La création de SaaS fait partie de notre expertise Produits digitaux — prototypage, SaaS et landing pages.
SYS/FOR
Pour qui
Outil interne à sortir des tableurs
Un process qui vit dans dix onglets Sheets partagés : on le transforme en application maîtrisée, avec des droits et un historique.
Portail client à ouvrir
Donner à vos clients un espace pour suivre, déposer, valider — au lieu d'échanges d'e-mails sans fin.
Produit à lancer sans équipe tech
Une idée de SaaS, pas de CTO : on cadre, on construit et on livre un MVP que vous pouvez montrer et vendre.
SYS/SCOPE
Ce que ça couvre
Six briques. Dépliez une carte pour voir ce qu'elle contient concrètement.
Cadrage et PRD
Parcours, écrans et règles métier écrits noir sur blanc avant la première ligne de code.
Ce que ça donne
Un PRD par étape du produit : objectif, données, actions, règles, états d'erreur. C'est le document qui cadre le travail des agents pendant tout le build — et qui permet de dire non à une fonctionnalité sans rouvrir le débat. Un prototype cliquable existant remplace avantageusement cette étape.
Modèle de données multi-tenant
Une base pensée pour isoler chaque compte proprement, dès le départ.
Ce que ça donne
Schéma PostgreSQL, entités, relations et clé de tenant portée par chaque requête. L'isolation se décide au premier jour : rajoutée après coup, elle impose une migration de toutes les tables et de toutes les requêtes.
API GraphQL Django
Un back-end robuste et typé, qui expose exactement ce dont le front a besoin.
Ce que ça donne
Un schéma typé, des resolvers testés et des mutations qui portent les règles métier. Le typage sert aussi de garde-fou aux agents : une requête inventée ne compile pas, elle ne part pas en production.
Front React
Une interface réactive et maintenable, alignée sur les maquettes validées.
Ce que ça donne
Des composants repris des écrans HTML du prototype, branchés sur l'API : ce qui a été validé cliquable devient l'interface réelle, sans phase de re-design intermédiaire.
Auth et rôles
Authentification, permissions et gates par rôle, côté front comme côté back.
Ce que ça donne
Un rôle par type d'utilisateur, une vérification côté serveur pour chaque action sensible, et le même gate répliqué côté interface pour ne pas afficher ce qui sera refusé. Le contrôle côté front est du confort ; celui du back est la sécurité.
Déploiement VPS
Mise en production sur VPS (nginx, base, cache), avec un chemin de déploiement reproductible.
Ce que ça donne
nginx en frontal, PostgreSQL et Redis derrière, un déploiement rejouable et des sauvegardes. Le dépôt, la base et le serveur vous appartiennent : aucun enfermement dans une plateforme propriétaire.
SYS/AI
Ce que l'IA change ici
Le studio construit du logiciel avec des agents dans la boucle, sous un protocole nommé GSD : chaque phase — plan, exécution, audit — passe par un agent dédié, relu par un humain. C'est ce qui permet à une personne de livrer un produit, pas un prototype jetable.
Avant
Un SaaS sur mesure supposait une équipe : un back, un front, un lead qui tient la cohérence. Une personne seule pouvait maquetter, pas livrer. Le budget d'un outil métier partait donc soit vers un éditeur qui ne correspond qu'à moitié, soit vers un empilement de tableurs que plus personne ne maîtrise.
Seuil d'équipe
Trois profils minimum pour tenir un produit multi-tenant, ses droits et son déploiement.
Coût du sur-mesure
Un outil vraiment adapté restait réservé aux structures capables de financer une équipe interne.
Avec des agents
Le travail est découpé en phases, chacune confiée à un agent dédié sous le protocole GSD, avec un plan écrit avant l'exécution et un audit après. RankyDocky — CRM multi-tenant, 33 modules — est construit exactement ainsi : c'est ce qui permet à une personne de livrer un produit et pas une démo. L'audit SEO & GEO, fork d'origine, automatise les analyses clients.
Protocole
GSD encadre le travail des agents : plans écrits, exécution par tâches, audits systématiques — la vitesse sans le chaos.
Skills projet
Des skills spécifiques au projet donnent le contexte aux agents. On l'explique en détail sur la page AI engineering.
Ce qui reste humain
Le modèle de données, l'isolation entre comptes et les permissions ne se délèguent pas : ce sont les décisions qu'on ne peut pas corriger après coup sans tout migrer. Le périmètre du MVP non plus — savoir ce qu'on ne construit pas est la moitié du travail. Chaque tâche produite par un agent est relue avant d'être commitée.
Architecture
Modèle de données, isolation multi-tenant et rôles : décidés et relus à la main, ligne à ligne.
Périmètre
Arbitrer le MVP, refuser la fonctionnalité de trop, décider quand le produit est prêt à passer en production.
SYS/LOOP
Comment on fait
De l'idée au produit en production, par itérations courtes.
- 01Cadrer — PRD, parcours et écrans clés — se mettre d'accord sur le produit avant de coder.
- 02Modéliser — schéma de données multi-tenant, entités et relations pensés pour durer.
- 03Construire — API GraphQL Django et front React, développés avec des agents et relus.
- 04Sécuriser — authentification, rôles et permissions vérifiés côté front et back.
- 05Déployer — mise en production sur VPS, avec un chemin de déploiement reproductible.
SYS/PROOF
Preuves
| Mesure | Inscrits |
|---|---|
| Objectif | 3 000 |
| Réalisé | 6 300 |
Plateforme de 60 webinaires sur 5 jours · 15 000 heures visionnées · NPS 60.
RankyDocky n'a pas de métrique d'usage publique — on l'écrit plutôt que d'inventer un chiffre. Ce qui est vérifiable, c'est la surface : 33 modules, isolation tenant, Django, GraphQL, React, GSD. L'audit SEO & GEO, en production pour les missions, se branche sur le même backend.
Outil métier · SEO / GEO
Audit SEO & GEO
En production
Outil interne pour les analyses clients. Intégrable à RankyDocky.
Produit · prototype
BAO (docAgency)
34 écrans
Parcours guidé en 13 étapes, 10 PRD, export PDF banque.
Le portail client de Shamalo lui-même est en construction sur cette stack (à venir).
SYS/TOOLS
Outils
- Django
- GraphQL
- React
- PostgreSQL
- Redis
- nginx
- GSD
SYS/FAQ
Questions fréquentes
Sur mesure ou no-code ?
Le no-code va vite pour valider une idée : un Airtable, un Webflow + logique, un outil métier collé. Il plafonne dès qu'il faut un modèle de données propre, des droits fins, des volumes, des intégrations, de la tenancy. Le sur mesure coûte plus au départ et rend la main sur le produit et le code.
PlusMoins
Shamalo construit du sur mesure (Django, React, GraphQL — le même genre de stack que RankyDocky) quand l'outil est le métier. On ne force pas un rebuild si un no-code honnête suffit encore six mois.
L'appel sert à voir de quel côté du plafond vous êtes. « On verra plus tard pour les rôles » est souvent le moment où plus tard est déjà trop tard.
Combien de temps pour un MVP ?
Quelques semaines pour un premier produit utilisable, selon le périmètre. Les agents dans la boucle accélèrent la production ; le cadrage et la relecture restent le facteur limitant — et c'est tant mieux. Un MVP flou livré vite est plus cher qu'un MVP étroit livré juste.
PlusMoins
Un proto HTML en amont (levier Prototypage) fait gagner ce temps : on ne découvre pas les flux pendant le build. BAO est passé par 34 écrans avant le code ; RankyDocky est un CRM de 33 modules, réellement en prod. L'audit SEO & GEO est le backend d'analyse du studio.
Personne ne devrait promettre « l'équivalent d'une équipe de huit en dix jours ». On promet un périmètre écrit et un rythme.
Qui possède le code ?
Vous. Le dépôt, la base et l'infrastructure vous reviennent. Pas d'enfermement dans une plateforme dont vous ne pourrez pas sortir, pas de « notre framework maison ».
PlusMoins
C'est la différence avec beaucoup d'outils no-code ou d'usines à sites : le jour où le studio n'est plus là, le produit continue. Documentation, accès, variables d'environnement : ça fait partie du livrable, pas d'un extra.
Les secrets (clés, tokens) restent les vôtres. On ne les recycle pas, on ne les met pas dans un slide.
Peut-on partir d'un prototype existant ?
Oui — c'est même l'idéal. Un prototype cliquable (voir Prototypage) sert de spécification vivante : écrans, PRD, décisions UX. Le build n'invente pas les flux une seconde fois.
PlusMoins
Un Figma seul marche aussi, avec plus de risque d'ambiguïté. Un cahier des charges Word, moins : on le retraduit en parcours avant de coder, sinon on code des malentendus.
Si le proto vient d'ailleurs, on fait une recette de reprise : ce qui est in scope, ce qui ne l'est pas, ce qui est du décor.
Designer ou développeur — qui fait quoi ?
Dans ce studio, le même interlocuteur relie parcours, interface et code. Ce n'est pas une équipe design d'un côté et une usine de tickets de l'autre. Les agents accélèrent les deux bouts ; la relecture produit reste humaine.
PlusMoins
Une DA soignée, une illustration, un motion : on peut s'appuyer sur un designer partenaire. Le cœur du SaaS (modèle, rôles, écrans métier) ne se sous-traite pas à une maquette décorative.
Si vous avez déjà un design system, on s'y cale. Si vous n'en avez pas, on pose une base sobre, pas une identité complète « tant qu'on y est ».
Et la maintenance après la mise en ligne ?
Un produit vivant a besoin de correctifs, de dépendances, parfois d'une petite évolution. On peut tenir une suite — ce n'est pas obligatoire le jour 1, mais l'abandonner le jour de la recette est un mauvais plan.
PlusMoins
Parce que vous possédez le code, vous pouvez aussi passer la main à une équipe interne ou à un autre prestataire. Le studio documente pour que ce soit possible, pas pour se rendre indispensable par opacité.
Hébergement type VPS, backups, mises à jour : on les cadre. Pas de magie « c'est dans le cloud » sans nommer qui paie et qui surveille.
Multi-tenant, rôles, sécurité — vous gérez ça ?
Oui, quand le produit l'exige. RankyDocky / Shamalo portent une isolation par organisation, des rôles (owner, admin, editor, viewer), des cookies HttpOnly, pas de tokens dans le localStorage. Ce n'est pas du théâtre : c'est le métier d'un outil B2B.
PlusMoins
On ne pose pas une usine de sécurité « au cas où » sur un MVP à trois utilisateurs. On pose ce qui empêche de tout refaire dans six mois : le modèle d'accès, dès qu'il y a plus d'un rôle ou plus d'un client.
Les détails se cadrent à l'écrit. Un SaaS sans tenancy alors que vous vendez à plusieurs clients, c'est une dette, pas une simplicité.
Quelle stack, concrètement ?
Côté studio, le réflexe est celui déjà en prod : Django, GraphQL, React, PostgreSQL, Celery quand il faut de l'asynchrone. On s'adapte si vous avez une stack imposée — on ne reconvertit pas une équipe Symfony de force.
PlusMoins
Le front marketing n'est pas le produit : Next.js ou du statique pour une vitrine, le SaaS à part. Mélanger les deux sans le dire, c'est comment on se retrouve avec un CMS qui ne peut plus bouger.
Les agents (Cursor, GSD, skills) sont la façon de coder, pas un runtime que vous devez installer. Vous recevez un dépôt classique.
SYS/NEXT
Prochaine étape
Décrivez le process ou le produit à construire : on dit si un SaaS sur mesure est la bonne réponse, et par quel MVP commencer. Cadrage écrit sous 48 h, sans engagement.
Les autres leviers de Création de produits digitaux