Votre SaaS face à l’IA du navigateur : le playbook du CTO pour l’ère de la Prompt API

Le navigateur vient de devenir un runtime d’agent IA — et vous n’en avez pas la maîtrise. Entre la Prompt API proposée par Chrome (à laquelle Mozilla s’est publiquement opposée), les overlays de Gemini et d’Edge, et une population d’utilisateurs payants de Copilot en forte croissance (Microsoft annonce 20 M+), votre SaaS est automatisé de l’extérieur. Vous ne pouvez pas le bloquer avec un simple en-tête. Si vous l’ignorez, vous verrez des ruptures d’UI, des fuites de données et des files d’attente support frustrées. Si vous l’embrassez avec les bons contrôles, vous pouvez l’orienter vers des workflows clients plus sûrs et plus rapides.

Voici le playbook d’un CTO pour l’ère de la Prompt API : comment défendre votre produit contre les agents côté navigateur — et comment les prendre en charge à vos conditions.

Ce qui change : le navigateur devient une plateforme d’agents

Pendant une décennie, le navigateur a été un runtime prévisible : vous livriez du JavaScript ; les utilisateurs cliquaient sur des boutons. Désormais, le runtime a un second opérateur : un assistant qui lit le DOM, résume les pages, clique sur vos boutons et envoie vos données à un modèle. La Prompt API proposée par Chrome normaliserait une partie de ces comportements ; Mozilla a repoussé, invoquant des préoccupations de sécurité et de confidentialité. Le débat de gouvernance est un symptôme, pas la cause. L’IA côté navigateur est déjà là, via des overlays et des extensions.

Deux chiffres clés :

• Chrome détient plus de 60 % de part de marché dans le monde. Toute fonctionnalité de plateforme ici devient de facto omniprésente pour vos clients.
• Microsoft rapporte 20 M+ d’utilisateurs payants de Copilot. Ce n’est pas du trafic de hobbyistes ; c’est un comportement d’entreprise qui se diffuse dans l’usage des SaaS.

Les agents ne se contentent pas de lire. Ils exécutent des workflows : rédaction de contenu, rapprochement de commandes, édition d’enregistrements et scraping de tableaux de bord internes. Votre application doit partir du principe qu’un assistant est présent, curieux et rapide.

Les risques que vous verrez réellement (classés par probabilité)

1) Exfiltration silencieuse de données via la lecture du DOM

Les agents en surcouche extraient le texte rendu de votre application — pas vos API. Cela signifie que des résumés sensibles, des ID internes et du contenu caché mais rendu sont en jeu. La Content Security Policy (CSP) n’empêchera pas une extension de navigateur de lire le DOM, et beaucoup d’overlays peuvent relayer des données vers leurs processus d’arrière-plan sans passer par votre pile réseau.

2) Interférences UI et rupture de parcours

Des fonctions d’autopilotage cliquent à travers des modales, choisissent des valeurs par défaut non prévues et collent du contenu dans de mauvais champs. Vous verrez « ça marche chez moi » côté ingénierie et « ça vient d’écraser mon brouillon » côté support. Attendez-vous à des sélecteurs fragiles, des assistants instables et des cas limites étranges lorsque des agents émettent des événements non approuvés.

3) Pics de taux et régressions de perf

Certains assistants sondent le DOM, sérialisent de gros segments de innerText et diffent les changements à chaque mutation. Cela se traduit par une hausse de CPU, du churn mémoire et davantage de bavardage réseau à cause des auto-saves. Cela se manifeste par une augmentation de 5–15 % du CPU page sur des écrans chargés et un jitter bizarre sous charge — surtout sur des appareils d’entrée de gamme.

4) Conformité et exposition contractuelle

Si un assistant tiers copie des données client dans un modèle, qui est le sous-traitant ? Votre DPA dit probablement « le client contrôle le comportement côté client », mais cela n’empêchera pas les réclamations quand un champ caviardé apparaîtra dans un transcript de support. Vous avez besoin d’un langage plus clair et d’une segmentation technique pour défendre votre position.

Un cadre de décision pour CTO : bloquer, accommoder ou construire

Vous ne pouvez pas complètement bloquer les automatisations du navigateur. Les extensions opèrent hors de votre origine et contournent la plupart des contrôles au niveau de la page. Vos options réalistes :

• Bloquer quand il le faut (paiements, revue de données personnelles/PII, rotation de clés),
• Accommoder prudemment pour les tâches à faible risque (résumés, réponses à base de modèles), et
• Construire un « Agent Mode » officiel qui coûtera moins cher qu’un jeu du tape-taupe sans fin.

Des contrôles qui aident vraiment (et ce qui n’aide pas)

1) Séparer les flux sensibles vers des origines durcies

• Déplacez les étapes critiques (saisie de carte, rotation d’identifiants, export/téléchargement) vers une origine distincte et durcie. Beaucoup d’overlays génériques n’ont pas de permissions d’hôte pour des sous-domaines inconnus ; ils ne peuvent donc pas lire à l’intérieur de cet iframe par défaut.
• Utilisez un iframe sandboxé cross-origin pour la frame critique avec le minimum de drapeaux nécessaires (par ex., allow-scripts, allow-forms ; éviter allow-top-navigation). Un document sandboxé, cross-origin relève la barre pour le scraping DOM opportuniste par des extensions sans permissions d’hôte explicites.
• Compromis : plus de complexité autour de l’état et de la messagerie. Vous aurez besoin de ponts postMessage et d’un CORS soigné.

2) Réduire la surface de rendu des secrets

• N’affichez pas ce que vous ne pouvez pas vous permettre de laisser fuiter. Conservez les secrets côté serveur jusqu’à ce que l’utilisateur les révèle explicitement, une seule fois. Éliminez totalement les ID internes et les tokens du DOM.
• Utilisez un Shadow DOM fermé pour les composants qui contiennent des rendus sensibles mais nécessaires. Ce n’est pas une garantie, mais cela réduit le scraping DOM naïf et la fragilité des sélecteurs.
• Compromis : friction de test et d’outillage ; l’ergonomie des DevTools en pâtit.

3) Freiner l’automatisation non approuvée sans pénaliser les humains

• Protégez les actions destructrices derrière des vérifications de confiance d’événement : rejetez ou confirmez les actions quand event.isTrusted === false. Fournissez une modale de confirmation de repli liée à une interaction utilisateur.
• Limitez les patterns d’interaction « très bot » : frappes clavier à des intervalles < 5 ms, rafales de collage à 0 ms sur de gros volumes, tempêtes de clics sans variance de mouvement du pointeur.
• Compromis : certaines technologies d’accessibilité ressemblent à de l’automatisation. Coordonnez-vous avec votre référent a11y et mettez sur liste blanche les technologies d’assistance quand c’est possible.

4) Renforcer quand même CSP et SRI (ça aide sur l’autre moitié du problème)

• Verrouillez les sources de scripts externes avec CSP et Subresource Integrity. Cela n’arrêtera pas les extensions, mais coupe des voies d’exfiltration classiques et réduit votre surface XSS — toujours votre plus gros risque de base.
• Activez COOP/COEP et l’isolation cross-origin pour des fonctionnalités de sûreté mémoire et une meilleure perf de WASM/OffscreenCanvas, ce qui compense la surcharge des agents.
• Compromis : une CSP plus stricte peut casser d’anciens widgets tiers ; prévoyez un sprint pour la remédiation.

5) Publier un Agent Mode officiel

Combattre les overlays indéfiniment est une bataille perdue. Proposez une voie plus sûre :

• Endpoints structurés en lecture seule (REST/GraphQL) pour « ce qu’il y a sur cette page » afin que les agents n’aient pas besoin de scraper le DOM. Ne retournez que le minimum de champs.
• OAuth éphémère pour les agents : flows device-code ou PKCE avec des tokens de 5–15 minutes, des scopes étroits (par ex., read:ticket, draft:comment) et des conditions explicites « no training ».
• Actions synthétiques et limitées : des endpoints pour « proposer des changements » qui créent des brouillons ou des PR au lieu de valider des données en direct. L’humain reste l’approbateur final.
• Contrats de quota/limitation de débit : par défaut 2–5 RPS par utilisateur pour le trafic étiqueté agent, avec rafales possibles et des consignes 429.
• Hooks de détection : autorisez un en-tête personnalisé comme X-Agent-Intent: summarize pour que les assistants puissent s’auto-identifier. Oui, certains ne le feront pas, mais les bons acteurs le feront — comme le respect de robots.txt.

Coût : pour la plupart des backends SaaS, l’Agent Mode est un projet de 2–3 sprints. C’est moins cher qu’une année de correctifs UX et d’escalades support.

6) Détection heuristique et observabilité

• Signaux front-end à collecter (respectueux de la vie privée) : fréquence des appels à getSelection(), churn de MutationObserver, longueur des lectures de texte sérialisé, cadence des collages, et part d’événements non approuvés sur les actions destructrices.
• Signaux côté serveur : activité anormale 24/7 depuis une même session, motifs répétés read-modify-draft à des intervalles de millisecondes, et user-agents extrêmement uniformes sur de nombreux comptes d’une même organisation.
• Construisez des dashboards pour comparer les sessions orientées agent aux sessions purement humaines sur le taux d’erreurs, les échecs d’enregistrement et les tickets support. Votre objectif est de prouver (ou d’infirmer) que l’Agent Mode réduit le taux d’incidents.

Ce sur quoi il ne faut plus perdre de temps

• Bloquer les extensions avec des sniffs JavaScript. Énumérer les propriétés de window ou scanner les effets de bord CSS est fragile et casse des outils légitimes. Vous finirez dans un jeu du chat et de la souris perdant.
• Supposer que CSP peut policer les extensions. Non. Les extensions s’exécutent dans un monde isolé ; votre CSP régit vos ressources, pas les leurs.
• Randomiser les IDs et noms de classes du DOM. Cela ralentit les scripts naïfs et casse votre QA. Les agents utilisent de plus en plus des indices visuels et sémantiques ; ils s’adapteront.

Juridique, politique et communication : mettez-le par écrit

• Mettez à jour vos Conditions et DPA : clarifiez que les assistants côté client sont des sous-traitants mandatés par le client et qu’ils doivent respecter vos limites d’API publiées. Interdisez l’entraînement sur les données client sauf consentement explicite du client.
• Publiez une page « Politique relative aux agents » : documentez les comportements d’agent pris en charge, les limites de débit et les endpoints de l’Agent Mode. Offrez un contact pour les grands fournisseurs (Copilot, Gemini, Claude) afin de coordonner.
• Envisagez un fichier agents.txt : un simple fichier de politique à la racine décrivant l’automatisation acceptable sur votre domaine. Ce n’est pas encore un standard, mais c’est un signal découvrable indiquant « nous avons des règles — et une API ».

Un plan sur 90 jours qui ne torpille pas votre roadmap

Jours 0–30 : Triage et durcissement

• Cartographiez les surfaces de rendu sensibles : champs ou panneaux affichant des secrets, des ID internes, des PII ou des liens d’export.
• Déplacez les 2 flux principaux (souvent, paiements et rotation d’identifiants) dans un iframe sandboxé, cross-origin, sur un sous-domaine durci. Verrouillez CSP et SRI.
• Ajoutez une garde de confiance d’événement aux actions destructrices et testez avec des lecteurs d’écran pour éviter des régressions a11y.
• Mettez à jour vos ToS/DPA avec un langage relatif aux assistants ; préparez un brouillon de Politique relative aux agents.

Jours 31–60 : Livrer l’Agent Mode v1

• Exposez des miroirs de page en lecture seule via REST/GraphQL renvoyant exactement les champs affichés dans les dashboards clés — rien de plus.
• Implémentez un OAuth éphémère (device code ou PKCE) avec des tokens de 5–15 minutes et des scopes étroits.
• Créez des endpoints « proposer un changement » pour générer des brouillons au lieu de valider des éditions en direct.
• Déployez des limites de débit basiques et retournez des consignes 429 structurées pour le backoff.

Jours 61–90 : Observer, adapter, et nouer des partenariats

• Déployez des heuristiques d’agent via des balises front-end et des métriques serveur. Comparez taux d’erreur et volume support entre sessions agent et humaines.
• Publiez la Politique relative aux agents et la doc. Annoncez-le dans le produit. Proposez des exemples de scripts pour que les clients branchent leurs assistants sur l’Agent Mode en moins d’une heure.
• Pilotez avec un fournisseur (Copilot ou Gemini) pour valider les en-têtes, l’OAuth et les contrats de débit. Ajoutez un canal Slack partagé pour la réponse aux incidents.

Les aspérités du réel que vous rencontrerez

• Chevauchement accessibilité : certaines technos a11y déclenchent vos heuristiques d’automatisation. Travaillez avec les leads a11y pour mettre sur liste blanche des patterns UA et permettre aux utilisateurs d’opter pour un mode permissif.
• Douleur de debug avec le Shadow DOM : votre QA se plaindra que les sélecteurs ont cassé. Investissez dans des helpers de test capables de traverser des arbres fermés en préproduction avec un build de debug.
• Règles de confidentialité internationales : des clients UE demanderont si les assistants constituent un transfert transfrontalier. Votre Politique relative aux agents doit indiquer explicitement que le client choisit l’assistant utilisé et reste le responsable du traitement.
• Fatigue du support : vous verrez des tickets du type « Copilot a fait X ». Vos macros doivent trier : confirmer l’usage d’un agent, pointer vers la Politique relative aux agents et suggérer le flux pris en charge. Suivez les catégories qui déclinent après l’adoption de l’Agent Mode.

Pourquoi c’est moins cher que de ne rien faire

Sans canal officiel, les agents scrappent, cliquent et enregistrent de manière imprévisible. Vous payez en :

• Toil d’ingénierie : correctifs de sélecteurs et d’assistants fragiles après chaque mise à jour d’overlay.
• Temps support : escalades en plusieurs étapes de 10–20 minutes pour diagnostiquer des « clics fantômes ».
• Nettoyage sécurité : travail post-incident après qu’un assistant d’utilisateur a copié des notes internes dans un modèle.

L’Agent Mode centralise le rayon d’explosion : lectures structurées, écritures limitées aux brouillons, et limites claires. C’est la même leçon apprise avec les bots et les scrapers il y a dix ans — publiez un contrat, et la majorité des acteurs le suivront. Les autres, vous les limitez et les surveillez.

Ce que des équipes nearshore peuvent prendre en charge sans vous ralentir

• Construction de l’Agent Mode : miroirs en lecture seule, endpoints de brouillons, OAuth éphémère et documentation.
• Durcissement front-end : isolation des flux sensibles, resserrement CSP/SRI, et garde de confiance des événements.
• Observabilité : balises heuristiques, dashboards et alertes d’anomalies adaptées à votre domaine.

Une équipe nearshore senior peut livrer cela en 6–8 semaines pendant que votre équipe cœur continue de livrer des fonctionnalités. Le travail est hautement parallélisable et testable — parfait pour un pod dédié avec des SLA clairs.

En bref

Le débat autour de la Prompt API est un aperçu de votre prochaine année : l’IA vivra dans les navigateurs de vos utilisateurs que les organismes de standardisation soient d’accord ou non. Traitez-la comme la météo — prévisible en agrégé, dangereuse dans les extrêmes, et gérable avec la bonne architecture. Bloquez où c’est nécessaire, accommodez là où c’est sûr, et construisez un Agent Mode pour que le futur s’intègre à vous au lieu d’entrer en collision avec vous.

Points clés

• Les agents IA côté navigateur automatisent déjà votre SaaS ; la Prompt API de Chrome normaliserait cela à 60 %+ de part de marché.
• Vous ne pouvez pas bloquer complètement les extensions ; concentrez-vous sur la séparation des flux sensibles, la réduction de la surface de rendu et la mise sous garde des événements non approuvés.
• Publiez un Agent Mode officiel : miroirs en lecture seule, écritures limitées aux brouillons, OAuth éphémère et limites de débit documentées.
• Instrumentez des heuristiques d’agent pour mesurer le taux d’erreurs et l’impact support ; démontrez le ROI de l’Agent Mode face au tape-taupe continu.
• Mettez à jour les termes juridiques et publiez une Politique relative aux agents pour que clients et fournisseurs connaissent les règles — et disposent d’une voie prise en charge.