Choisir son agence MVP ou SaaS : les questions à poser et les réponses qui doivent alerter

---

title: "Choisir son agence MVP ou SaaS : les questions à poser et les réponses qui doivent alerter" seoTitle: "Choisir une agence MVP : les bonnes questions" description: "Les classements d'agences MVP sont écrits par des agences. À la place, voici la grille d'entretien qui sépare un prestataire qui livrera d'un prestataire qui facturera : quinze questions, et surtout les réponses qui doivent vous faire arrêter la discussion." seoDescription: "Quinze questions à poser à une agence MVP ou SaaS avant de signer, et les réponses précises qui doivent vous alerter sur le périmètre, l'équipe et la sortie." date: "2026-09-17" author: "Équipe Raicode" tags: ["mvp", "saas", "gestion de projet", "développement"] category: "SaaS & MVP" keywords: ["choisir une agence MVP", "agence développement SaaS", "questions à poser à une agence", "prestataire développement SaaS", "sélectionner une agence MVP", "audit prestataire technique", "contrat développement MVP", "propriété du code agence", "agence création MVP"]

Vous avez trois propositions sur le bureau, un écart de budget qui va du simple au triple, et aucun moyen de savoir laquelle des trois équipes livrera réellement quelque chose d'exploitable. Alors vous cherchez « meilleure agence MVP » et vous tombez sur des classements. Ce qu'ils ne disent pas en tête d'article, c'est qui les écrit : dans la quasi-totalité des cas, une agence concurrente qui se place première, ou une place de marché qui revend votre demande de devis à ses abonnés. Le format est devenu le contenu dominant du segment précisément parce qu'il capte des prospects, pas parce qu'il éclaire une décision.

Autant l'annoncer : cet article est écrit par une agence, et nous avons donc exactement le même conflit d'intérêts. La différence, c'est que nous ne vous donnons pas de liste. Nous vous donnons la grille que nous utiliserions nous-mêmes si nous devions choisir un prestataire, et qui a le mérite de fonctionner contre nous aussi. Si un prestataire y répond mieux que nous sur votre projet, prenez-le.

Ce que vous évaluez réellement

Un founder qui compare des agences croit évaluer la « qualité » — un mot qui ne se vérifie pas avant six mois. En pratique, quatre risques concrets décident du sort d'un MVP, et chacun se teste en entretien :

1. Le périmètre. L'agence a-t-elle compris ce que votre produit doit prouver, ou a-t-elle chiffré la liste de fonctionnalités que vous avez envoyée ?
2. Qui code. La personne qui vous impressionne en rendez-vous est-elle celle qui écrira le code, et pour quelle part de son temps ?
3. La sortie. Le jour où vous arrêtez, que récupérez-vous, sous quel délai, et dans quel état ?
4. Ce qui reste après. Quelles décisions structurantes seront prises pendant les six semaines, et lesquelles vous coûteront une réécriture si elles sont prises à la légère ?

Les trois premiers risques se testent sans aucune compétence technique. Le quatrième demande un peu d'aide, et nous y revenons plus bas.

Les questions sur le périmètre

« Qu'est-ce que vous enlevez de mon brief ? »

C'est la question la plus discriminante de toute la grille, et elle ne coûte rien à poser. Un brief de founder contient presque toujours vingt à trente fonctionnalités, dont cinq portent la promesse et le reste vient de la projection sur l'année suivante. Un prestataire qui a lu votre brief en professionnel sait déjà lesquelles il couperait, et il vous le dira en rendez-vous, quitte à vous contrarier.

La réponse qui doit alerter : « tout nous paraît nécessaire, on peut tout faire ». Elle signifie que le devis chiffre une liste au lieu de chiffrer un produit. Vous paierez le tableau de bord analytique que personne n'ouvrira, et le budget sera épuisé au moment où il faudra corriger le parcours d'inscription que vos dix premiers utilisateurs ne comprennent pas. C'est le mécanisme exact par lequel un MVP finit par durer huit mois : personne n'a coupé au départ, et plus rien n'est coupable ensuite sans avouer une erreur.

La réponse rassurante est inconfortable : « ces six-là, on ne les fait pas dans la V1, voilà pourquoi, et voilà à quelle condition on les rouvre ».

« Que se passe-t-il si on dépasse ? »

Il y a trois modèles contractuels et aucun n'est mauvais en soi : le forfait à périmètre fermé, la régie au temps passé, et le forfait par sprint ou par itération. Ce qui compte, c'est que votre interlocuteur sache expliquer le sien, y compris ses effets pervers. Le forfait pousse le prestataire à défendre le périmètre — c'est son intérêt, et souvent le vôtre. La régie ne pousse à rien, ce qui est confortable jusqu'au jour où plus personne ne surveille le compteur.

La réponse qui doit alerter : « ne vous inquiétez pas, on s'arrangera ». Un prestataire qui refuse de nommer ce qui se passe au dépassement vous laissera découvrir la règle au moment où elle joue contre vous. Demandez explicitement le mécanisme d'avenant, le délai de préavis, et ce qu'il advient des développements en cours si vous arrêtez au milieu d'un sprint.

« Sur quoi repose votre estimation ? »

Un chiffrage sérieux se décompose. S'il est présenté en une ligne — « MVP SaaS : 35 000 € » —, vous ne pouvez rien comparer. Demandez la décomposition par lot, avec les hypothèses qui la sous-tendent : nombre d'écrans, intégrations tierces, périmètre d'authentification, volume de données attendu. C'est ce qui permet de comprendre pourquoi trois devis pour le même brief vont de 12 à 58 k€ sans qu'aucun ne soit malhonnête.

La réponse qui doit alerter : un devis inférieur de moitié aux deux autres et qui ne mentionne ni tests, ni environnement de recette, ni mise en production. L'écart ne vient pas d'une productivité supérieure, il vient de postes absents que vous paierez plus tard, au moment le plus coûteux.

Les questions sur qui code réellement

« Qui écrit le code, nommément, et sur quel pourcentage de son temps ? »

Le schéma classique : le rendez-vous se fait avec un associé expérimenté et convaincant, le code est écrit par un profil junior encadré deux heures par semaine. Ce n'est pas illégitime — tout le monde a commencé quelque part — mais cela change le devis, le rythme et le niveau de suivi dont vous avez besoin. Vous avez le droit de savoir.

Formulez-le en termes vérifiables : combien de personnes sur le projet, quels prénoms, quelle ancienneté, quelle part de leur semaine vous est allouée, et qui relit leur code. Demandez à parler dix minutes à la personne qui codera. Un prestataire à l'aise organise l'appel.

Les réponses qui doivent alerter : « une équipe dédiée » sans nom ni nombre ; une allocation à 100 % du temps de trois personnes sur un projet à 25 k€, ce qui est arithmétiquement impossible ; et le refus de dire si une partie est sous-traitée. La sous-traitance n'est pas disqualifiante, l'opacité l'est.

« Quelle part du code sera générée par IA, et qui la relit ? »

En 2026, la bonne réponse n'est plus « aucune ». Tous les prestataires sérieux utilisent des assistants de génération de code, et c'est une raison légitime pour laquelle certains délais se sont raccourcis. La question utile porte sur la relecture : qui valide ce qui est produit, quelle est la politique sur les dépendances ajoutées automatiquement, et que se passe-t-il quand l'assistant produit du code qui fonctionne mais que personne de l'équipe ne sait expliquer.

La réponse qui doit alerter est celle qui vend la génération comme un argument de prix — « nos outils IA divisent le coût par trois ». La génération déplace l'effort vers la revue et les tests ; elle ne le supprime pas. Un prestataire qui l'a compris vous dira plutôt où il gagne du temps et où il n'en gagne pas.

« Montrez-moi un projet livré l'an dernier, et dites-moi ce que vous y referiez autrement »

Les références servent moins à vérifier la compétence qu'à observer le rapport à l'erreur. Un prestataire qui a réellement exploité un produit sait nommer une décision qu'il regrette : une base de données choisie trop vite, un modèle de données qui a résisté au premier vrai client, un choix d'authentification qu'il a fallu défaire.

La réponse qui doit alerter : un parcours sans aucun accroc, ou l'attribution systématique des difficultés au client précédent. Vous serez le client suivant.

Demandez aussi un contact client direct, et appelez-le. Posez-lui trois questions : le délai annoncé a-t-il été tenu, que s'est-il passé au premier désaccord, et travaillez-vous encore ensemble. La troisième est la plus informative.

Les questions sur la sortie

C'est la famille de questions que presque personne ne pose avant de signer, et celle qui coûte le plus cher quand on ne l'a pas posée. Nous intervenons régulièrement sur des projets où le code appartient au client sur le papier, mais où le dépôt, le compte d'hébergement, le nom de domaine, la base de production et les clés d'API sont tous sous le compte du prestataire. Le client est propriétaire d'un actif auquel il n'a pas accès.

Les quatre questions à poser, dans cet ordre :

• La propriété intellectuelle est-elle cédée, à quelle date, et sous quelle condition ? Beaucoup de contrats prévoient une cession au paiement intégral. C'est normal. Ce qui ne l'est pas, c'est une cession partielle qui exclut les « briques réutilisables » du prestataire sans les lister nommément.
• Les comptes sont-ils à mon nom dès le premier jour ? Dépôt Git, hébergeur, base de données, nom de domaine, fournisseurs tiers, gestionnaire de secrets. La bonne pratique est que le client soit propriétaire de l'organisation et invite le prestataire, jamais l'inverse.
• L'infrastructure est-elle décrite dans le dépôt ? Si la production a été configurée à la main dans une interface web, elle n'est pas reproductible, et le transfert consistera en un appel d'une heure et beaucoup d'espoir.
• Que contient la passation, et combien de temps est-elle provisionnée ? Une passation sérieuse, c'est un document d'architecture, un environnement reconstructible depuis zéro par un tiers, la liste des décisions non évidentes, et deux à trois jours d'accompagnement facturés d'avance.

La réponse qui doit alerter est la formule rassurante sans contenu : « bien sûr, le code vous appartient ». Reposez la question sur les accès. C'est là que la réponse se durcit ou se précise.

Un test simple pour trancher : demandez comment se passerait, concrètement, la reprise du projet par une autre équipe dans six mois. Un prestataire qui construit pour durer répond en décrivant une procédure — cloner, installer, lancer, déployer. C'est d'ailleurs la première chose que nous engageons sur nos propres projets de développement de MVP et de SaaS, avant même la première fonctionnalité, parce qu'un environnement qu'un tiers ne sait pas reconstruire finit par enfermer le client chez son prestataire sans que personne ne l'ait voulu.

Les questions techniques qu'un founder non technique peut poser

Vous n'avez pas besoin d'évaluer la réponse pour que la question soit utile. Ce que vous observez, c'est si votre interlocuteur a une position claire ou s'il improvise.

• « Comment gérez-vous la séparation des données entre clients ? » Sur un SaaS, c'est la décision la moins rattrapable après coup. Attendez une réponse nette — schéma partagé avec identifiant de locataire, base par client, ou autre — assortie d'une raison.
• « Comment gérez-vous les abonnements et les changements de plan ? » Un prestataire qui a déjà livré un SaaS payant connaît les cas pénibles : passage d'un plan à l'autre en cours de mois, échec de prélèvement, annulation puis retour.
• « Qu'est-ce qui sera testé automatiquement, et qu'est-ce qui ne le sera pas ? » La bonne réponse n'est jamais « tout ». Sur un MVP, on teste les parcours qui font perdre de l'argent ou des données. Le reste attend.
• « Comment je saurai que la production est cassée, et en combien de temps ? » Si la réponse est « vos utilisateurs vous préviendront », le produit n'a pas de supervision.
• « Que se passe-t-il si un client me demande la suppression de ses données ? » Une réponse floue ici annonce des semaines de travail non prévu au premier client sérieux.

Pour préparer ces échanges, un brief écrit vaut mieux qu'une liste de souhaits orale, même court et même imparfait : il fixe ce que vous comparez d'un entretien à l'autre.

La liste des réponses qui doivent vous faire arrêter

Sept signaux justifient de ne pas poursuivre, quel que soit le reste du dossier :

1. Le prestataire ne coupe rien dans votre brief.
2. Il refuse de nommer les personnes qui coderont ou de les faire parler.
3. Il ne sait pas dire ce qui se passe au dépassement de budget.
4. Il promet un délai en dessous de six semaines sans avoir vu votre périmètre en détail — la promesse courte, nous en avons démonté le mécanisme ailleurs.
5. Les comptes d'infrastructure restent chez lui.
6. Aucune référence joignable, ou des références qui ne travaillent plus avec lui sans qu'il sache dire pourquoi.
7. Il est d'accord avec tout ce que vous dites. Un prestataire qui ne vous contredit jamais pendant l'avant-vente ne vous contredira pas non plus quand vous aurez tort.

Comment mener la comparaison

Trois entretiens suffisent, et la méthode compte autant que la grille.

Envoyez le même document écrit aux trois, avec le problème à résoudre, l'utilisateur visé, la contrainte de budget et la contrainte de date. Ne fournissez pas la liste de fonctionnalités que vous imaginez : vous voulez voir ce que chacun propose, pas vérifier qu'il sait recopier.

Prévoyez 45 minutes par entretien et posez les mêmes questions dans le même ordre. Notez les réponses pendant l'appel, pas après — au troisième entretien, votre mémoire aura fusionné les deux premiers.

Demandez enfin une semaine de cadrage payante avant tout engagement long. Deux à quatre jours facturés, à l'issue desquels vous repartez avec un périmètre découpé, une estimation argumentée et un premier livrable. C'est le seul test qui vaille : vous ne jugez plus un discours commercial, vous jugez un travail. Un prestataire qui refuse de vendre un cadrage court vous demande de lui faire crédit sur trois mois — et si le cadrage se passe mal, vous aurez perdu quatre jours au lieu d'un trimestre.

Ce que vous devez apporter

Une part des projets qui dérapent ne dérape pas à cause du prestataire. Trois engagements de votre côté changent l'issue : un interlocuteur unique et disponible au moins deux heures par semaine, une décision rendue en moins de 48 heures quand elle est demandée, et un accès réel aux utilisateurs cibles. Si vous ne pouvez tenir aucun des trois pendant les deux mois à venir, décalez le démarrage. Un MVP construit sans son commanditaire coûte le même prix et sert rarement.

Choisissez donc dans cet ordre : d'abord le prestataire qui a coupé votre périmètre avec des arguments, ensuite celui dont vous connaissez la personne qui codera, enfin celui dont vous pouvez partir sans négociation. Le prix n'arrive qu'après, parce qu'un devis bas sur un périmètre non découpé n'est pas un devis bas, c'est une facture différée. Votre prochaine action tient en une phrase : rédigez le document d'une page qui décrit le problème, envoyez-le à trois prestataires, et commandez un cadrage payant à celui qui vous aura le plus contredit.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.