Comment déboguer une application créée avec l'IA : une méthode pratique

Pour déboguer une application créée avec l'IA, commencez par reproduire volontairement le bug, puis rassemblez des preuves — les étapes exactes, le message d'erreur, et ce que montrent la console et l'onglet réseau du navigateur — et donnez-les à l'IA sous la forme « j'ai fait X, je m'attendais à Y, j'ai obtenu Z ». Si une correction empire les choses, revenez à la dernière version qui fonctionnait au lieu d'empiler les corrections. Vous n'avez pas besoin de lire le code pour bien faire tout cela.

Ce guide présente la boucle complète, y compris un tour rapide des outils de développement du navigateur pour les non-développeurs.

La boucle de débogage

Chaque correction de bug, qu'elle soit faite par une personne ou par une IA, suit la même boucle :

1. Reproduire — faire réapparaître le bug de façon fiable.
2. Observer — relever le message d'erreur et ce que faisait l'application.
3. Décrire — donner à l'IA des étapes précises, le résultat attendu et le résultat réel.
4. Corriger — laisser l'IA modifier une seule chose.
5. Vérifier — refaire exactement les mêmes étapes et confirmer que c'est corrigé, et que rien à côté ne s'est cassé.
6. Revenir en arrière si besoin — si cela a empiré, annulez et réessayez avec de meilleures informations.

La plupart du temps perdu sur les applications créées avec l'IA vient de l'oubli des étapes 1, 2 et 5 : dire « c'est cassé », accepter une modification sans la tester, puis demander une nouvelle correction par-dessus une correction défaillante.

Étape 1 : reproduire le bug

Un bug que vous pouvez déclencher à volonté est déjà à moitié corrigé. Essayez de trouver la séquence d'étapes la plus courte qui le provoque.

Demandez-vous :

• Est-ce que cela arrive à chaque fois ? Si c'est seulement parfois, qu'est-ce qui est différent quand cela arrive — un enregistrement particulier, une connexion lente, une déconnexion ?
• Est-ce que cela arrive à tous les utilisateurs ? Connectez-vous avec un autre compte. Beaucoup de bugs n'apparaissent que pour les nouveaux utilisateurs sans données, ou pour un utilisateur ayant un rôle différent.
• Est-ce que cela arrive sur tous les appareils ? Essayez un écran de la largeur d'un téléphone et un autre navigateur.
• Est-ce que cela a commencé après une modification précise ? Si cela fonctionnait hier, les dernières modifications sont les principaux suspects.

Notez les étapes sous forme de liste numérotée courte. Vous la collerez dans le prompt plus tard.

Étape 2 : lire le message d'erreur

Les messages d'erreur impressionnent, mais vous n'avez besoin que de quelques éléments.

Inutile de le comprendre ; il faut le recopier exactement. « Cannot read properties of undefined (reading 'name') » indique à l'IA que le code attendait des données (probablement une réservation ou un utilisateur) qui n'étaient pas là. Une paraphrase comme « une erreur undefined » perd cette information.

Quelques erreurs courantes, traduites approximativement :

• Erreurs undefined / null — le code attendait des données qui ne sont pas arrivées. Souvent un état de chargement ou une liste vide que le code ne gère pas.
• 404 Not Found — la page ou l'adresse de l'API n'existe pas. Souvent une faute de frappe dans une route ou un lien vers une page renommée.
• 401 Unauthorized / 403 Forbidden — la requête n'était pas connectée, ou l'utilisateur n'a pas le droit de faire cela.
• 500 Internal Server Error — le code côté serveur a planté. La vraie raison se trouve dans les journaux du serveur, pas dans le navigateur.
• Erreurs CORS — le navigateur a bloqué une requête vers un autre domaine. Généralement un problème de configuration côté serveur.

Étape 3 : utiliser les outils de développement du navigateur

Chaque navigateur de bureau possède des outils de développement intégrés (« devtools »). Ils montrent ce que fait la page en coulisses. Dans Chrome, Edge et Firefox, faites un clic droit n'importe où sur la page et choisissez Inspecter, ou appuyez sur F12 (Cmd+Option+I sur Mac). Dans Safari, activez d'abord le menu Développement dans les réglages de Safari.

Il ne vous faut que trois onglets.

Console

L'onglet Console liste les erreurs et messages venant du code de la page. Les erreurs apparaissent en rouge. Si un bouton ne fait rien quand vous cliquez, la console affiche très souvent une erreur rouge au moment du clic. Copiez le texte complet de l'erreur (faites un clic droit dessus pour l'option de copie dans la plupart des navigateurs).

Réseau

L'onglet Réseau liste chaque requête envoyée par la page — chargement de données, enregistrement d'un formulaire, connexion. Ouvrez-le, puis répétez les étapes qui provoquent le bug.

• Cherchez les lignes en rouge ou avec un statut 400 ou supérieur.
• Cliquez sur une ligne en échec pour voir sa Réponse. Une erreur serveur contient souvent un message plus utile que tout ce qui s'affiche à l'écran.
• Notez l'URL de la requête et le code de statut — « le POST vers /api/bookings a renvoyé 500 » est une phrase très utile à donner à l'IA.

Cochez Conserver le journal si le bug implique un rechargement ou une redirection de page, pour que les requêtes ne disparaissent pas.

Éléments

L'onglet Éléments (ou Inspecteur) montre la structure et les styles de la page. Il est surtout utile pour les bugs de mise en page : survolez un élément pour voir sa taille et ses espacements en surbrillance. Vous n'avez rien à modifier ici ; il suffit de dire « le pied de page fait 2 000 pixels de large sur mobile et pousse la page sur le côté ».

Étape 4 : consulter les journaux du serveur

Certains bugs se produisent côté serveur, où le navigateur ne peut pas les voir. Une erreur 500 dans l'onglet réseau en est le signe classique. Les journaux du serveur — la sortie texte de votre backend pendant son exécution — contiennent généralement la vraie erreur avec une trace d'appel (la liste des fonctions en cours d'exécution au moment de l'échec).

Leur emplacement dépend de votre outil. Dans la plupart des constructeurs d'applications IA, vous pouvez ouvrir un terminal ou une vue des journaux pour le projet, ou simplement demander à l'IA : « Vérifie les journaux du serveur pour les erreurs de la dernière requête et dis-moi ce qui a échoué. »

Étape 5 : décrire le bug à l'IA

Mettez en forme ce que vous avez rassemblé ainsi :

Sur la page Réservations, connecté en tant que membre : j'ai cliqué sur Annuler pour le cours de 9 h de demain. Attendu : la réservation disparaît et le cours affiche une place libre de plus. Réel : rien ne change à l'écran. La console affiche TypeError: Cannot read properties of undefined (reading 'id') à BookingCard.tsx:31, et l'onglet réseau montre que DELETE /api/bookings/123 a renvoyé 500. Trouve la cause, corrige-la, et vérifie que l'annulation fonctionne pour un membre avec une seule réservation et pour un membre avec plusieurs réservations.

Pourquoi chaque élément compte :

• Où et en tant que qui réduit le problème à un écran et à un rôle.
• Les étapes exactes permettent à l'IA de reproduire le bug.
• Attendu contre réel définit ce que signifie « corrigé ».
• Le texte de l'erreur et la requête en échec pointent directement vers la cause.
• « Vérifie que… » demande à l'IA de contrôler, pas seulement de modifier.

Si l'IA a tenté deux corrections sans succès, demandez-lui d'expliquer avant de modifier quoi que ce soit :

Ne modifie pas le code pour l'instant. Quelle cause supposes-tu, et quels éléments la soutiennent ?

Une mauvaise hypothèse se repère facilement une fois écrite, et elle est beaucoup moins coûteuse à corriger qu'une mauvaise correction.

Étape 6 : vérifier, puis contrôler les alentours

Lorsque l'IA affirme que c'est corrigé, refaites les étapes exactes de l'étape 1. Vérifiez ensuite ce qui se trouve autour :

• La même action pour un autre rôle d'utilisateur
• La même action sans données, puis avec beaucoup de données
• Les pages qui partagent des composants avec celle que vous avez corrigée
• Un écran de la largeur d'un téléphone, si la correction touchait à la mise en page

Les modifications de l'IA corrigent parfois un chemin et en cassent discrètement un autre. Deux minutes de contrôle maintenant vous évitent une heure de confusion plus tard.

Étape 7 : revenir en arrière plutôt qu'empiler

Si une correction a empiré les choses, ou si vous en êtes à trois tours sans progrès, revenez en arrière. Revenir à la dernière version qui fonctionnait et reformuler avec de meilleures preuves bat presque toujours la demande d'une quatrième correction par-dessus trois erreurs. Chaque tentative échouée laisse du code derrière elle, et ce code embrouille la tentative suivante.

Quelques bonnes habitudes qui facilitent le retour en arrière :

• Testez après chaque modification, pour savoir quel changement a tout cassé.
• Gardez des modifications petites — une fonctionnalité ou une correction par message.
• Notez la dernière bonne version avant de tenter quelque chose de risqué.
• Si le code est dans Git, enregistrez des versions fonctionnelles en commit pour pouvoir y revenir.

Schémas de bugs courants dans les applications créées avec l'IA

Quand le problème n'est pas un bug

Certains « bugs » sont simplement l'IA qui construit exactement ce qu'on lui a demandé, et la description était ambiguë. Si la correction que vous demandez est en réalité un changement de comportement, dites-le clairement : « Change-le pour que… ». Si vous ne savez pas exactement quel est le comportement correct, décidez-le d'abord. Notre guide sur la rédaction de prompts pour les constructeurs d'applications IA explique comment formuler des règles avec précision. Et si vous préparez une application pour de vrais utilisateurs, faire passer un prototype IA en production présente les vérifications à faire avant le lancement.

Déboguer dans Mythex

Mythex propose des outils pour chaque étape de la boucle :

• Aperçu pour reproduire le bug, y compris dans un cadre de la taille d'un téléphone.
• /test demande à l'agent de parcourir votre aperçu en direct comme un utilisateur et de signaler les parcours cassés.
• /fix dirige l'agent vers les dysfonctionnements précis.
• Le mode Plan permet à l'agent d'enquêter et d'expliquer avant de modifier quoi que ce soit.
• Code → terminal affiche les journaux du serveur de votre application.
• Revenir à ce point sur n'importe quelle réponse ramène le projet à ce point de sauvegarde.

Si une publication échoue, la fenêtre de publication propose généralement Corriger avec l'IA, qui lit la sortie de build ou les journaux de l'application. Voir Déboguer votre application et Dépannage de la publication dans la documentation.

Questions