Pourquoi nous ne développons pas de MVP pour 10k

Je m’appelle Florian, je code depuis 15 années. J’ai été CTO de plusieurs startups que j’ai co-fondé ou accompagné, et je suis membre fondateur depuis plus de 5 ans du Product Studio Alqemist.com qui s’avère être un collectif de freelances. Notre spécialité est de développer des MVP ou des produits “from scratch” à partir d’une simple idée. Si vous voulez en savoir plus sur le collectif, Delphine a écrit un post medium présentant notre fonctionnement.

Le mythe de l’entrepreneuriat facile

Quand j’ai commencé à coder et à entreprendre, avant le concept de “Startup-Nation”, j’étais bercé par le mythe du “startup garage”. Je pensais qu’on pouvait devenir Marc Zuckerberg en s’enfermant simplement dans sa chambre pour coder (à moindre frais) un produit que le monde entier allait vouloir utiliser instantanément. 15 ans après, je passe mon temps à expliquer qu’on ne monte plus des startups dans des garages. Et pourtant le mythe de l’entrepreneur qui lance son business facilement, en quelques mois (ou quelques semaines), et à 0 frais (ou presque) a encore de belles années devant lui.

Chez Alqemist, nous rencontrons régulièrement des entrepreneurs et intrapreneurs brillants, soucieux de mettre en place une démarche itérative pour tester leur idée puis leur produit. Merci Lean Startup 🙏 Et pourtant ils sont encore nombreux à s’étonner quand on leur dit que le produit/MVP qu’ils ont en tête ne coûtera pas 10k.

Attention, je ne dis pas que développer un MVP pour 10k€ est impossible. Il existe d’ailleurs plein de solutions plus ou moins ingénieuses pour faire un MVP à moindre coût :

• Offshoring : Il y au moins autant d’exemples d’offshoring réussis que d’offshoring râtés. Malheureusement c’est encore bien souvent la loterie quand on n’a pas d’expérience du travail avec des prestataires à l’étranger. Je ne le répèterai jamais assez, le prix ne doit pas être votre seul critère de choix d’un prestataire.
• Faire appel à un junior : si votre développeur junior met 2x plus de temps, vous n’aurez rien économisé. Pour un résultat qui sera de toute façon en adéquation avec le niveau débutant de votre développeur, et risque même d’être décevant.
• Oncle Ted sur son temps libre : NO WAY. Ca part d’une bonne intention mais vous allez juste perdre votre temps et faire perdre celui de votre oncle également. A moins qu’Oncle Ted soit un crack.
• Auto-apprentissage : Apprendre à coder est évidemment une super idée et ça vous sera d’une grande utilité pour la suite. Attention à être réaliste sur le temps que ça prendra et de ne pas surévaluer vos capacités à délivrer un produit fonctionnel.
• Trouver un associé CTO : Le Saint Graal ! Trouver quelqu’un qui est motivé pour développer votre produit contre des parts (ie. sans rémunération). Trouver une telle personne c’est comme trouver une aiguille dans une botte de foin. Et lui donner des parts dès le démarrage est souvent une très très mauvaise idée.

Seulement chez Alqemist, nous ne développons pas (ou rarement) des produits pour 10k€. Nous sommes conscients que nos clients sont face à un choix difficile de devoir faire confiance à un prestataire dont ils ont du mal à apprécier la qualité du travail. D’où le fait d’accorder trop d’importance au critère “prix”. Mais choisir un prestataire sur le prix parce qu’on ne peut pas évaluer ses compétences techniques est une erreur qui peut coûter cher.

Qu’est-ce qui fait varier le prix d’un MVP ?

Faisons un peu de calcul. Avec un TJM moyen d’un développeur qui se situe entre 450 et 650€, cela laisse entre 15 et 22 jours de travail pour réaliser le MVP. Est-ce suffisant ? Evidemment il est impossible de répondre à cette question. Il faut savoir de quoi on parle avant de se prononcer. En l’occurence, voilà plusieurs critères qui font varier la durée d’un projet et son coût du simple au triple parfois :

• le projet en lui-même. S’agit-il de web ou de mobile ? S’agit-il d’une marketplace ? D’un Saas ? Nécessite-t-il de connecter d’autres services tiers via des API ? Y’a-t-il beaucoup de règles de gestion ? D’expérience, les porteurs de projet sous-estiment souvent la complexité technique de ce qu’ils ont en tête. C’est notre job de challenger leurs hypothèses, les amener à faire des coupes, à déprioriser certains “essentiels” et à valider le besoin au maximum en amont de la 1ere ligne de code.
• la techno utilisée. Les choix de langage et de technologie peuvent avoir un très fort impact sur la durée du projet. Certains langages sont considérés comme plus véloces et plus rapide à apprendre, c’est le cas de Ruby on Rails par exemple. Certaines techno plus matures disposent de nombreuses librairies disponibles, ce qui facilite grandement le travail des équipes tech. Et évidemment, il n’existe pas une seule et unique bonne stack technique. Ce serait trop simple sinon 😉
• les compétences du développeur et sa vélocité. Même s’il est difficile d’évaluer ses compétences, voici quelques critères à regarder attentivement : l’expérience de la personne (nombre d’années, postes occupés, projets et problématiques abordées…), sa vélocité, et sa capacité à produire du code de qualité (ie. propre, lisible et facilement exploitable par d’autres personnes). Chez Alqemist, on aime bien insister sur un autre critère : la capacité d’une personne à challenger le projet, à trouver des moyens de gagner en efficacité, ou à proposer des optimisations techniques et fonctionnelles. C’est ce qui différencie un exécutant, d’un lead.
• la qualité du design ou du cahier des charges. Que l’on travaille à partir d’une simple idée, à partir d’un cahier des charges, ou à partir d’un design complet, on peut rarement passer directement à la phase de développement sans challenger le projet et le confronter aux freins et opportunités techniques existantes. D’expérience, il est donc très très rare qu’un client fournisse une maquette parfaitement fonctionnelle et encore moins qu’il ne demande aucune modification au cours du projet. Quand bien même ce serait le cas, cela nous mettrait dans une position de simple exécutant technique, sans possibilité de mettre en oeuvre notre expertise de conseil, ni de challenger le travail réalisé dans une optique d’amélioration. C’est tout ce que nous détestons faire chez Alqemist.
• les aléas côté client. Il y a une donnée que nous ne pouvons jamais maitriser à l’avance en tant que prestataire : le temps que va nous prendre le client. Je parle du temps en réunions, en call, en aller-retour, en changement de cap… C’est d’ailleurs principalement à cause de cet aléa que nous n’acceptons plus de travailler au forfait. Quand bien même nous serions capable de cadrer le projet et d’estimer les coûts de développement à la virgule (ie. ce qui est mission impossible), nous serions dépendant de “l’aléa client”. Nous ne voulons simplement pas nous retrouver à sacrifier la qualité du produit pour rentrer dans nos frais.

(Not so) Minimum Viable Products

S’il était plus abordable par le passé de développer un MVP à moindre coût (et encore c’est discutable), c’est beaucoup moins courant aujourd’hui tant les standards d’expérience attendue par les utilisateurs se sont élevés. Plus personne n’accepte les produits avec des bugs ou les expériences utilisateurs moyennes, même pour une version bêta. Le MVP “quick & dirty” n’a plus le vent en poupe.

De même, quand on essaie de se faire une place sur un marché déjà concurrentiel, nos testeurs attendent rapidement une expérience au moins équivalente aux outils déjà existants, si ce n’est meilleure évidemment. De sorte que les scopes de MVP sont de moins en moins minimalistes.

Nous ne contestons pas du tout la logique de vouloir dépenser le moins possible tant qu’on est en phase de test. Mais 9 fois sur 10, quand le MVP a été réalisé en mode “quick & dirty”, on se retrouve rapidement confronté à des problématiques de maintenabilité, de scalabilité et de performance qui obligent à tout reconstruire de zéro. On en parle des 10k jetés par les fenêtres ?

Le MVP codeless

En revanche, nous sommes convaincus qu’il y a de plus en plus de moyens de tester son idée ou son produit sans ligne de code et à moindre coût :

• Créer une audience captive avec une stratégie de contenu en amont d’une démarche produit
• Tester un message ou une idée avec une landing page et un petit budget publicitaire (Hello The Machinery 👋avec qui on collabore)
• Réaliser des maquettes animées ultra réalistes avec Figma, Sketch, Invision etc… et les faire tester à des potentiels futurs clients.

Cette démarche est encore trop souvent perçue comme longue, fastidieuse, voire même inutile pour des primo-entrepreneurs impatients de jouer avec leur nouveau gadget. Nous le voyons souvent, bon nombre de porteurs d’idées sont plus enclin à dépenser de l’argent pour construire rapidement un produit que d’investir beaucoup de temps dans les premières phases de recherche et de test. Ils sont bien trop souvent dans l’illusion que leur connaissance du marché et leurs convictions sont suffisantes pour démarrer. Là encore, nous les mettons en garde.

Pour toutes ces raisons, nous ne faisons (presque) jamais de produits “quick & dirty”. Ce n’est pas notre approche. En revanche, nous sommes de fervents défenseur d’une approche de test d’idée (et d’audience) “sans ligne de code”. Il n’y a pas de rationalité économique à dépenser 10K pour un test qui sera jeté à la poubelle plusieurs mois après.