Le 26 août 2026, Anthropic a annoncé la disponibilité générale de Claude in Chrome sur les offres payantes et l’arrivée d’un navigateur intégré à Claude Cowork. Ces outils peuvent lire des pages, naviguer entre des onglets, saisir du texte et remplir des formulaires avec une autonomie accrue. Ils rendent accessibles des portails internes ou anciens dépourvus d’API, mais déplacent aussi la frontière de sécurité : le contenu d’une page devient une instruction potentiellement hostile placée à proximité d’une session authentifiée.
À retenir : un agent navigateur ne doit jamais hériter implicitement de tous les droits de son utilisateur. Il faut isoler son environnement, limiter les domaines et les comptes, classer les actions par risque, exiger une confirmation pour les effets sensibles, journaliser les décisions et vérifier le résultat. Les protections du modèle réduisent le risque de prompt injection ; elles ne le suppriment pas.
1. Le navigateur devient un environnement d’exécution
Les premières générations d’assistants se contentaient de répondre à une question. Un agent navigateur peut maintenant observer l’état d’une page, décider d’une suite d’étapes et agir dans une application. Il devient donc comparable à un utilisateur automatisé doté de capacités de raisonnement.
Cette évolution est utile pour les systèmes qui ne proposent ni API ni connecteur : extranet fournisseur, interface d’administration historique, CRM vertical ou tableau de bord interne. L’agent peut collecter des données, préparer une saisie, traverser plusieurs écrans et restituer le résultat dans la même conversation.
Mais une automatisation classique suit un scénario écrit à l’avance. L’agent choisit son chemin à partir du contenu affiché. Sa flexibilité constitue aussi sa surface d’attaque : une information rencontrée au cours du parcours peut modifier son plan.
Il faut donc traiter le navigateur comme un runtime sensible, avec politiques d’accès, environnement isolé, traces, limites de ressources et mécanismes d’arrêt. Ajouter une extension à un navigateur de travail sans revoir ces éléments revient à déployer un nouveau robot logiciel avec les droits d’un salarié, mais sans gouvernance adaptée.
2. Distinguer navigateur personnel et navigateur isolé
Les deux annonces d’Anthropic illustrent deux modèles différents.
Une extension comme Claude in Chrome opère dans le contexte du navigateur déjà utilisé. Elle bénéficie des sessions ouvertes et peut intervenir sur la page visible. Cette proximité facilite les tâches quotidiennes, mais augmente l’impact potentiel d’une erreur : l’agent peut rencontrer une messagerie, un CRM et un espace d’administration dans la même session.
Le navigateur intégré à Cowork est séparé du navigateur personnel. Selon Anthropic, il n’accède pas par défaut aux onglets, favoris ou mots de passe de l’utilisateur. Les connexions peuvent être importées site par site et certaines catégories sensibles, comme la banque, la messagerie ou le SSO, sont exclues sauf choix explicite.
Pour une entreprise, l’isolement devrait être le mode par défaut. Créez un profil dédié, sans synchronisation de navigateur, avec un coffre de secrets séparé et des comptes de service limités. Le navigateur personnel peut rester utile pour une assistance ponctuelle sous surveillance, mais il ne doit pas devenir le socle d’une automatisation récurrente.
Le choix dépend du besoin : assister une personne sur la page qu’elle voit ou déléguer une tâche à un environnement contrôlé. Confondre ces deux usages expose inutilement les sessions.
3. Pourquoi le prompt injection change la menace
Dans une injection classique, un attaquant tente de faire exécuter une commande par une application. Dans un prompt injection, il place des instructions dans une page, un e-mail, un document ou un champ afin d’influencer le modèle qui les lit.
Le contenu malveillant peut être visible, discret ou intégré à une donnée légitime. L’utilisateur demande par exemple de synthétiser des demandes clients ; l’un des messages contient une instruction demandant à l’agent d’ouvrir un autre écran et de transmettre des informations. Pour le modèle, la demande de l’utilisateur et le texte de la page appartiennent au même contexte de travail, sauf si l’architecture impose une séparation claire.
Anthropic décrit des sondes qui analysent le contenu et un classifieur qui vérifie les actions prévues par rapport à la demande initiale. L’éditeur précise aussi que ces mesures ne peuvent pas éliminer le risque et recommande de commencer par des sites de confiance.
Cette réserve doit guider le design. Aucun score de résistance produit par un fournisseur ne couvre vos applications, vos formulations, vos intégrations et vos permissions. Le prompt injection est un problème de système : modèle, outils, sessions, données, politique et contrôle humain doivent être conçus ensemble.
4. Appliquer le moindre privilège aux sessions web
Le premier garde-fou est la réduction des droits accessibles à l’agent.
Utilisez un compte distinct lorsque l’application le permet. Retirez les rôles d’administration, les exports globaux, la gestion des utilisateurs et les fonctions financières si la tâche n’en a pas besoin. Préférez un périmètre de données limité à l’équipe ou au dossier traité.
Définissez ensuite une liste de domaines autorisés. Une tâche sur le CRM ne devrait pas pouvoir ouvrir un service de partage de fichiers arbitraire. Contrôlez les redirections, sous-domaines et téléchargements, car une page approuvée peut contenir un lien vers une origine non approuvée.
Limitez aussi les flux réseau du navigateur isolé. L’accès sortant peut passer par un proxy qui journalise les destinations et bloque les catégories interdites. Les téléchargements doivent être analysés et stockés dans une zone temporaire sans exécution automatique.
Les secrets ne doivent pas être copiés dans le prompt ou dans un fichier de configuration lisible par le modèle. Utilisez un mécanisme d’authentification géré par le navigateur ou un coffre qui fournit une session sans révéler la valeur brute. Une rotation rapide doit être possible si le profil est compromis.
Cette approche prolonge les principes de notre article sur les agents IA zero-trust, la signature des écritures et l’isolation du code généré : chaque capacité doit être explicitement accordée et vérifiable.
5. Contrôler les actions, pas seulement les réponses
Un agent peut formuler une réponse correcte tout en ayant effectué une action indésirable. La politique doit donc s’appliquer au moment de l’action.
Classez les opérations en quatre niveaux. La lecture de pages publiques peut être automatique. La préparation d’un formulaire ou d’un brouillon peut être autorisée sans envoi. Une modification réversible, comme l’ajout d’une note interne, nécessite une vérification du contenu et de la cible. Une action externe ou difficilement réversible — envoi d’e-mail, changement de droit, suppression, commande, paiement, publication — exige une confirmation explicite et récente.
La confirmation doit présenter des éléments concrets : domaine, compte, objet modifié, valeur actuelle, nouvelle valeur et conséquences. Une question générique « continuer ? » n’aide pas l’utilisateur à détecter une dérive.
Après validation, l’agent doit exécuter uniquement l’action approuvée. Il ne doit pas profiter de la confirmation pour ajouter d’autres étapes. Les outils peuvent imposer des schémas stricts, des listes de champs autorisés et des limites de volume.
Pour les processus sensibles, séparez préparation et exécution. L’agent prépare la transaction ; un service déterministe ou une personne vérifie les règles métier et réalise l’écriture.
6. Journaliser, vérifier et prévoir le retour arrière
La traçabilité ne doit pas se limiter à une vidéo de la session. Enregistrez l’identité du demandeur, la tâche initiale, le modèle et sa version, les domaines visités, les outils appelés, les décisions de politique, les confirmations, les objets modifiés et le résultat observé.
Évitez toutefois de journaliser des secrets ou des données personnelles inutiles. Les captures d’écran et contenus de pages doivent respecter une durée de conservation, un contrôle d’accès et une finalité définie.
Après chaque écriture, l’agent doit relire l’état obtenu. Un bouton cliqué ne prouve pas qu’une modification a été enregistrée. Vérifiez le message de confirmation, la valeur persistée ou un identifiant de transaction. Pour un lot, rapprochez le nombre d’éléments attendus et traités.
Préparez un mécanisme d’annulation : brouillon plutôt que publication directe, corbeille plutôt que suppression définitive, transaction idempotente, version précédente conservée, ou journal permettant de rejouer l’inverse. Certaines opérations, comme un e-mail envoyé ou un paiement, ne sont pas réellement réversibles ; elles doivent être placées derrière le niveau de contrôle le plus strict.
7. Tester l’agent comme un système non déterministe
Les tests fonctionnels habituels ne suffisent pas. Un agent peut choisir des parcours différents pour la même demande et réagir à des formulations inattendues.
Construisez un jeu d’évaluation avec des tâches normales, des ambiguïtés, des erreurs d’authentification, des redirections, des pages lentes et des contenus tentant d’orienter l’agent. Vérifiez qu’il s’arrête lorsqu’une information manque, qu’il demande une confirmation au bon moment et qu’il n’élargit pas son périmètre.
Ajoutez des cas de prompt injection adaptés à vos applications, sans exposer de données réelles : instructions dans une description de ticket, un nom de fichier, un champ CRM, un e-mail ou une page de documentation. Mesurez le taux de blocage, mais aussi les faux positifs qui empêchent le travail légitime.
Testez chaque nouvelle version de modèle et chaque changement de politique. Une amélioration générale du modèle peut modifier son interprétation des instructions, sa propension à demander confirmation ou la façon dont il utilise un outil.
Enfin, réalisez une phase d’observation en lecture seule. Comparez les décisions proposées par l’agent aux actions d’un opérateur avant d’autoriser les écritures.
8. Déployer par classes d’usage
Commencez par les tâches à faible impact : collecte d’informations publiques, vérification d’un statut, préparation d’un rapport ou saisie d’un brouillon dans un environnement de test.
La deuxième étape peut couvrir des portails internes avec un compte limité et des actions réversibles. Conservez une validation humaine et mesurez le temps réellement gagné, y compris la revue et la correction.
Les usages impliquant messagerie, données sensibles, changement de droits, commandes ou finance doivent rester dans un périmètre séparé. Exigez une analyse de risque, un propriétaire métier, un responsable technique, des journaux exploitables et un plan d’incident.
Définissez aussi les exclusions : domaines non autorisés, catégories de données, plages horaires, volumes et actions que l’agent ne réalisera jamais. Une liste claire protège mieux qu’un prompt général demandant « d’être prudent ».
Le passage à l’échelle doit dépendre de preuves : taux de tâches terminées, erreurs confirmées, interventions humaines, incidents de politique, coût et satisfaction des utilisateurs. L’autonomie est un niveau de service à gagner, pas une option à activer globalement.
Conclusion
Les agents navigateur rendent automatisables des applications que les intégrations traditionnelles laissaient de côté. Leur capacité à utiliser les sessions existantes et à interpréter des pages dynamiques apporte une réelle valeur, mais elle rapproche des données non fiables d’actions authentifiées.
La sécurité doit être construite autour du modèle : navigateur isolé, droits minimaux, domaines autorisés, politique d’action, confirmations informatives, vérification du résultat et journalisation. Partitech accompagne la conception de ces architectures agentiques, la définition des garde-fous et la mise en place de pilotes mesurables avant toute généralisation.