Vibe coding : le guide du dirigeant qui a une application codée vite sur les bras

Qui vibe code dans une entreprise, et pourquoi

Le dirigeant, d'abord, un dimanche soir. Il attend depuis deux ans un outil pour suivre ses devis, le prestataire consulté avait parlé de trois mois de travail, et il découvre qu'en décrivant son besoin à Lovable il obtient quelque chose qui marche avant minuit. Le lundi, il le montre à l'équipe. Le mercredi, deux personnes s'en servent. Personne n'a décidé de mettre un logiciel en service, et pourtant il tourne.

Le commercial, ensuite, qui veut montrer quelque chose à un prospect au lieu de lui envoyer une plaquette. Une démo cliquable, construite en un après-midi avec Bolt, convainc mieux qu'un diaporama. La difficulté arrive quand le prospect signe et demande quand il pourra s'en servir : la démo devient la base du produit, avec ses raccourcis.

Il y a aussi le stagiaire ou l'alternant à qui l'on a confié « un petit outil pour le service », et qui l'a monté avec ChatGPT en copiant les morceaux de code un par un. Le petit outil rend service, le stage se termine, et la seule personne qui savait comment il tenait debout repart avec ses mots de passe.

Votre prestataire, peut-être. Certains livrent plus vite qu'avant parce qu'un outil écrit l'essentiel à leur place, ce qui n'a rien de condamnable tant que quelqu'un relit. La facture ne le précise pas. Une question lève le doute : qui, chez votre prestataire, a lu le code avant de vous le livrer, et pouvez-vous lui parler ?

Enfin, l'équipe de développeurs qui se sert de Cursor ou de Claude pour aller plus vite. Ici, les gens savent lire le code, et ils le lisent, au moins au début. À force de voir l'outil tomber juste, on relit en diagonale, puis on ne relit plus les modifications qui paraissent petites. Une échéance serrée suffit pour que la relecture saute sur une partie sensible.

Ce que ça produit de bon, et pourquoi c'est souvent la bonne décision

Un prototype en quelques jours. Il y a peu, tester une idée de logiciel demandait un devis et plusieurs semaines de développement avant de voir le premier écran. Aujourd'hui, un après-midi suffit pour voir l'écran, cliquer dessus et se rendre compte que l'idée de départ ne tenait pas, ou qu'elle tenait mieux que prévu. Cette vitesse évite de payer des mois de travail pour une fonction dont personne ne se servira.

Une démo qui convainc. Un client ou un financeur comprennent en trente secondes, devant un écran qui réagit, ce qu'ils n'auraient pas saisi en vingt pages de présentation. Pour obtenir un accord ou débloquer un budget, la démo construite vite obtient ce qu'aucun document n'obtient, avant même que vous ayez engagé quoi que ce soit.

Une idée testée avant d'investir. Le service le plus précieux du vibe coding est de faire échouer vite, et pour presque rien, les idées qui ne tiennent pas. Une application de réservation que personne n'utilise au bout de trois semaines vous a coûté quelques soirées. La même, commandée à un prestataire, vous aurait coûté un vrai budget, et l'échec aurait été plus difficile à admettre devant votre équipe.

Construire un premier outil de cette façon est donc souvent une bonne décision, y compris quand l'application finit à la corbeille. Les gens qui l'ont fait n'ont pas à s'en excuser, et un prestataire qui commence par critiquer le travail déjà fait vous fait perdre du temps. Le risque arrive plus tard, au moment où l'application change de rôle sans que personne ne l'ait décidé.

Lovable, Bolt, Cursor, ChatGPT, Claude : à quoi servent les outils que vous croisez

Les noms reviennent dans toutes les conversations sans désigner la même chose. Deux familles se distinguent : les outils qui construisent une application entière à partir d'une conversation, et les assistants qui écrivent du code à la demande dans un projet tenu par quelqu'un. La famille de l'outil utilisé chez vous indique déjà où regarder en premier.

Lovable et Bolt appartiennent à la première famille. Ils s'ouvrent dans le navigateur : vous décrivez l'application dans une fenêtre de discussion, elle se construit à côté, et vous pouvez la mettre en ligne sans rien installer. Ils plaisent aux gens qui ne programment pas. La base de données et la connexion des utilisateurs passent par des services que l'outil branche pour vous, et ce branchement mérite d'être regardé de près.

Cursor appartient à la seconde famille. C'est un éditeur de code, l'outil de travail quotidien d'un développeur, dans lequel un assistant lit les fichiers du projet, propose des modifications et peut les appliquer lui-même. Il demande un minimum de pratique : quelqu'un doit savoir ouvrir un projet, le lancer et le publier. Une application construite avec Cursor a donc presque toujours un auteur qui sait programmer, ce qui ne garantit pas qu'il ait tout relu.

ChatGPT, d'OpenAI, et Claude, d'Anthropic, sont des assistants de conversation généralistes. On leur demande un morceau de code, on le copie dans son projet, on revient quand quelque chose ne marche pas. Des outils internes entiers naissent ainsi, bout par bout, sans que personne en ait jamais eu une vue d'ensemble. Les deux éditeurs proposent aussi des outils qui travaillent directement dans les fichiers d'un projet, plus proches de Cursor dans l'usage.

Aucun de ces outils n'est mauvais, et ce guide ne les classe pas. Leurs prix et leurs conditions changent vite : pour l'abonnement ou la propriété du code, la seule référence fiable est la page officielle de l'outil que vous utilisez. Pour juger votre application, une autre question pèse plus lourd que le nom de l'outil : quelqu'un a-t-il relu ce qu'il a écrit ?

Les cinq endroits où une application codée vite casse

Une application construite sans relecture ne casse pas au hasard. Les mêmes faiblesses reviennent d'un projet à l'autre, parce que personne ne demande ces choses-là à l'outil. Quand on décrit une page de réservation, on parle des créneaux et du bouton de confirmation, rarement de qui a le droit de lire la liste des réservations.

Un : les mots de passe et les clés écrits dans le code. Pour envoyer un courriel, encaisser un paiement ou interroger une base de données, l'application a besoin de codes d'accès. Il arrive que l'outil les écrive là où c'est le plus commode, directement dans le code, parfois dans la partie envoyée au navigateur de chaque visiteur. Quiconque sait ouvrir les outils de développement de son navigateur peut alors les lire, et s'en servir à vos frais.

Deux : les données dont on ne sait pas où elles vont. Les fiches clients et les pièces jointes sont stockées quelque part, mais chez quel fournisseur, et dans quel pays ? Et qui peut les lire ? Certains outils branchent une base de données que le navigateur interroge directement, protégée par des règles d'accès qu'il faut écrire. Quand ces règles manquent ou laissent tout passer, un visiteur un peu curieux peut lire la table entière.

Trois : la charge. L'application tenait sans effort avec dix utilisateurs, ceux de l'équipe. Avec cent, elle ralentit, et avec mille elle tombe le lundi matin à neuf heures. L'outil a écrit un code qui marche sans se demander combien de fois il serait appelé : une page qui relit toute la base à chaque affichage passe inaperçue en test, puis coûte cher en production, en lenteur comme en factures d'hébergement.

Quatre : l'absence de sauvegarde. Sans copie récente de la base de données, une fausse manipulation ou un fournisseur en panne suffit à effacer des mois d'inscriptions, et l'outil ne prévoit pas toujours cette copie de lui-même. Une sauvegarde que personne n'a jamais essayé de restaurer ne vaut guère mieux : vous découvrez qu'elle est vide ou incomplète le jour où vous en avez besoin.

Cinq : personne pour réparer. Le jour où l'application tombe en erreur, qui répond ? La personne qui l'a construite est peut-être partie, ou elle n'a jamais compris le code qu'elle a fait écrire. Demander à l'outil de corriger marche parfois. D'autres fois, la correction casse autre chose, ailleurs, et personne ne le voit avant qu'un client ne s'en plaigne.

Le jour où le prototype devient un produit sans que personne l'ait décidé

Personne ne signe un document qui dit « à partir d'aujourd'hui, ce prototype est notre logiciel ». Le passage se fait par petites touches. Un premier client réel crée son compte. Quelqu'un saisit de vraies adresses et de vrais numéros de téléphone. Un jour, le bouton de paiement quitte le mode test. À chacune de ces étapes, l'application garde la même apparence, ce qui rend le changement invisible depuis votre bureau.

Trois signes permettent de dater ce passage. Des personnes extérieures à l'entreprise ont un compte. Des données personnelles y sont stockées : des noms, des courriels, parfois des pièces d'identité ou des informations de santé. De l'argent y circule, ou une décision commerciale dépend de ce qu'elle montre. Un seul de ces signes suffit pour que l'application mérite d'être traitée comme un produit.

Ce changement de rôle déplace la responsabilité. Tant que l'application servait à tester une idée en interne, une panne coûtait une soirée. Dès que des clients y confient leurs données, une fuite engage votre entreprise : le RGPD en France et la loi sur la protection des données en Suisse visent l'entreprise qui les collecte, quel que soit l'outil qui a écrit le code.

Rien n'oblige à tout arrêter. Il s'agit de rattraper après coup ce qu'un projet classique aurait fait avant la mise en ligne : vérifier qui accède à quoi, sortir les secrets du code, prévoir des sauvegardes, écrire des tests sur les parcours qui comptent. Notre guide sur le MVP, la première version d'un logiciel, décrit ce chemin, et il vaut aussi pour une application codée vite.

Plus tôt vous le faites, moins il en coûte. Une application qui compte vingt clients se consolide sans que personne ne s'en aperçoive. La même, un an et deux mille comptes plus tard, demande de déplacer des données vivantes sans interrompre le service, avec des utilisateurs habitués à ses défauts.

Comment savoir si la vôtre tient : dix questions à vous poser

Un premier tri se fait sans lire une ligne de code, en interrogeant la personne qui a construit l'application et en ouvrant les comptes de l'entreprise. Chaque « je ne sais pas » est une réponse utile : il montre où regarder en premier. Gardez les réponses : elles serviront à qui relira le code.

Sur les accès, d'abord. Qui détient les identifiants de l'hébergement, du nom de domaine et de la base de données : un compte de l'entreprise, ou le compte personnel de celui qui a construit l'outil ? Si cette personne partait demain, pourriez-vous encore vous connecter partout ? Où se trouve le code, et votre entreprise en possède-t-elle une copie qu'elle contrôle ?

Côté données, quelles informations sur vos clients l'application garde-t-elle, et dans quel pays sont-elles stockées ? Un utilisateur connecté peut-il voir les fiches d'un autre en changeant un chiffre dans l'adresse de la page ? L'application accepte-t-elle des fichiers envoyés par les visiteurs, et où les range-t-elle ? Existe-t-il une sauvegarde, et quelqu'un a-t-il déjà essayé de la restaurer ?

Reste le fonctionnement. Combien de personnes s'en servent aujourd'hui, et combien dans six mois si tout va bien ? Qui est prévenu quand l'application tombe, et par quel moyen ? Quand quelqu'un la modifie, une vérification s'assure-t-elle que le reste marche encore, ou attend-on qu'un client se plaigne ?

Une partie se vérifie de l'extérieur en quelques minutes. Notre analyseur de site lit vos pages comme un visiteur : la connexion sécurisée, les liens qui ne mènent nulle part, le code technique affiché en clair, la vitesse de la page d'accueil, chaque point avec la page et l'extrait en cause. Il ne lit pas le code et ne remplace pas une relecture.

Si vos réponses sont nettes, que l'application ne garde aucune donnée sensible et qu'elle sert à quelques personnes de l'équipe, vous n'avez sans doute besoin de personne. Gardez-la, notez quelque part qui détient les accès, faites une sauvegarde, et revenez à cette liste le jour où l'application s'ouvre à des clients ou à des paiements.

Ce que regarde une relecture de code, expliqué à un dirigeant

Une relecture de code, qu'on appelle aussi audit de code ou revue de code, consiste à faire lire l'application par quelqu'un qui sait programmer et qui ne l'a pas écrite. Elle répond à trois questions de dirigeant, sans juger la personne qui l'a construite : l'application tient-elle, qu'est-ce qui risque de casser, et combien coûte la remise en ordre ?

Le relecteur commence par la structure. Chaque règle se trouve-t-elle à un seul endroit, ou la même logique est-elle recopiée dans quinze fichiers ? Un outil qui écrit à la demande recopie parfois au lieu de réutiliser, et une règle copiée quinze fois se corrige quinze fois. Une structure confuse se paie ensuite à chaque modification, plus lente et plus chère que la précédente.

Viennent ensuite les secrets et les droits d'accès. Le relecteur cherche les mots de passe et les clés écrits en clair, dans le code comme dans son historique : un secret effacé du code reste lisible dans les anciennes versions, et utilisable tant qu'on ne l'a pas changé. Il vérifie aussi que chaque page contrôle qui la demande. Un client ne voit que ses propres données, et l'administration reste fermée au reste du monde.

Restent les dépendances et les tests. Une application s'appuie sur des dizaines de briques écrites par d'autres, les bibliothèques, dont certaines ont des failles connues ou ne sont plus entretenues. Le relecteur regarde aussi s'il existe des tests automatiques, ces petits programmes qui vérifient à chaque modification que l'inscription, la connexion ou le paiement marchent encore. Dans une application codée vite, il arrive qu'il n'y en ait aucun.

Un compte rendu utile se lit en une demi-heure. Il classe les problèmes du plus grave au moins grave, explique chacun en une phrase que vous comprenez (« un client connecté peut lire les factures des autres »), chiffre le temps de correction et propose un ordre. Il se termine par un avis net : garder en l'état, corriger ou refaire. Quarante pages de termes techniques ne vous aident pas à décider quoi faire lundi.

La sécurité d'une application web, en langage de dirigeant

La sécurité d'une application se ramène à une question que tout dirigeant comprend : qui peut voir quoi, et qui peut faire quoi ? Les failles graves des applications codées vite demandent rarement un pirate de génie. On les trouve en cliquant, en changeant un chiffre dans une adresse, ou en envoyant un fichier qui n'est pas celui que l'application attendait. Quatre endroits méritent votre attention.

Qui peut voir quoi. Imaginez que votre facture se trouve à l'adresse « /factures/1042 ». Que se passe-t-il si un client tape « /factures/1043 » ? Dans une application bien construite, il reçoit un refus. Dans une application où personne n'a pensé à ce contrôle, il lit la facture d'un autre client. Cette faille arrive en tête du classement des failles du web que publie l'OWASP, la fondation qui fait référence sur la sécurité des applications, et elle se corrige vite une fois repérée.

Les formulaires. Chaque case qu'un visiteur peut remplir est une porte d'entrée, du formulaire de contact à la barre de recherche. L'application doit vérifier ce qu'on y tape avant de s'en servir, faute de quoi un texte bien choisi peut modifier ce que voient d'autres visiteurs, ou lui faire sortir des données qu'elle n'aurait pas dû montrer. Un formulaire sans protection contre les robots peut aussi se remplir de fausses inscriptions en une nuit.

Les envois de fichiers. Une application qui accepte des pièces jointes ou des justificatifs doit contrôler ce qu'elle reçoit : la taille, le type réel du fichier et l'endroit où elle le range. Un piège classique est le dossier de documents rangé à une adresse publique, que n'importe qui peut ouvrir s'il la devine. Quand ces documents sont des pièces d'identité, l'incident devient une fuite de données personnelles, qu'il faut parfois déclarer à l'autorité.

Les pages d'administration. L'espace qui permet de tout voir et de tout modifier doit être le mieux gardé de l'application. Il se trouve parfois à une adresse facile à deviner, protégé par un mot de passe choisi le premier soir et jamais changé, sans code de confirmation envoyé sur un téléphone. Le jour où ce mot de passe circule, la personne qui le détient a exactement les mêmes droits que vous.

Garder, reprendre ou refaire : comment trancher

Une fois les faiblesses connues, trois chemins s'ouvrent, et aucun n'est honteux. Garder l'application telle quelle, en connaissant ses limites. La reprendre, c'est-à-dire corriger ce qui est dangereux, ranger ce qui ralentit et ajouter ce qui manque. Ou la refaire, en se servant de la première version comme d'un cahier des charges vivant. Le choix dépend de ce que l'application porte, de ce qu'elle doit devenir et de l'état de son code.

Garder est le bon choix plus souvent qu'on ne le croit. Un outil interne utilisé par cinq personnes, sans donnée sensible, qui rend service et dont l'entreprise détient les accès, n'a pas besoin d'une reprise. Il a besoin d'une sauvegarde et d'un nom écrit quelque part à côté de « qui s'en occupe ». Dans ce cas, aucun prestataire ne devrait vous vendre autre chose, et nous non plus.

Reprendre convient quand l'application rend service, que ses utilisateurs y tiennent et que ses défauts sont localisés : des secrets à sortir, des contrôles d'accès à poser, des tests à écrire. C'est souvent le cas d'une application qui a trouvé son public. Le raisonnement suit celui de la dette technique : vous remboursez d'abord ce qui fait courir le plus de risques, puis ce qui ralentit chaque évolution.

Refaire se justifie quand le code ne peut pas porter ce que l'application doit devenir : une structure où chaque correction en casse deux autres, ou un outil interne qui doit s'ouvrir à des milliers de clients. La première version ne part pas à la poubelle pour autant. Elle a validé l'idée, montré comment les gens s'en servent, et elle sert de modèle à la refonte du logiciel.

Pour les cas douteux, le coût tranche. Si corriger l'existant revient plus cher que reconstruire, il faut reconstruire, et la personne qui relit votre code doit vous le dire avant de vous facturer la moindre correction. Méfiez-vous d'un avis qui conclut toujours à la refonte, ou toujours à la correction : il reflète plus souvent ce que vend celui qui le donne que l'état de votre application.

Qui s'occupe de l'application une fois qu'elle est en ligne

Une application continue de vieillir après sa mise en ligne, même si personne n'y touche. Les briques sur lesquelles elle repose publient des correctifs de sécurité, l'hébergeur change ses offres. Sans suivi, les mises à jour en retard s'accumulent, et quelqu'un les découvre le jour où il faut modifier l'application.

Les questions à régler sont terre à terre. Au nom de qui sont l'hébergement, le nom de domaine et les comptes des services branchés ? Qui reçoit l'alerte quand le site ne répond plus ? Qui applique les mises à jour de sécurité, et à quel rythme ? Tant que ces cases restent vides, l'application dépend de la bonne volonté de quelqu'un.

Pour une application dont dépend une partie de votre chiffre d'affaires, la réponse classique s'appelle la tierce maintenance applicative : un prestataire s'engage par écrit à surveiller, corriger et mettre à jour, avec des délais d'intervention. Au-delà du contrat, deux points comptent : les accès restent à votre nom, et le code reste dans votre dépôt. Le jour où vous changez de prestataire, vous n'avez rien à récupérer.

Une structure plus petite se contente souvent d'un suivi mensuel : quelqu'un qui connaît l'application, applique les mises à jour, corrige ce qui doit l'être et répond aux questions de l'équipe. Notre suivi mensuel fonctionne ainsi, à la cadence qui vous convient, et il s'arrête librement le mois suivant. Rien ne vous oblige à nous le confier : l'important est qu'une personne soit nommée, et qu'elle ait les accès.

L'hébergement mérite une ligne à part. Il arrive qu'une application codée vite tourne sur le compte personnel de son auteur : le jour où sa carte bancaire expire ou qu'il quitte l'entreprise, elle s'éteint. Faire passer l'hébergement sur un compte de l'entreprise est la première chose à faire, et la moins chère. Notre hébergement, en France ou en Suisse, vous laisse partir avec vos données et votre configuration quand vous le décidez.

Ce que nous faisons quand vous nous appelez

Quand vous nous appelez, l'application tourne déjà, des gens s'en servent, et vous voulez savoir si vous pouvez dormir tranquille. Nous commençons par lire le code, en entier, dans votre dépôt, sans rien modifier. Nous vous disons ensuite ce qui tient et ce qui ne tient pas, et nous chiffrons chaque correction séparément, pour que vous choisissiez ce qui se fait tout de suite et ce qui peut attendre.

Si vous décidez de consolider, ce qui protège passe en premier : nous sortons les secrets du code, vérifions les droits d'accès page par page, mettons en place des sauvegardes et contrôlons les formulaires comme les envois de fichiers. Viennent ensuite des tests automatiques sur les parcours qui comptent, puis un hébergement que vous contrôlez. Si refaire coûte moins cher que corriger, nous vous le disons avant de facturer la suite.

Le Groupe des Arbitres Genevois se trouvait dans une situation voisine : des inscriptions dans un site dont le fonctionnement n'était plus documenté, et des pièces d'identité de candidats dispersées sans contrôle d'accès clair. Avant de reconstruire, nous avons récupéré 557 inscrits et 18 sessions, puis placé 1 355 pièces d'identité derrière un accès réservé au comité. La revue de sécurité a couvert les formulaires, les envois de fichiers et les accès administrateur, et nous avons trouvé pourquoi certains courriels n'arrivaient pas en production. Le cas des arbitres genevois raconte le détail.

Chez Hairdex, une entreprise de téléconsultation capillaire, la situation de départ était autre : neuf applications, trois développeurs qui faisaient déjà écrire du code par des assistants, chacun à sa façon, et aucun test automatisé. L'équipe garde la main, et nous la formons sur ses propres dépôts : des tests d'abord, sur les parcours qui touchent au patient, 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 Hairdex est en cours.

La démarche complète, ses étapes et la façon dont le prix est fixé et signé avant de commencer sont décrites sur notre page reprise d'une application codée vite. Et si, une fois le code lu, la meilleure décision est de ne rien faire, nous vous le disons aussi, avec les raisons.

Continuer à vibe coder après une reprise

Une reprise ne vous oblige pas à renoncer à l'outil. Le code reste dans votre dépôt, et la personne qui construisait avec Lovable ou Cursor peut continuer à le faire. L'outil travaille désormais dans un projet rangé, protégé par quelques garde-fous, et ces garde-fous évitent que la consolidation se défasse en trois demandes mal formulées.

Le premier est un dépôt propre. Le dépôt, c'est l'endroit où vit le code et où chaque modification est enregistrée avec sa date et son auteur. Rangé, avec les secrets à part, il permet à l'outil de mieux s'y retrouver. Chaque changement passe par une demande de modification qu'un humain peut relire, et qu'on peut annuler si elle casse quelque chose.

Le deuxième, ce sont des tests qui préviennent. Une fois que des tests automatiques couvrent l'inscription, la connexion et le paiement, chaque modification les déclenche. Si l'outil casse un parcours en ajoutant une fonction ailleurs, le test échoue avant la mise en ligne, et vous n'apprenez pas la panne par un client mécontent. Pour savoir si la dernière modification est sûre, vous regardez si les tests sont passés, sans lire le code.

Le troisième est un fichier de contexte. Il décrit en quelques pages comment l'application est organisée, ce qu'il ne faut pas toucher et les règles du projet, par exemple « aucune clé écrite dans le code ». Des assistants comme Cursor ou Claude savent lire un tel fichier avant de travailler, et le tenir à jour évite qu'ils réintroduisent, au détour d'une demande, un défaut que la reprise avait corrigé.

L'outil garde alors son meilleur rôle, celui d'accélérateur. Vos équipes décrivent une fonction, l'outil l'écrit, les tests vérifient que rien d'autre n'a bougé, et quelqu'un relit avant la mise en ligne. En pratique, la personne qui faisait tout avec Lovable continue à la même vitesse, mais ses modifications passent par une relecture et par les tests avant d'arriver chez vos clients.