Développement SaaS au Maroc

Problèmes métier

• Une app mono-tenant avec une table tenants collée après, si bien que l'isolation repose sur une convention plutôt que sur le schéma de la base lui-même.
• Une facturation qui ne mappe pas les limites réellement appliquées, si bien qu'un client peut être facturé pour un palier que le produit ne bride pas réellement.
• Un onboarding qui lâche un nouveau client dans un dashboard vide sans données ni guide, si bien que les dix premières minutes décident s'il revient.
• Une page de tarifs qui promet des limites que le produit n'a aucun moyen de faire respecter, si bien que les ventes font une promesse que l'ingénierie doit rattraper après coup.
• L'export des données d'un tenant géré comme une faveur manuelle ponctuelle plutôt qu'une vraie fonctionnalité, si bien qu'un tenant qui veut partir — ou juste avoir une sauvegarde — doit demander et attendre.
• Aucune piste d'audit sur qui a changé le plan ou l'accès d'un tenant, si bien qu'un litige de facturation n'a aucune trace à vérifier.

Processus de développement

1. L'isolation d'abord : données, files, fichiers. Puis onboarding, offres, admin — dans cet ordre, parce que rajouter l'isolation après le lancement veut dire toucher chaque table.
2. Laravel + React depuis Tanger, exploités avec Docker et sauvegardes, pour que la plateforme survive à un mauvais déploiement ou un serveur en panne sans perdre les données d'un tenant.
3. Brancher les événements d'abonnement Stripe sur de vrais feature flags, pas juste un nom de plan, pour qu'un downgrade retire vraiment l'accès plutôt que de changer une étiquette.
4. Modéliser plans et limites comme des données, pas comme des if éparpillés dans le code, pour qu'un nouveau palier tarifaire soit une ligne en base, pas un déploiement.
5. Journaliser chaque changement de plan et de permission avec qui l'a fait et quand, pour que le support puisse répondre « pourquoi ce tenant a accès à X » sans deviner.
6. Construire l'export de données par tenant comme une vraie fonctionnalité dès le départ, pas une faveur manuelle, pour qu'un tenant puisse récupérer ses propres données sans ouvrir un ticket de support.
7. Limiter le débit et les ressources des tenants d'essai séparément des payants, pour qu'un compte gratuit ne puisse pas dégrader le service des clients qui paient réellement.
8. Suivre l'usage des fonctionnalités par tenant dès le départ, pour que les paliers tarifaires et la roadmap se construisent sur ce que les tenants font réellement, pas des suppositions.

Ce que vous obtenez

• Une plateforme que le deuxième client ne peut pas faire tomber, parce que l'isolation a été pensée dès la première table, pas rajoutée après un incident.
• Un onboarding assez rapide pour qu'un nouveau tenant travaille dans son premier job ou sa première équipe en quelques minutes après l'inscription.
• Un modèle de tarification que le produit applique réellement, si bien que ce que les ventes promettent et ce que la plateforme livre sont la même chose.
• Le support peut répondre aux questions d'accès et de facturation depuis le journal d'audit au lieu de demander à un ingénieur de vérifier la base.
• Des tenants qui peuvent exporter leurs propres données à la demande, ce qui rend aussi les demandes RGPD et similaires anodines plutôt qu'une course contre la montre.
• Un signal de désabonnement attrapé tôt, parce que les données d'usage montrent un tenant qui se tait des semaines avant d'annuler vraiment, pas après.

Projets choisis