Développement de MVP, construit pour survivre au succès.

Un produit minimum viable est la plus petite chose que vous puissiez mettre devant un vrai utilisateur pour qu'il accomplisse une vraie tâche, et qui vous donne des preuves quant à la validité de l'idée. Minimum se rapporte au périmètre. Viable se rapporte à la qualité. La plupart des MVP ratés ont inversé les deux.

Ce n'est pas

• Un prototype. Une maquette cliquable vous dit si les gens comprennent un écran. Elle ne dit rien de leur volonté d'utiliser le produit, de le payer, ou de revenir mardi.
• Une démonstration pour investisseurs. C'est un autre objet, avec un autre budget, et confondre les deux produit un logiciel qui ne fonctionne que lorsque c'est vous qui le pilotez.
• Une version bon marché du produit complet. Retirer la finition de trente fonctionnalités vous donne trente mauvaises fonctionnalités. Réduire à trois bonnes vous donne un produit.
• Un objet jetable. Les MVP qui fonctionnent sont étendus, pas reconstruits — et c'est précisément pour cela que les fondations sont le mauvais endroit où faire des économies.

C'est

• Un utilisateur, une tâche, un parcours complet à travers le produit, fait correctement de bout en bout.
• Assez réel pour être facturé, quand la facturation fait partie de ce que vous testez.
• Instrumenté, pour que ce qui se passe soit mesuré plutôt que rappelé de mémoire.
• Écrit pour que les six mois de travail suivants l'étendent au lieu de le remplacer.

Chaque décision dans un MVP répond à la même question : que devons-nous apprendre ensuite, et quelle est la plus petite chose réelle qui nous l'apprend.

Il y a deux façons de rendre un développement plus petit. L'une est de faire moins de choses. L'autre est de faire les mêmes choses moins bien. Seule la première fonctionne, et la différence entre les deux est tout le métier du MVP.

À couper sans hésiter

• Les fonctionnalités qui servent un utilisateur que vous ne testez pas encore. Le second segment peut attendre que le premier soit prouvé.
• Les écrans de configuration. Un réglage dont trois clients ont besoin peut être modifié directement par votre équipe jusqu'à ce qu'ils soient trente.
• L'interface d'administration dessinée. Un back-office généré ou quelques pages internes suffisent tant que le modèle de données bouge encore.
• Les intégrations agréables plutôt que nécessaires : exports, synchronisation avec des tiers, authentification unique d'entreprise pour des sociétés que vous n'avez pas signées.
• Les cas limites que personne n'a réellement rencontrés. Traitez-les à la main et de façon visible jusqu'à ce qu'ils surviennent.
• Les langues supplémentaires, les plateformes supplémentaires, les canaux supplémentaires. Être correctement présent sur un seul suffit pour apprendre.
• Tout ce qui ne compte qu'à une échelle que vous n'avez pas. Vous pourrez ajouter un cache la semaine où vous aurez besoin d'un cache.

À ne pas couper

• L'authentification, la gestion des sessions et les vérifications de droits côté serveur. C'est la seule catégorie de bug qui met fin à un produit au lieu d'agacer un utilisateur.
• Le traitement correct de l'argent : opérations idempotentes, webhooks que l'on peut rejouer sans danger, et un journal que l'on peut rapprocher de celui du prestataire.
• Les migrations de base de données dès le premier commit, pour que le schéma ait un historique et que tous les environnements concordent.
• Les sauvegardes — avec une restauration que quelqu'un a réellement effectuée au moins une fois.
• Le suivi des erreurs et assez de logs pour répondre à la question de ce qui s'est passé. Voler à l'aveugle n'est pas une économie.
• Un modèle de données capable de représenter la réalité. Une donnée fausse coûte cher à corriger plus tard, et parfois c'est impossible.
• Les bases de la vie privée : collecter moins, dire ce que l'on collecte, et pouvoir le supprimer sur demande.
• L'accès au clavier et des contrastes lisibles. Ils ne coûtent rien quand ils sont intégrés dès le début et deviennent un projet quand il faut les rattraper.

La ligne est assez simple pour être appliquée en réunion. Coupez ce qui est cher à construire maintenant et bon marché à ajouter plus tard. Gardez ce qui est bon marché maintenant et cher à réparer.

Toute idée de produit repose sur une hypothèse qui décide de tout le reste, et c'est rarement celle par laquelle le plan commence. Ce peut être la volonté de payer, la faisabilité même d'une intégration, la fiabilité d'un calcul, ou l'existence de l'offre de l'autre côté d'une place de marché. Construisez cela en premier, tant qu'il reste du budget pour agir sur la réponse.

L'ordre que nous suivons

• Nommer l'hypothèse qui tuerait le produit si elle se révélait fausse, et décider comment le développement va la tester.
• Construire un parcours complet — de l'inscription au moment où la valeur apparaît — plutôt que plusieurs zones à moitié faites. Personne ne peut utiliser la moitié de trois parcours.
• Mettre la partie difficile sur le chemin critique tôt. L'intégration qui pourrait ne pas fonctionner n'est pas une tâche de la onzième semaine.
• Remplacer par une personne ce qu'une personne peut faire. Si un humain peut faire l'appariement, la modération ou l'accueil à la main pour les premiers utilisateurs, c'est une fonctionnalité que vous n'avez pas construite et un processus que vous comprenez désormais correctement.
• Instrumenter avant le lancement. Décider du chiffre qui signifie continuer et du chiffre qui signifie arrêter, et s'assurer qu'on peut le voir dès le premier jour.

Ce qui est reporté est écrit avec sa raison, pas oublié. Cette liste devient le début de la feuille de route, et elle évite d'avoir deux fois la même discussion dans trois mois.

Un MVP existe pour produire des preuves, et une preuve a besoin d'une personne réelle à l'autre bout. Dix utilisateurs venus de quelque part et ayant fait quelque chose valent plus que cent comptes de démonstration et une bonne réunion.

• Un canal et un segment. Si vous ne pouvez pas dire d'où viendront les cinquante premiers utilisateurs, ce n'est pas le développement qui vous bloque.
• Un lancement volontairement étroit : une liste d'invités, une ville, un partenaire, une catégorie.
• Le paiement tôt, si le produit est payant. La volonté de payer est le seul signal fiable, et des utilisateurs gratuits vous apprennent très peu de choses sur un produit payant.
• Un petit nombre d'événements mesurés — activation, action centrale, usage répété, paiement — plutôt qu'un tableau de bord analytique que personne n'ouvre.
• Une ligne directe avec les premiers utilisateurs. Les premières semaines sont des conversations, pas des tickets.

Le plan laisse du temps pour cela. Un MVP qui dépense la totalité de son budget avant le lancement a acheté un logiciel et sauté la partie qui devait le rendre utile.

Dextra est notre propre produit — nous l'avons conçu, nous l'avons construit, et nous l'exploitons. C'est la référence honnête de notre façon de travailler, plutôt qu'une histoire sur le projet de quelqu'un d'autre.

• Une application web de coaching sportif, en ligne sur dextra.fitness, en arabe, en français et en anglais — ce qui fait de la mise en page de droite à gauche un cas de première classe et non une arrière-pensée.
• De vrais utilisateurs, et des coachs certifiés qui délivrent des programmes à travers la plateforme.
• De vrais paiements par Flouci et D17, les prestataires que les gens utilisent réellement en Tunisie, avec le rapprochement, les relances et le travail de support qui arrivent avec l'argent.
• Des applications mobiles natives publiées sur l'App Store et Google Play, en plus de l'application web.

Il a été construit comme cette page le décrit. Le web d'abord, parce qu'une application web touche tout le monde immédiatement et n'attend pas dans une file de revue. Un parcours complet, de l'inscription à un programme payé, avant d'élargir quoi que ce soit. Des prestataires de paiement locaux plutôt qu'une passerelle carte que le marché n'utilise pas. Des applications mobiles seulement une fois que le produit les avait méritées.

L'exploiter est la partie qui enseigne le plus : le support, les montées de version, les paiements échoués, de vrais utilisateurs sur des téléphones Android bon marché et des connexions lentes. C'est une autre forme de connaissance que celle qui consiste à livrer et à partir. Il y a plus de détails sur le projet Dextra.

Si le MVP fonctionne, la pression change de forme. Plus d'utilisateurs, plus de rôles, plus de cas limites, et une équipe qui doit maintenant supporter le produit tout en continuant à le construire. Très peu de ce travail consiste à réécrire du code.

• L'exploitation : une vraie supervision avec alertes, un chemin d'incident, et des rapports que votre propre équipe peut produire sans demander à un développeur.
• L'outillage interne que vous aviez reporté : de vrais écrans d'administration, des droits, et une piste d'audit indiquant qui a changé quoi.
• Les performances là où elles comptent désormais : index et plans d'exécution face à un vrai volume de données, mise en cache, tâches en arrière-plan, pagination qui survit à un gros compte.
• La liste des reports, revisitée avec des preuves. Une partie se révèle inutile, et c'est précisément pour cela qu'elle a été reportée au lieu d'être débattue.
• La conformité et les contrats à mesure que les clients grossissent : conditions de traitement des données, règles de conservation, export et suppression, le questionnaire de sécurité qui arrive avec le service achats.
• La couverture de tests étendue autour de ce qui a cassé, parce que les incidents vous disent où les tests auraient dû être.

Ce sont des incréments délibérés sur le même code. Si cela ne peut se faire que par une réécriture, c'est que le MVP a été mal construit — ce qui est le sujet des deux sections suivantes.

Un MVP est censé porter de la dette. La dette est un emprunt sur la vitesse, et la vitesse est toute la raison d'être d'un MVP. Ce qui compte, c'est de savoir quels emprunts peuvent être remboursés et lesquels ne le peuvent pas.

Acceptable à ce stade

• Pas d'interface d'administration. Un script et un client de base de données, utilisés par quelqu'un qui sait ce qu'il fait.
• Des opérations manuelles. Une personne qui fait à la main ce qui sera automatisé plus tard, avec les étapes écrites.
• Une seule région, un seul serveur, pas de mise à l'échelle automatique. De la capacité que l'on ajoute la semaine où on en a besoin.
• Une couverture de tests mince en dehors du cœur, avec les tests concentrés là où vivent l'argent, l'authentification et le parcours principal.
• Des écrans internes sommaires, un minimum de réglages, et une configuration en dur dans un fichier facile à trouver.
• Un monolithe. Découper en services un système que personne ne comprend encore est l'erreur coûteuse, pas la précaution.

Inacceptable, à n'importe quel stade

• Des mots de passe mal stockés, des secrets versionnés dans le dépôt, des vérifications de droits qui n'existent que dans l'interface.
• Des données personnelles collectées sans raison, conservées sans limite, ou impossibles à supprimer sur demande.
• Pas de migrations, et un schéma qui n'existe que dans la base locale d'un développeur.
• De l'argent traité sans idempotence, sans trace d'audit, et sans moyen de rapprochement avec le prestataire.
• Pas de sauvegardes, ou des sauvegardes que personne n'a jamais restaurées.
• Pas de suivi des erreurs, si bien que les défaillances sont découvertes par l'e-mail d'un client.
• Un modèle de données incapable de représenter la réalité et tenu par des cas particuliers.
• Des déploiements faits à la main depuis un portable, sans chemin de retour.

Tout ce qui figure sur la première liste peut être remboursé en un sprint. Tout ce qui figure sur la seconde se transforme en réécriture, en fuite de données, ou en courrier de quelqu'un dont vous préféreriez ne pas avoir de nouvelles.

Les réécritures sont rarement causées par le framework. Elles sont causées par un système que plus personne ne peut modifier sans danger, et les causes sont assez constantes pour être listées.

• Un modèle de données faux dès le départ, contourné au lieu d'être corrigé.
• Des règles métier éparpillées dans les écrans, si bien que changer une règle veut dire la retrouver à onze endroits.
• Aucune frontière aux extrémités : un prestataire de paiement, un service d'e-mail ou une API externe appelés directement de partout, si bien qu'en remplacer un touche tout le code.
• Aucun test là où se trouve l'argent, si bien que personne n'ose refactoriser et que le code se calcifie.
• Une stack choisie parce qu'elle était intéressante, comprise par une seule personne, qui est partie depuis.
• Six mois de provisoire accumulé, jamais écrit nulle part et jamais planifié.

Ce qui l'évite

• Modéliser le domaine correctement dès le premier jour. C'est la chose la moins chère du projet et la plus chère à changer plus tard.
• Garder les règles métier dans une seule couche, séparée de l'interface, quelle que soit la mode de l'année en matière de framework.
• Placer une interface devant chaque service externe pour qu'il puisse être remplacé sans chirurgie.
• Des migrations dès le premier commit, avec l'historique du schéma dans le dépôt.
• Des tests autour de l'authentification, du paiement et de l'action centrale. Le reste peut être testé une fois qu'il cesse de bouger.
• Une technologie ennuyeuse et bien documentée, que des gens de votre marché peuvent réellement être recrutés pour maintenir.
• Une liste écrite des raccourcis pris et de ce qu'il en coûterait de défaire chacun, revue à la fin du MVP au lieu d'être redécouverte par la personne suivante.

Et la question qui décide plus que tout le reste : qui en est propriétaire. Le dépôt, les comptes d'infrastructure et les domaines sont à vous dès le premier commit. Si vous continuez avec nous, cela doit être parce que le travail est bon.

Un MVP commence par une conversation de cadrage, pas par un modèle de proposition commerciale. Dites-nous l'utilisateur, la tâche, et l'hypothèse qui vous inquiète, et vous recevez un périmètre, un découpage en phases et une estimation que vous pouvez contester.

• Un périmètre écrit avant le développement. Un changement est une décision avec sa propre estimation, jamais un ajout discret.
• Des sprints de deux semaines avec une démonstration à la fin, pour que vous pilotiez avec du logiciel qui fonctionne.
• Nearshore depuis Tunis, à UTC+1 : une journée de travail européenne complète recouvre la vôtre. Nous travaillons en anglais, en français et en arabe.
• Le support continue après le lancement, parce que les semaines qui suivent la mise en ligne produisent le retour qui était l'objet de l'exercice.

Les fourchettes de budget pour une application ou un MVP, et ce qui les fait bouger, sont publiées sur combien cela coûte. La façon dont le travail se déroule réellement — cadrage, sprints, transfert — est sur notre méthode.