WebDriver vs CDP : les capacités de chaque connexion

Le choix WebDriver ou CDP devient concret lorsqu’un test exige une commande ou un événement précis. BotBrowser fournit des intégrations documentées d’automatisation, mais il ne garantit pas la disponibilité des opérations absentes de la bibliothèque ni le choix du mode de connexion.

TL;DR

WebDriver, WebDriver BiDi et Chrome DevTools Protocol (CDP) définissent des contrats de protocole distincts. Choisissez selon l’opération nécessaire, puis vérifiez sa prise en charge par le navigateur, le pilote, la bibliothèque et le mode de connexion. Selenium peut exposer WebDriver classique, BiDi et CDP : le nom de la bibliothèque ne désigne pas le protocole actif.

Sommaire

• Une bibliothèque n’est pas un protocole
• Carte des capacités
• Choisir selon l’opération
• Vérifier la connexion réellement utilisée
• Le cœur du navigateur reste en dessous
• Conclusion pratique

Une bibliothèque n’est pas un protocole

L’expression « WebDriver vs CDP » évoque un choix binaire, mais réunit plusieurs décisions. WebDriver est une norme du W3C qui contrôle un agent utilisateur par une extrémité distante. WebDriver BiDi est un protocole W3C distinct pour les commandes et événements bidirectionnels. CDP est le protocole DevTools de Chromium, avec des domaines pour le navigateur et JavaScript. La bibliothèque constitue encore une autre couche : elle peut exposer un ou plusieurs protocoles, ou une connexion propre au framework.

La question utile n’est pas « lequel voit le plus de choses ? », mais « quelle connexion prise en charge expose l’opération requise, avec le comportement et la portabilité nécessaires ? ». Un test qui clique sur un bouton puis attend un titre peut se contenter de commandes WebDriver standard. Un test qui collecte des événements réseau peut avoir besoin de BiDi ou d’un chemin CDP propre au navigateur. Ces deux constats ne rendent aucune option supérieure dans tous les cas.

Selenium documente l’API WebDriver classique, les API BiDi et des exemples CDP. Sa page consacrée à CDP qualifie cette prise en charge de temporaire jusqu’à l’implémentation de WebDriver BiDi. Playwright propose sa connexion native et une connexion CDP pour Chromium, décrite comme moins fidèle. « J’utilise Selenium » ou « J’utilise Playwright » ne suffit donc pas à identifier le protocole. Le cycle des événements WebDriver BiDi traite des abonnements après ce choix ; l’inventaire de migration depuis Selenium traite du changement de framework.

Carte des capacités

Le tableau décrit les familles d’opérations définies par les protocoles. Il ne garantit pas que chaque navigateur ou client les implémente toutes. Un schéma peut définir une commande ou un événement sans que la combinaison de versions retenue le prenne en charge.

Tâche	WebDriver classique	WebDriver BiDi	CDP	Vérification nécessaire
Trouver des éléments, cliquer, saisir, naviguer	Commandes standard pour éléments et contextes de navigation	Des commandes de contexte existent ; le client peut ne pas toutes les exposer	Contrôles Chromium dans les domaines Page et DOM	Sémantique des sélecteurs, contexte et commandes du client
Lire la console	Ce n’est pas le flux central de requêtes/réponses classique	Le module log définit des événements	Les domaines Runtime et Log exposent des événements de console	Événement activé, contexte et conservation des arguments
Observer le réseau	Pas de flux universel d’événements WebDriver classique	Le module network définit des événements de requêtes et réponses	Network.enable active le suivi et ses événements	Couverture, corps conservés, masquage et prise en charge du pilote
Évaluer du JavaScript	Les commandes incluent l’exécution de scripts	Commandes de script visant des realms et contextes	Runtime.evaluate évalue une expression sur l’objet global	Realm, permissions, CSP et sérialisation des valeurs
Modifier le user-agent ou les dimensions	Capacités et options propres au navigateur, sans modification dynamique universelle	Aucune promesse d’équivalence entre toutes les modifications propres aux navigateurs	Network.setUserAgentOverride et modification des dimensions dans le domaine d’émulation	Cohérence des métadonnées et différences restantes
Modifier une permission	Peut dépendre d’une capacité ou d’une API propre au navigateur	Dépend des commandes et de leur implémentation	Browser.setPermission existe et est expérimental	Nom de permission, origine, contexte et statut expérimental

Cette carte indique où chercher, sans attribuer de score. WebDriver classique fournit une interface standardisée destinée à plusieurs implémentations. BiDi ajoute un modèle bidirectionnel défini par une spécification. CDP expose des domaines orientés Chromium, utiles pour certains diagnostics et contrôles. Un raccourci dans une bibliothèque ne transforme pas ces opérations en garanties inter-navigateurs.

La stabilité varie aussi selon la commande. Une opération peut être expérimentale, facultative, absente d’un navigateur ou exposée autrement par un ancien pilote. La création réussie d’une session ne prouve pas que toutes les opérations suivantes fonctionnent. Le contrôle de permission du tableau est explicitement expérimental. Pour le réseau CDP, il faut activer le domaine avant d’attendre ses événements.

Choisir selon l’opération

Commencez par un inventaire d’opérations, plutôt que par une préférence de protocole. Notez la preuve nécessaire au test, pas seulement la méthode disponible dans sa bibliothèque actuelle.

« Il faut plus de visibilité » ne permet pas de choisir. Nommez le relevé manquant : entrée de console, statut de réponse, état de permission, dimension de fenêtre ou assertion visible. Définissez ensuite la condition minimale qui prouvera sa réception. Cela évite d’adopter une couche inférieure uniquement parce que sa liste de domaines est plus longue. Une interface étendue n’aide que si la commande existe dans l’environnement réel et répond à la question du test.

Besoin	Première voie à évaluer	Réserve
Navigation et interactions portables	WebDriver classique ou connexion native documentée du framework	Vérifier navigateurs et sémantique des commandes
Recevoir des événements pendant l’exécution de commandes	WebDriver BiDi	Vérifier module, portée de l’abonnement et pilote
Détails réseau Chromium ou émulation spécifique	CDP	Figer Chromium et le client ; conserver cette dépendance explicite
Faire évoluer une suite Selenium sans changer de framework	Garder WebDriver, ajouter BiDi ou CDP pour une lacune précise	Le protocole peut modifier les événements et les artefacts de diagnostic
Exécuter la suite sur plusieurs moteurs	Préférer les voies standard si elles répondent au besoin	Un point CDP Chromium n’établit pas la parité avec Firefox ou WebKit

Prenez un test qui doit vérifier une page de confirmation et conserver le statut d’une requête en échec. L’assertion visible appartient au parcours de la page. L’événement réseau aide au diagnostic, mais une réponse observée ne prouve pas l’affichage du succès. BiDi ou CDP complètent donc l’assertion sémantique au lieu de la remplacer. Si seul Chromium est visé, CDP peut offrir une opération encore absente de l’API BiDi du pilote retenu ; consignez cette dépendance plutôt que de qualifier la suite de neutre vis-à-vis du protocole.

L’évaluation JavaScript demande la même séparation. WebDriver exécute des scripts, BiDi définit des realms et des opérations d’évaluation, CDP fournit Runtime.evaluate. Ces accès n’impliquent pas une sélection de realm, une sérialisation ou des erreurs identiques. Si une assertion dépend d’une variable globale, identifiez son contexte et vérifiez comment le client retourne sa valeur.

Consignez si le script s’exécute dans le document principal, une frame enfant ou un monde isolé. Une expression correcte dans la mauvaise frame peut produire une valeur plausible mais sans rapport avec l’assertion. Distinguez exception de page, panne de transport et problème de sérialisation du client. Une navigation entre l’envoi du script et sa réponse change les conditions de l’observation. Liez le résultat à un identifiant de contexte ou de realm lorsque le protocole l’expose, puis signalez clairement sa disparition.

« Pouvoir modifier » ne signifie pas « rendre équivalent ». Une modification des dimensions ne reproduit ni la pile graphique du matériel, ni les polices, ni les périphériques d’entrée, ni toutes les fonctions multimédias. Une modification du user-agent n’aligne pas automatiquement les client hints ou toutes les valeurs du document. Décrivez les champs concernés et les différences qui restent hors de l’opération.

Une matrice doit aussi porter le coût de portabilité. Si le test vise uniquement Chromium, une dépendance CDP peut être un choix explicite et raisonnable. Pour plusieurs moteurs, vérifiez d’abord si WebDriver ou BiDi suffisent. Ne doublez pas un test avec deux protocoles sauf si cette seconde observation peut détecter une régression réelle ; sinon la suite gagne de la maintenance sans gagner de preuve.

Quand une opération n’a pas de voie équivalente ailleurs, marquez la cellule comme non prise en charge ou non vérifiée. Ne changez pas silencieusement la signification du test. Une solution de repli peut être valable si elle observe le même résultat utilisateur, mais un champ au nom similaire ne prouve pas l’équivalence. Un événement de console et une bannière d’erreur visible sont deux preuves différentes. Conservez ensemble le résultat, la collecte et la règle de repli.

Vérifier la connexion réellement utilisée

Avant d’ajouter une opération propre au protocole, consignez quatre faits : navigateur et version, pilote ou extrémité distante, bibliothèque cliente et version, méthode de connexion. « Selenium avec Chrome » est insuffisant. « Selenium 4, Chrome figé, ChromeDriver local, connexion BiDi pour network.responseCompleted » est vérifiable. Avec CDP, précisez aussi si la bibliothèque lance le navigateur ou rejoint un processus existant.

Gardez cette fiche près de la configuration du test. Une mise à jour du paquet peut changer le point de connexion ou ses valeurs par défaut sans changer le code du scénario. En CI, affichez la version effective du navigateur et le mode de connexion dès la création de session. Si un service distant fournit le navigateur, conservez ses capacités annoncées et les options acceptées. Une option demandée ne prouve pas qu’elle a été appliquée : la réponse de session ou une observation doit le confirmer.

Effectuez une petite vérification avant le parcours complet :

1. Créer une session neuve avec le chemin de lancement exact de la CI.
2. Envoyer la plus petite commande ou souscription nécessaire.
3. Conserver les capacités négociées, le résultat et toute erreur d’opération non prise en charge.
4. Déclencher une requête ou un message dans une fixture maîtrisée, puis vérifier l’événement et son contexte.
5. Fermer la session et vérifier le nettoyage des abonnements, processus et données de la fixture.

La page du protocole ne suffit pas. Elle prouve que le schéma publié définit une méthode ou un événement. Le navigateur, le pilote, le service et le client déterminent sa disponibilité effective. Figez une version du schéma lorsque la répétabilité importe ; le visualiseur CDP « tot » et les fichiers master évoluent.

Une fiche sépare la sortie de la conclusion qu’elle soutient :

browser=Chrome <pinned version>
client=Selenium <pinned version>
connection=WebDriver BiDi
operation=subscribe to network.responseCompleted
result=subscription acknowledged; one fixture response observed
scope=owned local fixture, one browsing context
not established=all browsers support this event identically

Remplacez les champs provisoires par l’environnement réel avant d’utiliser cette fiche comme preuve. Un abonnement rejeté indique la prise en charge de cette combinaison, pas l’absence de la fonction dans BiDi. Si l’événement arrive mais que l’assertion de page échoue, gardez les deux résultats séparés. Une trace de protocole explique un test ; elle ne décide pas du succès du parcours produit.

Recommencez après avoir changé un composant à la fois. Gardez le navigateur fixe pour changer client ou pilote ; restaurez le client avant de changer le navigateur. Cela aide à attribuer l’évolution du support. Changer simultanément de service distant modifie potentiellement le binaire, le réseau, le propriétaire de session et la passerelle du protocole. Un journal de changements borné apporte davantage qu’un « fonctionne chez moi ».

Pour les tests par événements, limitez l’abonnement aux types et contextes nécessaires, bornez le nombre de relevés et retirez les écouteurs à la fermeture. Les traces réseau ou console peuvent contenir des URL, en-têtes, textes de page ou données personnelles. Le protocole n’est pas une politique de conservation. Masquez les valeurs sensibles avant de sauvegarder les artefacts et gardez seulement les métadonnées nécessaires à la corrélation.

Pour une commande, consignez son nom ou identifiant, la catégorie de réponse et l’état de page suivant. Un accusé signifie que l’extrémité a accepté une commande, pas nécessairement que le résultat attendu est visible. Attendez une condition sémantique, comme l’apparition d’une confirmation. En cas de délai dépassé, distinguez l’absence de réponse du protocole de l’absence de résultat dans la page.

Le cœur du navigateur reste en dessous

Les protocoles exposent des opérations et observations ; ils ne définissent pas chaque valeur du moteur. Un script peut lire le DOM, un événement peut rapporter une requête, tandis que le rendu dépend encore des polices, du backend graphique, du système, du build et du profil. Modifier une valeur émulée ne modifie pas nécessairement toutes les surfaces associées. La couche protocole et le cœur du navigateur répondent à des questions différentes.

BotBrowser fournit des intégrations d’automatisation documentées, mais ne traduit pas WebDriver vers CDP, n’implémente pas un événement BiDi absent du client et ne garantit pas la parité des modes. La référence de cohérence d’automatisation décrit les limites du navigateur ; elle n’est pas une matrice de conformité des protocoles. Le navigateur cible peut rester constant pendant l’évaluation d’une connexion, mais le client et l’opération exacts doivent encore être vérifiés. En cas de différence, séparez commande demandée, support du protocole, adaptation du client et environnement du navigateur.

Une observation JavaScript ou une modification par commande ne prouve pas ce qu’un autre système déduira d’une session complète. Elle n’établit pas non plus la présence du même contrôle dans un autre moteur. Limitez la conclusion au navigateur, à la connexion, à l’opération et à la fixture consignés.

Le client peut ajouter des valeurs par défaut, le pilote traduire les appels, un service distant gérer la session et le moteur produire le document. Face à une valeur inattendue, posez les questions dans cet ordre : opération voulue envoyée, acceptation par l’extrémité, restitution correcte par le client, état de page attendu. Cela n’accuse pas une couche à l’avance ; cela empêche son nom de remplacer une preuve.

Si deux connexions renvoient la même valeur DOM, seule cette égalité a été observée dans cette exécution. L’ordre des événements, les erreurs, les délais et les opérations non prises en charge peuvent encore différer. Un besoin de parité exige une liste d’opérations et leurs résultats dans des conditions contrôlées. Pour un simple test fiable, choisissez le chemin compatible le plus limité et vérifiez le résultat utilisateur.

Questions fréquentes

CDP et WebDriver désignent-ils la même chose ?

Non. CDP est le protocole DevTools de Chromium. WebDriver est une norme W3C de contrôle du navigateur, et BiDi possède sa propre spécification. Une bibliothèque peut exposer plusieurs connexions : vérifiez le mode effectif plutôt que le nom du paquet.

Selenium utilise-t-il seulement WebDriver ?

Non. Son API principale est WebDriver, mais Selenium documente aussi BiDi et CDP. Sa documentation présente CDP comme temporaire pendant l’implémentation de BiDi. La disponibilité dépend toujours des versions du client, du navigateur et du pilote.

CDP convient-il mieux à toutes les tâches ?

Cette généralisation n’est pas justifiée. CDP fournit des commandes Chromium utiles à certains tests ; WebDriver et BiDi fournissent des contrats standardisés. Comparez la prise en charge de l’opération exacte et son coût de portabilité.

L’émulation rend-elle Chrome headless équivalent à un téléphone ?

Non. Elle modifie les valeurs spécifiées sans recréer chaque capteur, police, GPU, codec, périphérique ou comportement du système. Décrivez séparément les champs émulés et les conditions non reproduites.

Une commande présente dans le schéma suffit-elle ?

Non. Le schéma prouve qu’une opération est définie, pas qu’une version donnée du navigateur, pilote, service ou client la prend en charge. Vérifiez-la avec le même mode de connexion que la CI.

Sources

• WebDriver du W3C
• WebDriver BiDi du W3C
• Visualiseur Chrome DevTools Protocol
• Domaine CDP Network
• Domaine CDP Runtime
• Prise en charge CDP de Selenium
• connectOverCDP de Playwright
• Cohérence d’automatisation BotBrowser

Conclusion pratique

Partez de l’opération : nommez commande ou événement, confirmez navigateur, client et pilote, consignez versions et mode, puis gardez une assertion sur le résultat utilisateur. Utilisez WebDriver pour ses interactions standard, BiDi lorsque son contrat événementiel est pris en charge, CDP lorsqu’une opération Chromium justifie cette dépendance. Protocole, bibliothèque et environnement doivent rester trois entrées distinctes du relevé ; aucune ne dispense de vérifier les autres.