SaaS MVP : construire avec l’IA ou déléguer ? Un cas concret

Une fondatrice — appelons-la Claire — veut lancer un petit logiciel en ligne pour des cabinets de conseil : suivre les demandes de leurs clients dans un seul tableau. Elle a déjà assemblé des outils no-code, mais n’a jamais écrit de code. Elle a vu des démonstrations où un agent d’IA construit une application en un après-midi. Doit-elle construire elle-même, acheter un outil existant ou confier le projet à un développeur ? Ce cas suit la méthode du diagnostic, étape par étape.

Exemple illustratif : Claire et son projet sont fictifs. Aucun client réel n’est décrit ici, et la recommandation ne vaut que sous les hypothèses écrites plus bas.

Avec trois réponses : une orientation, pas un verdict

Premières réponses : un SaaS, au stade de la première version à lancer (MVP), d’une importance « normale » pour son activité. Avec si peu d’informations, une réponse honnête reste provisoire :

« Orientation préliminaire : approche hybride à évaluer. Les données traitées, les droits d’accès et votre capacité à maintenir le produit restent à préciser. »

Pourquoi ne pas trancher tout de suite ? Parce que ce qu’on ignore n’est pas un risque faible. Un SaaS qui traite des dossiers médicaux, ou qui isole plusieurs entreprises clientes avec leurs rôles, ne se décide pas comme un SaaS qui stocke des contacts. Les trois premières réponses ne disent rien des données, des droits d’accès ni de qui maintiendra le produit — or ce sont précisément les points qu’une démonstration ne montre pas.

Les hypothèses explicites

Claire complète le diagnostic. La recommandation qui suit ne vaut que sous ces hypothèses :

• Une personne fondatrice seule, sans formation technique.
• Un parcours B2B étroit : une tâche principale pour un type de client.
• Des données ordinaires de contact et d’activité, pas de dossiers sensibles ou réglementés.
• Une facturation standard via un prestataire de paiement.
• Un pilote limité à quelques clients connus.
• Pas d’exigence de temps réel strict.
• Pas de moteur de décision financière sur mesure.

Elle a aussi cherché un logiciel existant : les outils qu’elle a essayés ne couvrent pas le parcours précis que ses clients demandent. Elle peut y consacrer 5 à 15 heures par semaine, avec un budget de CHF 2’000 à 10’000 sur douze mois, et elle compte s’occuper du produit après le lancement sans savoir encore comment.

La recommandation : hybride

« Construire le parcours principal avec l’IA, acheter les composants standards et faire vérifier les accès, paiements et procédures de reprise avant un lancement payant. »

Concrètement, Claire construit avec un agent de code ce qui fait la valeur de son produit : le parcours principal, les écrans, les listes. Elle n’écrit ni sa propre connexion ni son propre paiement : elle les achète à des services spécialisés — un fournisseur d’authentification, un prestataire de paiement, un service d’email — et les configure. Avant le premier paiement réel, une personne expérimentée vérifie trois choses précises : que chaque compte ne voit que ses propres données, que l’accès suit bien le paiement confirmé, et qu’une sauvegarde se restaure.

Ce n’est pas « faites tout faire par un développeur ». La revue est bornée, datée, et porte sur les points où une erreur coûte cher sans se voir en démonstration.

Les huit étapes

La matrice découpe le projet en étapes. Chacune a une décision, un risque principal, une preuve qui permet de passer à la suivante, et les coûts à évaluer.

Cocher une ligne n’est pas une preuve technique : la preuve, c’est le test observé (deux comptes, un paiement refusé, une restauration réussie), noté avec sa date.

Qui fait quoi

Chaque étape laisse aussi une question ouverte. Ce sont souvent les meilleures questions à poser à un développeur, ou à vous-même :

• Valider : Qui paie, combien, et pour quel résultat mesurable ?
• Cadrer : Quelles demandes des clients du pilote refusez-vous pour l’instant ?
• Choisir les composants : Que se passe-t-il si un fournisseur augmente ses prix ou ferme ?
• Construire une tranche verticale : Qui sait expliquer ce que fait chaque fichier modifié ?
• Vérifier identité et accès : Un administrateur doit-il voir tous les comptes ? Qui l’autorise ?
• Brancher la facturation : Que reçoit un client si le paiement passe mais que l’accès échoue ?
• Piloter prudemment : Combien de temps de panne le pilote peut-il supporter ?
• Exploiter et décider : À partir de quel coût ou de quelle charge arrêtez-vous ou recadrez-vous ?

Ce qui changerait la recommandation

La recommandation dépend des hypothèses. En changer une seule suffit parfois à la renverser :

• Des dossiers sensibles — santé, finances personnelles, pièces d’identité : une revue spécialisée devient obligatoire avant toute donnée réelle, et les parties sensibles se confient plutôt qu’elles ne se construisent seule. Autre option : réduire le périmètre pour ne pas stocker ces données.
• Des permissions entre plusieurs entreprises clientes, chacune avec ses rôles : l’isolation entre clients devient la partie la plus risquée du produit ; un spécialiste la conçoit, au lieu de seulement la relire.
• Des pertes plus lourdes en cas de panne : surveillance, restauration testée et une personne capable d’intervenir passent avant le lancement, ce qui pousse vers une exploitation confiée.
• Une capacité technique plus forte — Claire développe, ou une personne technique rejoint le projet : construire soi-même devient raisonnable, avec une revue ciblée sur les paiements.
• Un produit existant adapté : l’acheter et le configurer devient la recommandation, et la construction n’a plus lieu d’être.
• Un budget impraticable : il ne fait pas disparaître le risque. On réduit le périmètre, on livre d’abord le service à la main, ou on reporte le lancement payant — on ne saute pas la vérification des accès et des paiements.

Les coûts à regarder

Le coût ne se limite pas à la facture d’un développeur. Il faut séparer l’argent qui sort — abonnements d’outils, hébergement, revue, frais de paiement, réserve pour imprévus — et le coût économique total, qui ajoute le temps de la fondatrice. Un projet « gratuit » parce que construit seule peut représenter des centaines d’heures. À l’inverse, une revue de quelques heures au bon moment coûte souvent moins qu’un incident sur les données d’un client.

Refaire l’exercice avec votre projet

Le diagnostic gratuit pose les mêmes questions en langage simple, avec « je ne sais pas » toujours possible. Il donne une orientation dès trois réponses, puis une recommandation argumentée, ce qui reste à préciser et vos prochaines actions — sans email ni paiement. Pour comprendre les limites de l’IA tâche par tâche, voir les limites de l’IA pour développer un produit web.