Analyse du navigateur avec REA : que se passe-t-il après Export ?

01. Démarrez une session de navigateur isolée

Ouvrez votre application locale dans un profil de débogage distinct. Cela permet d’identifier clairement la page choisie et les données de test. Remplacez l’URL finale par celle de votre application locale. Sous Windows ou Linux, utilisez l’exécutable Chrome correspondant.

L’adresse de débogage sert à contrôler le navigateur ; elle diffère de l’URL de votre application. Utilisez l’adresse de boucle locale explicite et l’identifiant de cible renvoyé par REA.

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/rea-export-profile \
  http://127.0.0.1:3000

02. Sélectionnez la bonne page

Listez les cibles, repérez l’URL de votre application et copiez son identifiant. Inspectez cette page avant de commencer. Si l’onglet est rechargé ou remplacé, listez de nouveau les cibles au lieu de réutiliser un ancien identifiant.

npx -y [email protected] list-browser-targets http://127.0.0.1:9222 --json
npx -y [email protected] inspect-web-page http://127.0.0.1:9222 TARGET_ID --observation-ms 1000 --json

03. Enregistrez une référence au repos, puis un export

Enregistrez d’abord une courte période d’inactivité pour repérer les requêtes périodiques en arrière-plan. Lancez ensuite une seconde observation et cliquez vous-même sur Export pendant la capture. L’observateur passif de REA ne clique pas à votre place.

Utilisez une entrée petite et reconnaissable, comme deux lignes avec un libellé de test unique. Notez si l’application affiche un indicateur de chargement, télécharge un fichier ou signale une erreur. Comparez les deux captures sans supposer que chaque nouvelle requête vient de l’export.

npx -y [email protected] observe-web-session http://127.0.0.1:9222 TARGET_ID --observation-ms 10000 --json > export-capture.json

• Une requête commence-t-elle après l’action ?
• Quels sont sa méthode, son URL et le statut indiqué ?
• Un initiateur ou un script chargé permet-il de la relier au bouton ?
• Le fichier téléchargé a-t-il réellement été créé et contient-il les lignes de test ?

04. Aucune requête ? Inspectez le chemin côté client

Certains exports créent un Blob en JavaScript et le téléchargent sans requête au serveur. Une liste de requêtes vide est donc un indice utile, pas une preuve d’échec de capture. Inspectez les scripts chargés et recherchez Blob, createObjectURL et l’attribut download dans la fonction concernée.

L’analyse du bundle fournit des candidats statiques. Une chaîne ressemblant à une adresse de service ne prouve pas qu’elle a été appelée. Consignez les requêtes observées et les résultats de lecture du code dans des colonnes distinctes.

npx -y [email protected] analyze-web-bundle http://127.0.0.1:9222 TARGET_ID --json

À partir de la page sélectionnée et de cette capture d’export, explique si Export demande un fichier généré par le serveur ou le construit dans le navigateur. Relie l’activité observée au code chargé pertinent. Indique les éléments manquants. Ne déduis pas le contenu des réponses à partir des seules métadonnées.

05. Recommencez avec une entrée délicate

Exportez une ligne contenant une virgule, un guillemet et un saut de ligne. Ouvrez le fichier obtenu avec un analyseur de ce format, pas seulement un éditeur de texte. Un téléchargement terminé sans erreur ne prouve pas que l’encodage est correct.

Livrez la chronologie de l’action, la requête retenue ou la fonction côté client, ainsi que les vérifications du fichier. Cette méthode est reproductible sur votre propre cible ; cet article ne contient pas de session capturée sur un service tiers.