Développement en vibe coding : prototypes et MVP livrés vite, code repris proprement

Que recouvre ce service de vibe coding, et où s'arrête-t-il ?

Le service tient en deux temps. D'abord, construire vite : un écran cliquable, puis une première version utilisable, en faisant écrire l'essentiel du code par un assistant d'IA guidé pas à pas. Ensuite, reprendre ce code comme le ferait n'importe quel développeur avant une mise en service : le lire, le ranger, fermer les accès qui ne devraient pas exister, écrire les tests, poser une vraie base de données, déployer sur un hébergement maîtrisé et documenter. Le premier temps sert à apprendre vite ce que veulent vos utilisateurs ; le second, à ne pas leur confier une application fragile.

Un troisième cas arrive de plus en plus souvent : le sauvetage. Un dirigeant, un enseignant ou un commercial a construit seul son outil sur Lovable, Bolt ou v0, il fonctionne, des collègues ou des clients s'en servent, puis chaque nouvelle demande à l'assistant casse une autre partie. Le travail consiste alors à récupérer le code, à établir un diagnostic écrit, à sécuriser ce qui expose des données, puis à décider avec vous s'il faut consolider, reprendre en partie ou reconstruire.

Le service ne couvre pas tout. Un logiciel de gestion central, avec des années de vie devant lui et des règles métier lourdes, relève d'une application web sur mesure conçue comme telle dès le départ. Ajouter une fonction d'IA à un logiciel qui existe déjà, comme la lecture de factures ou la recherche dans vos documents, relève de l'intégration de l'IA en entreprise. Et si vous voulez apprendre à pratiquer vous-même, la formation au vibecoding est faite pour cela : ici, c'est le résultat qui est livré, pas la méthode enseignée.

D'où vient l'expression « vibe coding », et que disait vraiment Andrej Karpathy ?

Le mot a été lancé par Andrej Karpathy, ancien directeur de l'IA chez Tesla et membre fondateur d'OpenAI, dans un message publié sur X le 2 février 2025. Il y décrit « une nouvelle façon de coder » où l'on « se laisse porter », jusqu'à « oublier que le code existe ». Il précise sa pratique : il accepte toutes les modifications proposées, ne lit plus les différences, colle les messages d'erreur sans commentaire, et reconnaît que le code dépasse ce qu'il comprend d'habitude. Sa conclusion tient en une phrase, citée en entier par Simon Willison le 19 mars 2025 : c'est « pas mal pour des projets jetables du week-end ».

L'expression a ensuite quitté le cercle des développeurs. Le 6 novembre 2025, selon une dépêche de l'agence PA reprise par The Irish News, le dictionnaire Collins a fait de « vibe coding » son mot de l'année 2025, défini comme un développement logiciel qui transforme le langage naturel en code informatique grâce à l'IA. Les lexicographes de Collins y notent une très forte hausse d'usage depuis son apparition en février.

Karpathy a lui-même mis des limites à sa formule. Dans un billet de son blog daté du 27 avril 2025, consacré à son application MenuGen, il raconte que le prototype local lui a demandé peu de temps, mais que l'essentiel du travail s'est passé ailleurs : dans les réglages d'hébergement, d'authentification, de paiement et de clés d'API. Il y relève qu'un assistant a voulu rapprocher les paiements Stripe des comptes par l'adresse e-mail, alors que l'adresse saisie au paiement peut différer de celle du compte. Sa conclusion : construire ainsi une application web complète reste « assez brouillon » et « pas une bonne idée pour quoi que ce soit d'important ».

C'est exactement l'écart que ce service comble. Simon Willison, dans le même article, distingue le vibe coding du développement assisté par IA : quand le code produit est relu, testé et compris, ce n'est plus du vibe coding, c'est du développement logiciel. Le prototype peut naître « aux vibes » ; ce qui part chez vos clients doit avoir été lu par quelqu'un capable de l'expliquer.

Pourquoi le choix de l'outil compte-t-il moins que la relecture ?

Les éditeurs le disent eux-mêmes. La documentation de GitHub Copilot rappelle que l'utilisateur reste responsable de relire et d'approuver le travail de l'assistant. La page de sécurité de Claude Code écrit que c'est à vous de vérifier le code et les commandes proposés avant de les approuver. La page de sécurité de Lovable va plus loin : ses analyses automatiques aident à repérer les problèmes courants mais « ne peuvent pas garantir une sécurité complète », et une application qui traite des données sensibles mérite une revue de sécurité professionnelle supplémentaire.

Les mesures indépendantes vont dans le même sens. En juillet 2025, l'organisme de recherche METR a suivi 16 développeurs expérimentés sur 246 tâches de leurs propres projets : avec les outils d'IA, ils ont mis 19 % de temps en plus, alors qu'ils s'attendaient à gagner 24 % et croyaient encore, après coup, avoir accéléré de 20 %. L'étude porte sur des experts dans un code qu'ils connaissaient bien ; elle ne dit pas que l'IA ralentit tout le monde, elle dit que l'impression de vitesse ne vaut pas mesure.

L'enquête 2025 de Stack Overflow auprès des développeurs donne la même image : 84 % des répondants utilisent ou prévoient d'utiliser des outils d'IA, mais 46 % se méfient de l'exactitude de leurs réponses, contre 33 % qui leur font confiance. La première frustration citée, par 66 % d'entre eux, concerne des solutions « presque justes, mais pas tout à fait ». Et 72,2 % déclarent que le vibe coding ne fait pas partie de leur travail professionnel. L'outil accélère l'écriture ; la vérification, elle, ne s'automatise pas.

Quels risques de sécurité sont propres au code écrit par une IA ?

Le premier est la fréquence des failles. Le rapport 2025 de Veracode sur la sécurité du code généré, mis à jour en octobre 2025, a testé plus de 100 grands modèles de langage en Java, JavaScript, Python et C# : le code produit introduisait des failles de sécurité dans 45 % des tests, et les modèles plus grands ou plus récents ne faisaient pas mieux. Un assistant écrit un code qui marche ; rien ne garantit qu'il écrive un code qui résiste.

Le deuxième est propre aux modèles de langage : les dépendances inventées. Une étude présentée au symposium USENIX Security 2025, « We Have a Package for You! », a analysé 576 000 extraits de code produits par 16 modèles : au moins 5,2 % des paquets recommandés par les modèles commerciaux n'existaient pas, et 21,7 % pour les modèles ouverts, soit 205 474 noms inventés distincts. Un attaquant peut publier un paquet malveillant sous l'un de ces noms et attendre qu'un assistant le recommande. L'OWASP range ce danger dans la désinformation (LLM09:2025), en citant les bibliothèques non sûres ou inexistantes suggérées par les modèles.

Le troisième est la fuite de secrets. Le rapport 2026 de GitGuardian sur la dispersion des secrets compte 28 649 024 nouveaux secrets détectés dans les commits publics de GitHub en 2025, en hausse de 34 % sur un an, dont 1 275 105 identifiants de services d'IA, en hausse de 81 %. Le même rapport observe que les commits co-signés par Claude Code exposent des secrets environ deux fois plus souvent que la moyenne des commits publics, et relève 24 008 secrets dans des fichiers de configuration MCP. La protection à l'envoi de GitHub bloque ces envois avant qu'ils n'atteignent le dépôt ; elle est active par défaut pour les comptes personnels, mais désactivée par défaut au niveau des dépôts.

Le quatrième tient aux plateformes elles-mêmes. Le registre américain des vulnérabilités a publié le 30 mai 2025 la faille CVE-2025-48757, notée 9,3 sur 10 : des règles de sécurité au niveau des lignes insuffisantes dans les applications générées par Lovable jusqu'au 15 avril 2025 permettaient à un attaquant non authentifié de lire ou d'écrire dans leurs tables. Lovable conteste la qualification, au motif que chaque client reste responsable de la protection des données de son application. Que l'on donne raison à l'un ou à l'autre, la conclusion pratique est la même : quelqu'un doit vérifier ces règles, application par application.

Données personnelles, mobile money, connexion et langue : que change le contexte local ?

Au Bénin, la loi n° 2017-20 portant code du numérique ne fait aucune différence entre une application écrite à la main et une application générée. Son article 426 oblige le responsable du traitement et son sous-traitant à protéger les données contre la perte, l'altération et l'accès non autorisé, par des mesures qui peuvent comprendre le chiffrement, des moyens de rétablir l'accès aux données après un incident et une procédure pour tester régulièrement l'efficacité des mesures. L'article 427 impose de notifier sans délai à l'Autorité et à la personne concernée toute atteinte à la sécurité de ses données, et au sous-traitant d'avertir sans délai le responsable. Une table laissée ouverte par un outil de génération entre dans ce cadre.

En Europe, le RGPD, présenté article par article par la CNIL, demande une protection des données dès la conception (article 25), un niveau de sécurité adapté au risque (article 32) et la notification d'une violation à l'autorité dans les 72 heures au plus tard quand c'est possible (article 33). Un développeur qui reprend à distance, depuis le Bénin, l'application d'une entreprise française ou belge agit comme sous-traitant : un contrat conforme à l'article 28 s'impose avant tout accès aux données réelles. Le guide RGPD du développeur de la CNIL rappelle aussi que chaque dépendance ajoutée augmente la surface d'attaque.

Le paiement demande une attention particulière en Afrique de l'Ouest. Les agrégateurs de mobile money se branchent par leur API et par des notifications envoyées au serveur de l'application : c'est du code à écrire, à signer et à tester, pas un interrupteur à activer dans l'outil de génération. Une commande ne se valide qu'après confirmation du statut auprès de l'agrégateur, et chaque notification se traite une seule fois, même reçue deux fois. Le choix de l'agrégateur lui-même se prépare avec le comparatif FedaPay, Kkiapay et CinetPay.

Restent la connexion et la langue. Les applications générées sont souvent lourdes : elles chargent tout le code d'un coup et s'arrêtent au premier réseau instable. La reprise allège les pages, met en cache ce qui peut l'être et prévoit un message clair quand la connexion tombe, plutôt qu'un écran blanc. Côté langue, les assistants comprennent très bien les consignes en français ; il faut en revanche vérifier ce qu'ils produisent : textes d'interface traduits mot à mot, dates au format américain, montants en francs CFA affichés avec des décimales. Ces détails font qu'un utilisateur de Cotonou ou de Dakar fait confiance à l'outil, ou non.

Pourquoi confier votre prototype ou votre reprise à Richard SALANON ?

Richard SALANON est consultant en digitalisation et développeur logiciel, basé à Cotonou, au Bénin. Il crée des sites, des applications web et mobiles, des automatisations et des intégrations d'intelligence artificielle, déploie Odoo et Dolibarr, et forme les équipes à ces outils, pour des entreprises d'Afrique francophone, d'Europe et du Canada.

Avec plus de 6 ans d'expérience dans le numérique, une formation à EPITECH (2022) et plus de 50 projets livrés, tous types confondus, il a travaillé pour des organisations au Bénin, en Côte d'Ivoire, au Togo, au Sénégal, au Burkina Faso, au Mali, au Niger, au Tchad, au Gabon, en RD Congo, en France, en Belgique, en Suisse et au Canada. Le vibe coding figure parmi ses compétences déclarées, à côté du développement d'applications web et mobiles : c'est cette double pratique qui permet de construire vite, puis de lire ce qui a été construit.

Il développe aussi ses propres produits, dont Wapy, un assistant WhatsApp à intelligence artificielle pour les entreprises d'Afrique francophone, et il est co-fondateur d'Audyxa. Il connaît donc les deux côtés : celui qui veut une démonstration pour la semaine prochaine, et celui qui devra maintenir l'application dans deux ans.

Sa façon de travailler tient en engagements vérifiables : un dépôt Git et des comptes à votre nom dès le premier jour, une décision écrite avant toute reprise, un rapport qui dit ce qui a été corrigé et ce qui ne l'a pas été, aucune donnée réelle dans un prototype, et une réponse sous 24 heures. Il a formé plus de 200 personnes au numérique ; si votre équipe veut ensuite pratiquer seule, la formation vibecoding prend le relais. Son parcours complet figure sur la page Richard SALANON.