IA & PILOTE

Agent IA navigateur : tester un parcours sans risque

Publié le 2 novembre 2026

Un agent IA peut agir sur un écran, pas seulement répondre à une question. Avant de vendre cette automatisation, teste un parcours fictif, ses erreurs et son arrêt.

Guide pratique · Lecture : environ 11 minutes

Ce qui change avec les agents capables de cliquer

Le 30 octobre 2026, Google a annoncé dans les notes de version de la Gemini API la disponibilité générale de Computer Use dans les API Interactions et GenerateContent. Il s'agit d'une disponibilité technique, pas d'une garantie de fiabilité sur tous les sites. L'heure exacte de publication n'est pas indiquée. Ce guide est rédigé le 2 novembre, après une veille de six heures sans annonce pertinente vérifiable, élargie aux trois derniers jours.

La documentation Computer Use décrit une boucle : le modèle reçoit une capture d'écran, suggère un clic ou une saisie, puis un programme exécute l'action et renvoie une nouvelle capture. Il faut donc un environnement d'exécution, des règles d'arrêt et des contrôles. Un agent qui propose une action ne l'a pas nécessairement réalisée.

Pour un indépendant ou une petite agence, l'enjeu n'est pas de promettre un assistant universel. Il consiste à tester une seule tâche avant de vendre une automatisation. Un pilote sur des données fictives permet de repérer des problèmes sans exposer les comptes d'un client.

Ce qu'un agent navigateur sait faire, et ce qu'il ne prouve pas

Un agent visuel observe des éléments affichés et choisit une action. Il peut essayer de retrouver un dossier, remplir un formulaire ou naviguer entre plusieurs pages. Si l'interface change, il doit réexaminer la situation. Contrairement à une démonstration enregistrée, un véritable parcours peut contenir des champs manquants, des erreurs et des choix ambigus.

La documentation de Google présente des environnements navigateur, mobile et bureau pour certains modèles. Cela ne signifie pas que Computer Use est une application autonome sur iPhone. Les exemples officiels montrent une intégration technique avec un gestionnaire d'actions, notamment pour exécuter les clics et récupérer les captures.

Un résultat affiché à l'écran n'est pas forcément enregistré dans un système. Une confirmation simulée ne prouve pas qu'un message a été envoyé. Et une action réussie ne démontre ni la rentabilité d'un service ni sa conformité. Distingue toujours ce que tu as observé de ce que tu aimerais conclure.

Choisir une tâche assez petite pour être testée

Commence par une action répétitive, sans conséquence irréversible. Par exemple : retrouver une demande fictive et préparer sa catégorie dans un tableau. Évite les paiements, les suppressions, l'envoi de messages ou les modifications de dossiers réels. Pour une première démonstration, tu peux construire un formulaire de test avec des noms et des identifiants inventés.

Écris le résultat attendu avant d'ouvrir un outil : « Retrouver DEMO-014, sélectionner la catégorie réparation et s'arrêter avant confirmation. » DEMO-014 est un identifiant fictif. Tu sais ainsi quoi regarder et quand l'essai doit se terminer. Sans résultat précis, tu risques de prendre chaque clic pour une avancée.

Si tu cherches une tâche pertinente, consulte le guide automatiser les tâches d'une PME avec l'IA. L'objectif est de choisir un problème observable, pas de multiplier les fonctionnalités. Un pilote limité peut être plus instructif qu'une démo spectaculaire dont personne ne comprend les conditions.

Le cadre TESTE : cinq questions avant de démarrer

TESTE est une grille pédagogique proposée ici, pas une certification ni un score scientifique. Elle sert à préparer les preuves dont tu auras besoin pour décider de poursuivre.

Ne transforme pas ces cinq questions en note de performance inventée. Une capture d'écran peut prouver qu'un formulaire est visible, pas que le dossier a été correctement traité. Un journal d'exécution peut montrer qu'une étape a tourné, pas que la prestation répond au besoin d'un client.

Prépare trois colonnes supplémentaires : fait observé, hypothèse, prochaine action. « Le dossier n'a pas été trouvé » est un fait si tu l'as constaté. « Le modèle est incapable de chercher » est une conclusion beaucoup plus large. « Tester un libellé de recherche plus clair » est une action possible.

Premier scénario : le parcours normal

Crée une interface fictive avec une liste de demandes, un champ de recherche et un formulaire de catégorie. Donne à l'agent une consigne courte. Observe chaque étape : où il clique, quel dossier il ouvre, ce qu'il écrit et le moment où il annonce avoir fini. Ne modifie pas la consigne après coup pour rendre le résultat favorable.

Le test est réussi seulement si l'état final correspond à la demande. Si l'agent ouvre le bon dossier mais renseigne le mauvais champ, note l'erreur. S'il annonce « terminé » alors que la modification n'est pas enregistrée, la preuve est insuffisante. Garde un récapitulatif visible avant toute confirmation.

Tu peux aussi faire essayer l'interface à une personne du métier, sans lui dire où cliquer. Cette observation ne mesure pas directement la qualité de l'agent, mais elle révèle si le parcours est compréhensible. Une automatisation qui reproduit une interface confuse peut simplement déplacer le problème.

Deuxième scénario : le dossier manque ou l'écran change

Prépare une variante : le dossier demandé n'existe pas, deux noms se ressemblent ou un champ a changé de place. L'agent doit reconnaître la situation plutôt que sélectionner un résultat au hasard. S'il reste bloqué, un arrêt explicite est préférable à une action erronée qui semble réussie.

Observe les tentatives, les retours en arrière et les messages d'incertitude. Un agent qui clique plusieurs fois sur un bouton inactif peut entrer dans une boucle. Il faut alors une limite d'essais et une sortie vers une personne. Cette règle doit être appliquée dans l'environnement, pas seulement souhaitée dans une consigne.

Tu peux répéter le scénario avec plusieurs états fictifs. Ne présente pas le nombre de cas réussis comme un taux de fiabilité général. Les résultats d'une démo ne se transfèrent pas automatiquement à d'autres interfaces, versions ou jeux de données.

Troisième scénario : s'arrêter avant l'action sensible

Ajoute un bouton fictif « Envoyer » ou « Confirmer ». L'agent peut préparer les champs et montrer le récapitulatif, mais il doit s'arrêter avant l'action finale. Aucun vrai courriel ne doit partir. Aucun paiement ni changement en production ne doit être possible dans cet environnement.

Google décrit des décisions de sécurité pouvant demander une confirmation humaine et recommande une supervision des actions importantes. Cela ne dispense pas de limiter les droits côté application. Un simple prompt « ne clique pas » n'est pas une protection suffisante si le programme peut réellement exécuter une action interdite.

Le bon livrable de ce test est une préparation contrôlable : voici ce qui serait fait, voici ce qui reste à approuver. La personne responsable doit pouvoir refuser sans dommage. Si cette séparation n'est pas possible, ne présente pas le système comme prêt pour un client.

Cas pratique fictif : un atelier de réparation

Imagine un atelier de vélos qui classe les demandes reçues. L'atelier et les résultats ci-dessous sont entièrement fictifs. Tu crées dix dossiers inventés et un écran de suivi. Le problème supposé est la double saisie de catégories, mais tu ne sais pas encore si cette difficulté existe vraiment dans une entreprise.

Le premier essai demande de retrouver DEMO-014 et de préparer la catégorie « révision ». Le deuxième retire DEMO-014 de la liste pour observer la réaction. Le troisième place un bouton de confirmation que seul un humain peut actionner. Tu conserves les consignes, les captures, les erreurs et les limites.

Supposons que l'agent trouve le bon dossier au premier essai, mais choisisse un autre dossier quand la recherche échoue. Ce résultat fictif ne justifie pas de dire que le modèle est fiable ou inutile. Il montre seulement qu'une règle d'arrêt doit être testée. Tu modifies le protocole, puis tu vérifies la nouvelle version.

Pour savoir si l'offre intéresse quelqu'un, il faut ensuite discuter avec des personnes réellement concernées. Le guide valider une idée de business aide à préparer ces entretiens. Peut-être qu'un simple formulaire mieux conçu évitera la double saisie, sans agent IA.

Pourquoi ça marche : observer au lieu de promettre

Une phrase commerciale comme « notre agent gère ton administratif » ne permet pas de juger un service. Un parcours défini, en revanche, donne un résultat attendu, des erreurs visibles et une décision possible. Tu peux expliquer au client ce qui fonctionne dans le test, ce qui reste manuel et ce qui n'a pas été vérifié.

Cette méthode réduit les hypothèses cachées. Elle ne garantit pas l'absence d'erreurs futures. Les interfaces changent, les contenus affichés peuvent être trompeurs et les données réelles sont plus complexes que les exemples. Le pilote sert à cadrer un projet, pas à certifier une solution.

La logique rejoint celle d'un MVP no-code centré sur un parcours : une petite expérience utile vaut mieux qu'une longue construction sans preuve de besoin. Le meilleur résultat peut être de simplifier le processus ou de renoncer à l'automatisation.

Sécurité : isoler le pilote et contrôler les permissions

La documentation officielle recommande un environnement isolé, comme une machine virtuelle ou un conteneur, pour limiter les conséquences d'une erreur. Elle évoque aussi les risques d'instructions malveillantes rencontrées sur les pages. Un texte affiché dans un navigateur ne doit pas être traité comme une autorisation donnée par le client.

Utilise des données fictives. Ne fournis pas de vrais identifiants, de documents de santé, d'informations bancaires ou de conversations privées. Ne demande pas à l'agent de contourner un CAPTCHA ou d'accepter des conditions contractuelles. Vérifie les conditions d'utilisation du site concerné avant d'envisager une automatisation réelle.

Google documente une détection optionnelle d'injections de prompt sur les captures pour certains modèles. Ce contrôle ne doit pas être considéré comme infaillible. L'environnement de test doit lui-même interdire les actions dangereuses, indépendamment de ce que le modèle propose.

Coûts : mesurer aussi le temps humain

La disponibilité générale d'une API ne signifie pas qu'elle est gratuite et illimitée. Les modèles, quotas et prix peuvent changer. Consulte la page officielle des tarifs Gemini API avant de chiffrer une prestation. N'utilise pas un tarif ancien comme garantie pour les prochains mois.

Compte le temps de préparation, l'installation, les captures, les corrections, les reprises et la validation humaine. Si l'agent accomplit une tâche rapidement mais demande une longue surveillance, le bénéfice économique peut être faible. Compare avec une méthode manuelle ou un script simple sur une tâche similaire.

Pour construire une offre, distingue le coût technique, le temps de travail et la marge souhaitée. Le guide calculer le prix d'une prestation permet de cadrer ces éléments. Aucune économie ni revenu n'est démontré par les scénarios fictifs de cet article.

Comment l'appliquer dès aujourd'hui

Voici une séance indicative d'une heure, sans promesse de durée réelle. Pendant quinze minutes, écris la tâche et les actions interdites. Pendant quinze minutes, dessine un formulaire fictif avec trois états : dossier présent, absent et ambigu. Tu peux faire cette préparation sur papier, sans API.

Pendant quinze minutes, rédige les consignes et les preuves attendues. Prévois une case « non testé » plutôt qu'une réussite inventée. Termine par quinze minutes de revue : où faut-il arrêter le parcours, qui peut approuver la suite et quelles informations manquent pour parler à un client ?

Si tu ne disposes pas de l'environnement technique, le résultat du jour est un protocole, pas un agent exécuté. C'est déjà une étape utile. Ensuite, demande à un professionnel comment il réalise aujourd'hui cette tâche et ce qui lui pose réellement problème.

Erreurs courantes avant de vendre un agent navigateur

Confondre une vidéo avec une preuve de fiabilité. Une démonstration réussie montre un cas particulier. Présente toujours ses conditions et ses limites.

Brancher immédiatement les comptes du client. Un premier pilote ne justifie pas l'accès à ses données. Utilise un environnement séparé.

Prendre un clic pour une décision. Le fait de remplir un formulaire ne donne pas à l'agent l'autorité de l'envoyer.

Oublier les cas d'erreur. Un dossier absent ou une interface modifiée doivent conduire à une réponse contrôlée, pas à un choix au hasard.

Ignorer les coûts humains. Le temps de surveillance, de correction et d'assistance fait partie du service.

Promettre une compatibilité universelle. Les interfaces et les règles d'utilisation changent. Une fonction d'API n'est pas une garantie sur chaque site.

Éviter l'entretien client. Même un agent techniquement convaincant n'a pas de valeur commerciale démontrée si personne n'a besoin du résultat.

Transformer le protocole en offre pilote

Une offre honnête peut tenir sur une page : une tâche, trois scénarios, un compte rendu des blocages et une recommandation. Précise ce qui n'est pas inclus : accès aux comptes réels, envoi automatique, paiement, déploiement en production et garantie de performance.

Commence par un métier et un problème précis. Le guide trouver ses premiers clients freelance peut t'aider à organiser les premiers échanges. Une page de présentation de service doit expliquer les livrables et les limites, sans prétendre que l'agent est déjà opérationnel si tu n'as qu'un protocole.

Si le client n'a pas ce problème, change de piste. Si une règle simple suffit, propose-la. Une activité durable repose sur un besoin vérifié, pas sur le nombre d'actions automatiques affichées dans une démonstration.

FAQ : agent IA et navigation automatisée

Un agent IA peut-il remplir un formulaire dans un navigateur ?

Oui, certaines API permettent de suggérer des actions à partir de captures d'écran. Un programme doit ensuite exécuter ces actions, gérer les erreurs et limiter les permissions. La réussite n'est pas garantie.

Computer Use fonctionne-t-il gratuitement sur iPhone ?

La disponibilité annoncée concerne une fonction de la Gemini API, pas une application iPhone autonome. Les coûts et les prérequis dépendent de l'intégration et des modèles. Vérifie les pages officielles avant d'essayer.

Peut-on tester sans utiliser les données d'un client ?

Oui. Crée des dossiers inventés, une interface fictive et un bouton final désactivé. Tu peux même préparer les scénarios sur papier avant toute intégration technique.

Trois tests suffisent-ils à prouver la fiabilité ?

Non. Les trois scénarios sont une méthode de départ, pas une certification ni une mesure générale de réussite. Des essais supplémentaires seront nécessaires selon les risques et le contexte.

Que faire si l'agent ne trouve pas un dossier ?

Il doit signaler l'incertitude et s'arrêter plutôt que choisir au hasard. Documente l'échec et prévois une correction ou une reprise humaine.

Conclusion : une tâche, une preuve, une décision

L'annonce du 30 octobre montre que les outils d'interaction avec les écrans progressent. Elle ne transforme pas automatiquement une démonstration en service rentable. Avant de vendre un agent navigateur, choisis une tâche, prépare trois scénarios et vérifie l'arrêt avant toute action sensible.

Confronte ensuite l'idée à des professionnels, mesure le travail réel et décide de continuer, d'ajuster ou d'abandonner. Pour structurer la suite, découvre DO TO DAY et avance dans une mission guidée, une étape après l'autre. L'important n'est pas de multiplier les clics, mais de résoudre un problème concret.

Ressources complémentaires

Les notes de version Gemini API datent l'annonce du 30 octobre 2026. La documentation Computer Use détaille les environnements, la boucle d'actions et les précautions. Les tarifs officiels servent à vérifier les conditions économiques avant une offre.

Sources et limites

Cas d'usage et identifiants fictifs. Aucun test réel d'agent ni économie mesurée ; aucune promesse de compatibilité, de sécurité totale ou de revenu.

• Google AI for Developers — Gemini API release notes, 30 octobre 2026
• Google AI for Developers — Computer use, documentation technique
• Google AI for Developers — Gemini Developer API pricing