Rapport Vibe Coding 2026  : l’état des applications créées par l’IA

Demandez aux personnes qui créent des applications avec l’IA ce qu’elles pensent de leur propre code  : 68% le qualifient de «  rapide mais imparfait  ». Ni cassé, ni brillant. Rapide mais imparfait est la catégorie de logiciel la plus coûteuse qui existe, car elle se déploie facilement et échoue plus tard.

Ce chiffre provient d’une étude évaluée par des pairs publiée en 2026, et c’est la plus honnête des statistiques sur le vibe coding de cette année. Si vous cherchiez un vibe coding report 2026 pdf, cette page en tient lieu  : chaque chiffre ci-dessous renvoie à sa source primaire, en accès libre et citable librement, sans aucun formulaire à remplir.

La réponse courte  : en août 2026, le vibe coding est un moyen de masse pour créer des logiciels et un moyen minoritaire pour les mettre en production. Des dizaines de millions de projets générés par l’IA existent, environ 45% des échantillons de code généré par l’IA échouent aux tests de sécurité, et 60.5% des créateurs interrogés sur une grande plateforme ne gagnent pas encore d’argent avec ce qu’ils ont créé. L’adoption devance largement la vérification.

Si votre prototype a déjà dépassé ses origines, c’est exactement pour cela que notre service de nettoyage de vibe code existe.

Les statistiques du vibe coding qui comptent le plus en 2026

L’adoption du codage par IA continue de gagner du terrain, aussi bien chez les développeurs professionnels que chez les créateurs non techniques, et rien dans les données de cette année ne suggère un ralentissement. La confiance, elle, n’a pas suivi. Les équipes mettent désormais en production du code auquel elles ne croient pas totalement, à des volumes qu’elles n’avaient jamais atteints auparavant.

Constat
Chiffre
Type
Source
Constat

Vibe coders qui qualifient leur propre production de «  rapide mais imparfaite  »

Chiffre

68%

Type

Évalué par des pairs, n=114 comptes

Source
Constat

Vibe coders qui font entièrement l’impasse sur l’assurance qualité

Chiffre

36%

Type

Évalué par des pairs, n=132 comptes

Source
Constat

Échantillons de code généré par l’IA qui échouent aux tests de sécurité

Chiffre

45%

Type

Benchmark, plus de 100 LLM

Source
Constat

Développeurs qui ne font pas entièrement confiance à l’exactitude du code généré par l’IA

Chiffre

96%

Type

Enquête, n=1,149

Source
Constat

Développeurs qui utilisent ou prévoient d’utiliser des outils de codage par IA

Chiffre

84%

Type

Enquête, n=49,000+

Source
Constat

Développeurs qui affirment que le vibe coding ne fait pas partie de leur flux de travail professionnel

Chiffre

77%

Type

Enquête, n=49,000+

Source
Constat

Augmentation mesurée des tâches terminées grâce aux outils d’IA

Chiffre

26.08%

Type

ECR, n=4,867

Source
Constat

Projets créés sur Lovable, avec environ 1M ajoutés chaque semaine

Chiffre

50 millions

Type

Télémétrie de l’éditeur

Source
Constat

Créateurs qui ne gagnent pas encore d’argent avec ce qu’ils ont créé

Chiffre

60.5%

Type

Enquête de l’éditeur, n=14,300+

Source
Constat

Failles de sécurité officiellement attribuées à des outils de codage par IA

Chiffre

6 en janvier 2026, 35 en mars

Type

Suivi public des CVE

Source
Constat

Part des modifications de code consacrée à ranger le code existant plutôt qu’à en empiler davantage

Chiffre

21% en 2022, en baisse à 3.8% en 2026

Type

Analyse de dépôts

Source

Cette dernière ligne est celle qui surprend le plus. Lorsque les développeurs cessent de réorganiser ce qui existe déjà et se contentent d’ajouter, une base de code devient plus difficile à faire évoluer chaque semaine, et le coût apparaît des mois plus tard sous la forme de  : «  pourquoi une petite fonctionnalité prend-elle désormais trois sprints  ?  »

Ce que les statistiques d'adoption du vibe coding 2026 montrent vraiment

Voici le constat qui devrait vous rendre méfiant face à tous les titres sur ce sujet. Deux enquêtes réputées menées en 2026 ont mesuré le même comportement et sont arrivées à des résultats presque exactement opposés. Adaptavist a interrogé 240 ingénieurs professionnels aux États-Unis et au Royaume-Uni et a constaté que 83.9% pratiquent actuellement le vibe coding sous une forme ou une autre. Stack Overflow a interrogé plus de 49,000 développeurs dans 177 pays et a constaté que 77% déclarent que cela ne fait pas partie de leur flux de travail professionnel.

Les deux ont probablement raison. Elles ont posé des questions différentes à des populations différentes  : l’une comptait toute personne ayant un jour obtenu un résultat fonctionnel par prompt, même chez elle un dimanche, l’autre comptait les personnes qui traitent cela comme une pratique professionnelle. Cet écart est l’élément le plus important de ce rapport. Tout chiffre de statistiques d’adoption du vibe coding 2026 cité sans sa définition doit être considéré comme incomplet jusqu’à ce que l’on sache quelle question a réellement été posée, ce qui explique pourquoi «  84% des développeurs pratiquent le vibe coding  » est une affirmation que personne ne peut actuellement étayer.

Le tableau plus large des outils d’IA est bien moins ambigu. La recherche DORA 2025 de Google situe l’adoption de l’IA à 90% parmi près de 5,000 professionnels de la technologie, avec une utilisation médiane d’environ deux heures par jour et plus de 80% qui rapportent des gains de productivité. Gartner prévoit que 90% des ingénieurs logiciels en entreprise utiliseront des assistants de code par IA d’ici 2028, contre moins de 14% début 2024. Les outils sont partout. Ce que les gens en font varie énormément, c’est pourquoi décider où cette approche a sa place compte plus que décider de l’autoriser ou non, et c’est pourquoi nous avons conçu un test d’adéquation pour les outils internes créés avec le vibe coding.

Combien d'applications sont réellement créées avec des outils de codage par IA  ?

Personne ne le sait, et quiconque avance un chiffre global avec assurance devine. Il n’existe aucun recensement des applications créées avec l’IA, et les chiffres des plateformes ne peuvent pas être additionnés, car les utilisateurs se recoupent, une même personne crée de nombreux projets, et le mot «  projet  » couvre tout, de l’expérience abandonnée au produit générant des revenus. Ce que nous pouvons faire, c’est aligner les meilleurs indicateurs disponibles et préciser ce que chacun mesure réellement.

Lovable annonce 50 millions de projets créés, avec environ un million ajoutés par semaine, contre 1.2 million en février 2025. Il s’agit de projets, pas d’applications  : ce chiffre inclut des sites web, des tableaux de bord, des tentatives dupliquées et des expériences abandonnées dans l’heure, si bien que «  50 millions d’applications vibe-codées  » est un titre que la source ne permet pas d’établir. v0 de Vercel annonce plus de 4 millions d’utilisateurs, ce qui compte des personnes et non des produits. Un preprint arXiv analysant 128,018 projets GitHub publics a détecté l’adoption d’agents de codage dans 22.20% à 28.66% d’entre eux, et les auteurs notent que leur méthode sous-estime probablement le total, car elle dépend de traces visibles. Apple a reçu 557,000 nouvelles soumissions à l’App Store en 2025, en hausse de 24%, mais personne n’a classé combien avaient été créées avec l’IA.

Le chiffre qui dégonfle l’engouement, c’est l’argent. Dans sa propre enquête auprès de plus de 14,300 utilisateurs, Lovable a constaté que 60.5% déclaraient ne pas encore gagner d’argent avec ce qu’ils avaient créé mais prévoyaient de le faire, et seulement 10.7% ont déclaré des revenus produit directs. Les projets créés et les entreprises en activité sont des quantités radicalement différentes. Combler cet écart relève presque toujours d’un travail de nettoyage, car le code qui vous a permis d’obtenir une démo fonctionnelle est rarement celui qui survit au contact de clients payants, de la facturation et des tickets de support. Nous démarrons chaque collaboration par une phase de découverte logicielle avant de toucher une seule ligne de code, ce qui permet régulièrement aux clients d’économiser des heures de retouches et, plus tard, des milliers de dollars, en repérant le problème architectural plutôt que le symptôme. Pour un aperçu des projets qui ont franchi ce cap, nous avons suivi les meilleures applications vibe-codées ayant atteint de vrais utilisateurs.

Qui sont les créateurs  ?

Le déplacement démographique est la véritable nouveauté de 2026, et il compte plus que l’histoire du volume. Sur les plateformes grand public qui transforment un prompt en application, la plupart des créateurs ne sont pas des développeurs du tout. Lovable indique qu’environ quatre utilisateurs sur cinq n’ont pas de profil technique, que 45.7% se définissent comme fondateurs ou cofondateurs, et seulement 5.8% comme ingénieurs. Bolt rapporte que 63% de ses utilisateurs issus de petites entreprises n’avaient jamais écrit une seule ligne de code.

Les fondateurs constituent le centre de gravité. Y Combinator a demandé aux fondateurs d’une promotion quelle part de leur base de code était générée par IA, bibliothèques importées exclues, et un quart a répondu plus de 95%. Ce ne sont pas des jouets. Ce sont des entreprises financées qui livrent à de vrais clients. Le chiffre est souvent étiré en «  un quart des startups sont codées à 95% par l’IA  », ce qui n’est pas exact  : les parts étaient auto-estimées, et les fondateurs YC sont des adopteurs précoces inhabituellement techniques, pas un échantillon représentatif des startups en général. Par ailleurs, Stripe Atlas a constaté que 42% des 23,000 entreprises constituées via sa plateforme en 2025 se décrivaient comme des startups d’IA, contre 15% en janvier 2023.

Gartner s’attend à ce que ce phénomène touche aussi les organisations établies, en prévoyant que 40% des membres des équipes logicielles pourraient venir de parcours techniques non traditionnels d’ici 2028, soit environ le double de la part observée au moment de la prévision. Le bassin de personnes capables de créer des logiciels s’élargit plus vite que celui des personnes capables de les vérifier, ce qui nous amène à la partie inconfortable de ce rapport.

Le vibe coding rend-il vraiment les équipes plus rapides  ?

C’est possible, et la combinaison qui fonctionne n’est pas le vibe coding seul. Prenons Pridefit, une application mobile de fitness et cliente de Redwerk. Nous avons commencé par auditer leur application et éliminer la dette technique héritée d’un précédent prestataire, puis livré de nouvelles fonctionnalités et ajouté les analyses dont ils se passaient jusque-là, ce qui a fait grimper les abonnements à l’application de 45% et leur a enfin donné une visibilité sur leur propre croissance. Aujourd’hui, leur équipe développe elle-même de nouvelles fonctionnalités en vibe coding, et nous relisons et nettoyons le résultat avant sa mise en production. Cette association, génération rapide plus ingénierie professionnelle, produit de réelles économies de temps et de coûts, d’une façon que ni l’une ni l’autre ne parvient à obtenir seule.

Si l’on prend du recul sur la recherche plus large, le tableau devient cependant plus confus, et c’est justement la partie utile. La preuve positive la plus solide vient de Microsoft Research, dont les expériences de terrain randomisées menées auprès de 4,867 développeurs ont mesuré une augmentation de 26.08% des tâches terminées, les développeurs les moins expérimentés en bénéficiant le plus. Il convient de préciser ce que représente ce chiffre  : un gain d’achèvement des tâches au sein d’essais contrôlés de codage assisté par IA, et non un multiplicateur de vitesse universel de 26% ni une mesure spécifique au vibe coding. L’étude contrôlée de McKinsey a constaté que la documentation était réalisée en environ moitié moins de temps et certaines tâches de refactorisation en environ un tiers du temps, les gains diminuant avec la complexité.

La donnée la plus inquiétante est à quel point cela devient difficile à mesurer, tout simplement. METR a mené un essai randomisé dans lequel 16 développeurs open source expérimentés ont réalisé 246 tâches réelles sur leurs propres dépôts matures, et ils ont mis 19% de temps supplémentaire avec des outils d’IA tout en étant convaincus, du début à la fin, d’avoir été plus rapides. Lorsque METR a reproduit l’étude en 2026, les développeurs ont de plus en plus refusé les tâches assignées à la condition sans IA, ce qui a rompu la randomisation et a conduit l’équipe à qualifier sa propre estimation la plus récente de simple borne inférieure. Stack Overflow apporte la nuance  : 66% des développeurs sont frustrés par des solutions «  presque justes, mais pas tout à fait  », et 45% déclarent que déboguer du code généré par IA peut prendre plus de temps que de l’écrire eux-mêmes.

Le schéma qui se dégage de tout cela est cohérent. Les gains sont importants et fiables sur un travail délimité et vérifiable, et ils deviennent imprévisibles dès qu’il faut comprendre une base de code mature, exactement le moment où une passation relue commence à se rentabiliser.

Les chiffres de la qualité et de la sécurité

La rapidité, c’est ce que tout le monde mesure. Ce que décrivent les chiffres suivants, c’est la facture qui arrive ensuite, et elle se règle en trois endroits  : des failles de sécurité que personne n’a cherchées, une duplication qui rend chaque modification future plus risquée, et des secrets qui dorment dans un dépôt. Chaque ligne ci-dessous représente une équipe de recherche différente arrivant à une version de la même conclusion par une voie différente. Le détail complet du mécanisme se trouve dans nos analyses des risques de sécurité du vibe coding et de la dette technique dans le code généré par IA.

Ce qui a été mesuré
Résultat
Source
Ce qui a été mesuré

Développeurs touchés par au moins un effet de dette technique lié à l’IA

Résultat

88%, dont 53% ayant trouvé du code qui semblait correct mais s’est révélé peu fiable

Source
Ce qui a été mesuré

Taux d’échec aux tests de sécurité sur plus de 100 modèles

Résultat

45% des échantillons ont échoué ou introduit une faiblesse du Top 10 OWASP

Source
Ce qui a été mesuré

15 applications créées par 5 outils d’IA leaders à partir de prompts identiques

Résultat

69 vulnérabilités au total, dont environ 6 classées critiques  ; toutes les applications manquaient de protection CSRF et d’en-têtes de sécurité

Source
Ce qui a été mesuré

Densité de problèmes sur 470 pull requests open source

Résultat

10.83 problèmes par PR rédigée par IA contre 6.45 pour celles uniquement humaines, avec des problèmes de sécurité jusqu’à 2.74 fois plus fréquents

Source
Ce qui a été mesuré

Commits ayant divulgué un mot de passe ou une clé API

Résultat

3.2% des commits assistés par IA contre 1.5% de référence, sur un total de 28.65 millions de secrets trouvés sur GitHub public en 2025

Source
Ce qui a été mesuré

Code dupliqué copié-collé par million de lignes modifiées

Résultat

40.3 blocs en 2023, 73.0 en 2026, le niveau le plus élevé jamais enregistré

Source

Deux réserves permettent de garder ces chiffres honnêtes. Les 45% de Veracode et les 69 vulnérabilités de Tenzai proviennent de bancs d’essai contrôlés, et non d’audits d’applications réellement en production, et CodeRabbit a identifié les pull requests rédigées par IA via des signaux de co-paternité plutôt que par confirmation directe. Ils décrivent ce que ces outils produisent de façon fiable, pas un recensement de ce qui tourne actuellement en production.

Le résultat de Tenzai mérite un second regard, car il est plus intéressant que «  l’IA écrit du code non sécurisé  ». Les outils excellaient sur les problèmes de manuel  : les chercheurs n’ont trouvé aucune injection SQL ni XSS exploitable sur l’ensemble des 15 applications. Ce qu’ils ont trouvé en revanche, ce sont des failles dans la logique d’autorisation, des trous dans la logique métier et des falsifications de requêtes côté serveur, des vulnérabilités où la frontière entre sûr et dangereux dépend entièrement d’un contexte que le modèle n’a jamais reçu. L’IA a largement résolu les vulnérabilités que l’on peut mémoriser. Elle n’a pas touché à celles qui exigent de savoir ce que votre entreprise considère comme une permission.

Le Vibe Security Radar, géré par le Systems Software and Security Lab de Georgia Tech, suit désormais publiquement les conséquences. Les vulnérabilités officiellement cataloguées et attribuables à des outils de codage par IA sont passées de 6 en janvier 2026 à 35 en mars, et le fondateur du projet estime que le chiffre réel est cinq à dix fois plus élevé, car la majeure partie du code écrit par IA ne laisse aucune signature détectable.

Point de vue d'un praticien  : ce que nous voyons en ouvrant une base de code vibe-codée

Cette section correspond à l’observation directe de Redwerk issue du travail avec ses clients, pas à une recherche. Elle figure ici parce que des données agrégées ne peuvent pas dire ce que ces bases de code donnent à ressentir de l’intérieur.

Le schéma qui surprend le plus les clients, c’est que le code fonctionne généralement. La démo tourne, le chemin nominal est propre, et l’interface est souvent plus soignée que ce qu’aurait produit une équipe interne pressée. Ce qui manque n’est presque jamais la fonctionnalité. C’est la couche du dessous  : une autorisation qui ne suppose qu’un seul type d’utilisateur, un accès aux données sans frontière de tenant, des secrets qui dorment dans le dépôt, aucun chemin de migration, et aucun test pour signaler qu’une modification a cassé quelque chose trois écrans plus loin.

Le second schéma est une duplication qui se fige avec le temps. Comme le moyen le plus rapide d’obtenir un nouvel écran est de le demander par prompt, une logique quasi identique s’accumule en cinq endroits, et la sixième modification d’une règle métier en oublie silencieusement deux. Le constat de GitClear selon lequel le travail de rangement est passé de 21% des modifications de code en 2022 à moins de 4% en 2026 est la version à l’échelle du secteur de ce que nous observons fichier par fichier. C’est aussi pourquoi le chiffre évalué par des pairs de «  rapide mais imparfait  » sonne si juste  : les personnes qui ont créé ces applications sentent généralement que quelque chose ne va pas, elles ne parviennent simplement pas à voir où. C’est précisément à cela que sert un audit structuré de vibe code ou un audit de développement logiciel plus large.

Vers où cela évolue en 2027

La prévision qui mérite d’être prise au sérieux ne porte pas sur la capacité. Elle porte sur l’écart grandissant entre la quantité de code déployée et la quantité que quelqu’un comprend réellement. Les chercheurs en sécurité s’attendent de plus en plus à ce que le premier incident de production très médiatisé soit directement attribué à du code généré par IA non relu, et le raisonnement tient de l’arithmétique la plus simple  : chaque trimestre, davantage de code non testé atteint la production, dans des systèmes qui traitent de l’argent et des données personnelles, maintenus par des personnes qui ne l’ont pas écrit et ne peuvent pas le lire entièrement.

La littérature académique converge vers la même frontière par un autre chemin. Un rapport d’expérience sur le vibe coding en production a constaté que le code généré sous-spécifiait systématiquement la multi-location, le contrôle d’accès et le traitement asynchrone, et a identifié des zones architecturales que les auteurs appellent des «  zones de non-délégation  ». Leur observation centrale est que l’effort ne disparaît pas, il se déplace  : il s’éloigne de l’écriture de code répétitif pour se rapprocher de la spécification de contraintes et de la vérification de leur respect.

C’est là la vraie histoire de 2027. Générer un logiciel devient trivial, et le vérifier devient le vrai travail, ce qui fait de la maintenance à long terme des applications vibe-codées la discipline pour laquelle la plupart des équipes ne se sont pas encore dotées de personnel.

Pourquoi collaborer avec Redwerk sur une application vibe-codée

Si votre prototype porte désormais de vrais utilisateurs, la question n’est pas de savoir si l’IA l’a écrit. La question est de savoir si les fondations en dessous peuvent supporter ce que vous êtes sur le point de construire par-dessus. Nous faisons ce travail au quotidien, et nous préférons vous dire que l’application va bien plutôt que vous vendre une reconstruction dont vous n’avez pas besoin.

Nous commençons par une phase de découverte pour comprendre vos besoins et objectifs métier, car la réponse n’est souvent pas du tout un problème de code. Parfois, l’architecture doit être repensée, parfois le modèle de sécurité n’a jamais existé, et parfois le code est correct et c’est le modèle de données qui cédera à 10,000 utilisateurs. Vous obtenez une estimation avant que nous touchions à quoi que ce soit.

Pour voir comment cela se déroule sur un engagement complet, l’étude de cas Pridefit couvre tout le parcours  : la dette technique héritée d’un précédent prestataire a d’abord été résorbée, puis sont arrivées de nouvelles fonctionnalités et les analyses dont l’équipe se passait jusque-là, une hausse de 45% des abonnements à l’application, et une équipe produit qui développe désormais en toute confiance de nouvelles fonctionnalités en vibe coding, parce que quelqu’un relit le résultat avant sa mise en production.

Sous tout cela se trouvent les principes d’ingénierie fondamentaux et les pratiques de sécurité affinés au fil de deux décennies de développement de logiciels sur mesure pour des entreprises en Amérique du Nord et en Europe, dont des sociétés du Fortune 500 comme Siemens, J.B. Hunt et Universal Music Group. Que vous ayez besoin d’un nettoyage ciblé de vibe code ou d’un engagement complet de développement logiciel sur mesure avec IA construit correctement dès le départ, vous saurez lequel des deux vous convient avant d’engager un budget. Contactez-nous et nous vous dirons honnêtement de quel côté de cette ligne se situe votre application.

FAQ

Quel est l'état du vibe coding en 2026  ?

Le vibe coding est un moyen courant de créer des logiciels et un moyen minoritaire de mettre des systèmes en production. Des dizaines de millions de projets générés par l’IA existent sur des plateformes individuelles, 68% des praticiens décrivent leur propre production comme «  rapide mais imparfaite  », et 60.5% des créateurs interrogés sur une grande plateforme ne gagnent pas encore d’argent avec ce qu’ils ont créé. La création a été mise à l’échelle  ; la vérification ne l’a pas été.

Combien d'applications sont créées avec des outils de codage par IA  ?

Aucun décompte mondial crédible n’existe. Lovable seul annonce 50 millions de projets créés, et une analyse de 128,018 projets GitHub publics a détecté l’adoption d’agents de codage dans 22.20% à 28.66% d’entre eux. Les projets ne sont pas la même chose que des applications déployées et maintenues, et les chiffres des plateformes ne peuvent pas être additionnés, car les utilisateurs et les projets se recoupent.

Quel pourcentage du code généré par l'IA présente des problèmes de sécurité  ?

Le benchmark de Veracode portant sur plus de 100 grands modèles de langage a révélé que 45% des échantillons générés échouaient aux tests de sécurité ou introduisaient une faiblesse du Top 10 OWASP. Une étude distincte portant sur 15 applications créées par cinq outils d’IA leaders a recensé 69 vulnérabilités, dont environ 6 classées critiques, chaque application manquant de protection CSRF et d’en-têtes de sécurité. L’analyse de CodeRabbit sur 470 pull requests open source chiffre cet écart  : les PR rédigées par IA comptaient en moyenne 10.83 problèmes chacune contre 6.45 pour les PR uniquement humaines, avec des problèmes de sécurité jusqu’à 2.74 fois plus fréquents.

Le vibe coding est-il sûr pour la production  ?

Cela dépend entièrement de ce que fait l’application. Les outils internes, les tableaux de bord et les prototypes ont un rayon d’impact limité. Tout ce qui traite des paiements, des données personnelles ou un accès multi-tenant nécessite d’abord une revue indépendante, car la recherche montre systématiquement que l’IA gère bien les vulnérabilités mémorisables et mal la logique d’autorisation dépendante du contexte.

Une application vibe-codée peut-elle être sauvée, ou a-t-elle besoin d'une réécriture  ?

Généralement, elle peut être sauvée. D’après notre expérience, les fonctionnalités sont correctes et les fondations sont fragiles, ce qui implique un travail ciblé sur l’architecture, l’autorisation et la couverture de tests plutôt qu’un nouveau départ. Un audit vous indique lequel des deux cas s’applique, et cela coûte nettement moins cher que de deviner.

Découvrez comment Redwerk a repris une application de fitness en difficulté appartenant à un autre fournisseur, a résorbé la dette technique héritée et a aidé Pridefit à augmenter le nombre d'abonnements de 45 %

Veuillez saisir votre adresse courriel professionnelle n'est pas un courriel professionnel