Checklist de mise en production SaaS :14 points à vérifier

Avant la mise en ligne de votre SaaS, passez une seule checklist de mise en production SaaS : règles de sécurité activées et testées sur chaque table de la base de données, clés secrètes hors de votre code, SSL actif, sauvegardes vérifiées et un rollback que vous avez réellement répété. Le marketing du lancement accapare toute l'attention — mais ce sont les vérifications ingrates avant la mise en ligne qui décident si vos premiers vrais utilisateurs tombent sur un produit qui marche ou sur une fuite de données.

C'est la moitié technique du lancement. La moitié marketing — l'annonce, les canaux, l'élan — c'est le playbook de la semaine de lancement. Aujourd'hui, il s'agit de s'assurer que ce que vous annoncez ne s'effondre pas.

Pourquoi une checklist de production est indispensable

Votre produit a vécu dans un monde indulgent : une base de développement que vous pouvez effacer et reconstruire, des règles de sécurité appliquées mollement, des messages d'erreur généreux, aucune vraie donnée utilisateur en jeu. La production est le monde inverse — de vraies personnes, de vraies données, une sécurité stricte, et aucune seconde chance sur une clé divulguée ou une base de données perdue.

Le danger, c'est qu'une app peut sembler terminée alors qu'elle est à une case non cochée du désastre. Tout ce qui figure sur cette liste est invisible dans une démo. Tout est vital en production.

La checklist de mise en production SaaS en 14 points

Voici la checklist que je passe avant la mise en ligne de n'importe quel produit, traduite en langage simple :

Chaque vérification est une question à poser à l'IA : « Montre-moi que la row-level security est activée sur chaque table, et liste les tables où elle ne l'est pas. » Vous n'avez pas besoin de savoir corriger chaque point à la main. Vous devez refuser de lancer tant que chaque réponse n'est pas oui.

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

Les trois vérifications que les fondateurs sautent le plus souvent

La row-level security (vérifications 2 et 3). C'est le mur entre les données de vos clients — la base de données qui refuse, à son propre niveau, de remettre les enregistrements de l'utilisateur A à l'utilisateur B. C'est la vérification dont la défaillance est la pire, ce qui explique qu'elle ait son propre guide. Activée ne suffit pas ; testez-la en essayant de lire les données d'un autre compte et en confirmant que vous n'y arrivez pas.

Les clés secrètes (vérifications 8 et 14). Votre app a des clés publiques (sûres dans le navigateur) et des clés secrètes (accès total à tout). Les secrètes appartiennent aux paramètres protégés de votre hébergeur. Si une clé secrète a un jour été écrite dans votre code, considérez-la comme compromise et renouvelez-la avant le lancement.

La répétition du rollback. Absente de la liste ci-dessus parce que c'est un exercice, pas un réglage : déployez, puis entraînez-vous à revenir à la version précédente depuis le tableau de bord de votre hébergeur. Cela prend environ 30 secondes sans interruption — mais ne devient un filet de sécurité qu'une fois que vous l'avez fait. Cette répétition est aussi le fondement du déploiement sans peur après le lancement.

Vérifications côté hébergement : domaine, SSL, environnement

Côté hébergement, quatre éléments complètent la mise en ligne. Votre domaine personnalisé est connecté — les changements DNS mettent 10–30 minutes à se propager. Le SSL est actif, ce que votre hébergeur délivre gratuitement et automatiquement en 5–10 minutes ; aucun utilisateur ne devrait jamais voir un avertissement « non sécurisé ». Les variables d'environnement de production sont définies dans le tableau de bord avec de vraies valeurs, distinctes de toute valeur de préproduction. Et le suivi des erreurs ainsi que l'analytique sont activés, afin que dès votre tout premier utilisateur vous voyiez ce qui casse et ce qui est utilisé — la même plomberie que derrière le monitoring de votre SaaS en fondateur solo.

Sauvegardes et reprise : envisagez le pire une fois

Sur l'offre gratuite d'une plateforme comme Supabase, les sauvegardes sont quotidiennes et conservées 7 jours. L'offre Pro (25 $/mois) étend la rétention à 30 jours et ajoute la restauration à un instant donné — restaurez votre base de données à n'importe quel moment, par exemple cinq minutes avant un mauvais changement. Consacrez dix minutes à écrire votre plan de reprise à tête reposée : base de données corrompue → restaurer la dernière sauvegarde et vérifier. Cela ressemble à de la paranoïa jusqu'au jour où cela ressemble à du génie.

Ce que tout cela coûte : généralement rien

La partie rassurante. Les offres gratuites sont vraiment de niveau production : ma propre configuration fait tourner 3 sites de production avec 300–500 builds et 50–100 Go de bande passante par mois — pour 0 € d'hébergement. Les signes que vous avez dépassé le gratuit sont concrets : une base de données de plus de 500 Mo, une bande passante au-delà de 5 Go/mois, ou l'envie d'une rétention de sauvegardes plus longue — et alors c'est 25 $/mois. Pour la plupart des produits solo, l'offre gratuite vous porte pendant des mois, voire des années. La checklist coûte un après-midi. L'ignorer peut coûter l'entreprise.

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 →

Questions fréquentes

Que vérifier avant de lancer un SaaS ?

Quatorze points techniques répartis en cinq domaines : base de données (migrations exécutées, row-level security activée et testée, index en place), authentification (configurée pour votre domaine en production, e-mails à votre marque), sécurité (clés secrètes hors du code, limitation de débit), résilience (sauvegardes vérifiées, un rollback de 30 secondes répété) et visibilité (suivi des erreurs et alertes de monitoring activés).

Ai-je besoin d'une offre payante pour mettre en ligne ?

Généralement non. Les offres gratuites sont de niveau production : bande passante illimitée côté hébergement, sauvegardes quotidiennes avec 7 jours de rétention côté base de données. Passez à l'offre base de données à 25 $/mois quand vous dépassez 500 Mo de données ou voulez 30 jours de rétention avec restauration à un instant donné. Mes trois sites de production tournent avec 0 € d'hébergement.

Quelle est la vérification la plus souvent oubliée ?

Tester la row-level security — pas seulement l'activer. Les fondateurs l'activent, ne voient aucune erreur et livrent. Mais une mauvaise politique se comporte exactement comme une bonne jusqu'à ce que quelqu'un lise les données d'un autre client. Avant le lancement, essayez activement d'accéder à des données entre comptes et confirmez que la base de données refuse.

Comment fonctionnent les sauvegardes pour un fondateur solo ?

Automatiquement, une fois vérifiées. Les plateformes gérées sauvegardent votre base de données chaque jour sans configuration — 7 jours de rétention en gratuit, 30 jours plus restauration à un instant donné avec l'offre à 25 $/mois. Votre travail est double : confirmer que les sauvegardes tournent vraiment avant le lancement, et écrire la procédure de restauration pendant que rien ne brûle.