Le terme est devenu un marqueur d'appartenance : ceux qui le revendiquent y voient une libération, ceux qui le méprisent y voient de l'amateurisme. Les deux camps parlent d'objets différents. Générer quelque chose qui fonctionne à l'écran et faire tourner ce quelque chose pendant deux ans avec de vrais utilisateurs dessus, ce ne sont pas deux niveaux de difficulté du même exercice. Ce sont deux métiers. Je réponds ici aux questions qu'on me pose le plus souvent.
Est-ce que ça marche vraiment ?
Oui, pour produire. Non, sans condition, pour exploiter.
Prompter jusqu'à ce que ça tourne est une manière parfaitement valable d'obtenir un résultat. J'ai construit deux produits en ligne de cette façon. Ce qui ne tient pas, c'est l'idée implicite que le moment où « ça marche » est le moment où c'est fini. C'est le moment où la moitié invisible commence.
La confusion vient de ce qu'on observe. Ce qu'on voit d'un produit, c'est le chemin où tout se passe bien. Ce qui coûte, c'est tout le reste : les cas non prévus, les erreurs, les gens qui font des choses que tu n'avais pas imaginées, et les six mois pendant lesquels il faudra modifier ce que tu ne te rappelles plus avoir écrit.
Quelle est la vraie différence entre un prototype et un produit exploité ?
Elle ne se mesure pas à la qualité du code. Elle se mesure à ce qui se passe quand ça casse.
Un prototype jetable sert à répondre à une question — est-ce que ce parcours est compréhensible ? est-ce que cette idée intéresse quelqu'un ? Quand il plante, tu perds une démonstration. Sa durée de vie utile se compte en jours. Tu n'as absolument aucune raison d'y mettre de la structure, des tests ou de la gestion d'erreur. C'est même une faute : tu paies un coût de rigueur pour un objet destiné à la poubelle.
Un produit exploité a des utilisateurs qui comptent dessus, souvent de l'argent qui transite, des données qui appartiennent à d'autres. Quand il casse, quelqu'un est bloqué et c'est toi le recours. Sa durée de vie se compte en années, et pendant ces années tu vas le modifier des dizaines de fois.
La faute la plus commune n'est pas de faire du vibe coding. C'est de laisser glisser un objet du premier statut vers le second sans jamais décider que la bascule a eu lieu.
Qu'est-ce qu'il faut ajouter pour tenir dans la durée ?
Cinq choses. Aucune n'est lourde si elle est faite au moment de la bascule ; toutes sont pénibles si elle est faite deux ans après.
De la structure. Pas d'architecture élégante — juste des conventions tenues : les choses nommées pareil partout, la logique métier au même endroit, pas quatre variantes du même traitement dispersées dans le projet. Le critère est simple : si tu cherches où modifier une règle et que tu dois fouiller, tu as un problème de structure.
Un minimum de tests. Pas une couverture complète. Les trois ou quatre parcours dont la casse serait inacceptable : l'inscription, le paiement, la donnée sensible. Un test qui vérifie qu'on peut encore réserver et payer vaut plus que cinquante tests sur des fonctions annexes.
De la gestion d'erreur explicite. Ce que voit l'utilisateur quand ça échoue, et ce que tu vois, toi, dans les journaux. Le second point est souvent oublié : sans trace exploitable, un incident signalé par un utilisateur devient une enquête à l'aveugle.
Des sauvegardes vérifiées. Vérifiées veut dire : tu as restauré au moins une fois, pour de bon. Une sauvegarde jamais restaurée est une hypothèse, pas une sécurité.
La compréhension de ce que tu as généré. Le point le plus important, et le plus difficile à s'imposer. Tu n'as pas besoin de savoir écrire chaque ligne. Tu dois savoir dire, sans ouvrir le projet : où vivent les données, comment un utilisateur est authentifié, ce qui se passe entre le clic sur « payer » et la confirmation. Si tu ne sais pas répondre à ces trois questions, tu n'exploites pas un produit — tu es locataire d'une boîte noire, et le jour où elle se comporte mal tu n'as aucun levier.
Comment savoir que la bascule a eu lieu ?
Un de ces trois faits suffit :
- Quelqu'un d'autre que toi dépend du fonctionnement pour son travail ou son argent.
- Tu stockes une donnée personnelle que tu ne pourrais pas te permettre de perdre ou d'exposer.
- Tu prévois de modifier l'objet dans plus de trois mois.
Le jour où l'un de ces trois est vrai, arrête d'ajouter des fonctionnalités pendant deux jours et fais le passage listé plus haut. Deux jours, à ce moment-là. Bien plus tard, ce sera plusieurs semaines et ce sera fait sous contrainte, avec des utilisateurs qui attendent.
Ma position, en clair
Je n'ai aucun mépris pour cette pratique — je l'utilise, et elle m'a permis de mettre en ligne des choses que je n'aurais pas construites autrement. Ce que je refuse, c'est le discours qui présente la génération comme la totalité du travail. Il produit des gens sincèrement surpris de découvrir, six mois après, qu'ils ont hérité d'un système qu'ils ne comprennent pas et qu'ils ne savent pas réparer.
La compétence qui compte n'a pas changé avec les outils. Ce n'est pas d'écrire le code. C'est de savoir dans quel état on met les choses avant de s'en aller.
Une chose à faire cette semaine
Prends ton projet en cours et réponds par écrit aux trois questions du paragraphe sur la compréhension : où vivent les données, comment on authentifie, que se passe-t-il pendant un paiement. Si une réponse te manque, tu viens de trouver le sujet de ta prochaine session — avant la prochaine fonctionnalité.