Évaluer un navigateur pour équipes : liste de contrôle pratique

Définir la décision avant d’ouvrir une page de tarifs

Une évaluation utile commence par le travail, non par la liste des fournisseurs. Consignez :

• les flux autorisés et les systèmes qui les permettent ;
• le nombre de personnes, de profils enregistrés, de profils synchronisés et de sessions simultanées du navigateur ;
• les systèmes d’exploitation et architectures de processeur pris en charge ;
• les moteurs de navigateur, extensions, proxys, fournisseurs d’identité et clients d’automatisation requis ;
• les obligations de résidence, de conservation, d’export, de suppression et d’audit des données ;
• les attentes en matière de temps de récupération et de perte de données acceptable ;
• les besoins d’accessibilité des opérateurs et administrateurs ;
• le budget, la période de facturation, la couverture de l’assistance et les conditions de sortie ; et
• les flux interdits que le produit ne doit pas permettre à votre équipe.

Séparez les types de ressources. Un forfait comprenant 500 profils enregistrés, 100 profils synchronisés dans le cloud, cinq sièges et dix sessions simultanées ne fournit pas 500 sessions d’équipe simultanées. Traduisez chaque limite dans l’unité consommée par votre flux.

Identifiez ensuite les critères non négociables. Un ensemble courant comprend :

1. des versions de navigateur actuelles et prises en charge ;
2. aucune corruption silencieuse des profils ni écriture simultanée ;
3. des identités individuelles avec un accès révocable suivant le moindre privilège ;
4. aucun secret brut dans les journaux ou sorties ordinaires d’automatisation ;
5. des preuves d’audit utilisables ;
6. un chemin de restauration et de sortie testé ; et
7. un usage légal et autorisé, conforme aux conditions applicables des services.

Ne diluez pas un critère non satisfait dans une note moyenne. Une interface soignée ne compense ni un outil de mise à jour non vérifié ni une restauration qui perd l’état.

Utiliser une échelle de preuves simple

Pour chaque élément de la liste, consignez le résultat et la preuve la plus solide obtenue.

Résultat

• Réussi : l’exigence déclarée a été démontrée dans l’environnement de test défini.
• Préoccupation : le comportement contredit l’exigence ou crée un compromis important.
• Non vérifié : les preuves manquent, sont inaccessibles, obsolètes ou trop ambiguës pour décider.
• Sans objet : l’exigence ne s’applique réellement pas au flux, avec une justification consignée.

Preuve

1. Affirmation publiée : texte commercial ou marketing.
2. Documentation technique : documentation versionnée du produit, de sécurité, d’API ou d’assistance.
3. Démonstration observée : démonstration en direct par le fournisseur avec votre scénario.
4. Essai contrôlé : votre équipe reproduit le comportement avec des données jetables et consigne les versions et résultats.
5. Preuve indépendante ou contractuelle : évaluation délimitée, engagement signé ou condition d’assistance couvrant l’exigence.

Une preuve de niveau supérieur n’est pas automatiquement meilleure dans tous les cas. Un rapport indépendant peut exclure le navigateur de bureau, tandis qu’un essai contrôlé peut le tester directement. Consignez le périmètre, la date, la version et les limites de chaque artefact.

1. État du produit et limites des affirmations

• □ Existe-t-il une version réellement installable pour chaque plateforme et architecture nécessaires ?
• □ Le fournisseur peut-il identifier la version actuelle de l’application, la version du navigateur et la date de publication ?
• □ Les fonctions bêta, en aperçu, expérimentales et disponibles pour tous sont-elles identifiées séparément ?
• □ La documentation et l’essai réel concordent-ils sur les limites et le comportement ?
• □ Les affirmations de sécurité, de disponibilité, de chiffrement et de performances sont-elles délimitées à des composants et des preuves précis ?
• □ Les limites connues, les flux non pris en charge et les règles de fin de support sont-ils publiés ?
• □ Le fournisseur évite-t-il de garantir l’invisibilité, la survie d’un compte ou l’accès aux services tiers ?

Conservez le programme d’installation, l’écran de version, les notes de publication et la documentation pertinente à la date de l’évaluation. Une réponse commerciale sans référence stable reste une affirmation publiée, non un comportement vérifié.

2. Isolation et intégrité des profils

Définissez d’abord ce que le produit appelle un profil. Il peut s’agir d’un répertoire persistant de données du navigateur, d’un contexte temporaire, d’une archive synchronisée, d’une session distante ou d’un ensemble de paramètres. Ces éléments ne sont pas équivalents.

Chromium décrit le répertoire de données utilisateur comme l’emplacement des données et explique comment sélectionner un répertoire personnalisé. Sa documentation précise aussi que, dans certains cas, deux instances actives ne peuvent pas partager un répertoire. Utilisez la documentation en amont sur le répertoire de données utilisateur comme point de départ, puis exigez des preuves propres au produit.

• □ Chaque profil persistant a-t-il une limite de stockage et de processus clairement définie ?
• □ Le produit empêche-t-il deux processus d’écriture d’ouvrir le même état modifiable ?
• □ Les cookies, le stockage, le cache, l’historique, les extensions, les téléchargements, les autorisations et les préférences sont-ils isolés comme indiqué ?
• □ Les sessions temporaires et les profils persistants sont-ils nommés différemment ?
• □ Un lancement propre n’utilise-t-il que les données du profil prévu ?
• □ Un redémarrage conserve-t-il exactement l’état promis par le produit ?
• □ Les autorisations et sources d’installation des extensions sont-elles contrôlées ?
• □ Les imports de profils sont-ils traités comme des entrées non fiables et validés avant utilisation ?
• □ Un profil endommagé ou incompatible peut-il être mis en quarantaine sans écraser une copie connue comme valide ?

Les preuves d’essai doivent inclure des tests entre profils. Placez un marqueur inoffensif dans le profil A, confirmez son absence dans B, redémarrez les deux, puis recommencez après une mise à jour de l’application. Utilisez des comptes jetables et des données synthétiques.

3. Actualité du navigateur, bac à sable et mises à jour

Un navigateur est une dépendance de sécurité continuellement maintenue. La documentation actuelle des canaux de Chromium indique que le canal stable reçoit des mises à jour mineures chaque semaine et des versions majeures toutes les quatre semaines. Ce rythme de publication ne dicte pas le niveau de service précis d’un fournisseur, mais montre pourquoi « fondé sur Chromium » reste incomplet sans preuves de version et de mise à jour.

• □ La version du navigateur du produit peut-elle être reliée à une version exacte en amont ?
• □ Existe-t-il un objectif ou un historique publié d’adoption des mises à jour de sécurité en amont ?
• □ Qui surveille les publications en amont et les correctifs urgents ?
• □ Les mises à jour de l’application et du navigateur sont-elles signées et authentifiées indépendamment de la connexion de téléchargement ?
• □ Pouvez-vous vérifier les empreintes des artefacts, la provenance de publication ou une chaîne de conservation équivalente ?
• □ Les déploiements sont-ils progressifs, surveillés et interrompables ?
• □ Le retour arrière évite-t-il de restaurer une version dangereuse selon la politique de sécurité actuelle ?
• □ Les migrations de schéma des profils sont-elles testées sur les chemins de mise à niveau et de retour à une version antérieure pris en charge ?
• □ Le produit maintient-il le bac à sable du navigateur en fonctionnement normal ?
• □ Le fournisseur peut-il expliquer tout processus non isolé ou privilégié et sa nécessité ?

Chromium décrit son bac à sable comme une limite qui restreint le code non fiable et applique le moindre privilège au code isolé comme à son contrôleur. Examinez la conception du bac à sable de Chromium, puis demandez au fournisseur de montrer sa configuration de production réelle. L’affirmation qu’un produit « utilise Chromium » ne prouve pas que toutes les protections en amont restent activées.

Pour l’intégrité des mises à jour, The Update Framework constitue une référence utile, car il traite explicitement la compromission des dépôts et des clés de signature. La provenance SLSA définit des informations vérifiables sur le lieu, le moment et la manière dont un artefact a été produit. Un fournisseur n’a pas besoin d’utiliser ces projets précis, mais doit expliquer comment sa conception traite l’identité des artefacts, les clés compromises, le retour arrière, le gel et la provenance du build.

4. Identité, appareils et moindre privilège

La NIST SP 800-53 Rev. 5 organise les contrôles entre contrôle d’accès, audit, authentification, continuité, réponse aux incidents et risque de chaîne d’approvisionnement. Utilisez ces familles comme questions, sans traiter l’alignement sur un cadre comme preuve d’implémentation.

• □ Chaque personne reçoit-elle une identité individuelle au lieu d’une connexion d’équipe partagée ?
• □ L’authentification multifacteur est-elle disponible et imposable aux administrateurs et autres rôles sensibles ?
• □ Des options d’authentification plus fortes et résistantes à l’hameçonnage sont-elles prises en charge lorsque le risque l’exige ?
• □ L’identité peut-elle être fédérée avec votre fournisseur, si nécessaire, sans contourner l’autorisation du produit ?
• □ Les rôles distinguent-ils suffisamment la consultation, le lancement, la modification, le partage, l’export, la suppression, la facturation et l’administration ?
• □ L’accès peut-il être limité à une organisation, un espace de travail, un dossier ou un ensemble explicite de profils ?
• □ Un appareil, une session, un utilisateur, un identifiant de service ou une invitation peuvent-ils être révoqués rapidement ?
• □ Les comptes de service ont-ils leur propre identité, date d’expiration, périmètre et limite de débit ?
• □ Les changements d’autorisations et les échecs d’autorisation apparaissent-ils dans la piste d’audit ?
• □ Le départ d’une personne supprime-t-il l’accès sans nécessiter de changer un mot de passe partagé ?

Pour la terminologie actuelle de l’authentification et les recommandations sur les niveaux de garantie, consultez la NIST SP 800-63B-4, finalisée le 31 juillet 2025. Confirmez les parties du produit couvertes par les affirmations du fournisseur : la connexion au site, le déverrouillage de l’application de bureau, l’API locale, l’API cloud, la récupération et l’accès de l’assistance peuvent utiliser des mécanismes différents.

5. Données sensibles et limites de confiance

Représentez le produit comme un flux de données. Indiquez le gestionnaire de bureau, les processus du navigateur, le service local, le plan de contrôle cloud, le stockage de synchronisation, l’outil de mise à jour, le rapporteur de plantages, les outils d’assistance et les intégrations tierces. Pour chaque limite, demandez ce qui la franchit et pourquoi.

• □ Quels contenus des profils restent locaux par défaut ?
• □ Quelles métadonnées et quels contenus sensibles sont téléversés lorsque la synchronisation est activée ?
• □ Où le chiffrement s’effectue-t-il et quelles parties peuvent obtenir les clés de déchiffrement ?
• □ Comment les clés locales sont-elles protégées, sauvegardées, renouvelées et récupérées ?
• □ Que peuvent lire les administrateurs de l’organisation, l’assistance du fournisseur, les opérateurs de l’infrastructure et les clients d’automatisation ?
• □ Les cookies, mots de passe, identifiants de proxy, secrets à deux facteurs et clés de chiffrement sont-ils exclus de l’interface, des journaux, de la télémétrie, des API et des sorties d’agents ordinaires ?
• □ Les rapports de plantage et diagnostics peuvent-ils être prévisualisés, expurgés, soumis au consentement et limités dans leur conservation ?
• □ L’assistance peut-elle intervenir sans demander d’archives brutes de profils ni d’identifiants ?
• □ Les extensions importées, archives, téléchargements du navigateur et métadonnées de mise à jour sont-ils traités comme des entrées non fiables ?
• □ La suppression est-elle définie pour les copies locales, les objets cloud, les sauvegardes, les journaux et les artefacts d’assistance ?

N’acceptez pas « chiffré » comme réponse complète. Consignez la catégorie de données, l’emplacement, la limite de chiffrement, le détenteur de la clé, le chemin de récupération et les situations dans lesquelles les données existent en clair.

6. Collaboration et auditabilité

• □ La propriété du profil reste-t-elle claire pendant l’attribution et le transfert ?
• □ Le produit peut-il empêcher ou résoudre visiblement les modifications simultanées ?
• □ Les invitations, changements de rôles, lancements, arrêts, partages, exports, suppressions, appels d’automatisation et actions de récupération sont-ils consignés ?
• □ Chaque événement identifie-t-il l’acteur humain, la charge de travail déléguée, la ressource, l’heure, la décision et le résultat ?
• □ Les valeurs avant et après sont-elles consignées pour les changements importants de configuration, avec les secrets expurgés ?
• □ Les horloges, fuseaux horaires, ordres d’événements et identifiants de requêtes sont-ils sans ambiguïté ?
• □ L’accès à l’audit, le format d’export, la conservation et les contrôles de suppression sont-ils documentés ?
• □ Un administrateur peut-il modifier ou effacer les enregistrements qui servent à examiner ses propres actions ?
• □ Votre équipe peut-elle exporter les journaux vers son système de surveillance ou d’enquête ?
• □ La journalisation continue-t-elle, utilise-t-elle un tampon sûr ou échoue-t-elle en mode fermé lorsque la destination d’audit est indisponible ?

Les recommandations d’OWASP sur la journalisation préconisent de consigner les échecs d’autorisation et les actions à risque élevé, de capturer quand, où, qui et quoi, tout en contrôlant l’accès aux journaux et en évitant les secrets techniques. Appliquez ce test aux événements réellement exportés par le produit, pas seulement aux captures d’écran d’une page de sécurité.

7. Récupération, interruption et sortie

Une affirmation de sauvegarde reste incomplète tant qu’une restauration n’a pas été testée. Le NIST Cybersecurity Framework 2.0 comprend des résultats relatifs à la création, la protection, la maintenance et au test des sauvegardes, ainsi qu’à la vérification des ressources de restauration et des systèmes restaurés.

• □ Pouvez-vous créer une sauvegarde cohérente en respectant les verrous du profil ?
• □ Les versions locales et synchronisées sont-elles identifiables et ordonnées ?
• □ Un opérateur peut-il restaurer une version choisie sans détruire la copie actuelle ?
• □ Les données restaurées et la compatibilité du navigateur sont-elles vérifiées avant la reprise d’un usage normal ?
• □ Que se passe-t-il après l’arrêt forcé d’un processus, la perte du réseau, un disque plein, un téléversement interrompu ou un plantage de l’application ?
• □ Une dernière version connue comme valide est-elle protégée d’une réparation qui échoue ?
• □ Un appareil révoqué ou perdu peut-il être retiré sans faire disparaître l’unique chemin de récupération ?
• □ Les clés ou codes de récupération sont-ils protégés à la fois d’une perte accidentelle et d’un accès administratif sans restriction ?
• □ L’équipe peut-elle exporter ses données dans un format documenté et vérifier l’export avant de résilier le service ?
• □ Existe-t-il un processus pris en charge de suppression et de fermeture du compte avec une déclaration claire sur la conservation résiduelle ?

N’exécutez les tests de récupération qu’avec des données d’essai jetables, sauf si le fournisseur et votre processus de changement prennent explicitement en charge les exercices en production. Consignez le temps de récupération, l’état perdu, les opérations manuelles, les avertissements et la version du produit. Une démonstration réussie sur un petit profil n’établit ni les performances ni l’intégrité à l’échelle de votre production.

8. Automatisation et contrôles pour développeurs

• □ Le produit expose-t-il des opérations de domaine versionnées plutôt qu’un accès sans restriction au système de fichiers ou aux processus ?
• □ Les capacités de l’API, de la CLI, des SDK, de Playwright, de CDP, de WebDriver, des webhooks et des agents sont-elles documentées séparément ?
• □ Existe-t-il une matrice de compatibilité exacte entre navigateur et client ?
• □ Les identifiants peuvent-ils être limités par locataire, profil, opération, audience, expiration, débit et coût ?
• □ Les actions destructrices, groupées, visibles à l’extérieur, porteuses de secrets ou engageant une dépense exigent-elles une politique ou une approbation renforcée ?
• □ Les aperçus sont-ils liés à la requête exacte qui sera exécutée ?
• □ Les commandes de modification sont-elles idempotentes ou explicites sur les résultats inconnus ?
• □ Les opérations longues peuvent-elles être annulées et reprises sans danger ?
• □ La révocation prend-elle effet pendant une tâche active ?
• □ Les décisions d’automatisation sont-elles attribuables dans la même piste d’audit que les actions humaines ?
• □ Une sortie ordinaire d’automatisation peut-elle rester utile sans renvoyer l’état brut de session ?
• □ Les messages d’erreur sont-ils assez précis pour permettre la récupération sans divulguer de secrets ?

Testez les chemins de refus. Un jeton en lecture seule doit échouer à lancer un profil. Un jeton limité à un profil doit échouer sur un autre dossier. Un identifiant expiré ne doit pas être silencieusement renouvelé avec un accès plus large. Un agent ne doit pas pouvoir transformer un appel refusé en approbation administrateur en reformulant la requête.

9. Expérience des opérateurs et accessibilité

• □ Les personnes utilisant le clavier peuvent-elles atteindre, utiliser et quitter chaque contrôle, boîte de dialogue, tableau, menu et action de profil ?
• □ Le focus est-il visible et ordonné logiquement après une navigation, une erreur ou un changement de fenêtre modale ?
• □ Les libellés, erreurs, changements d’état et confirmations destructrices fonctionnent-ils avec les lecteurs d’écran ?
• □ L’interface reste-t-elle utilisable avec un zoom et une taille de texte augmentée ?
• □ Les couleurs, mouvements et limites de temps sont-ils réglables ou non essentiels ?
• □ Les opérateurs peuvent-ils distinguer l’organisation, le profil, le proxy, l’environnement et l’état de risque sélectionnés sans dépendre uniquement de la couleur ?
• □ Les actions groupées peuvent-elles être révisées sans imposer des tableaux denses inaccessibles ?
• □ Le comportement natif de la plateforme, les notifications, sélecteurs de fichiers, invites d’identifiants et boîtes de dialogue de mise à jour fonctionnent-ils de manière cohérente ?

Les WCAG 2.2 fournissent des critères vérifiables pour le contenu web, notamment l’utilisation au clavier, l’ordre et la visibilité du focus, la taille des cibles, l’identification des erreurs et l’authentification accessible. Un produit de bureau peut comporter des interfaces natives et web : associez donc les contrôles de normes pertinents à des tests de technologies d’assistance sur chaque système d’exploitation pris en charge.

10. Adéquation commerciale et opérationnelle

• □ Les sièges, profils enregistrés, profils synchronisés, stockage, trafic, sessions simultanées, débit d’API, travailleurs d’automatisation et niveaux d’assistance sont-ils tarifés séparément et clairement ?
• □ Quelles limites sont des blocages stricts, des dépassements facturés ou des conditions d’usage raisonnable ?
• □ Une modification de facturation ou de capacité peut-elle se produire sans l’approbation d’un administrateur ?
• □ Les protocoles de proxy, méthodes d’authentification, extensions et environnements réseau pris en charge sont-ils documentés ?
• □ La politique d’assistance couvre-t-elle les incidents de mise à jour, la corruption des profils, les échecs de restauration, les rapports de sécurité et la récupération des comptes ?
• □ L’état du service, la communication des incidents et les chemins d’escalade sont-ils réels et surveillés ?
• □ Le contrat définit-il la restitution et la suppression des données, les changements de prix, la suspension et la résiliation ?
• □ Pouvez-vous partir sans perdre les preuves nécessaires pour démontrer une migration sûre ?

Calculez le coût selon le pic de travail simultané, l’état synchronisé prévu, le volume d’automatisation et le niveau d’assistance requis. Consignez les taxes, engagements annuels, dépassements et travaux de migration. Ne comparez pas uniquement le plus grand nombre de profils affiché sur chaque page de tarifs.

Plan d’essai contrôlé

Utilisez des comptes de test, des identifiants synthétiques et des profils créés pour l’évaluation. N’importez pas des cookies de production dans le seul but de rendre l’essai réaliste.

1. Consigner l’environnement. Notez les versions de l’application et du navigateur, le système d’exploitation, le matériel, le réseau, le type de proxy, les extensions, le forfait du compte et la date du test.
2. Créer deux rôles et plusieurs profils. Incluez un administrateur, un opérateur restreint, des dossiers distincts et au moins un profil auquel l’opérateur ne doit pas accéder.
3. Exécuter le flux normal. Lancez, utilisez, arrêtez, transférez et relancez les profils. Consignez l’état attendu et observé.
4. Exercer le refus. Avec l’identité restreinte, tentez d’accéder à un profil hors périmètre, d’exporter, de modifier un rôle et d’exécuter une commande d’automatisation.
5. Exercer l’interruption. Avec des données jetables, interrompez un arrêt du navigateur ou une étape de synchronisation selon une méthode prise en charge par le fournisseur ou sûre par ailleurs. Vérifiez le chemin de récupération.
6. Restaurer et comparer. Restaurez un instantané connu dans une nouvelle copie, vérifiez son intégrité et conservez la copie actuelle jusqu’à l’acceptation.
7. Révoquer l’accès. Retirez un utilisateur, un appareil, une session et un identifiant de service ; confirmez le refus dans l’interface et l’API, puis examinez les événements d’audit.
8. Vérifier la portabilité. Exportez les données permises, examinez leur format documenté, réimportez-les dans une destination jetable si cela est pris en charge et identifiez les éléments omis.
9. Examiner l’accessibilité. Réalisez les tâches essentielles au clavier et avec les technologies d’assistance pertinentes sur chaque plateforme requise.
10. Rapprocher coûts et affirmations. Comparez la consommation de ressources et les réponses de l’assistance observées avec la proposition et le contrat.

Modèle de dossier de décision

Exigence	Priorité	Résultat	Preuve et date	Limite ou risque	Responsable et prochaine action
Exemple : l’opérateur ne peut pas exporter l’état de session	Critère	Réussi	Essai contrôlé, version X, AAAA-MM-JJ	Surface d’API seulement ; CLI non testée	Le responsable de la sécurité doit tester la CLI

Clôturez l’évaluation par quatre listes explicites :

• les critères satisfaits avec des preuves suffisantes ;
• les préoccupations acceptées par un responsable nommé et une date de révision ;
• les éléments qui restent non vérifiés ;
• les conditions qui déclencheraient une nouvelle évaluation, comme un nouveau moteur de navigateur, fournisseur d’identité, outil de mise à jour, modèle tarifaire ou format de profil.

Signaux d’alerte courants

Suspendez la décision lorsque :

• la version du navigateur ne peut pas être identifiée ;
• le bac à sable doit être désactivé en usage normal ;
• les administrateurs et l’automatisation partagent un identifiant permanent ;
• le produit s’appuie sur le partage de cookies ou mots de passe bruts pour les transferts en équipe ;
• une API peut exporter des secrets que l’interface prétend protéger ;
• les événements d’audit omettent l’acteur ou ne peuvent pas être exportés ;
• « sauvegarde » signifie seulement qu’une copie cloud existe, sans restauration démontrée ;
• le fournisseur ne peut pas expliquer les écritures interrompues ou l’accès simultané aux profils ;
• un flux critique inaccessible ne dispose d’aucune solution de remplacement ;
• un rapport de sécurité exige l’envoi de secrets par e-mail ordinaire ; ou
• les affirmations du produit promettent l’indétectabilité, un accès garanti aux comptes ou le contournement des mesures d’une plateforme.

Un résultat « non vérifié » n’est pas une accusation. C’est une déclaration précise sur l’absence de preuves. Maintenez-le visible jusqu’à ce que le fournisseur apporte une preuve, que votre équipe teste le comportement ou que le responsable de la décision accepte le risque.