Les 7 questions à poser avant de signer avec un prestataire SaaS

Tu es sur le point de confier ton projet SaaS à quelqu'un. Un budget, des mois de ta vie, parfois l'avenir de ta boîte. Et pourtant, la plupart des gens signent après une belle présentation et un devis qui a l'air raisonnable. C'est là que ça dérape.

J'ai écrit un article sur ce que ton développeur ne te dit pas, une fois le projet lancé. Celui-ci arrive avant. Parce que le meilleur moment pour éviter un mauvais partenariat, c'est le jour où tu poses les bonnes questions, pas le jour où tu découvres le problème.

Voici comment choisir un prestataire SaaS suisse sans te faire avoir. Sept questions. Tu n'as pas besoin d'être technique pour les poser. Chacune révèle un signal clair. Et pour chacune, je te dis ce que tu dois entendre et ce qui doit te faire fuir.

Pourquoi ces questions comptent vraiment

Un projet SaaS raté coûte rarement à cause du code. Il coûte à cause d'un désalignement qu'on n'a pas vu venir. Le partenaire pense livrer un truc, toi tu en attends un autre. Personne n'était de mauvaise foi. Personne n'a posé les bonnes questions au départ.

La bonne nouvelle: un partenaire technique sérieux adore ces questions. Elles lui montrent que tu prends le projet au sérieux. Celui qui se braque ou qui noie le poisson, tu viens déjà d'apprendre l'essentiel.

1. À qui appartient le code ?

C'est la première, et c'est non négociable. Tu paies, donc le code t'appartient. Ça devrait être évident. Ça ne l'est pas toujours.

Ce que tu veux entendre: "Tout le code est à toi, hébergé sur ton propre dépôt Git, tu as les accès dès le premier jour." Un partenaire honnête te donne les clés au fur et à mesure, pas à la fin.

Red flags: le code vit sur "leur" serveur, sur "leur" compte, avec un accès qui t'est promis "à la livraison". Ou une licence floue qui t'oblige à rester chez eux pour la moindre modification. Si tu ne peux pas partir avec ton code demain matin, tu n'as pas acheté un produit, tu as loué une dépendance.

Demande aussi: est-ce que je reçois le dépôt Git, les accès à l'hébergement, les noms de domaine, les comptes tiers, tout à mon nom ? La réponse doit être oui, sans hésitation.

2. Quelle stack, et pourquoi celle-là ?

Tu n'as pas besoin de comprendre la réponse technique en détail. Tu as besoin de comprendre le raisonnement. Un bon partenaire choisit sa stack pour ton projet, pas pour son confort ou pour la techno à la mode du moment.

Ce que tu veux entendre: des technos éprouvées, avec une vraie communauté, faciles à reprendre par d'autres développeurs en Suisse. Une explication en français simple du genre "on prend ça parce que c'est stable, bien documenté, et que tu trouveras facilement quelqu'un pour la maintenir dans trois ans."

Red flags: une stack exotique que personne d'autre ne connaît. Un framework maison. Ou l'inverse, aucune justification, juste "c'est ce qu'on utilise toujours." La pérennité, c'est ta capacité à changer de prestataire un jour sans tout réécrire. Pose la question directement: si je veux confier la maintenance à quelqu'un d'autre dans deux ans, est-ce facile ?

3. Comment tu gères la sécurité et la protection des données ?

En Suisse, la nLPD s'applique. Si ton SaaS touche des données personnelles, et c'est presque toujours le cas, ce n'est pas une option. Ton partenaire doit y avoir pensé avant que tu poses la question.

Ce que tu veux entendre: de l'hébergement en Suisse ou dans l'UE selon tes besoins, des données chiffrées, une gestion propre des accès, une réflexion sur ce qui se passe en cas de fuite. Idéalement, quelqu'un qui te parle de la nLPD sans que tu aies eu à prononcer le mot.

Red flags: un blanc gêné sur la question de l'hébergement. Des serveurs par défaut aux États-Unis "parce que c'est moins cher" sans t'expliquer les implications. Ou pire, "la sécurité, on verra ça plus tard." La sécurité ne se rajoute pas à la fin, elle se construit dès la première ligne. Un partenaire qui la traite comme une option est un partenaire qui te la facturera au prix fort le jour du problème.

4. Comment tu garantis la qualité ? Tu écris des tests ?

Tout le monde livre un truc qui marche le jour de la démo. La vraie question, c'est: est-ce que ça marchera encore dans six mois, après vingt modifications ?

Ce que tu veux entendre: oui, il y a des tests automatisés sur les parties critiques, il y a des relectures de code, il y a un processus pour éviter qu'une nouvelle fonctionnalité en casse une ancienne. Un partenaire qui te parle de qualité comme d'un investissement, pas comme d'une corvée.

Red flags: "les tests, ça coûte cher et ça ralentit." C'est vrai à court terme et catastrophique à long terme. Sans filet de sécurité, chaque évolution devient un pari. Tu paieras la dette technique, avec les intérêts. J'en parle plus en détail dans ce que ton développeur ne te dit pas, parce que c'est souvent invisible depuis ta chaise.

5. Qu'est-ce qui se passe si tu disparais ?

Question brutale, mais essentielle. Ton partenaire peut arrêter son activité, tomber malade, changer de vie. Un freelance seul peut disparaître du jour au lendemain. Une agence peut faire faillite. Que devient ton projet ?

Ce que tu veux entendre: "Tout est documenté, le code est propre et lisible, tu as tous les accès, n'importe quel développeur compétent peut reprendre le projet." Un partenaire qui a pensé à ta continuité, pas seulement à sa mission.

Red flags: "ne t'inquiète pas, je serai toujours là." Personne ne peut promettre ça. Ou une documentation inexistante, un code que seul l'auteur comprend, une organisation où toute la connaissance tient dans une seule tête. C'est exactement le sujet que je creuse dans agence, freelance ou studio, parce que le risque de continuité change beaucoup selon qui tu choisis.

Dans mon cas précis, je te donne même une sécurité de plus. Je travaille en partenariat avec Wavemind, une agence suisse qui connaît ma manière de travailler et qui pourrait reprendre ton projet sans problème si je venais à disparaître. C'est une double sécurité, et surtout sans aucune obligation pour toi : tu n'es lié à personne, tu gardes ton code et tes accès, tu sais juste qu'il existe un plan B solide au cas où. C'est exactement ce que tu devrais chercher chez n'importe quel partenaire, la preuve concrète qu'on a pensé à ta continuité avant même que tu poses la question.

6. Comment on travaille ensemble ? Je vois quoi, et quand ?

Un projet SaaS, ce n'est pas une commande que tu passes et que tu récupères trois mois plus tard. C'est une collaboration. La méthode de travail détermine si tu gardes le contrôle ou si tu signes un chèque en blanc.

Ce que tu veux entendre: des démos régulières, toutes les semaines ou toutes les deux semaines, sur une version que tu peux toucher toi-même. Des points courts et fréquents. La possibilité d'ajuster le tir en cours de route. Tu dois voir le produit grandir, pas le découvrir à la fin.

Red flags: "on te montre tout à la livraison." C'est la meilleure façon de découvrir, trop tard, que vous n'aviez pas la même vision. Fuis aussi l'inverse, une usine à gaz de réunions qui bouffe ton temps. Le bon rythme, c'est: tu vois du concret souvent, et tu peux réagir tant que c'est pas cher de changer d'avis.

7. C'est quoi le prix, et qu'est-ce qu'il couvre exactement ?

Le prix seul ne veut rien dire. Un devis à 20'000 francs peut être plus cher qu'un devis à 30'000 si le premier oublie la moitié du travail. Ce qui compte, c'est le périmètre.

Ce que tu veux entendre: un devis clair qui liste ce qui est inclus et, tout aussi important, ce qui ne l'est pas. Une explication de ce qui se passe si le périmètre bouge. Une transparence sur la maintenance après la livraison. Un partenaire qui préfère te dire non aujourd'hui plutôt que te facturer une surprise demain.

Red flags: un prix rond sorti sans détail. Un "tout compris" qui ne définit jamais le "tout". Ou un tarif anormalement bas: soit il y a un piège dans les extras, soit la qualité paiera l'addition. En Suisse, un bon SaaS sur mesure a un coût réel. Méfie-toi de qui te promet la lune pour trois francs.

Le vrai signal, c'est comment il répond

Tu l'as compris: la réponse exacte compte moins que la manière de répondre. Un bon partenaire technique est direct, il assume ses choix, il te dit non quand c'est nécessaire, et il te traite comme quelqu'un d'intelligent même sur les sujets techniques.

Celui qui esquive, qui te noie sous le jargon pour t'impressionner, ou qui promet tout sans réserve, il vient de répondre à la seule question qui compte vraiment: est-ce que je peux lui faire confiance sur la durée ?

Pose ces sept questions à chaque candidat. Compare les réponses. Le bon choix va devenir évident.

Si tu veux échanger sur ton projet, je préfère les vraies discussions aux devis anonymes. Regarde comment je travaille sur le SaaS sur mesure en Suisse, et pose-moi directement ces sept questions. Je serai ravi d'y répondre, c'est exactement comme ça que commencent mes meilleurs partenariats.