Le vibe coding ringardise t-il le no-code ?

Introduction

Question : Pour les “citizen developers” — c'est-à-dire des utilisateurs capables de créer des applications sans être des développeurs professionnels — l'approche du vibe coding est-elle susceptible de remplacer les approches et les outils no-code ? La facilité d’accès et d’usage aux outils d’IA générative à des populations non informaticiennes, on a envie de dire “for sure !”. En tout cas, dans les milieux autorisés de l’informatique, c’est une assertion que l’on entend ;-)

Caricature - le vibe coding ringardise t-il le no-code ? (Illustration réalisée par Perplexity)

Rappels et définitions

Le no-code : approche de développement et d’outils qui utilisent une approche visuelle interactive sans écrire de code, permettant au plus grand nombre de créer et mettre en ligne des applications simples, des sites web, des automatisations ou des bases de données avec un investissement limité. L'utilisateur construit son application en assemblant des éléments visuels (glisser-déposer, formulaires, workflows, règles métier) plutôt qu'en programmant. Un avantage puissant reste le déploiement et l’exploitation géré automatiquement de manière assez transparente par les plateformes. De nombreuses plateformes parfois spécialisées, dont certaines sont open sources (OS) sont bien installées dans le paysage de l’IT :

• Web : Bubble, Softr. CMS : Webflow
• App Mobile : Glide, Thunkable, Adalo, Flutterflow (proche du low-code)
• Application métier : Appsheet (de Google), AppSmith (OS), BudiBase (OS), Power Apps (de MS, low-code)
• Base de données : Air Table, NocodeDB (OS), Baserow (OS)
• Workflow : Zapier, n8n (OS), Make
• Exemple d’usage : Utilisation du no-code par les employés de la DSI Support d’Octo; objectif : “autonomie”

Le vibe coding : est une façon de développer un logiciel où l'on décrit ce que l'on veut en langage naturel à une IA générative, qui génère ensuite la majeure partie du code. L’utilisateur se concentre davantage sur l'intention, les essais et les ajustements que sur l'écriture manuelle du code. La facilité d’accessibilité et d’usage des outils permet à des profils non informaticiens d’accéder à un champ des possibles assez incroyable. Exemples d’outils pré-packagés : Lovable, Bolt.new, Firebase Studio, Replit AI, v0

Prompte d’entrée de Lovable (src : Lovable)

Hypothèse : Dans cet article, nous examinons les conditions dans lesquelles un “citizen developer” peut bâtir une application répondant à un besoin métier relativement simple, par exemple un prototype ou un démonstrateur (côté client ou fournisseur), un outil d'amélioration de l'efficacité opérationnelle (automatisation d'un workflow ou d'une tâche répétitive), ou encore une application répondant à un besoin ponctuel, comme une application mobile pour un événement (salon, conférence, etc.). Nous faisons l'hypothèse que l’équipe, disposant de compétences techniques limitées, construit progressivement son application au travers de quelques itérations, en affinant ses fonctionnalités au fil des retours. Nous nous plaçons dans le scénario où, une fois le démonstrateur validé, une équipe de développement reprend le concept et, lorsque cela est possible, le code produit afin de poursuivre l'évolution de l'application et d'en assurer la maintenance.

Le vibe coding offre plus de possibilités créatives

L'approche par vibe coding offre un potentiel créatif supérieur à celui du no-code. Sa principale force réside dans sa capacité à s'affranchir des composants prédéfinis des plateformes no-code. Plutôt que d'assembler des éléments existants, l'utilisateur peut demander à l'IA de générer des interfaces, des comportements et des logiques métier spécifiquement adaptés à son besoin. Cette liberté favorise l'exploration d'idées originales.

Qui dit plus de libertés dit plus de risque de sortie de route

Le no-code facilite le travail d'un “citizen developer” en lui permettant de concevoir des logiciels rapidement. En contrepartie, afin de garantir la maintenabilité, la sécurité et la stabilité des applications, la plateforme encadre les possibilités techniques et limite certaines personnalisations. Elle conserve ainsi la maîtrise de l'architecture, de l'exécution et des mécanismes techniques sous-jacents de l'application.

Maintenant, ce même “citizen developer” avec le vibe coding, sur le papier, voit sa vie encore plus facilité, pour un espace de liberté et de possibilités bien plus grandes ! Alors il est où le loup ? Est ce trop beau ?

Attendez une minute : qui garantit la maintenabilité, l’architecture, la sécurité ou encore la stabilité du code produit ? Comme souvent, rien n’est magique! Cette facilité et ces nouveaux espaces que l’on gagne avec le vibe coding peut virer au chaos si on ne pose pas les garde-fous.

Prenons un exemple d’un workflow avec de l’intégration dans un SI ou avec des partenaires et comparons les 2 approches. Dans le monde du no-code des plateformes comme Zapier ou n8n sont spécialisées dans la construction de ce type de workflow.

Ecarts d'implémentation d’un workflow intégré dans un SI par l’approche No-code et l’approche vibe-coding

Dans le cas des plateformes no-code l’intégration dans le SI se fait via des connecteurs et des workflows standardisés, plus faciles à documenter et à auditer; le cadre d’usage est connu par les architectes et la sécurité; là ou en vibe coding les intégrations sont hétérogènes, plus difficiles à harmoniser et à documenter sans gouvernance forte. On conclut facilement que dans un cas la gouvernance est facilitée : grâce au catalogue de connecteurs approuvés, des règles de sécurité et de conformité qui sont centralisées la ou pour le vibe coding chaque application peut être différente (tout comme pour un développement classique sans cadre à priori), avec ses propres règles si rien n’est défini en standard en amont et si rien n’est revu techniquement en aval.

L’approche vibe coding non encadrée tourne à une production logicielle chaotique

Plus généralement, les retours d’expérience actuels montrent que l’approche vibe coding non encadrée tourne assez vite à une production logicielle chaotique, non maintenable, instable, ou encore non sécurisée. Les dérives les plus communes du vibe coding :

• Du code généré avec des failles de sécurité : comme SQL injection, injection de scripts (XSS), exposition de clés API, mauvaise validation des entrées et erreurs de configuration
• Un risque de confiance excessive : le code semble marcher, mais reste fragile ou incomplet du point de vue sécurité et architecture. Les profils non techniques acceptent trop vite le code généré sans compréhension minimale
• La dette explose : Une utilisation de l’IA sans cadre, crée vite du code hétérogène, difficile à maintenir et potentiellement fragile

Un “citizen developer” ne peut seul garantir la qualité, la maintenabilité et la pérennité du code produit. Il en va de même pour son déploiement et l’exploitation. Pour ces aspects, l'accompagnement d'un technicien reste indispensable. Dans les grandes entreprises, ce rôle est assuré par la DSI : Software development : les DSI face au chaos du code généré par l’IA.

Dans notre cas d’usage, l'un des principaux atouts du vibe coding est qu'il autorise de conserver du code produit et sa maîtrise - sous certaines conditions. Celui-ci peut ensuite être intégré au référentiel de code de l'entreprise, puis repris, enrichi et maintenu par une équipe pluridisciplinaire incluant des développeurs. À l'inverse, si le code généré est chaotique, peu lisible ou difficile à maintenir, cette continuité devient très pénible voire impossible. Le résultat se limite alors à l'intention initiale exprimée dans les prompts et les éléments visibles comme les écrans pouvant servir de spécification mais sans véritable actif logiciel réutilisable.

Cette approche n'est pas nouvelle. Elle a déjà été mise en œuvre dans l’approche du no-code où le démonstrateur peut être considéré comme une spécification exécutable. Pour passer à l'échelle ou intégrer la solution au SI, le démonstrateur no-code n'a généralement pas vocation à être conservé. Il est considéré comme jetable, sa valeur résidant principalement dans la validation du besoin et la formalisation des exigences.

Avec l’approche en vibe coding, c’est peut être regrettable, car le deuxième grand potentiel du vibe coding réside précisément dans sa capacité à produire un code qui puisse être repris par des équipes de développement classique**, puis maintenu et enrichi avec ou sans le recours ultérieur au vibe coding.** Ce code peut ainsi devenir un véritable actif logiciel, susceptible de s'intégrer durablement au SI de l'entreprise.

L’approche vibe coding non encadrée tourne à une production logicielle sous jacente chaotique, non maintenable, instable, ou encore non sécurisée (Illustration réalisée avec Perplexity)

Qui dit plus de libertés dit alors plus de responsabilités

Pour obtenir un code acceptable pour une DSI et espérer et ensuite le valider voire le maintenir, il convient de mettre en place une gouvernance et un cadrage en amont afin d’éviter les dérives. Ainsi pour envisager le vibe coding à l’échelle, il faut positionner des gardes fous :

• Cadrer le périmètre : N’autoriser le vibe coding que sur des cas bien définis : un composant, un workflow, une intégration, un écran ou une fonction précise. Éviter absolument de demander à l’IA de “faire l’application” d’un bloc, car on perd vite la maîtrise du comportement et des dépendances. Le bon format est : objectif unique, entrée, sortie attendue, contraintes, cas d’erreur, critères d’acceptation. Comme évoqué dans notre hypothèse de départ l’application se construit ensuite sur quelques itérations.
• Standardiser les prompts : utiliser un modèle de prompt commun. Sans cela, chaque utilisateur parlera différemment à l’IA, et on obtiendra des résultats incohérents entre eux, difficiles à maintenir. Un prompt devrait toujours contenir : le contexte, le besoin, les règles, les limites techniques, le comportement attendu, les contraintes de sécurité.
• Tester par scénarios : Chaque composant ou workflow généré doit être testé avec des cas normaux, des cas limites et des cas d’échec.
• Documenter systématiquement même succinctement : Chaque élément généré doit avoir une courte fiche de documentation ; ce qu’il fait, où il est utilisé, quelles sont ses dépendances, qui l’a validé, quelles limites connues il a.

Ensuite, si l’on veut aller au delà d’un simple démonstrateur jetable et envisager de pérenniser l’application et le code associé, il est nécessaire de contrôler ce qui a été généré en sortie de l’IA et ainsi :

• I****mposer une revue humaine : Aucune génération IA ne doit aller directement en production sans relecture. A minima une personne (un TL, un développeur) qui sait évaluer le code et détecter les problèmes de logique, de sécurité ou de maintenance. Cette revue ne doit pas seulement vérifier que “ça marche”, mais aussi que le code est compréhensible, ré-appropriable/maintenable et cohérent avec d’autres développements et le SI.
• Protéger la sécurité : points sensibles à identifier comme les secrets et clés API, l’authentification et les autorisations, les entrées utilisateur, appels réseau externes, le stockage de données sensibles…L’IA peut produire quelque chose qui fonctionne, mais pas forcément de sûr.

Certes, cette démarche dépasse le cadre du vibe coding au sens strict. Toutefois, plus ces bonnes pratiques sont introduites tôt dans le cycle de développement, plus la reprise et la maintenance de l'application seront facilitées ensuite. Cette exigence peut constituer un frein pour les “citizen developers”, qui n’ont pas toujours des compétences pour pérenniser leurs développements. À ce stade, le support par des profils techniques devient clé. Plus le niveau de maturité technique de l'équipe est faible, plus les garde-fous et les bonnes pratiques doivent être explicites. Le but n’est pas de freiner l’usage de l’IA, mais d’éviter qu’elle devienne une source de bricolage.

Peut-on faire du vibe coding sur une plateforme no-code et tirer le meilleur des 2 mondes

Un peu mais seulement en surface. Prenons l'exemple d'une plateforme no-code comme Bubble. La solution intègre une IA qui assiste l'utilisateur dès le démarrage : à partir d'une description en langage naturel, elle aide à préciser le besoin et à construire un premier plan d'exécution au travers d'une interface de prompting simple. Bubble génère ensuite une première version de l'application au sein de la plateforme. L'utilisateur poursuit alors son développement dans l'éditeur visuel standard pour adapter l’application.

L'IA permet ainsi de réduire le temps de démarrage en fournissant une base immédiatement exploitable. L'IA embarquée continue d'accompagner le développement en facilitant la création ou la modification de certains composants, tant que ceux-ci restent dans le périmètre de la plateforme. Au-delà d'un certain niveau de complexité, l'utilisateur doit reprendre la main dans l'éditeur visuel standard. L’IA embarquée fournit une couche d'abstraction supplémentaire qui facilite, assiste et accélère le développement, sans pour autant permettre de produire l'intégralité de l'application.

L’interface d’accueil en prompt de Bubble (src. Bubble)

Ensuite, il est possible de générer des composants à l’aide de l’IA, mais celle-ci ne remplace pas complètement le cadre technique. C’est plutôt du no-code assisté par IA. On sort du catalogue standard pour demander à l’IA de produire un composant ciblé, mais toujours dans un cadre contrôlé et réutilisable. C’est une extension du no-code, mais pas du développement libre.

Ces deux approches ne permettent pas de produire une application complète ni de développer un composant qui sortirait du périmètre fonctionnel et technique défini par la plateforme no-code. Un côté Canada Dry en quelque sorte : « Canada Dry est doré comme l'alcool, son nom sonne comme un nom d'alcool… mais ce n'est pas de l'alcool ». Les plus vieux d’entre nous reconnaîtront le slogan publicitaire de la marque.

Le vibe coding sur une plateforme no-code, c’est comme le Canada Dry. Vu de l'interface utilisateur, ça y ressemble au départ, mais il s’agit plutôt d’une assistant IA, limité et encadré par la plateforme no-code (src. Wikipedia)

Enfin, les applications créées en no-code ne sont ni réversibles, ni portables. Le code source sous-jacent n'est pas accessible et ne peut pas être récupéré pour être repris, modifié ou migré vers un autre environnement. Cette limitation n'est pas un défaut des plateformes no-code, mais un choix de conception : faciliter le développement d’applications par des “citizen developers” dans un cadre technique encadré par la plateforme no-code.

Les plateformes no-code conservent la maîtrise du code généré, de l'architecture d'exécution et des mécanismes techniques sous-jacents. Ce sont des éléments de stabilité et de sécurité (Illustration réalisée avec Perplexity)

Modèle simple de maturité

Au niveau 2, les composants sont générés par IA, mais ils restent des briques réutilisables et validées dans le système no-code. C’est l’étape la plus naturelle pour une équipe no-code, elle profite d’une première interaction en mode vibe coding puis garde l’interface visuelle tout en ajoutant des composants spécifiques quand la plateforme ne suffit plus. On peut le voir comme du “no-code augmenté”, pas encore comme du vrai développement assisté. Cela donne aussi plus d’autonomie aux “citizen developers” qui avant auraient peut être dû solliciter un technicien pour réaliser un tel composant/plugin.

Au niveau 3, on entre dans le vibe coding au sens propre : l’IA ne génère plus seulement un composant isolé, elle produit du code qu’il faut organiser, relire et tester. Le changement clé pour une équipe no-code est qu’il faut commencer à parler de structure de son projet, de versioning, de tests et de sécurité. C’est là que le niveau de maturité devient plus important. Si l’équipe ne sait pas encore gérer du code, elle doit rester au niveau 1 ou 2 avec des composants IA très cadrés. Pour le niveau 3, l’équipe s’appuyera sur du support et de l’encadrement de la part de la DSI (cf chapitre “garde fous”). Sans technicien embarqué dans l’équipe projet la fabrication même d’un simple démonstrateur tournera vite (au delà de quelques itérations) à un code ingérable qu’il sera pénible à refactorer ensuite, on ne pourra garder que l’intention (au travers des écrans par exemple), ce qui est dommage.

Conclusion

Le vibe coding offre aux non-spécialistes de l'informatique la possibilité d'exprimer directement leurs besoins et d'obtenir rapidement un résultat concret et démontrable. Il devient possible d'explorer rapidement des idées originales, de réaliser des prototypes riches et d'itérer sans être limité par les modèles des plateformes no-code. Cette approche favorise la création d'interfaces plus innovantes, de workflows sur mesure et d'expérimentations plus ambitieuses.

À terme, il est envisageable de rendre les “citizen developers” de plus en plus autonomes. Pour autant, le vibe coding ne dispense pas d'un accompagnement technique. L'objectif n'est pas de freiner l'adoption de l'IA, mais de s'assurer qu'elle soit utilisée dans un cadre maîtrisé, afin d'éviter qu'elle ne devienne une source de bricolage.

Cette approche s'inscrit d'ailleurs dans la continuité de ce que nous avons déjà mis en place au travers certaines plateformes low-code par exemple. De la même manière, lorsque le code généré a vocation à être repris, maintenu ou enrichi par une équipe de développement, le support d'un développeur en amont demeure indispensable. Son rôle est d'accompagner les équipes non techniques tout en garantissant la qualité, la sécurité, la maintenabilité et la conformité du code produit.

Caricature des 2 approches entre le no-code et le vibe coding non encadré (Illustration réalisée par Perplexity)

De plus, cela suppose aussi de construire l'application par petites itérations. En effet, les modèles d'IA générative ne sont pas encore capables de concevoir de manière fiable une application complète en une seule étape. Chaque itération doit s'appuyer sur un contexte d'exécution suffisant : un objectif unique, les entrées et sorties attendues, les contraintes, les cas d'erreur à gérer ainsi que les critères d'acceptation. Cette façon de travailler incite également les équipes métier à mieux formaliser leur besoin avant de démarrer le développement. La qualité des résultats dépend en grande partie de la précision avec laquelle le problème est défini, ce qui constitue finalement une bonne pratique pour tout logiciel, qu'il fasse ou non appel à l'IA générative.

Le no-code, lui, est plus rapide pour assembler des fonctionnalités standard, mais il impose davantage la forme et les limites de l’outil. Le no-code augmenté par l’IA lui accélère les premières itérations de développement puis la génération de composants ciblés, tout en restant dans le cadre d’une plateforme contrôlée. Le no-code reste souvent meilleur pour transformer une idée en produit stable, vite, sans trop de complexité technique. Enfin, la plateforme prend en charge les aspects techniques liés au déploiement, aux mises à jour et à l'exploitation de l'application, de manière transparente pour les “citizen developers” comme pour les utilisateurs finaux.

Si le MVP / test est concluant et que l’on souhaite poursuivre et enrichir on peut envisager que l’application produite à une première spécification avant d’aller plus loin dans un développement à façon par exemple. C’est toujours une des bonnes recettes de l’utilisation du no-code.

Pour aller plus loin

• Michel Lutz : Un profil non technique. Une IA agentique. Une application en production
• Software development : les DSI face au chaos du code généré par l’IA.
• Découvrez notre Refcard Low Code / No code; Et si vous osiez le No-Code/Low-Code ?
• Le Low-Code pris en étau entre le No-Code et le développement assisté par l’IA
• Monter une filière No-Code - Retours d’expérience dans la data avec Data Fusion - Part I/III
• Culture Innov’ : Osez le code jetable ! - OCTO Talks !
• Les dix commandements d'une plateforme no-code mature
• Souveraineté : NoCode open source : notre top 6 des meilleurs outils 2026
• Souveraineté : NoCode et souveraineté, what’s up ?