Les bugs typiques des apps codées avec l’IA

L’app a été construite en un week-end, en décrivant chaque écran à une IA. La démo du lundi est parfaite : l’inscription marche, le panier se remplit, le paiement passe. Le mardi, un vrai client tape un nom avec une apostrophe, perd la 3G au mauvais moment, et l’app se fige sur un écran blanc.

Le vibe coding, l’expression lancée par le chercheur Andrej Karpathy en février 2025 et élue mot de l’année 2025 par le dictionnaire Collins, consiste à décrire ce qu’on veut à une IA en langage courant et à la laisser écrire le code. Le gain de vitesse est réel. Mais les apps produites ainsi échouent souvent aux mêmes endroits, si régulièrement qu’on peut en dresser la carte.

Cet article n’est pas un réquisitoire contre l’IA : elle accélère, le test humain sécurise. Vous y trouverez les familles de bugs typiques, la façon de repérer chacune en test, des exemples concrets et une grande liste de contrôle à dérouler avant de publier.

Pourquoi les apps codées avec l’IA cassent toujours aux mêmes endroits

Une IA répond à la demande telle qu’elle est écrite. Demandez « une page d’inscription » et vous obtenez des champs et un bouton qui fonctionnent quand tout va bien. Personne n’a précisé quoi faire si le numéro existe déjà, si le réseau coupe ou si le nom contient une apostrophe. L’IA n’invente pas ces exigences à votre place.

Trois autres causes s’ajoutent :

• Le contexte manque. L’IA ne sait pas que vos clients ont des téléphones d’entrée de gamme, paient en francs CFA et lisent le français comme l’anglais.
• Chaque écran naît séparément. Généré dans une conversation différente, il a son propre style, ses propres mots, ses propres règles.
• Personne ne relit. Par définition, le vibe coder ne lit pas le code ligne à ligne. Si personne ne teste, personne ne voit rien.

Les chiffres confirment le risque. En juillet 2025, l’éditeur de solutions de sécurité Veracode a publié une étude portant sur 80 tâches de programmation confiées à plus de 100 modèles d’IA : dans 45 % des cas, le code produit contenait une faille appartenant au Top 10 de l’OWASP, la liste de référence des risques web. Les modèles les plus gros ne faisaient pas significativement mieux.

Cas limites et erreurs non gérées : là où l’app casse en premier

Les cas limites oubliés

Pour chaque champ, essayez la série suivante : vide, quelques espaces seulement, 300 caractères, des accents et des apostrophes (« Éyenga N’Diaye »), un emoji. Pour un numéro de téléphone, tapez-le comme les gens le font vraiment : avec ou sans indicatif, avec des espaces. Pour un montant : zéro, négatif, décimal, très grand. Pour une date : le 29 février, le 31 d’un mois qui n’en a que 30.

Testez aussi les gestes : toucher deux fois un bouton d’envoi, revenir en arrière pendant un enregistrement, tourner l’écran en plein formulaire.

Les erreurs non gérées

Le code généré suppose souvent que le serveur répond toujours, vite et bien. Provoquez le contraire : mode avion pendant une action, réseau lent, session expirée, stockage plein. Sur le web, l’onglet Network des outils de développement de Chrome permet de couper le réseau d’un clic.

Les signes qui ne trompent pas : une roue de chargement qui tourne sans fin, un écran blanc, un message brut comme « TypeError : Cannot read properties of undefined », un « Something went wrong » sans aucune piste, un formulaire vidé après l’erreur. Sur le web, ouvrez aussi la console : une page qui « marche » peut y afficher des dizaines d’erreurs rouges.

États vides, chargements et données de démo oubliées

Les états vides. L’IA conçoit les écrans avec des données d’exemple, rarement sans données. Créez un compte tout neuf et visitez chaque écran : « Mes commandes » est-il vide, cassé, ou affiche-t-il « undefined » ? Un bon état vide explique la situation et propose une action, par exemple « Vous n’avez pas encore de commande. Découvrir les produits ».

Les chargements. Pendant un envoi, le bouton doit se désactiver et un indicateur doit apparaître. Sinon, sur un réseau lent, l’utilisateur touche encore et crée des doublons. Vérifiez aussi que la page ne saute pas quand les images arrivent.

Les données de démo. C’est le défaut le plus gênant, car il se voit tout de suite. Cherchez :

• « John Doe », « Lorem ipsum », « jane@example.com », « Acme Inc. » ;
• des produits fictifs, des prix en dollars au lieu de francs CFA, des numéros au format américain ;
• des avis clients inventés, avec cinq étoiles et des prénoms étrangers à votre marché ;
• un compte de test ou un bouton « Admin » encore visible, des identifiants préremplis dans le formulaire de connexion ;
• des images d’illustration génériques, des liens « À propos » ou « Mentions légales » qui mènent nulle part.

Des avis inventés ne sont pas un simple oubli : ils trompent vos clients. Supprimez-les avant toute publication.

Sécurité : clés exposées et règles d’accès trop larges

C’est la famille la plus grave, parce qu’elle ne se voit pas à l’écran.

Les clés exposées. Une app web ou mobile envoie son code au téléphone de l’utilisateur : tout ce qui s’y trouve peut être lu. Une clé secrète de paiement ou d’API d’IA placée dans ce code est donc publique. Sur votre propre app web, ouvrez l’onglet Sources des outils de développement et cherchez « secret », « sk_ », « service_role » ou « api_key ». Attention aux nuances : chez Supabase, la clé publique (anon ou publishable) est prévue pour le navigateur, à condition que la sécurité au niveau des lignes soit activée ; la clé secrète, elle, ne doit jamais y apparaître.

Les règles d’accès trop larges. Les bases de données en ligne prisées des apps générées reposent sur des règles d’accès. La documentation de Supabase demande d’activer la sécurité au niveau des lignes (Row Level Security) sur chaque table exposée : sans elle, une table peut être lue et modifiée par toute personne qui possède la clé publique. Chez Firebase, des règles ouvertes laissent quiconque devine l’identifiant du projet lire, modifier ou supprimer les données ; une règle qui vérifie seulement que l’utilisateur est connecté donne à chaque compte l’accès aux données de tous les autres.

Pour le repérer sans rien attaquer, créez deux comptes de test, A et B. Avec B, cherchez les commandes, messages, fichiers et profils de A, par les listes, la recherche et les liens partagés. Avec un compte ordinaire, essayez d’ouvrir l’adresse /admin. Puis demandez au développeur de vous montrer les règles d’accès, table par table.

Interface incohérente, accessibilité oubliée, textes non traduits

Les incohérences. Trois styles de boutons, « Valider » ici et « Envoyer » là, des dates au format « 10/20/2026 » sur un écran et « 20/10/2026 » sur l’autre, « XAF », « FCFA » et « $ » dans la même app. Pour les repérer, faites une capture de chaque écran et posez-les côte à côte : les différences sautent aux yeux. La cohérence est l’une des heuristiques de Nielsen : elle évite à l’utilisateur de réapprendre l’app à chaque écran.

L’accessibilité oubliée. Boutons-icônes sans nom, texte gris pâle à la mode, cibles minuscules, zones cliquables impossibles à atteindre au clavier. Cinq minutes de TalkBack ou de VoiceOver sur le parcours principal, et quelques appuis sur la touche Tab sur le web, suffisent à révéler l’essentiel. La méthode complète est dans le guide pour tester l’accessibilité d’une app.

Les textes non traduits. L’app est en français, mais les erreurs disent « Invalid email », le bouton dit « Submit » et les dates s’affichent « Oct 20 ». Pluriels ratés (« 1 commandes »), textes qui débordent quand la traduction est plus longue, moitié de l’écran restée en français quand on passe le téléphone en anglais. Changez la langue du téléphone, déclenchez chaque message d’erreur et lisez les SMS et e-mails envoyés par l’app.

Performance : rapide chez le créateur, lente chez l’utilisateur

Sur l’ordinateur du créateur, branché à la fibre, tout va vite. Chez l’utilisateur, les causes typiques de lenteur apparaissent : images de plusieurs mégaoctets tout droit sorties d’un générateur d’images, liste entière chargée d’un coup au lieu de page par page, grosse bibliothèque ajoutée pour une seule fonction, mêmes requêtes envoyées plusieurs fois.

Pour le repérer, ouvrez l’onglet Network des outils de développement : regardez le poids total transféré et le nombre de requêtes, puis limitez le débit à la 3G et rechargez. Sur mobile, prenez le téléphone le moins cher de votre liste. Les seuils et la méthode complète sont dans le guide pour tester sur un téléphone modeste et un réseau lent.

La liste de contrôle avant de publier une app codée avec l’IA

Déroulez cette liste avant chaque publication. Elle complète la liste de contrôle avant publication, valable pour toutes les apps.

Cas limites

• Chaque champ testé vide, avec des espaces, très long, avec accents, apostrophes et emoji
• Numéros de téléphone acceptés sous leurs formes courantes, avec ou sans indicatif
• Montants nuls, négatifs et décimaux refusés ou traités correctement
• Double appui sur chaque bouton d’envoi sans doublon

Erreurs et états

• Mode avion pendant chaque action importante, avec un message clair et les saisies conservées
• Aucune trace technique ni message en anglais brut affiché à l’utilisateur
• Console du navigateur sans erreur rouge sur les parcours principaux
• Chaque écran vérifié avec un compte tout neuf, sans données
• Indicateur de chargement et bouton désactivé pendant chaque envoi

Données de démo

• Aucun « Lorem ipsum », « John Doe », « example.com » ni produit fictif
• Aucun avis client inventé
• Prix, devise et formats de date adaptés à votre marché
• Comptes de test, identifiants préremplis et boutons « Admin » retirés

Sécurité

• Aucune clé secrète dans le code envoyé au navigateur ou au téléphone
• Règles d’accès vérifiées table par table (RLS chez Supabase, règles de sécurité chez Firebase)
• Le compte B ne voit aucune donnée du compte A
• Pages d’administration inaccessibles à un compte ordinaire
• Revue par un développeur ou un expert si l’app manipule de l’argent ou des données sensibles

Interface, accessibilité, langues

• Mêmes mots, mêmes styles de boutons, mêmes formats sur tous les écrans
• Parcours principal réalisable avec TalkBack ou VoiceOver
• Texte du téléphone agrandi au maximum sans contenu coupé
• Toute l’app vérifiée dans chaque langue proposée, messages d’erreur compris

Performance

• Parcours principal testé en 3G simulée et sur un téléphone d’entrée de gamme
• Images allégées et listes longues chargées par morceaux

L’IA vous a fait gagner des semaines ; quelques heures de test humain protègent ce gain. Pour aller plus loin sur ce partage des rôles, lisez pourquoi le vibe coding a besoin de tests humains. Et pour un regard neuf avant le lancement, vous pouvez faire tester votre app par les testeurs GeekTest, sur leurs propres téléphones.

Pour aller plus loin

• Le message d’Andrej Karpathy qui a lancé l’expression « vibe coding » (nouvel onglet) (en anglais, 2 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.
• Communiqué de Veracode sur son rapport 2025 consacré au code généré par IA (nouvel onglet) (en anglais) : la méthode et les résultats de l’étude sur plus de 100 modèles.
• Row Level Security, documentation Supabase (nouvel onglet) (en anglais) : activer la sécurité au niveau des lignes et protéger les clés secrètes.
• Éviter les règles non sécurisées, documentation Firebase (nouvel onglet) : les règles d’accès trop ouvertes et la façon de les restreindre.
• OWASP Top 10:2025 (nouvel onglet) (en anglais) : les dix risques de sécurité les plus critiques des applications web.