💻 computer science

From Prompting to Verification: How Experience Shapes Vibe Coding Practices

Cette étude menée auprès de 162 utilisateurs répartis dans des groupes de non-développeurs, de novices et de professionnels révèle que, si les niveaux d'expérience façonnent de manière similaire les perceptions de la qualité du code généré par l'IA, ils divergent considérablement en matière de motivations et de pratiques de vérification, créant ainsi un « fossé perception-action » où l'accès à la création logicielle est démocratisé sans distribution correspondante de l'expertise nécessaire pour l'évaluer.

Auteurs originaux : Ahmed Fawzy, Amjed Tahir, Kelly Blincoe

Publié 2026-05-26

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Ahmed Fawzy, Amjed Tahir, Kelly Blincoe

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

L'idée principale : le « Vibe Coding »

Imaginez que vous voulez construire une chaise en bois.

Codage traditionnel : Vous êtes un menuisier. Vous mesurez le bois, coupez les assemblages, poncez les bords et l'assemblez vous-même. Vous savez exactement comment chaque vis s'emboîte.
Vibe Coding : Vous êtes un réalisateur. Vous dites à un robot magique : « Construis-moi une chaise solide », et le robot en construit une instantanément. Vous ne savez pas comment les assemblages sont coupés, mais vous vous asseyez dessus. Si elle vacille, vous ne réparez pas le bois ; vous dites simplement au robot : « Rends-la plus solide », et vous espérez qu'il la répare lui-même.

Ce papier étudie les personnes qui utilisent cette méthode de « Vibe Coding » (utiliser l'IA pour écrire du code via le langage naturel) et se demande : Est-ce que cela change quelque chose si vous êtes un menuisier professionnel, un débutant ou quelqu'un qui n'a jamais tenu un marteau ?

L'étude : Trois groupes à la table

Les chercheurs ont interrogé 162 personnes et les ont répartis en trois groupes :

Non-développeurs : Des personnes sans formation formelle en codage.
Novices : Des personnes qui ont suivi un cours ou construit de petits projets mais ne sont pas encore des pros.
Professionnels : Des ingénieurs logiciels expérimentés qui font cela pour vivre.

Ils ont posé quatre questions principales à ces groupes :

Pourquoi le faites-vous ? (Motivation)
Comment cela se passe-t-il ? (Expérience)
Faites-vous confiance au résultat ? (Qualité perçue)
Que faites-vous quand cela plante ? (Assurance qualité)

Les résultats : Ce qui est pareil, ce qui est différent

1. Le « ressenti » et la « confiance » sont identiques (La vision partagée)

Surprenamment, les trois groupes ont ressenti la même chose concernant l'expérience et la qualité du travail de l'IA.

L'analogie : Imaginez que tout le monde à table mange un repas cuisiné par un chef célèbre. Les non-coders, les étudiants et les pros s'accordent tous à dire : « Cette nourriture est délicieuse et rapide, mais elle a parfois une texture étrange, et vous ne la serviriez pas à un mariage chic. »
Le résultat : Tout le monde sait que le code généré par l'IA est excellent pour des prototypes rapides, mais qu'il peut être « instable » ou « bourré de bugs » pour un travail sérieux. Ils ressentent tous le même mélange d'excitation et de prudence. L'expérience ne change pas la façon dont ils voient l'IA.

2. Le « pourquoi » et le « comment » sont différents (Les approches divergentes)

Bien qu'ils voient l'IA de la même manière, ils l'utilisent de façon très différente.

Non-développeurs (Les utilisateurs de baguettes magiques) : Ils sont principalement motivés par l'accès. Ils disent : « Je n'aurais pas pu construire cela sans l'IA. » Ils ont tendance à laisser l'IA faire presque tout avec très peu d'instructions. C'est comme remettre une toile blanche au robot en disant : « Fais de l'art. »
Novices (Les apprenants) : Ils sont motivés par l'apprentissage. Ils utilisent l'IA pour expérimenter et voir comment les choses fonctionnent. Ils sont comme des étudiants regardant un chef cuisinier préparer un plat, essayant de comprendre la recette.
Professionnels (Les chefs d'orchestre) : Ils utilisent l'IA pour le travail. Ils ne disent pas juste « fais une chaise » ; ils donnent des instructions détaillées, du contexte et des contraintes. Ils traitent l'IA comme un assistant junior qu'ils doivent gérer soigneusement.

3. Le grand fossé : Quand les choses tournent mal (Le « fossé perception-action »)

C'est la découverte la plus importante. Même si tout le monde sait que l'IA fait des erreurs, seuls les experts savent les corriger.

L'analogie : Imaginez que le robot construit une chaise, mais qu'une jambe est instable.
- Le non-développeur : Dit : « Oh non, ça vacille ! » et dit immédiatement au robot : « Rends la jambe plus longue ! » Il continue de demander au robot de le réparer jusqu'à ce que ça ne vacille plus, sans jamais regarder le bois lui-même.
- Le novice : Essaie de le réparer mais se perd. Il peut abandonner ou continuer de demander de l'aide au robot.
- Le professionnel : Dit : « Oh non, ça vacille ! » Il prend une clé, examine l'assemblage, trouve la vis desserrée et la resserre lui-même. Il vérifie le travail avant de s'asseoir.

La conclusion du papier : Il existe un « fossé perception-action ».

Perception : Tout le monde sait que l'IA peut se tromper.
Action : Seules les personnes expérimentées ont les compétences pour vérifier et débugger le code quand il est erroné.

La métaphore de la « démocratisation partielle »

Les auteurs appellent cela la « démocratisation partielle ».

Démocratisé : L'IA a abaissé la barrière pour créer des logiciels. N'importe qui peut maintenant construire une « chaise » numérique.
Non démocratisé : La capacité d'inspecter et de garantir la qualité de cette chaise reste enfermée derrière une porte dont seuls les personnes expérimentées ont la clé.

Nous donnons à tout le monde une baguette magique pour créer, mais nous n'avons pas encore donné à tout le monde le manuel d'instructions pour savoir si la création est sûre à utiliser.

Que veulent les gens ?

Lorsqu'on leur a demandé ce qui les ferait davantage faire confiance à l'IA, tout le monde (des non-coders aux pros) voulait la même chose :

Fiabilité : « Assure-toi juste que ça marche. »
Transparence : « Dis-moi pourquoi tu l'as construit de cette façon. »
Sécurité : « Ne me donne pas de code qui pourrait casser plus tard. »

Résumé

Le papier soutient que si les outils d'IA ont rendu facile pour n'importe qui de créer des logiciels, ils n'ont pas rendu facile pour n'importe qui de les vérifier.

Les débutants comptent sur l'IA pour réparer ses propres erreurs (en relançant le prompt).
Les experts vérifient le travail eux-mêmes (en débuguant).
Tout le monde sait que l'IA n'est pas parfaite, mais seuls les experts savent la réparer quand elle échoue.

Le risque n'est pas que les gens ne sachent pas que l'IA fait des erreurs ; le risque est que beaucoup de gens n'aient pas les compétences pour réparer ces erreurs quand elles surviennent.

Résumé technique : Du prompting à la vérification : comment l'expérience façonne les pratiques du « vibe coding »

Énoncé du problème
Les outils de génération de code par intelligence artificielle, propulsés par des modèles de langage de grande taille (LLM), ont élargi la création logicielle au-delà des développeurs professionnels pour inclure des non-développeurs et des novices. Ce glissement a donné naissance au « vibe coding », une pratique où les utilisateurs génèrent des logiciels via des prompts en langage naturel, évaluent les résultats principalement par leur exécution, et itèrent par de nouveaux prompts plutôt que par un débogage systématique. Alors que des recherches antérieures ont examiné la programmation assistée par IA au sein de groupes spécifiques (généralement des professionnels ou des étudiants) ou ont étudié des non-experts de manière isolée, il manque une comparaison systématique à travers les niveaux d'expérience. Il reste incertain comment les motivations, les styles d'interaction, la qualité de code perçue et les pratiques d'assurance qualité (QA) diffèrent entre les non-développeurs, les développeurs novices et les développeurs professionnels. Crucialement, il est inconnu si la prise de conscience généralisée des limites du code généré par l'IA se traduit par une action corrective efficace à tous les niveaux d'expérience, ou si un fossé existe entre la perception et le comportement.

Méthodologie
Les auteurs ont mené une enquête quantitative transversale auprès de 162 participants, répartis équitablement en trois groupes d'expérience : non-développeurs (aucune formation formelle mais utilisation d'outils d'IA), développeurs novices (expérience limitée via des tutoriels ou des cours) et développeurs professionnels (expérience formelle ou professionnelle en codage).

Instrument : Le questionnaire s'appuyait sur une revue préalable de la littérature grise ayant identifié quatre dimensions comportementales du vibe coding : motivations, expériences, qualité de code perçue et pratiques d'assurance qualité. Ces dimensions ont été opérationnalisées sous forme de construits à échelle de Likert (échelle de 5 points) et complétées par des questions ouvertes.
Collecte de données : Les participants ont été recrutés via Prolific. La qualité des données a été rigoureusement assurée par un filtrage de complétude, des vérifications de plausibilité cognitive basées sur le temps (excluant les réponses de moins de 4 minutes) et des diagnostics de motifs de réponse (détection du remplissage en ligne droite).
Analyse : L'étude a employé des méthodes statistiques non paramétriques adaptées aux données ordinales de type Likert. Les différences entre les trois groupes indépendants ont été évaluées à l'aide du test H de Kruskal–Wallis, avec une correction de Benjamini–Hochberg pour les comparaisons multiples et des tests post-hoc de Dunn pour les comparaisons par paires. Les tailles d'effet ont été calculées à l'aide de l'épsilon au carré ( $\varepsilon^2$ ). De plus, une régression logistique ordinale a été utilisée pour déterminer si les différences en matière d'assurance qualité étaient dues à l'appartenance au groupe d'expérience ou à des dimensions d'utilisation sous-jacentes (par exemple, heures de codage indépendant, durée d'adoption).

Résultats clés
L'étude révèle que l'expérience façonne sélectivement les pratiques de vibe coding, créant un fossé distinct entre « perception et action ».

Perceptions partagées (RQ2 & RQ3) : Il n'y avait aucune différence statistiquement significative entre les niveaux d'expérience concernant les expériences subjectives (par exemple, flux, frustration, hallucinations) ou les perceptions de la qualité du code. Tous les groupes reconnaissaient des forces similaires (prototypage rapide, structure propre) et des limites (fragilité, bugs cachés, inadéquation pour la production). Cela indique une prise de conscience générale largement partagée des risques et des avantages du code généré par l'IA.
Motivations et styles divergents (RQ1 & Style d'interaction) :
- Motivations : Les non-développeurs étaient principalement motivés par l'accessibilité et l'autonomisation (créer des logiciels qu'ils ne pourraient pas faire autrement). Les novices étaient motivés par l'apprentissage et l'expérimentation. Les professionnels étaient plus orientés vers les objectifs, utilisant souvent le vibe coding dans des contextes liés au travail.
- Styles d'interaction : Les non-développeurs montraient une plus grande dépendance à la « génération pilotée par l'IA » (délégation de la création de code avec une intervention minimale). Les professionnels s'engageaient davantage dans un « dialogue interactif » (prompts itératifs et affinage) et fournissaient un « contexte plus riche ».
Pratiques d'assurance qualité divergentes (RQ4) : La divergence la plus significative s'est produite dans les comportements de vérification.
- Débogage vs Reprompting : Les non-développeurs comptaient significativement davantage sur le reprompting de l'IA pour corriger les erreurs plutôt que sur un débogage manuel. Ils ont également signalé des niveaux plus élevés de « rupture d'assurance qualité » (abandonner car ils ne pouvaient pas comprendre le code).
- Fréquence de vérification : Environ 45 % des professionnels ont déclaré vérifier toujours le code généré par l'IA avant utilisation, tandis que les non-développeurs étaient le seul groupe à déclarer « ne jamais » vérifier le code.
- Résultats de la régression : L'analyse de régression a indiqué que ces différences en matière d'assurance qualité n'étaient pas simplement une fonction de la catégorie de groupe, mais étaient motivées par la pratique accumulée du codage et l'exposition aux outils (spécifiquement, les heures de codage indépendant non lié au vibe coding).

Contributions clés

Caractérisation empirique du vibe coding : L'étude fournit la première comparaison quantitative systématique des pratiques de vibe coding entre non-développeurs, novices et professionnels, allant au-delà des preuves anecdotiques ou des études sur un seul groupe.
Identification du fossé perception–action : L'article identifie un découplage critique où la prise de conscience générale des risques du code par l'IA est répartie à tous les niveaux d'expérience, mais la capacité à évaluer, déboguer et vérifier ces risques reste dépendante de l'expérience.
Raffinement de la « démocratisation partielle » : Les auteurs soutiennent que le vibe coding démocratise partiellement la création logicielle en abaissant les barrières à la production sans distribuer également l'expertise requise pour l'évaluation. Les barrières ont glissé de l'écriture de code vers la décomposition des problèmes, la spécification de l'intention et la validation des résultats.
Comportement piloté par l'utilisation : L'étude démontre que les comportements d'assurance qualité sont mieux prédits par des dimensions spécifiques de l'expérience (pratique du codage et exposition aux outils) que par de simples étiquettes catégorielles larges.

Importance et affirmations
L'article affirme que les risques du vibe coding dépendent non seulement des capacités des outils d'IA, mais significativement de la capacité de l'utilisateur à agir sur sa prise de conscience des limites de ces outils. Les auteurs interprètent leurs résultats comme la preuve d'un fossé perception–action : tandis que les utilisateurs de tout le spectre reconnaissent que le code généré par l'IA peut être défectueux, les utilisateurs moins expérimentés manquent des compétences spécifiques pour traduire cette reconnaissance en vérification systématique.

Par conséquent, les auteurs suggèrent que :

Conception d'outils : Les outils de génération de code par IA devraient fournir un étayage plus fort pour les utilisateurs moins expérimentés (par exemple, mise en évidence proactive des erreurs, support explicatif, signalisation de l'incertitude) tout en restant discrets pour les experts.
Éducation : L'évaluation du code généré par l'IA doit être traitée comme une compétence distincte du prompting, nécessitant un enseignement du test, de l'identification des cas limites et du raisonnement sur le code.
Recherche future : Le « fossé perception–action » est présenté comme une hypothèse pour de futures études comportementales à tester, car les résultats actuels reposent sur des données auto-déclarées plutôt que sur un comportement observé.

L'article conclut que, alors que le vibe coding élargit la participation à la création logicielle, s'assurer que la capacité à évaluer le code produit suit le rythme de la capacité à le produire est central pour une adoption sûre et efficace.