Vibe coding : pourquoi votre app a besoin de vrais testeurs

Un dimanche soir, vous décrivez votre idée à une IA. Le lundi matin, l’application tourne : des écrans soignés, une base de données, un formulaire de paiement. Il n’y a pas si longtemps, il aurait fallu une équipe et plusieurs mois.

Créer une app n’a jamais été aussi facile. La faire adopter, si. Car un code qui compile ne dit rien de l’essentiel : est-ce qu’une vraie personne, sur son propre téléphone, comprend votre app en quelques secondes, réussit ce qu’elle était venue faire, et a envie de revenir ?

À la fin de ce guide, vous saurez ce que l’IA ne peut pas vérifier à votre place, pourquoi cinq vrais utilisateurs valent mieux qu’une centaine de tests générés, et comment organiser en une semaine les tests humains qui font la différence entre une app publiée et une app adoptée.

Le vibe coding, en deux mots

L’expression vient d’Andrej Karpathy, chercheur en intelligence artificielle. En février 2025, il décrit une nouvelle façon de programmer : on dit à l’IA ce qu’on veut, en langage courant, on accepte ses propositions, on colle les messages d’erreur, et on avance « au feeling », sans vraiment lire le code. L’expression a tellement circulé que le dictionnaire Collins en a fait son mot de l’année 2025.

Ce n’est pas une mode de niche. Dans l’enquête 2025 de Stack Overflow auprès des développeurs, 84 % des répondants disent utiliser des outils d’IA dans leur travail ou prévoir de le faire. Les fondateurs sans équipe technique, les étudiants, les PME qui veulent un outil interne : tout le monde peut désormais sortir une première version.

C’est une excellente nouvelle. Mais elle déplace le problème.

Ce que l’IA a vraiment changé, et ce qu’elle n’a pas changé

Hier, la question difficile était : « Saurons-nous la construire ? » Aujourd’hui, elle devient : « Les gens vont-ils l’utiliser ? » Le coût de fabrication a chuté ; le coût d’un mauvais lancement, lui, n’a pas bougé. Une application que personne ne comprend reste une application que personne n’utilise, qu’elle ait coûté trois mois ou trois soirées.

Le tableau suivant résume ce qui a changé, étape par étape, dans la vie d’une application.

Les trois dernières lignes n’ont pas changé. Elles ne dépendent pas de la vitesse à laquelle on écrit le code, mais de la façon dont de vraies personnes vivent l’application. Et c’est précisément là que l’IA a un angle mort.

Pourquoi « ça marche sur mon écran » ne suffit pas

Une IA teste votre app comme elle l’a construite : avec la même logique, les mêmes hypothèses et les mêmes oublis. Si elle n’a pas pensé qu’un utilisateur pouvait taper son numéro avec des espaces, ses tests n’y penseront pas non plus. Elle vérifie que le code fait ce qu’elle a compris ; elle ne vérifie pas que vous vous êtes bien compris.

Les développeurs eux-mêmes le constatent. Dans la même enquête Stack Overflow, 46 % des répondants disent se méfier de l’exactitude des réponses de l’IA, contre 33 % qui lui font confiance. Leur première frustration, citée par 66 % d’entre eux : des solutions « presque justes, mais pas tout à fait ». Et 45 % trouvent que déboguer du code généré par l’IA prend plus de temps.

La sécurité suit le même chemin. En 2025, l’éditeur Veracode a soumis 80 tâches de programmation à plus de 100 modèles d’IA : dans 45 % des cas, le code produit contenait une faille de la liste OWASP Top 10, la référence des risques les plus critiques du web. Les modèles les plus gros ne faisaient pas sensiblement mieux.

Rien de tout cela n’est une raison de se passer de l’IA. C’est une raison d’ajouter, à la fin de la chaîne, ce que l’IA ne fournit pas : un regard extérieur, humain, sur de vrais appareils.

Ce que seuls des humains peuvent vous dire

Jakob Nielsen, l’une des références mondiales de l’ergonomie, résume la qualité d’usage d’une interface en cinq composantes. Aucune ne se mesure en lisant le code.

1. La facilité d’apprentissage : une personne qui découvre votre app réussit-elle les tâches de base du premier coup ?
2. L’efficacité : une fois l’app connue, va-t-on vite, ou faut-il cinq écrans pour une action simple ?
3. La mémorisation : après deux semaines sans l’ouvrir, s’y retrouve-t-on encore ?
4. Les erreurs : combien en fait-on, sont-elles graves, et s’en remet-on facilement ?
5. La satisfaction : l’app est-elle agréable, ou seulement fonctionnelle ?

À cela s’ajoute tout ce que l’on ne voit que sur le terrain. Un téléphone d’entrée de gamme avec peu de mémoire. Une connexion 3G qui coupe dans le taxi. Un écran en plein soleil, utilisé d’une seule main. Un appel qui interrompt le paiement par mobile money. Notre guide sur les tests sur téléphone modeste et réseau lent montre comment reproduire ces conditions.

Il y a enfin la confiance. Une personne qui ouvre votre app pour la première fois se demande, souvent sans le dire : « Est-ce sérieux ? Est-ce que je peux donner mon numéro ici ? » Ce jugement se forme en quelques secondes, et il décide de tout le reste. Le guide sur la première impression et l’onboarding explique comment le tester.

Cinq utilisateurs suffisent pour commencer

Bonne nouvelle : pas besoin de centaines de testeurs pour apprendre l’essentiel. Selon les travaux de Jakob Nielsen, un test avec cinq utilisateurs représentatifs suffit en général à faire apparaître les problèmes d’utilisation les plus importants. Mieux vaut plusieurs petits tests, avec des corrections entre chacun, qu’une seule grande étude.

La méthode de base tient en trois gestes : recruter des personnes qui ressemblent à vos futurs utilisateurs, leur confier des tâches réalistes, puis les observer sans les aider. C’est le dernier point qui coûte le plus aux créateurs : on a envie d’expliquer, de montrer le bon bouton. Mais chaque explication efface justement l’information que l’on était venu chercher.

Pour préparer les tâches, recruter les bonnes personnes et animer la séance, suivez notre guide pour organiser un test utilisateur.

Un plan de test humain en une semaine

Voici un plan simple pour une première version, que vous ayez codé seul avec l’IA ou avec une petite équipe.

1. Jour 1 : fixer l’objectif. Écrivez les trois tâches qui comptent le plus (par exemple : s’inscrire, trouver un produit, payer). Une app qui réussit ces trois tâches est une app utilisable.
2. Jour 2 : préparer l’app et les testeurs. Une version installable, des comptes de test, des données réalistes. Recrutez cinq à huit personnes qui ressemblent à vos clients, pas vos meilleurs amis développeurs.
3. Jours 3 et 4 : faire tester. Chaque testeur réalise les tâches sur son propre téléphone, dans ses conditions habituelles, et note ce qui bloque, ce qui surprend, ce qui rassure.
4. Jour 5 : trier les retours. Regroupez ce qui revient plusieurs fois et classez par gravité.
5. Jours 6 et 7 : corriger, puis refaire tester. Corrigez les problèmes majeurs, avec l’IA si vous voulez, puis faites tester à nouveau par d’autres personnes, pour vérifier que la correction marche vraiment.

Si trouver des testeurs fiables est le plus difficile pour vous, une plateforme comme GeekTest fournit de vrais testeurs sur Android, iPhone, web et ordinateur, et leurs retours.

Les stores, eux aussi, veulent des humains

Les boutiques d’applications ont tiré les mêmes conclusions. Google exige, pour les comptes développeur personnels créés après le 13 novembre 2023, un test fermé avec au moins 12 testeurs inscrits pendant 14 jours d’affilée avant de pouvoir publier en production, selon l’aide officielle de la Play Console (nouvel onglet). Notre guide sur le test fermé Google Play à 12 testeurs détaille chaque étape.

Côté Apple, les règles de l’App Store rejettent les apps incomplètes ou qui plantent : une app générée en une nuit et jamais essayée sur un vrai iPhone a toutes les chances d’être refusée. TestFlight permet de la faire tester avant de la soumettre ; voyez notre guide pour faire tester une app iPhone et iPad avec TestFlight.

Autrement dit, même les géants du secteur, qui disposent des meilleurs outils automatiques du monde, demandent de vraies personnes avant d’ouvrir leurs vitrines.

Transformer les retours en améliorations

Un test ne vaut que par ce qu’on en fait. Triez chaque retour en trois familles : les bugs (quelque chose ne marche pas), les frictions (cela marche, mais on hésite, on se trompe, on perd du temps) et les suggestions (une idée de l’utilisateur). Les frictions sont souvent les plus précieuses : ce sont elles qui font fuir en silence.

Pour décider quoi corriger d’abord, croisez deux questions : combien de testeurs ont rencontré le problème, et à quel point il les a bloqués. Un souci qui empêche trois personnes sur cinq de payer passe avant une couleur que deux personnes trouvent terne.

Puis recommencez. Les meilleures applications ne sont pas celles qui ont été testées une fois, mais celles qui sont testées à chaque version importante, par des personnes qui ne les connaissent pas encore.

Pour aller plus loin

• Le message d’Andrej Karpathy qui a lancé l’expression « vibe coding » (nouvel onglet) (en anglais, février 2025) : la définition d’origine, par son auteur.
• Collins’ Word of the Year 2025 (nouvel onglet) (en anglais) : pourquoi le dictionnaire Collins a choisi « vibe coding » comme mot de l’année.
• Enquête Stack Overflow 2025, partie consacrée à l’IA (nouvel onglet) (en anglais) : usage des outils d’IA par les développeurs, confiance dans leurs réponses et principales frustrations.
• Communiqué de Veracode sur le code généré par l’IA (nouvel onglet) (en anglais, juillet 2025) : 80 tâches, plus de 100 modèles, et les failles de sécurité trouvées.
• Usability 101, Nielsen Norman Group (nouvel onglet) (en anglais) : les cinq composantes de l’utilisabilité et la méthode de base du test utilisateur.
• Why You Only Need to Test with 5 Users, Nielsen Norman Group (nouvel onglet) (en anglais) : pourquoi plusieurs petits tests valent mieux qu’une grande étude.