Le logiciel que vous vendez, pas celui qui vous fait tourner.
Un MVP qu’un vrai utilisateur paiera — ou le produit SaaS derrière : comptes, facturation, multi-locataires, et l’admin qui le rend exploitable. Sur le web, sur iOS et Android, ou les trois.
démarrer un projet→Pour qui
Vous avez quelque chose que les gens veulent, et pas encore de logiciel pour le vendre.
Peut-être le livrez-vous à la main à des clients payants et cela ne tient plus. Peut-être avez-vous une maquette, une liste d’attente et aucun développeur. Peut-être une v1 construite vite par quelqu’un qui est parti depuis, où chaque nouvelle fonctionnalité prend trois fois plus de temps que la précédente.
Le point commun : le logiciel est l’entreprise. Quand il s’arrête, le revenu s’arrête avec lui.
Ce qui est inclus
- Cadrage produit — quoi construire en premier, et surtout quoi laisser hors de la v1
- Une architecture choisie pour les deux prochaines années, pas pour la démo
- Le développement — front, API, modèle de données, déployé derrière un pipeline
- Les fondations SaaS — multi-locataires, comptes, rôles et permissions, facturation et cycle d’abonnement
- Le mobile, quand le produit a sa place sur un téléphone — React Native, partageant la couche API et les tokens de design avec le web plutôt que de s’en écarter
- L’exploitabilité — onboarding, analytique d’usage, une interface d’administration, journaux et alertes
- L’itération après la sortie — instrumentation, retours, et la deuxième version
S’il s’agit d’une application
Un seul code, les deux magasins.
React Native, avec des modules natifs là où l’application en a vraiment besoin. Pas deux équipes qui construisent deux fois la même chose, et pas un site web dans une coquille.
Y entrer est le plus dur, et c’est notre part.
Provisioning, signature, TestFlight, la soumission à la validation — et le refus du vendredi auquel il faut répondre avant lundi.
La fiche du magasin se fait ici aussi.
Captures, icône, vidéo de présentation — conçues dans l’agence qui a construit l’application, depuis l’interface réelle. Les captures sortent de la même agence que l’application, et non d’un brief envoyé à un inconnu.
Ensuite, cela continue d’avancer.
Mises à jour à distance, notifications push, comportement hors ligne, et les montées de SDK que les plateformes imposent deux fois par an.
Ce qu’un MVP veut dire ici
Pas une démo. Pas un prototype cliquable. La plus petite version qu’un vrai utilisateur paiera et à laquelle il reviendra.
Ce qui veut dire qu’elle contient les parties ingrates dès la première sortie : comptes, permissions, un moyen d’encaisser, un moyen de voir ce que les gens font vraiment, et un moyen de réparer quand quelque chose casse à onze heures du soir.
Couper cela, c’est transformer un lancement en refonte six mois plus tard.
Pas une marque, pas une campagne, pas la photographie.
S’il vous faut l’annonce autour du produit, c’est Lancement — et la plupart des fondateurs achètent les deux en séquence plutôt qu’en même temps. Et pas un cofondateur : nous construisons des logiciels contre honoraires. Nous ne prenons pas de participation en échange du paiement, et il vaut la peine de dire pourquoi — une agence actionnaire de six clients privilégie celui qui pourrait sortir, soit l’inverse de ce que vous attendez de ceux qui construisent le vôtre.
Une première sortie de quelques semaines à quelques mois, selon ce que la v1 doit vraiment faire.
Cadré par phases plutôt que chiffré une fois. Un produit n’a pas de ligne d’arrivée — la première sortie est le moment où le travail commence à servir, pas celui où il s’arrête.
Questions
sept réponses
01Il nous faut une application mobile — est-ce la bonne page ?
+
Il nous faut une application mobile — est-ce la bonne page ?
+Si l’application est ce que vous vendez, oui. Si c’est un outil que vos équipes utilisent pour travailler, il s’agit de Plateforme. Si c’est une boutique, de Boutique. Et si elle doit être dans les magasins à une date avec une annonce autour, de Lancement.
02Nous avons déjà une v1 construite par quelqu’un d’autre.
+
Nous avons déjà une v1 construite par quelqu’un d’autre.
+Commencez par un audit technique payant : ce qui existe, ce que cela coûte à garder, et si l’année à venir coûte moins cher à l’étendre ou à le remplacer. Parfois la réponse est « gardez-le et embauchez votre propre développeur », et nous le dirons.
03Jusqu’où la v1 peut-elle être petite ?
+
Jusqu’où la v1 peut-elle être petite ?
+Plus petite que vous ne le pensez. Le cadrage est surtout une discussion sur ce qu’on coupe. Le test n’est pas de savoir si c’est impressionnant — c’est de savoir si une vraie personne paiera et reviendra la semaine suivante.
04Est-ce différent de Plateforme ?
+
Est-ce différent de Plateforme ?
+Oui, et cela change le cadrage. Plateforme construit un système qui fait tourner votre entreprise et s’achève quand le système fonctionne. Produit construit ce que vous vendez, et la première sortie est le début. Si vous hésitez, dites ce que vous cherchez à faire et nous vous le dirons.
05En sommes-nous propriétaires ?
+
En sommes-nous propriétaires ?
+Oui. La totalité, dans votre dépôt, dès le premier commit. Les comptes développeur des magasins sont enregistrés à votre nom, pas au nôtre — l’application reste la vôtre, quel que soit celui qui la maintiendra ensuite.
06Pouvez-vous continuer après le lancement ?
+
Pouvez-vous continuer après le lancement ?
+Le plus souvent, et la plupart des missions Produit se poursuivent en arrangement suivi. C’est tout aussi bien si le plan est d’embaucher vos propres développeurs et de reprendre en interne — le code est écrit en supposant que quelqu’un d’autre le lira.
07Y mettrez-vous de l’IA ?
+
Y mettrez-vous de l’IA ?
+Là où elle mérite sa place, et pas ailleurs. Un modèle dans un produit est un coût récurrent et une source d’imprévisibilité : il doit payer les deux.
Dites-nous ce que vous cherchez à faire.
démarrer un projet→