Votre SaaS est prêt ? La démo tourne, l'équipe veut appuyer sur le bouton. Avant de le faire, prenez une heure pour relire cette liste.
Chez KERN-IT, le développement SaaS a pris une place croissante ces derniers mois : nous avons mis en ligne plusieurs SaaS, les nôtres et ceux de nos clients. À chaque fois, la même leçon : pour lancer un SaaS, le produit n'est que la moitié du travail. L'autre moitié, c'est tout ce qui entoure le code : l'hébergement, les sauvegardes, la caisse, les factures, le contrat, et la façon dont les clients vont vous trouver.
Lancer un SaaS, c'est ouvrir un commerce qui ne ferme jamais. La vitrine compte. Mais la caisse, l'assurance et la porte de secours aussi.
Ce qui suit est la checklist que nous déroulons avant chaque mise en ligne, et ce que nous avons appris en la déroulant.
Ce que le développement SaaS change par rapport à un logiciel classique
Un logiciel sur mesure, on le livre. Un SaaS, on le fait tourner tous les jours.
Cette différence explique la plupart des lignes de cette checklist. Un logiciel installé chez un client vit dans son infrastructure, avec ses sauvegardes, son informaticien, son rythme. Un SaaS vit chez vous. Vous hébergez les données de dizaines ou de centaines d'entreprises sur la même plateforme, vous les mettez à jour toutes en même temps, vous encaissez chaque mois, et vous répondez quand ça tombe.
Le développement SaaS ajoute donc trois couches que le développement classique ignore.
- Le multi-locataire : une seule base de code, une seule infrastructure, et une cloison étanche entre chaque client.
- Le cycle de vie du compte : l'inscription, l'essai, l'abonnement, la montée en gamme, la résiliation, l'export, chacun avec ses règles et ses e-mails.
- L'exploitation : la supervision, les sauvegardes, les mises à jour sans interruption, le support. Aucune de ces trois couches ne se voit dans une démo. Ce sont pourtant elles qui séparent un produit qu'on peut vendre d'un prototype qu'on peut montrer.
Chez KERN-IT, nous posons ces trois couches dès la première semaine d'un projet de développement SaaS. AjouterRajouter le multi-locataire sur une application qui ne l'a pas prévu, c'est refaire la moitié du code. AjouterRajouter la facturation après le lancement, c'est facturer à la main pendant six mois.
Une dernière distinction avant d'entrer dans la liste. Le SaaS que vous lancez peut être votre produit, vendu à d'autres entreprises, ou votre propre plateforme métier, réservée à votre usage. Nous avons expliqué pourquoi la seconde option mérite d'être posée avant la première. Dans les deux cas, la checklist est la même : un service en ligne qui porte des données de tiers se lance avec les mêmes précautions.
1. Où héberger votre SaaS : un choix qui engage
Avant de comparer les prix, une question juridique : un SaaS qui traite des données de clients européens doit savoir où sont ses serveurs et sous quel droit vit son hébergeur. Un datacenter à Francfort opéré par un acteur américain reste soumis au Cloud Act. Un hébergeur européen (Scaleway, OVHcloud, Hetzner, Exoscale) n'y est pas exposé. Pour la plupart des SaaS B2B belges, c'est un argument de vente autant qu'une protection.
Le second réflexe est de commencer petit. Un serveur virtuel bien dimensionné, une base PostgreSQL managée, un stockage objet pour les fichiers : c'est assez pour les mille premiers clients. Kubernetes viendra si le succès l'impose. Nous avons vu trop de projets brûler leurs six premiers mois à construire une infrastructure prévue pour un trafic qui n'est jamais venu. La scalabilité se prépare dans l'architecture. La facture cloud du premier jour peut rester petite.
Enfin, tout ce qui touche à l'hébergement doit être écrit quelque part : le compte, les accès, le nom de domaine, les DNS, le renouvellement du certificat. Le jour où la personne qui a tout monté n'est plus là, c'est ce document qu'on va chercher en premier.
2. L'infrastructure minimale d'un SaaS sérieux
Il y a un minimum en dessous duquel on ne met pas en ligne. Le premier incident arrive en général la semaine du lancement, autant l'avoir prévu. Ce socle fait partie du développement SaaS lui-même : il se construit en même temps que les écrans.
- HTTPS partout, y compris sur l'API et les sous-domaines
- Aucun secret dans le code : clés et mots de passe vivent dans un gestionnaire de secrets ou des variables d'environnement
- Deux environnements au minimum, un de test et un de production, avec un déploiement automatisé entre les deux
- Une supervision qui prévient un humain : erreurs applicatives, disponibilité, espace disque
- Une limitation du nombre de requêtes sur les points sensibles, la connexion en premier
- Une authentification solide, avec double facteur proposé dès le départ
- Une isolation stricte entre les clients si votre SaaS est multi-locataire : un client ne doit jamais pouvoir voir une ligne d'un autre
Ce dernier point est celui que nous vérifions le plus longtemps. Dans un SaaS, une erreur d'isolation entre clients se pardonne mal : c'est la donnée d'un client qui s'affiche chez un autre. Elle se teste avant le lancement, avec deux comptes, en essayant de voir ce qu'on ne devrait pas voir.
3. Le backup : la case que tout le monde coche sans la tester
Tout le monde a des sauvegardes. Beaucoup moins de monde a déjà restauré une base de production à partir de l'une d'elles.
La règle reste le 3-2-1 : trois copies, sur deux supports, dont une hors site. Et en 2026, une quatrième précaution : une copie immuable, que personne ne peut effacer, pas même un administrateur avec un mot de passe volé. Les ransomwares récents chiffrent aussi les sauvegardes accessibles depuis le serveur, on le voit régulièrement.
Deux chiffres à écrire noir sur blanc avant de choisir une cadence. Combien de données vous acceptez de perdre : une heure, une journée ? En combien de temps vous devez être de retour en ligne ? Ces deux réponses dictent tout le reste : fréquence des sauvegardes, rétention, procédure.
Ensuite, le geste que presque personne ne fait : restaurer une sauvegarde sur un serveur vierge, une fois par mois, et chronométrer. Chez KERN-IT, le test de restauration fait partie de la checklist de mise en ligne, avant le premier client. Tant qu'une sauvegarde n'a pas été restaurée au moins une fois, on ne sait pas si elle fonctionne.
Dernier point souvent oublié : la sauvegarde ne doit pas dormir chez le même fournisseur que la production. Si le compte est suspendu, si le datacenter brûle, les deux disparaissent ensemble.
4. Le paiement : encaisser sans devenir un service comptable
Sur le papier, encaisser un abonnement est simple. En pratique, c'est le poste qui génère le plus de tickets de support la première année.
La première décision est de savoir qui vend. Avec un prestataire de paiement classique (Stripe, Mollie), vous restez le vendeur : vous encaissez, vous facturez, vous déclarez la TVA. Avec un « merchant of record » (Paddle, Lemon Squeezy), c'est lui qui vend à votre place : il collecte la TVA de chaque pays, la reverse, gère les litiges, et vous verse le solde. Vous payez pour ça, nettement plus cher en commission. Pour un SaaS belge qui vend surtout en Belgique et en B2B, le prestataire classique suffit : l'autoliquidation règle l'essentiel de la TVA intra-européenne. Pour un SaaS qui vend à des particuliers dans vingt pays, le merchant of record vaut son prix.
En Belgique, ne pas oublier Bancontact. Une bonne partie des clients ne paiera pas par carte de crédit, et Mollie comme Stripe le proposent.
Ensuite, les cas qui n'arrivent qu'en production : la carte qui expire, le paiement refusé, l'essai gratuit qui se termine, le client qui passe d'un plan à l'autre en milieu de mois. Chaque cas doit avoir une réponse écrite avant le lancement, et un e-mail prêt. La relance automatique des paiements manqués récupère à elle seule une part importante du chiffre d'affaires qu'on croyait perdu.
Deux choix de modèle se décident aussi avant le lancement. Essai gratuit plutôt que freemium pour un SaaS B2B. Un essai limité dans le temps convertit entre 18 et 25 % des inscrits. Un palier gratuit permanent convertit entre 3 et 5 %, et il faut le supporter indéfiniment. Et un plan annuel dès le premier jour, avec deux mois offerts : les clients qui le prennent partent nettement moins, et la trésorerie encaissée d'avance finance les premiers mois.
Un principe que nous appliquons : c'est votre base de données qui sait qui a droit à quoi, le prestataire de paiement se contente d'encaisser. Le jour où vous en changez, vous ne repartez pas de zéro.
5. La facturation : Peppol depuis le 1er janvier 2026
Un SaaS émet des factures en série, souvent des centaines par mois. En Belgique, depuis le 1er janvier 2026, toute facture entre deux entreprises assujetties à la TVA et établies en Belgique doit être électronique et structurée, au format Peppol BIS, transmise par le réseau Peppol. Le PDF envoyé par e-mail ne compte plus. Restent en dehors de l'obligation d'émission : les factures aux particuliers, celles adressées à des clients établis à l'étranger, et quelques régimes particuliers (opérations exonérées, forfait jusqu'en 2028). Les petites entreprises en franchise de TVA sont concernées comme les autres. Nous en avons détaillé les conséquences pour les entreprises belges.
Pour un SaaS, cela veut dire que la facture générée à chaque prélèvement doit partir en Peppol vers chaque client belge professionnel. Il faut donc un point d'accès Peppol, et une correspondance propre entre vos données d'abonnement et le format attendu. Nous avons dû résoudre cette étape pour nos propres abonnements. Il faut une boîte d'envoi qui prend chaque facture générée, la convertit au format structuré et la livre sur le réseau. Les règles de correspondance dépendent de votre modèle de données. À prévoir dans le développement : ça ne se règle pas en une après-midi après le lancement.
Au-delà de Peppol, les fondamentaux restent : numérotation continue sans trou, mentions obligatoires, TVA correcte selon le pays et le statut du client, conservation pendant dix ans à compter du 1er janvier qui suit, et un export propre pour votre comptable. Tout cela s'automatise. Une facture manuelle par abonnement ne tient pas au-delà du dixième client.
6. Les obligations légales d'un SaaS en Belgique et en Europe
C'est la partie que les fondateurs remettent à plus tard. Elle se règle en quelques jours quand on la prend avant le lancement, en quelques mois quand on la prend après.
Le RGPD, d'abord. Un SaaS est presque toujours un sous-traitant de ses clients : il traite les données de leurs utilisateurs pour leur compte. Cela impose un contrat de sous-traitance (le DPA), un registre des traitements, une politique de confidentialité lisible, et des mécanismes concrets pour répondre à une demande d'accès ou d'effacement. L'hébergement en Europe, vu plus haut, simplifie tout le reste.
Les conditions générales, ensuite. Un SaaS vend un service dans la durée. Les CGV doivent dire ce qui est compris, ce qui ne l'est pas, le niveau de service promis, ce qui se passe en cas de panne, et comment on résilie.
Le Data Act, en vigueur depuis le 12 septembre 2025, change ce dernier point. Un client doit pouvoir quitter votre SaaS avec un préavis de deux mois maximum, récupérer ses données dans un format exploitable, et à partir de janvier 2027 les frais de sortie disparaissent. Il faut aussi publier la procédure de sortie et les formats d'export. Cette règle vaut pour tous les contrats, y compris ceux signés avant.
L'accessibilité, si votre SaaS s'adresse à des consommateurs : depuis le 28 juin 2025, l'acte européen d'accessibilité impose le niveau WCAG 2.1 AA aux services numériques grand public. Les micro-entreprises (moins de dix personnes) en sont dispensées pour leurs services. Un SaaS purement B2B n'est pas visé directement, mais ses clients le sont parfois, et ils le demanderont.
L'AI Act, si votre produit embarque de l'IA. Les obligations de transparence s'appliquent depuis le 2 août 2026 : dire à l'utilisateur qu'il parle à une IA, marquer les contenus générés. Les usages à haut risque (recrutement, crédit, santé) ont été reportés à décembre 2027 par l'omnibus numérique, et ils demandent beaucoup plus qu'une mention dans les CGV.
Et pour les secteurs concernés (santé, énergie, finance, certains fournisseurs numériques), NIS2 est transposé en Belgique depuis octobre 2024, avec des exigences de sécurité et de notification d'incident.
Un dernier document, qui n'est pas une loi mais qui arrive aussi sûrement : le questionnaire de sécurité de votre premier client d'une certaine taille. Il demandera qui a accès à quoi, comment les données sont chiffrées, où sont les journaux, comment vous réagissez à un incident, et parfois une certification. En Europe, c'est ISO 27001 qu'on vous citera, plus que SOC 2. Vous n'avez pas besoin du certificat au lancement. Vous avez besoin des réponses écrites, et les points 2 et 3 de cette liste en couvrent déjà la plus grande part.
Nous ne sommes pas juristes, et ce paragraphe ne remplace pas une consultation. Il sert à savoir quoi demander, et à le demander avant le premier client payant.
7. La distribution à l'ère de l'IA : entrer dans la liste courte
La plupart des checklists de lancement s'arrêtent avant ce point. C'est celui qui décide si le produit trouve des clients.
Il y a trois ans, un acheteur B2B tapait « logiciel de gestion de » suivi de son métier dans Google, ouvrait dix onglets, comparait. En 2026, il pose la question à ChatGPT, Perplexity ou Claude, décrit son cas, et reçoit une liste courte de trois à cinq outils avec une justification. Il demande une démo à ces trois-là. Si vous n'êtes pas dans cette liste, vous n'êtes pas consulté.
On n'entre pas dans cette liste en le décidant. Il faut donner aux modèles de quoi vous citer, et c'est ce qu'on appelle le GEO, l'optimisation pour les moteurs génératifs. Les modèles citent ce qu'ils peuvent lire et comprendre : une documentation publique et claire, des pages qui répondent à une question précise, des comparatifs honnêtes, des FAQ visibles, des données structurées. Un site vitrine de cinq pages avec des promesses ne donne rien à citer.
Ce matériau entre dans la checklist au même titre que le serveur ou la sauvegarde. Il s'écrit avant le lancement, pas après.
8. Le marketing : un ou deux canaux, mesurés avant le jour J
Le lancement ne se joue pas en un jour. Ce qui compte, c'est ce qu'on répète chaque semaine après.
Avant les canaux, la cible. Un SaaS « pour toutes les équipes » ne parle à personne. Un SaaS pour les bureaux d'études de moins de vingt personnes en Belgique sait à qui écrire, où le trouver et quoi lui dire. Les post-mortems de SaaS abandonnés citent la cible trop large avant tous les autres motifs.
Ensuite, ne pas attendre le lancement pour avoir des clients. Une liste d'attente ouverte pendant le développement, avec une question de qualification à l'inscription, donne les premiers testeurs et les premiers payeurs. Une bêta par petits lots, et les premiers comptes ouverts à la main par le fondateur, avec un appel d'accueil de vingt minutes. Et les premiers clients paient, dès le premier jour, même à un tarif fondateur : un « oui » gratuit ne prouve rien, un virement prouve tout.
Pour les canaux, le premier conseil est de ne pas tout faire. Un ou deux, choisis selon la cible, et tenus dans la durée. Pour un SaaS B2B belge, deux canaux reviennent sans cesse. Le contenu qui répond aux vraies questions du métier : il coûte peu et il s'accumule. Et la prise de parole du fondateur sur LinkedIn : un profil personnel touche beaucoup plus de monde qu'une page d'entreprise. La prospection directe vient compléter, tant que le produit n'a pas trouvé son product-market fit.
Le second conseil est de mesurer avant de lancer. D'où vient le visiteur, s'est-il inscrit, a-t-il fait le geste qui prouve qu'il a compris le produit, a-t-il payé. Quatre chiffres, branchés avant le jour J. Sans eux, la semaine de lancement ne vous apprend rien.
Le troisième est l'onboarding. Un nouvel inscrit doit obtenir quelque chose d'utile dans les cinq premières minutes, un vrai résultat plutôt qu'une visite guidée. Tout ce qui retarde ce moment fait perdre des inscrits.
Le prix aussi se teste avant le lancement. Dix personnes qui répondent « oui, je paierais ça » vous en apprennent plus qu'une étude de marché, et dix qui paient encore plus.
9. La vie après le lancement
Le jour J passé, le SaaS continue. Un canal de support clair : un e-mail suffit au début, pourvu qu'on réponde, et que les délais soient écrits quelque part (quelques heures pour un blocage, un jour ouvré pour le reste). Une page d'état pour les pannes. Un journal des changements qui montre que le produit vit. Une veille de sécurité sur les dépendances. Et un rendez-vous mensuel devant les chiffres de désabonnement.
Deux points que les fondateurs découvrent la première nuit. Qui est réveillé quand ça tombe : une alerte qui sonne sur un téléphone, une personne désignée, un relais après quelques semaines, sinon la première panne tombe un dimanche soir et la deuxième épuise l'équipe. Et les pannes connues, écrites : base saturée, certificat expiré, file de mails bloquée, chacune avec la procédure pour s'en sortir. On écrit la procédure après le premier incident, jamais pendant.
Un chiffre pour cadrer l'effort : 60 à 70 % du désabonnement d'un SaaS se joue dans les 90 premiers jours du client. Un inscrit qui n'a rien fait au bout de trois jours est presque toujours perdu. Le suivi des nouveaux comptes, la première semaine, vaut plus que n'importe quelle campagne.
Tout cela a un coût mensuel, à budgéter dès le premier jour.
Faire développer son SaaS : ce que cette liste change dans le brief
Si vous confiez le développement SaaS à un partenaire, cette checklist devient la partie du cahier des charges que personne n'écrit. Le brief habituel décrit des écrans et des fonctionnalités. Il oublie presque toujours ce qui les entoure.
Six points à faire écrire dans l'offre :
- Le multi-locataire dès la conception, avec le test d'isolation compris dans la recette
- Le paiement et la facturation dans le périmètre, Peppol inclus pour les clients belges
- La sauvegarde et sa restauration testée comme un livrable, pas comme une option d'hébergement
- Le choix de l'hébergeur écrit, avec son pays, son droit et son coût mensuel
- Le passage de main : le code, les accès, la documentation d'exploitation, le nom de domaine à votre nom
- Un budget récurrent après la mise en ligne, parce qu'un SaaS ne cesse pas d'exister le jour de la livraison
Le sixième point est celui qui surprend le plus. Un développement d'application web ou SaaS ne se termine pas à la mise en ligne. Il faut compter l'hébergement, la supervision, les mises à jour de sécurité, l'évolution du produit. Un partenaire qui chiffre un SaaS comme un site vitrine, livré puis oublié, n'a pas compris ce qu'il vend.
Ce que nous disons à nos propres clients : le lancement coûte moins cher que la première année. Si l'offre ne montre que le premier chiffre, demandez le second.
Lancer un SaaS : la checklist en une page
- Hébergeur européen, hors portée des lois extraterritoriales
- Infrastructure simple au départ, architecture prête à grandir
- Accès, domaines, DNS et certificats documentés
- HTTPS partout, secrets hors du code, deux environnements, déploiement automatisé
- Supervision qui alerte un humain
- Authentification forte et isolation entre clients testée
- Sauvegardes 3-2-1, une copie immuable, une copie hors fournisseur
- Objectifs de perte et de reprise écrits, restauration testée et chronométrée
- Choix vendeur direct ou merchant of record, Bancontact compris
- Essai gratuit limité dans le temps et plan annuel disponibles dès le lancement
- Cas de paiement (échec, expiration, changement de plan) scénarisés
- Logique d'abonnement dans votre base, pas chez le prestataire
- Factures structurées et envoi Peppol pour les clients belges B2B
- Numérotation, mentions, TVA, conservation, export comptable
- DPA, registre des traitements, politique de confidentialité
- CGV de service continu avec niveau de service et résiliation
- Sortie Data Act : préavis de deux mois, export des données, procédure publiée
- Accessibilité si public consommateur, AI Act si fonctions IA
- Réponses écrites au questionnaire de sécurité (accès, chiffrement, journaux, incidents)
- Documentation publique, FAQ, comparatifs : de quoi être cité par les moteurs IA
- Cible précise, liste d'attente ouverte pendant le développement, premiers clients payants avant le jour J
- Un ou deux canaux marketing, mesure branchée avant le lancement
- Onboarding qui livre un résultat en cinq minutes
- Prix validé par des engagements réels
- Support avec délais écrits, page d'état, journal des changements, suivi du désabonnement
- Une personne d'astreinte, une alerte qui sonne, les pannes connues documentées
- Suivi rapproché de chaque nouveau compte pendant ses 90 premiers jours
- Si le développement est confié à un partenaire : les six points du brief écrits dans l'offre
Les questions qui reviennent
Faut-il tout cocher avant de lancer un SaaS ? Non. Il faut tout avoir lu, et savoir ce qu'on laisse ouvert en connaissance de cause. Le backup testé, l'isolation entre clients, le contrat et le RGPD ne se négocient pas. Le reste peut se prendre dans les semaines qui suivent.
Un prototype vibecodé peut-il servir de base au lancement d'un SaaS ? Il peut servir de base au produit. Tel quel, il est rarement prêt pour un lancement. La plupart des points de cette liste (secrets, isolation, sauvegardes, facturation) sont ceux qu'un prototype ignore.
Peppol s'applique-t-il aux abonnements SaaS ? Oui, dès que le client est une entreprise belge assujettie à la TVA. Chaque facture d'abonnement doit être structurée et transmise via Peppol depuis le 1er janvier 2026.
Stripe suffit-il pour vendre un SaaS dans toute l'Europe ? Techniquement, oui. Fiscalement, vous restez responsable de la TVA de chaque pays où vous vendez à des particuliers, via le guichet unique OSS. En B2B, l'autoliquidation simplifie. Si cette charge vous inquiète, un merchant of record la prend, contre une commission plus élevée.
Un hébergeur américain avec un datacenter en Europe est-il suffisant pour le RGPD ? Pour la localisation des données, oui. Pour l'exposition au Cloud Act, non : l'opérateur reste américain. Beaucoup de clients B2B, surtout publics et réglementés, font désormais la différence.
Faut-il une agence de développement SaaS pour dérouler cette checklist ? Pas forcément, si votre équipe a déjà tenu un service en production. Souvent, oui, pour les points qui ne se voient pas dans la démo : isolation multi-locataire, paiement, facturation Peppol, sauvegardes testées. Prise en compte dès la conception, la liste tient en deux à quatre semaines, en parallèle du développement SaaS lui-même. Découverte après le lancement, elle prend des mois.
Le lancement est un début
Lancer un SaaS, c'est ouvrir un service qu'on tient tous les jours, pour des clients qui ont mis leurs données chez vous. Cette checklist ne sert pas à retarder la mise en ligne. Elle sert à passer la première semaine sans mauvaise surprise, et les suivantes aussi.
Si vous préparez le vôtre, notre équipe de développement SaaS a déjà déroulé cette liste plusieurs fois, pour nos produits et pour nos clients. Vous savez où nous trouver.
