Décrire précisément le problème
Quel que soit l’auteur du code, il faut le vérifier dans ses conditions réelles d’exécution. L’IA peut aider au diagnostic si elle dispose de symptômes suffisamment précis.
Par exemple, en local, quantité 10, prix unitaire 12 et livraison 8 donnent 128 ; en ligne, le bouton de calcul n’affiche aucun résultat. Notez l’adresse, le navigateur, les étapes, l’heure et le message de la page. Conservez la version actuelle. Retirez clés secrètes et données personnelles des captures d’erreur et des journaux.
Étape 1 : refaire exactement le parcours
Vérifiez si le problème se reproduit. Ouvrez une nouvelle fenêtre du navigateur avec les mêmes entrées. S’il faut un compte, notez le rôle du compte de test, sans publier ses identifiants de connexion.
Repérez le premier écart : page inaccessible, bouton sans effet, requête en échec ou requête réussie avec un mauvais résultat ? Chacun conduit à des vérifications différentes.
Étape 2 : réduire le champ selon le symptôme
| Symptôme | À examiner en premier |
|---|---|
| L’accueil s’ouvre, mais actualiser une autre adresse échoue | Routage des pages et configuration de l’hébergement |
| La page s’affiche, mais le clic ne donne aucun résultat | Erreurs du navigateur, état des requêtes et action du bouton |
| La requête réussit en local et échoue en ligne | Adresse de l’API de production, configuration et conditions d’accès |
| Les données disparaissent à la réouverture après sauvegarde | Écriture effective et configuration du stockage de production |
| Plusieurs comptes voient les mêmes données | Identité authentifiée sur le serveur et périmètre des requêtes |
Ce sont des pistes de diagnostic, à confirmer par des observations. La console et l’onglet réseau du navigateur montrent les erreurs de page et l’état des requêtes. Avec un serveur, consultez aussi les journaux à l’heure correspondante.
Étape 3 : comparer local et production
Demandez à l’IA de lister dépendances, commandes de démarrage, noms des paramètres, API et sources de données du projet. Comparez avec l’environnement de production. Vérifiez seulement présence et format des paramètres ; ne collez pas de clé secrète dans la conversation.
Regardez aussi les dernières modifications. Traitez une cause étayée à la fois et gardez une trace du changement. Si le service en ligne est perturbé, vous pouvez restaurer une version dont le fonctionnement est connu et poursuivre sur une copie. Avant de modifier les données, vérifiez sauvegarde et méthode de restauration.
Étape 4 : revenir aux entrées de départ
La disparition du message d’erreur ne suffit pas. Rejouez le parcours initial et comparez résultat réel et résultat attendu. Essayez ensuite une entrée voisine, une actualisation, les messages d’échec et les fonctions liées. Avec des comptes, vérifiez séparément chaque rôle.
Si les données d’un autre compte étaient accessibles, examinez tous les points de lecture concernés. Notre exemple fictif d’apprentissage explique comment concevoir ces essais ; il ne présente pas un système de production ayant passé des tests réels.
Garder une note de dépannage
Notez symptôme, cause confirmée, modification, résultats des nouveaux essais et questions restantes. Cette trace servira lors d’une mise à jour, d’une migration ou d’un ajout. Pour la publication complète, utilisez la liste de vérification.
Questions fréquentes
Pourquoi cela marche-t-il en local et pas en ligne ?
Peut-on donner l’erreur à l’IA et lui demander de tout réécrire ?
Que faire si un autre compte voit les données de quelqu’un ?
À lire ensuite
- De l’idée à un outil utilisable — Relier exécution, vérification et versions
- Vérifier avant la mise en ligne — Compléter les points applicables
- Une fiche client fictive — Relier identité et périmètre de lecture
