Un clic sur « Enregistrer » fait apparaître deux lignes presque identiques dans le panneau réseau. Le serveur reçoit-il réellement la même opération deux fois ? Avant de corriger le formulaire, relevez ce que le navigateur a envoyé et l’action qui a déclenché chaque ligne. Un appel de préparation, une redirection ou un nouveau lancement du script peuvent donner des symptômes qui se ressemblent. La colonne Initiateur aide à distinguer ces cas.
Reproduire le problème avec une seule action
Ouvrez les outils de développement et allez dans Réseau. Effacez les lignes de la capture, puis réalisez une seule fois le geste qui déclenche le problème, avec des données de test. Si la page se recharge ou change d’adresse, activez la conservation du journal pour voir les événements avant et après la navigation. Gardez une capture propre, sans autres clics ni pages lancées pendant l’essai.
Comparez ensuite la méthode, l’adresse, le résultat et l’ordre des deux lignes. Un OPTIONS suivi d’un POST peut correspondre à une vérification préalable du navigateur pour un appel vers une autre origine. Une réponse de redirection peut aussi conduire à une seconde adresse. Deux lignes ne suffisent donc pas à établir un doublon. Cherchez d’abord deux opérations dont la méthode et l’effet attendu sont comparables. Notre article sur le diagnostic d’un parcours de paiement applique une démarche voisine : reproduire le geste exact et isoler le point où le comportement diverge.
Remonter au code qui a lancé la requête
Affichez la colonne Initiateur si elle n’est pas visible. Dans Chrome, la documentation des outils réseau indique qu’une requête déclenchée par JavaScript peut être reliée à sa pile d’appels. Examinez les deux lignes. Si elles renvoient à des fichiers ou fonctions différents, vous avez deux points de départ à comparer. Si elles partagent la même pile, regardez si la fonction a été appelée plusieurs fois ou si elle relance elle-même le traitement.
Pour un formulaire, vérifiez le lien entre l’événement de clic et l’événement de soumission. Une application peut installer un traitement sur le bouton et un autre sur le formulaire. À l’inverse, un seul traitement peut s’exécuter deux fois si un composant a inscrit un écouteur à chaque montage sans le retirer. Ces scénarios demandent des corrections différentes. Regardez ce qui se passe lorsque le même formulaire est soumis avec la touche Entrée.
Comparer le navigateur et le serveur
Le panneau réseau permet de lire les requêtes du navigateur. Les journaux du serveur indiquent ce que l’application a traité. Sur un environnement de test, comparez les identifiants de requête ou les heures des événements. Une interface qui répète l’affichage d’un message ne signifie pas toujours que la base a reçu deux écritures. Inversement, une relance côté serveur peut produire deux effets alors qu’une seule ligne apparaît dans le navigateur.
Pour une action qui crée une commande ou envoie un message, vérifiez aussi la protection contre les répétitions côté serveur. Une désactivation temporaire du bouton limite certains doubles clics, mais un nouvel essai peut survenir après une coupure. Notre guide sur la reprise après une panne rappelle l’intérêt de vérifier l’état final après une interruption. Dans ce cas, examinez le nombre réel d’opérations enregistrées.
Valider sur les gestes que les visiteurs utilisent
Après la correction, rejouez un clic simple, une soumission au clavier et un essai sur une connexion ralentie. Comparez les lignes réseau, le résultat à l’écran et les traces du serveur. Si le changement empêche un doublon tout en laissant l’utilisateur reprendre après un échec, le contrôle couvre les deux comportements utiles. Consignez l’adresse testée et le résultat attendu pour qu’un collègue puisse refaire le diagnostic si le problème revient.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
