Votre prototype fonctionne. Vous l’avez montré, on vous a dit oui, et la question devient : quand est-ce qu’on ouvre à tout le monde ? C’est le moment où l’écart entre une démonstration réussie et un produit exploitable devient visible.

Un prototype a un seul objectif, prouver qu’une idée tient. Il y parvient en écartant tout ce qui ne sert pas la démonstration. Ces éléments écartés constituent précisément le travail de mise en production.

Ce qu’un prototype laisse systématiquement de côté

Les utilisateurs qui font n’importe quoi. Pendant la démonstration, vous saisissez les bonnes valeurs dans le bon ordre. En production, quelqu’un colle une adresse de messagerie avec un espace, valide deux fois, revient en arrière au milieu d’un paiement, ou entre une date de naissance en 1823. Chaque écran doit tenir face à cela.

Les droits d’accès réels. Un prototype se montre avec un seul compte. Dès qu’il y a deux clients, la question devient : est-ce que le premier peut voir les données du second ? Ce défaut est la première cause de risque applicatif selon le classement de l’OWASP, et les applications générées le reproduisent presque toujours.

Le volume. Une liste de trente lignes s’affiche instantanément. La même liste avec trois mille lignes, chargée entièrement puis triée dans le navigateur, met une minute. Le seuil recommandé pour l’affichage du plus gros élément d’une page est de 2,5 secondes, et un prototype le franchit sans difficulté tant que la base est vide.

Ce qui se passe quand quelque chose échoue. Un service extérieur ne répond pas, un paiement est refusé, un courriel n’est pas parti. Le prototype ne prévoit rien parce que rien n’a échoué pendant la démonstration.

La trace. Quand un client affirme qu’il a bien validé sa commande et que rien n’apparaît, il faut pouvoir vérifier. Sans journal des actions, la discussion se règle à la parole contre parole.

Un défaut de fond qui pèse plus que les autres

Les outils de génération produisent du code qui fonctionne, et qui se répète. Une étude de GitClear portant sur plus de 200 millions de lignes modifiées entre 2020 et 2024 montre que la part de lignes copiées-collées est passée de 8,3 % à 12,3 % sur la période, pendant que la part de lignes déplacées, signe d’un remaniement du code, tombait de 24,1 % à 9,5 %.

Traduit en conséquences concrètes : la même règle de calcul se retrouve écrite à cinq endroits différents. Le jour où votre taux de remise change, il faut retrouver les cinq. On en oublie toujours une, et c’est celle qui touche la facturation.

Ce défaut ne provoque aucun incident le premier mois. Il rend simplement chaque évolution plus chère que la précédente, jusqu’au moment où plus personne n’ose toucher à certaines parties.

Ce qu’il faut décider avant de fixer une date

Combien d’utilisateurs, et lesquels. Ouvrir à vingt personnes que vous connaissez et à deux mille inconnus ne demandent pas le même travail. Une ouverture progressive reste la façon la moins coûteuse d’apprendre.

Quelles données sont sensibles. Des coordonnées professionnelles ne se traitent pas comme des données de santé ou des pièces d’identité. Le niveau d’exigence, et les obligations légales, en découlent directement.

Ce qui doit absolument ne jamais casser. Sur toute application, deux ou trois parcours comptent vraiment : s’inscrire, payer, recevoir sa confirmation. Ce sont ceux-là qu’on protège par des vérifications automatiques, pas l’ensemble du code.

Qui répond quand un utilisateur écrit. Une mise en production sans personne au bout du fil transforme le moindre incident en silence, puis en avis négatif.

L’ordre dans lequel on procède

La séquence qui fonctionne commence toujours par les droits d’accès et les secrets exposés, parce que ce sont les seuls défauts dont les conséquences sont irréversibles. Une donnée qui a fuité ne se rattrape pas.

Viennent ensuite la robustesse des parcours essentiels, puis la tenue en charge sur un volume réaliste, et enfin le remaniement du code qui coûte cher à faire évoluer.

Ce dernier point n’est pas toujours nécessaire avant l’ouverture. Il le devient dès que vous prévoyez plusieurs mois d’évolutions successives.

Le coût de l’attente

Reporter ce travail a un prix qui ne se voit pas immédiatement.

Chaque semaine passée à ajouter des fonctionnalités sur une base fragile augmente la quantité de code à reprendre ensuite. Une règle dupliquée dans trois écrans devient une règle dupliquée dans huit. Le remaniement qui prenait deux jours en prend six.

Sur le volet sécurité, l’arithmétique est différente et plus dure. Une application ouverte avec des droits d’accès défaillants expose ses données à partir de la première journée, et une donnée sortie ne rentre pas. Si des informations personnelles sont concernées, la découverte de la fuite ouvre un délai de 72 heures pour notifier la CNIL, procédure décrite sur son site, et ce délai court à partir de votre prise de connaissance.

Le calcul se fait donc en deux temps. Ce qui est réversible peut attendre et se traiter au fil de l’eau. Ce qui ne l’est pas se traite avant l’ouverture, même si cela décale la date de quelques semaines.

Ce qui se décide avec vos premiers utilisateurs

La mise en production n’est pas un interrupteur, c’est une progression qui s’organise.

Une ouverture à quelques utilisateurs internes pendant une semaine, sur des données réelles, révèle ce qu’aucune vérification interne ne produit : les usages auxquels personne n’avait pensé. Un commercial qui saisit trente commandes d’affilée trouve en une matinée trois irritants que vous n’auriez jamais vus.

Vient ensuite un petit groupe de clients prévenus qu’ils essuient les plâtres. Cette transparence change tout : un utilisateur averti signale un problème, un utilisateur surpris s’en va.

À chaque palier, une question à se poser : qu’est-ce qui a cassé, et qu’est-ce que cela révèle du reste ? Un défaut trouvé sur un écran existe généralement sur les écrans construits de la même façon.

Cette progression ne rallonge pas le calendrier, elle en déplace le contenu. Le temps qu’on passe à ouvrir progressivement, on ne le passe pas à réparer sous pression avec des clients mécontents.

Ce que nous faisons

Nous reprenons votre prototype et nous établissons l’écart entre son état actuel et ce que suppose une ouverture réelle, en français, point par point, avec ce que chacun représente.

Vous choisissez ce que vous traitez avant l’ouverture et ce qui peut attendre. Chaque lot est chiffré séparément, à prix fixe, et livré de façon à ce que vous voyiez l’avancement.

Nous ne prenons pas la main sur votre hébergement et nous n’exploitons pas votre application. Nous vous rendons un produit sur lequel vous pouvez ouvrir sans redouter le premier lundi.