Prototype d'application : quand et comment le mettre en production

Les signes que votre prototype est devenu un produit sans que personne l'ait décidé

La bascule se fait rarement en comité de direction. Elle se fait un mardi, quand un collègue envoie le lien à un client « pour qu'il voie », et que le client crée un compte. À partir de là, l'application garde quelque chose qui ne vous appartient plus tout à fait : le nom, l'adresse, parfois les documents d'une personne qui fait confiance à votre entreprise.

Le premier signe tient aux comptes. Tant que seuls vos collègues testent, une perte de données coûte un après-midi de ressaisie. Dès qu'un client a un identifiant, il s'attend à retrouver demain ce qu'il a saisi aujourd'hui, et à ce que personne d'autre ne puisse le lire. Il ignore que l'application devait servir de démonstration, et il n'a aucune raison de le savoir.

Les données réelles arrivent ensuite, souvent par la petite porte : quelqu'un importe le fichier clients « pour tester avec du vrai », un autre dépose des devis signés ou des pièces justificatives. Une donnée d'essai perdue ne manque à personne. Une vraie donnée perdue manque à quelqu'un, et une vraie donnée qui fuit engage votre entreprise auprès des personnes concernées, et devant la loi quand il s'agit de données personnelles.

Reste l'argent. Il suffit d'un paiement en ligne branché « pour voir si ça marche », et qu'un premier client utilise. À ce stade, une erreur ne se règle plus en effaçant une ligne dans la base : il faut rembourser, expliquer, parfois corriger une facture déjà partie chez le comptable du client. Une seule de ces situations suffit : votre prototype est déjà un produit, quel que soit le nom qu'on lui donne en interne.

Prototype, MVP, produit : trois mots, trois exigences

Les trois mots circulent dans les mêmes réunions, souvent pour désigner la même chose. Ils ne demandent pourtant pas le même travail, et les confondre conduit à promettre une date que personne ne pourra tenir. Parler de « notre MVP » à propos d'un prototype monté en trois semaines prépare une mauvaise surprise.

Le prototype montre que l'idée intéresse. On lui demande d'être construit vite et de se laisser modifier sans effort. Il peut perdre ses données, tomber en panne la nuit, n'avoir qu'un compte administrateur partagé par toute l'équipe. Tant que seuls vos collègues s'en servent, ces défauts ne coûtent presque rien.

Le MVP, pour « produit minimum viable », est la plus petite version qui rend un service réel à des gens qui n'ont pas participé à sa construction. Le mot « minimum » porte sur le nombre de fonctions. Sur la solidité de ce qu'il contient, un MVP ne transige pas : des comptes séparés, des données sauvegardées, et des erreurs que vous voyez passer avant qu'un client vous les signale. Notre chapitre sur le MVP et ce qu'on met dedans explique comment choisir ce périmètre.

Le produit, enfin, est ce que vous vendez ou ce dont votre équipe dépend chaque jour. Au MVP s'ajoutent des choses que personne ne voit : quelqu'un qui répond quand l'application tombe, des mises à jour de sécurité appliquées à temps, une façon de la modifier sans casser ce qui marche.

Les prototypes construits avec un outil qui écrit le code sautent souvent de la première case à la troisième. Ils passent de « on montre l'idée » à « des clients en dépendent » sans l'étape du MVP, celle où l'on prend le temps de rendre solide le peu qu'on garde. Mettre le prototype en production revient à faire cette étape après coup, sur un code qui existe déjà et dont des gens se servent.

Ce qui manque presque toujours à un prototype d'application

Ce qui manque à un prototype se trouve derrière l'écran, et la liste revient d'une application à l'autre, quel que soit l'outil qui a écrit le code. L'outil écrit ce qu'on lui demande, et personne ne pense à lui demander une sauvegarde quand il s'agit de montrer une idée. Notre guide du vibe coding explique d'où viennent ces trous. Six reviennent plus que les autres.

Les comptes et les droits d'abord. Le prototype vérifie souvent qu'une personne est connectée, beaucoup plus rarement qu'elle a le droit de voir ce qu'elle demande. Un client connecté qui change un numéro dans l'adresse de la page peut alors tomber sur la fiche d'un autre client. Le test est à votre portée : connectez-vous avec un compte ordinaire et essayez d'ouvrir une page réservée à l'administrateur.

Viennent les sauvegardes. Beaucoup de prototypes n'en ont aucune, ou comptent sur celle du service qui héberge la base sans que personne sache combien de temps elle est gardée ni comment la récupérer. Une sauvegarde compte à partir du jour où quelqu'un l'a restaurée une fois, sur une copie, en notant le temps que cela a pris.

Le journal de ce qui se passe et la gestion des erreurs vont ensemble. Quand un client écrit « ça ne marche pas », il faut pouvoir retrouver ce qu'il a fait, à quelle heure, et ce que l'application lui a répondu. Un prototype montre souvent une page blanche ou un message technique en anglais, et ne garde aucune trace. Vous apprenez la panne par le client, quand il prend la peine d'écrire.

La tenue à la charge se découvre en général le jour du lancement. Une application qui répond bien à cinq personnes peut ralentir nettement à cinquante, surtout quand chaque écran va chercher toute la base pour n'en afficher qu'une ligne. Personne ne l'a remarqué pendant les essais : la base contenait vingt fiches.

Dernier point, et le plus urgent : les mots de passe et les clés des services branchés, comme le paiement, l'envoi de courriels ou la base de données. Dans un prototype, ils sont souvent écrits en clair dans le code, parfois lisibles depuis le navigateur de n'importe quel visiteur. Celui qui les trouve peut envoyer des courriels en votre nom ou lire toute la base. Les sortir du code et les changer se fait en premier.

Ce que vous gardez du prototype, et ce que vous jetez

Le prototype a coûté peu et vous a beaucoup appris. Ce qu'il vous a appris vaut plus que son code. Avant de décider du sort de ce code, faites la liste de ce que de vrais utilisateurs ont validé : c'est ce qui coûterait le plus cher à retrouver.

Les écrans que vos utilisateurs ont adoptés se gardent. Vous les avez corrigés sous leurs yeux, au fil de leurs remarques, et chaque bouton déplacé correspond à une hésitation que quelqu'un a eue. Refaire ces écrans « proprement » à partir d'une page blanche ferait perdre ce travail, et vos utilisateurs le remarqueraient dès le premier matin.

Ce que les utilisateurs ont appris se garde aussi, et il se trouve rarement dans le code. Le cas particulier qu'un commercial a signalé, la question que tout le monde pose au premier usage : notez-les tant que les personnes concernées s'en souviennent.

Le reste se jette sans regret : les fonctions abandonnées en cours de route, les écrans d'essai que plus personne n'ouvre, les données factices mélangées aux vraies, les copies d'un même bloc que l'outil a réécrit trois fois parce qu'on lui a demandé trois fois la même correction. Chacun de ces morceaux est un endroit où un défaut peut se cacher.

Entre les deux, il y a le code qui fait tourner les écrans gardés. Il se garde quand il se lit et qu'il tient debout, il se réécrit par morceaux quand il ne se lit plus. Cette décision ne se prend pas depuis l'écran, où tout a l'air de fonctionner. Elle demande que quelqu'un ouvre le code et le lise en entier.

Pourquoi faire relire le code avant la mise en production

Mettre en production un code que personne n'a lu revient à signer un bail sans avoir visité l'appartement. L'application tient peut-être très bien. Personne ne le sait, et vous l'apprendrez le jour où un client vous écrira, ou le jour où quelqu'un lira le code à votre place pour de mauvaises raisons.

Une relecture lit tout le code sans rien modifier. Elle regarde où vivent les données et qui peut les lire, quels mots de passe et quelles clés traînent dans les fichiers, ce qui se passe quand un formulaire reçoit autre chose que ce qu'il attend, comment les fichiers envoyés par les utilisateurs sont contrôlés et rangés. Elle repère aussi ce que l'outil a écrit deux fois, et ce qui céderait si dix personnes se connectaient en même temps.

Vous recevez un compte rendu qu'un dirigeant peut lire : ce qui tient, ce qui est ouvert, ce que coûte chaque correction, classé par risque. Vous savez alors ce qu'il faut faire avant la mise en ligne et ce qui peut attendre. Sans cette liste, chaque correction est un pari, et le budget part dans ce qui se voit plutôt que dans ce qui protège.

La relecture vient avant la mise en ligne pour une raison pratique : une fois les clients branchés, chaque correction se fait sous leurs yeux. Changer la façon dont les comptes sont rangés quand vingt collègues testent prend une matinée. Le faire quand trois cents clients ont saisi leurs données demande une migration, et une coupure annoncée à chacun d'eux.

Si vous voulez confier ce travail à une équipe extérieure, la reprise d'une application codée vite commence par cette relecture, se poursuit par la consolidation de ce qui est ouvert, et laisse le code dans votre dépôt. Quand la relecture montre que refaire coûterait moins cher que corriger, nous vous le disons avant de facturer quoi que ce soit d'autre.

Sortir l'application du poste de celui qui l'a construite

Beaucoup de prototypes vivent à un endroit que personne n'a choisi : l'ordinateur de celui qui les a construits, ou un compte personnel ouvert un soir sur un service d'hébergement et payé avec sa carte bancaire. Pour montrer une idée, cela suffit largement. Pour servir des clients, c'est un risque que personne n'a mesuré.

Le jour où cette personne part en congé ou quitte l'entreprise, l'application part un peu avec elle. Les accès sont dans sa tête ou dans son gestionnaire de mots de passe, la facture arrive sur son compte, et personne d'autre ne sait redémarrer le serveur. Il suffit d'une carte expirée pour que le service s'arrête un dimanche soir, sans que quiconque reçoive l'alerte.

Passer en production, côté hébergement, veut dire installer l'application sur un serveur dont votre entreprise détient les accès : le compte à son nom, la facture à son nom, au moins deux personnes capables de s'y connecter. Les sauvegardes y tournent chaque jour sans qu'on ait à y penser. Une copie de l'application sert à essayer les changements avant qu'ils touchent les vrais utilisateurs.

Le choix du fournisseur compte moins que la question de qui détient les clés. Un hébergement au nom de votre entreprise chez un fournisseur connu vaut mieux qu'un montage ingénieux que seul son auteur comprend. Si vos données sont sensibles ou si vos clients sont en Suisse, l'endroit où elles sont stockées entre aussi dans la décision. Écrivez-le noir sur blanc, car un client finira par vous poser la question.

Votre informaticien ou un prestataire peut s'en charger, à condition que les accès reviennent à votre entreprise. Si vous préférez nous confier cette partie, notre page sur l'hébergement décrit ce que nous prenons en charge et ce que vous gardez. Dans tous les cas, posez-vous la question du départ : si la personne qui a installé l'application disparaît demain, quelqu'un d'autre peut-il la redémarrer ?

Des tests sur les parcours qui comptent, pour continuer avec l'outil sans rien casser

Une fois l'application consolidée, la tentation est forte de continuer comme avant : demander une nouvelle fonction à l'outil, vérifier à l'écran que ça marche, publier. Le risque se trouve dans ce que vous ne regardez pas. Pour ajouter un filtre, l'outil a modifié trois fichiers, dont un qui servait aussi à l'inscription. Personne ne s'en aperçoit avant qu'un nouveau client écrive qu'il ne parvient pas à créer son compte.

Un test automatique est un petit programme qui rejoue un parcours et vérifie le résultat. Un visiteur crée un compte, reçoit son courriel, se connecte, voit son tableau de bord et seulement le sien. Le test tourne à chaque modification, en quelques minutes, et signale ce qui a cassé avant que la modification n'arrive chez vos utilisateurs.

Tout couvrir ne sert à rien. Les tests qui rapportent le plus portent sur les parcours dont une panne vous coûterait un client : l'inscription, la connexion, le paiement, ce que vos utilisateurs font tous les jours. Ajoutez-y une vérification qui protège tout le reste, celle qu'un client ne voit jamais les données d'un autre.

Avec ces tests en place, vous pouvez continuer à faire écrire du code par Lovable, Cursor ou un assistant de programmation. Chaque modification passe la même vérification que celle d'un développeur. Quand un test échoue, vous montrez l'erreur à l'outil, il corrige, et vous savez que sa correction n'a rien cassé ailleurs. Sans tests, chaque demande faite à l'outil peut toucher le reste de l'application à votre insu.

Nous suivons cette démarche avec Hairdex, une entreprise de téléconsultation capillaire : neuf applications, trois développeurs qui font déjà écrire du code par des assistants, chacun à sa façon, et aucun test automatique au départ. Nous formons l'équipe sur ses propres dépôts. Les tests viennent d'abord sur les parcours qui touchent au patient, avec un fichier de contexte par dépôt tenu à jour automatiquement et une revue de code branchée sur chaque modification proposée. La mission est en cours.

Le jour de la mise en ligne : les données, un petit groupe, un retour arrière prévu

Avant la date, quelqu'un qui connaît le métier rejoue les parcours réels sur la copie de test, avec une liste écrite de ce qu'il doit obtenir, et note tout ce qui s'en écarte. Cette personne voit ce que celui qui a écrit le code ne pense pas à essayer. Notre chapitre sur la recette fonctionnelle explique comment écrire cette liste et qui la valide.

Les données du prototype demandent une décision à part. Celles des vrais clients se reprennent : comptes, fiches, historiques, documents. Les données d'essai, les comptes « test2 » et les fiches au nom de Mickey restent derrière. La reprise se prépare sur une copie, se vérifie (le nombre de comptes, quelques fiches ouvertes une à une) et se rejoue le jour venu avec un script, plutôt qu'à la main à minuit.

Quand nous avons reconstruit le site d'inscription du Groupe des Arbitres Genevois, la première étape a consisté à récupérer les 557 inscrits et les 18 sessions de l'ancien site, avant de toucher au reste. Nous avons ensuite placé les 1 355 pièces d'identité des candidats derrière un accès réservé au comité. L'ancien site n'avait rien d'un prototype, et la règle vaut pareil pour un prototype dont des clients se servent déjà.

Ouvrez ensuite à un petit groupe : cinq ou dix clients que vous connaissez, prévenus, qui savent à qui écrire quand quelque chose cloche. Une ou deux semaines avec eux révèlent ce que la recette n'a pas vu, sans que l'erreur touche tout le monde. Vous élargissez quand leurs remarques se calment, plutôt qu'à une date fixée d'avance.

Prévoyez enfin le retour arrière avant d'en avoir besoin. Si la nouvelle version pose problème, que remet-on en ligne, en combien de temps, et que deviennent les données saisies entre-temps ? Ces réponses s'écrivent la veille, à tête reposée. Choisissez aussi le moment : un matin en début de semaine, quand ceux qui peuvent corriger sont au bureau, plutôt qu'un vendredi soir.

Qui répond quand l'application tombe, une fois en production

Une application en production a besoin de quelqu'un qui décroche. Un lundi matin, un client écrit qu'il ne peut plus se connecter. Qui lit le message, qui a les accès au serveur, qui sait où chercher dans le journal, qui décide de remettre la version précédente ? Si ces quatre questions mènent à la même personne et qu'elle est en congé, la panne attendra son retour.

Il y a aussi ce qui ne tombe pas mais vieillit. Les briques sur lesquelles repose l'application publient des correctifs de sécurité, et le service de paiement fait évoluer ses règles sans vous demander votre avis. Une application laissée telle quelle pendant un an finit par casser sans que personne y ait touché, en général au moment où toute l'équipe est occupée ailleurs.

Trois organisations tiennent la route. Quelqu'un de votre équipe reprend l'application, avec la documentation et les tests, et garde quelques heures par mois pour son entretien. Un développeur indépendant ou une société s'en charge sous contrat, avec un délai de réponse écrit. Ou bien un suivi mensuel couvre les corrections et les petites évolutions, assuré par des gens qui connaissent déjà le code.

Le bon choix dépend de ce que vous coûte une heure de panne. Pour un outil interne utilisé par quatre personnes, une réponse dans la journée suffit. Pour une application où vos clients paient ou déposent des documents, il faut un délai écrit et quelqu'un de joignable. Notre chapitre sur la tierce maintenance applicative détaille ce qu'un contrat de ce type doit prévoir.

Si vous préférez que nous restions après la mise en ligne, notre suivi mensuel couvre les corrections et les évolutions, et s'arrête librement le mois suivant. Le code reste dans votre dépôt, documenté, pour qu'un autre puisse reprendre la main le jour où vous le décidez.

Quand reconstruire, quand consolider, et quand laisser le prototype tranquille

Un prototype n'a pas toujours vocation à passer en production. Une démonstration montée pour convaincre un financeur, un outil interne que trois collègues utilisent sans données sensibles : ils font leur travail tels qu'ils sont, et une relecture coûterait plus cher que ce qu'elle protège. Notez ce qu'il faudrait faire le jour où ils sortiront de ce cadre, et laissez-les tranquilles. Vous n'avez besoin de personne pour ça, nous compris.

Consolider vaut le coup quand le code se lit, que la structure des données tient debout et que les défauts trouvés à la relecture se corrigent un par un. C'est souvent le cas d'une application de taille modeste, construite par quelqu'un qui savait ce qu'il voulait. Les écrans restent, l'intérieur se renforce, et les utilisateurs ne voient presque rien changer.

Reconstruire vaut mieux quand le code ne se lit plus : des blocs entiers écrits trois fois, une structure de données que l'outil a changée en cours de route, chaque correction qui en casse deux autres. Corriger coûte alors plus cher que refaire. Ce qui a de la valeur se trouve ailleurs que dans le code : dans les écrans validés et dans les données de vos clients.

Reconstruire à partir du prototype va bien plus vite que partir d'une page blanche. Le prototype sert de cahier des charges qu'on peut cliquer : chaque écran montre ce qu'il faut obtenir, chaque remarque d'utilisateur signale un piège à éviter. Notre chapitre sur la refonte d'un logiciel détaille comment trancher entre corriger et refaire.

Cette décision se prend après lecture du code, avec des éléments, jamais sur une impression. Méfiez-vous d'un conseil de tout refaire donné sans avoir ouvert un seul fichier : il en dit plus sur ce que sait faire celui qui le donne que sur votre application. Pour une vue d'ensemble avant de choisir, notre guide du vibe coding reprend ce qu'on trouve dans une application écrite par un outil.