Du prototype à la production
Une première version existe et elle fonctionne. Construite vite, en interne, par un prestataire ou avec les outils d’IA, elle a fait son travail : démontrer, convaincre, parfois servir déjà des utilisateurs. Il ne s’agit pas de repartir de zéro, mais de la faire tenir dans la durée, devant de vrais utilisateurs.
Quand faire appel à nous
- _Votre prototype a convaincu et doit maintenant être ouvert à de vrais utilisateurs.
- _Une première version construite avec des outils d’IA fonctionne, sans que personne puisse dire si elle tiendra.
- _Un client ou un pilote impose une vraie mise en production, avec les engagements qui vont avec.
- _Votre équipe hésite entre stabiliser l’existant et réécrire, et veut trancher sur des éléments.
- _De nouvelles contraintes apparaissent : sécurité, données personnelles, conformité, plusieurs clients à cloisonner.
Ce qui change quand un prototype devient un produit
Un prototype est jugé sur ce qu’il montre. Un produit est jugé sur ce qu’il continue de faire dans la durée : quand les données s’accumulent, quand plusieurs clients ne doivent pas voir les mêmes choses, quand une erreur survient la nuit.
Ces sujets ne sont pas des défauts du prototype : ils étaient hors de son périmètre, et c’est ce qui lui a permis d’aller vite. La difficulté n’est pas seulement technique, elle consiste à décider ce qui mérite d’être repris.
Ce que nous sécurisons
Les données et les accès : ce qui est stocké, où, qui peut le lire, et ce qu’il faudra pouvoir prouver quand un client le demandera.
L’infrastructure et son coût, qu’une architecture de prototype facture souvent à la requête. Puis l’exploitation : savoir qu’une erreur s’est produite avant que l’utilisateur ne l’écrive.
Enfin la reprenabilité, la moins spectaculaire et la plus déterminante : une autre équipe que celle qui l’a écrit pourra-t-elle faire évoluer ce produit dans six mois ?
Stabiliser avant de réécrire
Ce qui fonctionne reste, jusqu’à preuve du contraire. Une réécriture complète coûte des mois, recrée des comportements que vos premiers utilisateurs ont déjà validés, et remplace les risques connus par les siens.
Elle est parfois la bonne décision. Elle se démontre alors partie par partie, et porte le plus souvent sur un composant précis plutôt que sur le produit entier.
Comment nous intervenons
Nous partons de l’usage qui doit fonctionner en production, pas d’une remise à niveau exhaustive du code : un prototype contient toujours des morceaux que personne n’utilisera.
La même équipe arbitre produit, design, frontend, backend, donnée et infrastructure. Sur un passage en production, ces décisions ne se prennent pas séparément.
Nous nous engageons sur ce que la version doit permettre d’opérer en production, dans le délai et le budget convenus. À nous d’arbitrer avec vous les travaux nécessaires pour y arriver.
Ce que vous obtenez
- _Ce qui peut rester, ce qui doit évoluer, et l’arbitrage stabilisation ou réécriture pour chaque partie
- _Le produit en production : données, accès, sécurité, déploiement, observabilité
- _La documentation permettant à une autre équipe de reprendre le produit
- _La trajectoire pour la suite : ce qui reste à traiter, et dans quel ordre
Questions fréquentes
Faut-il tout réécrire pour passer en production ?
Le plus souvent non. Une partie du prototype tient déjà, et la remplacer coûterait du temps sans rien apporter. L’arbitrage se fait partie par partie, et vous le validez. Si votre besoin s’arrête à ce diagnostic, c’est l’audit technique.
Travaillez-vous sur du code généré par des outils d’IA ?
Oui. Qu’un code soit généré ou écrit à la main ne dit rien de sa qualité à lui seul : ce qui compte est ce qu’il fait, ce qu’il expose, et ce qu’il coûtera à faire évoluer.
Combien de temps prend une mise en production ?
Cela dépend de ce que le prototype a laissé de côté. Nous commençons par l’établir : cette première étape se conclut par un arbitrage chiffré.
Notre façon de cadrer, d’arbitrer et de nous engager est décrite en détail dans la méthode Vezero.