Prototyper avec l'IA : ce que le vibe coding vaut vraiment

Prototyper avec l'IA vaut beaucoup — à condition de savoir ce que vous tenez à la fin. Le vibe coding, cette pratique où l'on décrit en langage naturel ce que le logiciel doit faire et où un modèle produit le code, compresse l'exploration de plusieurs semaines à quelques jours. Ce qu'il produit reste un prototype : parfait pour décider, inadapté pour servir des clients. Toute la valeur de la pratique tient dans cette distinction.

Article publié en mars 2026, refondu le 25 mai 2026, revu le 7 juillet 2026.

Le vibe coding, définition sans mythologie

Le vibe coding désigne une pratique de développement où l'intention exprimée en langage naturel précède le code : on décrit la fonctionnalité attendue, un système alimenté par modèle génératif produit l'implémentation, on la revoit et on l'ajuste. Le terme s'est répandu début 2025 — la formule est attribuée à un chercheur en intelligence artificielle de premier plan — et il a déclenché une conversation publique disproportionnée par rapport à sa portée réelle.

Pour les uns, la fin du développement logiciel. Pour les autres, une catégorie inédite de dette technique. La réalité observable se situe entre les deux : la phase de prototypage est transformée en profondeur, la discipline de production ne l'est pas, et confondre les deux coûte cher.

Ce que ça change quand on teste une idée

Un prototype n'a qu'un objectif : permettre de décider si une idée mérite l'effort de construction. Sous ce critère, le vibe coding change la donne sur la vitesse, l'accès et la pluralité. La vitesse : un prototype qui demandait plusieurs semaines à un développeur seul se produit en quelques jours, parfois quelques heures pour un concept simple — ce qui était trop coûteux à valider devient testable. L'accès : un chef de produit, un consultant, un analyste métier peut produire un prototype fonctionnel qui exprime concrètement son intention, sans passer par le filtre d'une équipe technique. La pluralité : produire plusieurs variantes d'un même concept en parallèle et retenir celle qui survit à la confrontation au réel devient abordable, ce qui change la qualité des décisions produit.

J'en parle d'expérience directe. FiscalDoc, l'application locale qui gère ma fiscalité, est née exactement comme ça : décrite, dialoguée, ajustée en trois soirées. Le récit est publié dans FiscalDoc, ou remplacer un SaaS par une IA locale, et l'outillage que j'utilise est décrit dans mon retour d'expérience sur Claude Code.

Ce que le prototype ne vous donne pas

Trois zones restent étrangères aux promesses du vibe coding, et elles se paient cher quand on les ignore.

La dette invisible d'abord. Un code produit par dialogue itératif fonctionne souvent, mais sa cohérence d'ensemble n'est garantie par personne. Chaque ajout complique silencieusement le tout, et le coût se révèle précisément au moment où le prototype devrait devenir produit — c'est-à-dire trop tard pour corriger sans réécriture substantielle.

La sécurité ensuite. Le code généré fonctionne sur le chemin nominal ; les cas d'erreur, les injections, les autorisations, les conditions limites — tout ce qui fait la sécurité applicative — ne sont pas traités systématiquement. Acceptable pour une maquette testée en circuit fermé. Dangereux devant des utilisateurs réels.

La conformité enfin. Les secteurs réglementés suisses — finance, santé, assurance — exigent une traçabilité des choix techniques que la génération dialoguée ne produit pas naturellement : processus peu déterministes, choix rarement documentés, revues allégées par construction. Rien de rédhibitoire pour un prototype ; tout le devient en production.

La règle d'arbitrage : valider avec, construire sans

La règle que j'applique tient en deux phrases. Le vibe coding est l'outil approprié pour valider qu'une idée mérite d'être construite ; il n'est pas l'outil pour la construire ensuite. Cette distinction n'est pas une concession à la prudence : c'est l'usage le plus efficace de la pratique elle-même.

Les équipes qui en tirent le plus prototypent vite, valident ce qui doit l'être, puis reconstruisent proprement ce qui a démontré sa valeur — architecture, tests, revue. Celles qui poussent le prototype en production accumulent une dette qui se paie dans les mois qui suivent, et qu'aucune itération supplémentaire de prompts ne rembourse. La reconstruction propre, elle, relève d'un développement sur mesure cadré : c'est un autre régime de travail, avec un autre niveau d'exigence.

Quatre situations où je ne prototype même pas

Même pour explorer, certains contextes sortent du cadre.

• Des données réelles. Un prototype qui manipule des données clients, financières ou médicales identifiables dépasse ce que le statut de prototype absorbe. Données fictives ou anonymisées, environnement isolé — sans exception.
• Une exposition publique. Un prototype en ligne sans contrôle d'accès est une mise en production sans la rigueur correspondante. C'est l'erreur opérationnelle la plus fréquente chez les équipes qui adoptent la pratique sans cadrage.
• Un lien avec vos systèmes en production. Connecté à votre gestion, à une base métier ou à une API critique, un bug de prototype a des conséquences réelles. Environnement séparé, toujours.
• L'absence de relecture. Personne ne montre un prototype à un client, un investisseur ou un utilisateur sans qu'une personne compétente ait pu dire si le résultat tient debout.

Et FiscalDoc, alors ?

On pourrait m'objecter que FiscalDoc, prototype dialogué en trois soirées, tourne encore chez moi tous les jours. C'est exact, et le périmètre explique tout : un utilisateur — moi —, mes propres données, une machine locale, aucune exposition réseau, aucune donnée de tiers. C'est précisément le périmètre dans lequel un prototype peut vivre longtemps. Le jour où un outil de ce type devrait servir quelqu'un d'autre que son auteur, il se reconstruit avec la discipline de production.

Appliquez le même test à vos prototypes : si leur périmètre ressemble à celui-là, ils peuvent vivre ; sinon, reconstruisez avant que la dette ne décide pour vous.

Ce que ça appelle dans votre organisation

Pour une PME suisse, l'enjeu est moins technique que de cadrage. Définissez explicitement ce qui peut être prototypé en vibe coding et ce qui relève d'un développement encadré — cette clarification se construit en quelques semaines et évite les arbitrages improvisés. Conservez les dialogues qui ont produit de bons résultats : c'est un capital de méthode qui se transmet, plutôt qu'un savoir tacite qui s'efface.

Et reliez la pratique à vos priorités réelles. Un prototype ne vaut que s'il teste une hypothèse qui compte, ce qui suppose d'avoir posé vos flux et vos chantiers d'automatisation au préalable. Pour l'ordre de ces chantiers, le cadre général est dans Que doit faire une PME suisse face à l'IA en 2026 ?.

Ce qu'il faut retenir

— Le vibe coding compresse l'exploration : ce qui prenait des semaines se teste en quelques jours, y compris sans profil technique. — Ce qu'il produit reste un prototype : dette invisible, sécurité et traçabilité excluent la mise en production telle quelle. — Valider avec le prototype, reconstruire proprement ce qui a fait ses preuves : la règle tient en une phrase.

FAQ

Un non-développeur peut-il vraiment prototyper seul ? Oui, pour explorer et exprimer une intention : le prototype qui en sort vaut mieux qu'un cahier des charges abstrait, parce qu'il se teste. Avant de le montrer hors de l'équipe ou de le brancher sur quoi que ce soit, une relecture par une personne compétente reste nécessaire.

Peut-on garder un prototype en production ? Seulement si son périmètre reste celui d'un prototype : utilisateur unique ou cercle fermé, données non sensibles, aucune exposition publique, aucun lien avec vos systèmes critiques. Dès qu'un de ces murs tombe, la reconstruction s'impose. FiscalDoc vit chez moi précisément parce qu'il respecte ces limites.

Combien coûte un prototype assisté par IA ? En interne, souvent quelques jours de travail là où il fallait des semaines — c'est le cœur du gain. En mandat, le montant dépend du périmètre : exigez un périmètre écrit et un prix ferme avant de lancer, et méfiez-vous d'un prototype vendu comme un produit fini.

Quelle différence entre vibe coding et développement assisté par IA ? Le vibe coding vise l'exploration : l'intention précède le code, la revue est allégée, le résultat est jetable par principe. Le développement assisté conserve la discipline de production — architecture, tests, revue systématique — en utilisant l'IA comme accélérateur d'exécution. Même famille d'outils, deux régimes de travail différents.

Et vos idées en attente ? Le Diagnostic d'Usage IA : soixante minutes pour poser vos flux réels, identifier ce qui mérite du sur-mesure, ce qui reste en SaaS, et ce qui n'a pas besoin d'IA du tout. Réserver un diagnostic

Jérôme Deshaie est CEO et fondateur de MCVA Consulting SA, agence augmentée basée en Valais. Quinze ans au service de grandes marques internationales, désormais en direct pour les PME suisses. Parcours.