.4UVmK5aw_1uGpNi.svg){kind=small}
.AzQB9McO_PVSYK.svg){kind=small}
.DjhlE8MO_Z1DYVxU.svg){kind=small}
.DM2pllEO_1cxFXE.svg){kind=small}
.CvN5042A_Z10D5qc.svg){kind=small}
.Dcqs_gC__NRL3p.svg){kind=small}
TimeoutError: waiting for selector à l'étape 14 sur 20
Les sessions sont gratuites : ne payez que le trafic
Navigateur cloud avec mode UI
Ouvrez cette session précise dans un véritable onglet de navigateur et regardez simplement. Quel que soit l'état de la page au moment où tout a dérapé, c'est ce que vous voyez.
- Ouvrez une vue en direct d'une session en cours au lieu de relancer la tâche pour reproduire l'échec
- Confiez un CAPTCHA difficile ou une demande 2FA inattendue à une personne, puis laissez le script se reconnecter
- Les cookies et l'état de la page restent intacts : seule la connexion change
Mode interface
Ouvrez la session
dans un vrai navigateur.
Toute session en cours peut être ouverte dans une vue en direct : le même navigateur que celui piloté par le script, dans un onglet à vous. Franchissez à la main ce qu'il ne peut pas passer, puis rendez-lui la main.
Pourquoi le mode UI compte dans un navigateur cloud
Quand un script headless plante en cours de route, vous n'obtenez généralement qu'une trace d'appels. Avec un peu de chance, un numéro de ligne. Bonne chance pour deviner quel clic a réellement échoué à l'étape quatorze sur vingt, ou même si la page s'est chargée comme prévu.
Le navigateur cloud avec mode UI vous offre une seconde option : ouvrir cette session précise dans un véritable onglet de navigateur et regarder simplement. Quel que soit l'état de la page au moment où tout a dérapé, c'est ce que vous voyez – inutile de reconstituer la scène a posteriori à partir de la sortie console, ni de relancer toute la tâche cinq fois en espérant un message d'erreur plus clair.
Cela compte surtout pour les connexions avec étapes supplémentaires, les formulaires qui changent selon les réponses précédentes et les tunnels de paiement. Bref, partout où une popup imprévue peut discrètement casser un script qui fonctionnait très bien une heure plus tôt, sans que personne ait écrit de règle pour cette popup précise, faute de l'avoir anticipée.
Principales fonctionnalités du mode visuel
La vue en direct remplit plusieurs rôles selon la raison pour laquelle vous en avez besoin. Parfois il s'agit de repérer un bug, parfois de le contourner.
Débogage de script en temps réel (débogage en direct)
Une exécution bloquée ou en échec ne signifie généralement pas que la session est morte. Elle est souvent toujours là, simplement déconnectée de tout. Ouvrez une vue en direct et vous la voyez telle quelle, en plein échec, au lieu de deviner à partir d'un fichier journal à quoi la page ressemblait probablement à ce moment-là.
Cela permet aussi de repérer des problèmes qui ne génèrent jamais d'erreur nette – une page à moitié chargée, un décalage de mise en page qui a déplacé un bouton juste avant le clic, une fenêtre modale apparue une demi-seconde trop tard.
Contrôle interactif de la session (intervention humaine)
Certaines choses, un script ne peut tout simplement pas les franchir seul – un CAPTCHA difficile, une demande 2FA inattendue, un contrôle de sécurité que personne n'avait prévu. Dans ce cas, la connexion d'automatisation est coupée, une vue en direct s'ouvre pour la même session, et quelqu'un passe à la main l'étape pénible.
Ensuite, le script se reconnecte et poursuit à partir de là. Les cookies, l'état de la page, tout reste en place – seule la connexion a changé. C'est tout aussi important pour les sessions exécutées via une configuration anti-détection : un navigateur anti-détection doté d'une empreinte par ailleurs convaincante et indétectable peut quand même tomber sur un contrôle que seule une vraie personne peut valider.
Enregistrement de session et captures d'écran
Suivre une session en direct n'est utile que si vous êtes là au bon moment. La plupart des débogages finissent par exiger quelque chose à examiner après coup – une capture d'écran du moment où tout s'est cassé, un enregistrement complet de la session, un journal réseau pour vérifier ce qui a réellement été envoyé et reçu.
Toutes les plateformes de navigateur cloud ne proposent pas ces trois options de la même manière : mieux vaut donc vérifier directement auprès de Floppydata ce qui est pris en charge avant de construire un workflow autour d'un format précis. Une capture d'écran juste avant l'échec suffit souvent à elle seule ; la vidéo et les journaux réseau montrent leur utilité dans les cas plus difficiles, où rien de visuel n'explique ce qui s'est mal passé.
Dans quels cas on s'en sert vraiment
Quelques situations reviennent sans cesse, et elles ne se ressemblent pas toujours en apparence :
-
Parcours d'inscription et contrôles antifraude au paiement
Parcours d'inscription avec vérification par SMS, ou pages de paiement qui déclenchent parfois un contrôle antifraude – pénibles à contourner par script, mais rapides à valider à la main.
-
Distinguer un vrai bug d'un sélecteur instable
Des équipes QA vérifient si l'échec d'un test de bout en bout est un vrai bug ou simplement un sélecteur instable, au lieu de relancer toute la suite à l'aveugle.
-
Reproduire ce qu'un client a décrit
Des équipes de support reproduisent un bug qu'un client a décrit sans parvenir à en faire une capture d'écran correcte.
-
Vérifier que la page s'affiche comme prévu
Des tâches de scraping vérifient qu'une page s'est bien affichée comme un sélecteur l'attend, avant de conclure que le sélecteur lui-même est défaillant.
-
Montrer le fonctionnement en direct
Démos client, où montrer quelque chose qui fonctionne en direct vaut mieux que demander à quelqu'un de se fier à un journal de terminal.
Comment activer l'interface / la vue en direct dans votre script
Une session ne peut pas maintenir à la fois une connexion d'automatisation et une vue en direct. Fermer l'une ouvre la voie à l'autre, et revenir en arrière prend à peu près autant de temps que le passage initial :
- Le script se déconnecte de sa session actuelle.
- Une vue en direct est demandée pour cette même session et ouverte dans un onglet du navigateur.
- Une personne s'occupe de ce qui doit l'être – un CAPTCHA, un code 2FA, un écran de consentement ponctuel.
- Le script demande une nouvelle connexion à la session et reprend exactement là où il s'était arrêté.
live-view.js
await browser.close(); // hand off to a human// POST /v2/browser/sessions/{id}/live-view -> { liveViewUrl }// person opens liveViewUrl, solves the CAPTCHA / 2FA prompt// GET /v2/browser/sessions/{id} -> fresh connectUrl, script resumesconnectUrl et liveViewUrl doivent être traités comme des mots de passe : ne les enregistrez dans aucun journal, ne les collez pas dans un ticket de support, et demandez-en un nouveau plutôt que de conserver un ancien lien plus longtemps que nécessaire.