Comment déboguer une application créée par IA : une méthode pratique

Pour déboguer une application créée avec l'IA, commencez par reproduire volontairement le bogue, puis rassemblez des preuves — les étapes exactes, le message d'erreur, et ce que la console et l'onglet réseau du navigateur affichent — et donnez le tout à 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 fonctionnelle au lieu d'empiler les correctifs. Vous n'avez pas besoin de lire le code pour bien faire tout cela.

Ce guide couvre la boucle complète, y compris un bref tour d'horizon des outils de développement du navigateur pour les non-développeurs.

La boucle de débogage

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

1. Reproduire — faire survenir le bogue de façon fiable.
2. Observer — recueillir le message d'erreur et ce que l'application faisait.
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 — répéter les étapes exactes et confirmer que c'est corrigé, et que rien à côté ne s'est cassé.
6. Revenir en arrière au besoin — si la situation a empiré, annulez et réessayez avec de meilleures informations.

La majeure partie du temps perdu sur les applications créées par IA vient du fait d'ignorer les étapes 1, 2 et 5 : dire « c'est cassé », accepter une modification sans la tester, puis demander une autre correction par-dessus une version brisée.

Étape 1 : Reproduire le bogue

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

Demandez-vous :

• Est-ce que cela se produit à chaque fois ? Si ce n'est que parfois, qu'est-ce qui change lorsque cela survient — un enregistrement particulier, une connexion lente, une session fermée ?
• Est-ce que cela touche tous les utilisateurs ? Connectez-vous avec un autre compte. Beaucoup de bogues n'apparaissent que pour les nouveaux utilisateurs sans données, ou pour un utilisateur ayant un autre rôle.
• Est-ce que cela se produit 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 tout fonctionnait hier, les dernières modifications sont les principales suspectes.

Notez les étapes sous forme de liste numérotée courte. Vous la collerez dans votre requête plus tard.

Étape 2 : Lire le message d'erreur

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

Vous n'avez pas besoin de le comprendre ; vous devez le copier exactement. « Cannot read properties of undefined (reading 'name') » indique à l'IA que le code attendait une donnée (probablement une réservation ou un utilisateur) qui n'était pas là. Une paraphrase comme « une erreur undefined » fait perdre cette information.

Quelques erreurs courantes, traduites librement :

• Erreurs undefined / null — le code attendait une donnée qui n'est pas arrivée. 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 qui a été renommée.
• 401 Unauthorized / 403 Forbidden — la requête n'était pas connectée, ou l'utilisateur n'a pas le droit de faire cette action.
• 500 Internal Server Error — le code du serveur a planté. La vraie raison se trouve dans les journaux du serveur, et non dans le navigateur.
• Erreurs CORS — le navigateur a bloqué une requête vers un autre domaine. Il s'agit généralement d'un problème de configuration côté serveur.

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

Tous les navigateurs de bureau proposent 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 un 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 du code de la page. Les erreurs apparaissent en rouge. Si un bouton ne fait rien lorsque vous cliquez dessus, la console affiche très souvent une erreur rouge au moment du clic. Copiez le texte complet de l'erreur (un clic droit offre une 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 bogue.

• Cherchez les lignes en rouge ou avec un statut 400 ou plus.
• Cliquez sur une ligne en échec pour voir sa Réponse. Une erreur serveur contient souvent un message plus utile que tout ce qui est affiché à 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 bogue implique un rechargement de page ou une redirection, afin 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 bogues 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 vers le côté ».

Étape 4 : Consulter les journaux du serveur

Certains bogues surviennent sur le serveur, que le navigateur ne voit pas. 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 de pile (la liste des fonctions qui s'exécutaient au moment de l'échec).

L'emplacement dépend de votre outil. Dans la plupart des outils de création d'applications par 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 survenues lors de la dernière requête et dis-moi ce qui a échoué. »

Étape 5 : Décrire le bogue à l'IA

Mettez ce que vous avez recueilli dans cette forme :

Sur la page Réservations, connecté comme 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, puis vérifie que l'annulation fonctionne pour un membre ayant une seule réservation et pour un membre en ayant plusieurs.

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 bogue.
• Attendu contre réel définit ce que signifie « corrigé ».
• Le texte de l'erreur et la requête en échec indiquent directement la cause.
• « Vérifie que… » demande à l'IA de contrôler, pas seulement de modifier.

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

Ne modifie pas encore le code. Que penses-tu être la cause de ce problème, et quelles preuves appuient ton hypothèse ?

Une mauvaise hypothèse est facile à repérer une fois écrite, et bien 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é, répétez 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 brisent discrètement un autre. Une vérification de deux minutes maintenant vous évite une heure de confusion plus tard.

Étape 7 : Revenir en arrière plutôt que d'empiler

Si une correction a aggravé les choses, ou si vous en êtes à trois essais sans progrès, revenez en arrière. Revenir à la dernière version fonctionnelle et reformuler avec de meilleures preuves l'emporte presque toujours sur une quatrième correction par-dessus trois mauvaises. Chaque tentative ratée laisse du code derrière elle, et ce code embrouille la tentative suivante.

Bonnes habitudes qui facilitent le retour en arrière :

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

Schémas de bogues courants dans les applications créées par IA

Quand le problème n'est pas un bogue

Certains « bogues » 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 : « Modifie pour que… ». Si vous ne savez pas quel est le comportement correct, décidez-en d'abord. Notre guide sur la rédaction de requêtes pour les outils de création d'applications par IA explique comment préciser les règles clairement. 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 bogue, y compris un cadre à 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 brisés.
• /fix dirige l'agent précisément vers les bris.
• 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 contrôle.

Si une publication échoue, la boîte de dialogue de publication propose généralement Corriger avec l'IA, qui lit la sortie de la compilation ou les journaux de l'application. Voir Déboguer votre application et Dépannage de la publication dans la documentation.

Questions