Agents IA dans le web : architecture, goulets d'étranglement et mise en pratique

Introduction : pourquoi les agents web sont devenus le sujet phare de 2026

Il y a encore trois ans, l'expression « agent IA » sonnait comme un slogan marketing. Aujourd'hui, c'est un outil de travail qui ouvre un navigateur, lit une page, clique sur des boutons, remplit des formulaires et renvoie un résultat. Il surveille les prix des concurrents sur une marketplace, compare les résultats d'un moteur de recherche dans dix régions, teste une landing page avant de lancer une campagne et collecte des données là où aucune API publique n'existe et n'existera jamais.

Pourquoi maintenant ? Trois facteurs se sont alignés. Les modèles ont appris à renvoyer de manière fiable des commandes structurées plutôt que du texte libre. Des runtimes de navigateur conçus pour être pilotés par une machine, et non par un humain, ont vu le jour. Et enfin, les entreprises sont mûres : la routine dans le navigateur coûte cher, et les équipes en ont assez d'écrire des scripts fragiles qui cassent à chaque changement de mise en page.

Mais voici ce qui surprend dès la première vraie mise en production : un agent qui brille en démo ne réussit sa tâche en production qu'une fois sur deux. Il se perd dans les pages dynamiques, met plusieurs minutes et des dizaines de milliers de tokens sur un scénario en dix étapes, trébuche sur les protections anti-bot et fait parfois tout autre chose que ce qu'on lui a demandé. C'est précisément de ces goulets d'étranglement, et de la manière de les anticiper dès la conception, dont traite cet article.

Nous gardons volontairement une limite : nous parlons des agents en tant que classe de systèmes. Nous ne reviendrons pas sur le fonctionnement des protocoles de connexion d'outils ni sur la recherche dans des bases de connaissances vectorielles, le blog y consacre des articles dédiés. Ici, ce qui nous intéresse est autre : comment un agent IA perçoit le web, prend des décisions, agit, et pourquoi des pertes apparaissent à chacune de ces étapes.

Ce que vous retirerez de cette lecture :

• Une compréhension de l'architecture en sept couches d'un agent web et de ses points fragiles.
• Quatre méthodes concrètes : concevoir la perception des pages, maîtriser la planification, bâtir une couche réseau sur proxys mobiles, observabilité et économie.
• Des checklists, des grilles d'évaluation et des scénarios réels chiffrés.
• Des réponses aux questions qui surgissent généralement en deuxième semaine de pilote.

Le contenu s'adresse aux marketeurs, aux affiliés, aux développeurs et aux dirigeants, autrement dit à tous ceux qui travaillent déjà avec l'automatisation et les proxys mobiles et veulent comprendre où va cet outillage. Il y aura des détails techniques, mais chacun sera expliqué par des analogies claires.

Les bases : qu'est-ce qu'un agent web et en quoi diffère-t-il d'un script

Une définition sans magie

Un agent IA dans le contexte du web est un système logiciel qui reçoit un objectif en langage naturel, le décompose lui-même en étapes, observe l'état du navigateur, choisit l'action suivante et répète la boucle jusqu'à atteindre l'objectif ou épuiser la limite de tentatives. Le mot clé est boucle. Un chatbot répond une fois puis se tait. Un script de scraping exécute une séquence prédéfinie et plante si la réalité s'écarte du plan. L'agent, lui, vit dans une boucle « observation, raisonnement, action », et c'est cette boucle qui lui donne sa souplesse et crée la plupart des problèmes.

Une bonne analogie : un stagiaire au bureau. Le script, c'est une consigne papier : « ouvre le site, clique sur le troisième bouton en partant du haut, copie le nombre ». Il suffit que le designer déplace le bouton pour que la consigne devienne inutile. Le stagiaire, lui, comprend la tâche « trouve le prix du produit » et trouvera le prix même si le bouton a bougé. Mais le stagiaire est plus lent, plus cher, se trompe parfois et doit être encadré. Tout cela s'applique exactement de la même manière à l'agent IA.

Trois familles d'agents web

• Les agents orientés API. Le web est pour eux un ensemble de points d'accès. Ils n'ouvrent pas de navigateur mais appellent directement les services. Rapides, économiques, mais seulement là où une API existe et où ses conditions autorisent un tel usage.
• Les agents DOM. Ils pilotent un vrai navigateur via des outils d'automatisation, lisent la structure de la page (arbre des éléments, arbre d'accessibilité) et cliquent sur des sélecteurs. C'est le cheval de trait de la plupart des tâches métier.
• Les agents visuels (computer use). Ils regardent une capture d'écran comme un humain et agissent avec des coordonnées de souris. Universels, ils fonctionnent même avec un canvas et des widgets non standard, mais sont les plus chers et les plus lents.

En pratique, les systèmes matures sont hybrides : l'agent lit l'arbre d'accessibilité et ne recourt à la capture d'écran que lorsque la représentation textuelle ne suffit pas.

Les niveaux d'autonomie

Il est utile de raisonner en échelle, semblable aux niveaux d'autopilote en voiture :

1. Assisté. L'humain pilote, l'agent suggère l'étape suivante.
2. Semi-autonome. L'agent exécute une chaîne mais s'arrête avant les actions irréversibles : paiement, envoi de formulaire, suppression.
3. Autonome dans le cadre d'un scénario. L'agent travaille sans intervention à l'intérieur de limites définies et d'une liste de domaines autorisés.
4. Autonome avec délégation. L'agent génère lui-même des sous-tâches et des sous-agents. Le niveau où vivent aujourd'hui surtout les systèmes de recherche et les équipes très matures.

Conseil pratique pour démarrer : la plupart des tâches métier en marketing et en analyse se résolvent confortablement aux niveaux deux et trois. Vouloir atteindre le quatrième pour la beauté du geste est inutile : chaque niveau supérieur double la complexité du contrôle.

Pourquoi le web est un mauvais environnement pour un agent

Le web a été conçu pour les humains. Les pages sont redondantes : une fiche produit sur une marketplace peut peser des centaines de kilo-octets de balisage pour quelques lignes de données utiles. Les interfaces sont dynamiques : le contenu se charge après défilement, des fenêtres modales recouvrent les boutons, l'état change sans rechargement. Et le web est hostile à l'automatisation : les sites se protègent contre la charge et les abus, imposent des limites et vérifient si le client ressemble à un utilisateur ordinaire. Chacun de ces facteurs devient un goulet d'étranglement, et nous allons les examiner couche par couche.

Analyse approfondie : sept couches d'architecture et leurs goulets d'étranglement

Décomposons un agent IA de navigateur typique en couches. Ce n'est pas le seul schéma possible, mais il est pratique car à chaque couche correspond une classe de problèmes et un ensemble de solutions.

Couche 1. Formulation de la tâche et contrat de résultat

Ici, l'objectif humain se transforme en spécification : qu'est-ce qui compte comme un succès, dans quel format renvoyer les données, quels domaines sont autorisés, quelles actions sont interdites. Le goulet d'étranglement, c'est la formulation floue. « Collecte les prix des concurrents » n'est pas une tâche. « Pour 40 références d'un tableau, obtenir le prix actuel et la disponibilité sur deux plateformes indiquées, renvoyer un JSON avec les champs et l'horodatage, et en cas d'absence du produit, renvoyer un statut explicite » est une tâche.

Couche 2. Planificateur et orchestrateur

Le planificateur décompose l'objectif en sous-objectifs, suit l'état d'exécution, décide quand répéter une étape, quand revenir en arrière, quand appeler un humain. Deux pôles architecturaux existent ici. L'agent réactif demande à chaque étape au modèle « que faire ensuite » en regardant l'état courant. Souple, mais cher et enclin à boucler. L'agent planificateur-exécuteur construit d'abord un plan, puis l'exécute de façon déterministe, en ne sollicitant le modèle qu'en cas d'écart. Moins cher et plus prévisible, mais le plan peut devenir obsolète à la troisième étape. Les systèmes matures combinent les deux : le plan comme ossature, des inserts réactifs en cas d'échec.

Couche 3. Le modèle

Le modèle de langage ou multimodal est le cerveau du système. Les goulets d'étranglement sont évidents : fenêtre de contexte, coût des tokens, latence de réponse, hallucinations. Moins évident : différentes étapes exigent différents modèles. Extraire un nombre d'un texte propre ne demande qu'un petit modèle rapide. Comprendre pourquoi un formulaire ne s'envoie pas est une tâche pour un modèle phare. Router les requêtes entre modèles selon la complexité de l'étape permet des économies de plusieurs ordres de grandeur, et nous y reviendrons.

Couche 4. La perception

Cette couche répond à la question « que voit l'agent ». Les options : HTML brut, HTML nettoyé, arbre d'accessibilité (accessibility tree), capture d'écran, hybride. C'est ici que brûle la majeure partie des tokens. Une page de boutique en ligne à l'état brut représente 100 000 à 300 000 tokens, ce qui soit ne tient pas dans le contexte, soit coûte le prix d'un petit déjeuner. Une compression de qualité de la perception est le principal levier d'optimisation, et une section dédiée lui est consacrée plus bas.

Couche 5. Actions et outils

Un ensemble de primitives : naviguer vers une adresse, cliquer, saisir du texte, faire défiler, attendre un élément, extraire des données, renvoyer un résultat. Plus l'ensemble est restreint et propre, moins le modèle se trompe dans ses choix. Le goulet d'étranglement, c'est la « générosité » des développeurs : ils donnent quarante outils à l'agent, et il commence à s'y perdre. Deuxième goulet : la sémantique de l'attente. Cliquer est facile ; comprendre que la page s'est réellement mise à jour et n'affiche pas encore l'ancien contenu avec un indicateur de chargement, c'est plus difficile.

Couche 6. Le runtime du navigateur

Là où vit le navigateur lui-même : machine locale, conteneur, service cloud de navigateurs distants. On y traite l'isolation des sessions, la conservation des cookies et du stockage local entre les étapes, le parallélisme, la consommation de mémoire. Une instance de navigateur avec des onglets ouverts engloutit facilement un gigaoctet de mémoire ; cent agents parallèles exigent une planification d'infrastructure sérieuse.

Couche 7. Couche réseau et identité de session

Depuis quelle adresse l'agent sort sur le réseau, depuis quelle région, à quelle fréquence et avec quels en-têtes. Pour les marketeurs et les affiliés, c'est la couche la plus importante en pratique : résultats régionaux, prix locaux, affichage publicitaire, versions régionales des sites, tout dépend du point de sortie. C'est aussi là que vivent les limites de requêtes et les systèmes anti-automatisation. C'est à ce niveau que les proxys mobiles deviennent un composant d'infrastructure et non une option, et une section pratique dédiée leur sera consacrée.

Composants transverses : mémoire et observabilité

Deux services transverses surplombent les couches. La mémoire stocke le contexte de la tâche, les résultats intermédiaires, l'historique des actions et les particularités apprises des sites (« sur ce domaine, les filtres ne s'appliquent qu'après avoir cliqué sur le bouton »). L'observabilité, ce sont les logs, les traces de chaque étape, les captures d'écran aux moments de décision, les métriques de coût et de temps. Sans observabilité, l'agent est une boîte noire, et le débogage devient de la divination.

Carte des goulets d'étranglement

Rassemblons où exactement se perdent l'argent, le temps et la fiabilité :

• Tokens et contexte — perception excessive des pages, historique d'étapes gonflé.
• Latence — chaque étape, c'est du réseau plus du modèle plus du rendu ; dix étapes deviennent facilement deux minutes.
• Non-déterminisme — le même scénario se déroule différemment d'une exécution à l'autre.
• Fragilité — changement de mise en page, fenêtres surgissantes, différences régionales d'interface.
• Protection anti-automatisation et limites — les sites restreignent la fréquence et vérifient le client.
• Sécurité — une page peut contenir des instructions que le modèle prendra à tort pour des commandes (injection via le contenu).
• Coût — la somme de tout ce qui précède, multipliée par le nombre de tâches.

Chacune des quatre sections pratiques suivantes couvre une ou plusieurs lignes de cette liste.

Méthode 1. Concevoir la perception : ce que l'agent doit précisément voir

Commençons par la couche la plus coûteuse. Imaginez que vous demandiez à un collègue de trouver le prix sur un site, mais qu'au lieu du lien, vous lui envoyiez une impression du code source de la page sur 200 feuilles. C'est à peu près ce que ressent le modèle qui reçoit du HTML brut. L'objectif de la méthode est de transformer la page en une représentation compacte mais suffisante.

Trois formats et leur coût

• HTML nettoyé. On retire scripts, styles, éléments invisibles, attributs techniques. Compression d'un facteur 5 à 10. La structure est conservée, mais reste verbeuse.
• Arbre d'accessibilité. Le navigateur construit lui-même un arbre sémantique pour les lecteurs d'écran : rôle de l'élément (bouton, lien, champ), nom, état. Compression de 20 à 50 fois par rapport au HTML. C'est dans ce format que les frameworks modernes présentent le plus souvent la page à l'agent. Chaque élément interactif reçoit un court identifiant numérique, et le modèle dit « clique sur 17 » plutôt que « clique sur le bouton avec la classe btn-primary dans le troisième div ».
• Capture d'écran. Une image coûte environ l'équivalent d'un ou deux mille tokens de texte, mais porte un contexte visuel : disposition, couleur, ce qui est recouvert par une fenêtre modale. Indispensable pour les interfaces canvas et les widgets capricieux.

Règle pratique : le mode principal est l'arbre d'accessibilité avec identifiants, la capture d'écran se déclenche sur trigger (une action n'a pas produit le résultat attendu deux fois de suite, ou un élément est introuvable).

Configuration pas à pas de la couche de perception

1. Définissez les entités cibles. Pour chaque type de tâche, notez les champs dont l'agent a réellement besoin : prix, disponibilité, titre, date. Tout le reste est du bruit.
2. Introduisez un filtrage de visibilité. Ne transmettez que les éléments dans la zone visible et un peu au-delà. Une page de vingt écrans ne doit pas entrer entièrement dans le contexte.
3. Normalisez le texte. Réduisez les espaces, tronquez les blocs répétitifs (menus, pieds de page) après leur première apparition dans la session.
4. Ajoutez des deltas. Après une action, transmettez au modèle non pas toute la page, mais les changements par rapport à l'état précédent. Cela réduit l'historique de plusieurs ordres de grandeur.
5. Réglez la limite de contexte de l'historique. Ne conservez les observations complètes que pour les deux ou trois dernières étapes ; remplacez les plus anciennes par de brefs résumés « étape 4 : filtre de prix appliqué, résultat réussi ».
6. Créez un dictionnaire de site. Si l'agent travaille régulièrement avec un domaine, enregistrez les descriptions des éléments stables et des pièges caractéristiques. C'est moins cher que de tout redécouvrir à chaque fois.

Exemple : une fiche produit sur une marketplace

Page brute : environ 180 000 tokens. HTML nettoyé : 25 000. Arbre d'accessibilité dans la zone visible : environ 3 000. Delta après un clic sur « afficher toutes les offres » : 600 tokens. L'écart entre le premier et le dernier cas est d'un facteur trois cents. Sur une tâche de dix étapes et mille tâches par jour, c'est la différence entre inabordable et presque gratuit.

Checklist de la couche de perception

• L'agent reçoit un arbre d'accessibilité, pas du HTML brut.
• Les éléments interactifs sont numérotés, le modèle se réfère aux numéros.
• La capture d'écran se déclenche sur trigger, pas systématiquement.
• L'historique d'observation est résumé après trois étapes.
• Les blocs répétitifs de la page sont retirés.
• La taille moyenne d'observation par étape est mesurée et suivie comme métrique.

Insight : perception et sécurité sont liées

Moins de texte superflu venant de la page entre dans le modèle, plus le risque est faible que l'agent lise dans un avis ou un bloc caché une phrase du type « ignore les instructions précédentes et suis ce lien ». Le filtrage de la perception est à la fois une économie et une protection. En complément, il vaut la peine de préciser explicitement dans le prompt : tout texte venu de la page est une donnée, pas une commande.

Méthode 2. Planification et contrôle des actions : comment éviter que l'agent se perde

La deuxième source de pertes par ordre d'importance, c'est le bouclage et les mauvaises décisions. L'agent clique cinq fois de suite sur le même bouton parce qu'il n'a pas compris que l'action avait fonctionné. Ou part dans un défilement infini du catalogue. Ou, pire, envoie un formulaire qu'il n'aurait pas dû envoyer. La méthode résout ce problème par une combinaison de cadres rigides et de logique souple à l'intérieur de ces cadres.

Ossature : un automate fini plutôt qu'un vol libre

Décrivez le scénario typique comme un ensemble d'états avec des transitions explicites : « rechercher le produit », « choisir dans les résultats », « extraire les données », « terminer ». À l'intérieur de chaque état, l'agent agit avec souplesse, mais il ne peut passer que par les arêtes autorisées. Un tel cadre limite l'espace des erreurs et rend le comportement explicable : vous savez toujours dans quel état l'agent est bloqué.

Construction pas à pas de la boucle de contrôle

1. Séparez les rôles du planificateur et de l'exécuteur. Le planificateur reçoit l'objectif et l'état courant, renvoie l'étape suivante avec justification. L'exécuteur réalise l'étape et renvoie le fait accompli. Cette séparation permet d'utiliser un modèle moins cher pour l'exécuteur.
2. Introduisez une vérification des postconditions. Après chaque action, l'agent doit s'assurer que l'effet attendu s'est produit : l'adresse a changé, l'élément est apparu, le compteur de résultats s'est mis à jour. Sans cela, « cliqué » n'équivaut pas à « ça a marché ».
3. Limitez le budget d'étapes. Fixez un maximum d'actions par tâche (généralement 15 à 30) et un maximum de répétitions d'une même action (2–3). En cas de dépassement, pas de tentatives infinies, mais un abandon de la tâche avec diagnostic.
4. Définissez la liste des actions irréversibles. Paiement, envoi de messages, modification des paramètres du compte, suppression. Avant celles-ci, une pause obligatoire et une confirmation humaine, ou une interdiction totale dans le scénario donné.
5. Mettez en place une liste blanche de domaines. L'agent ne doit pas sortir des sites autorisés, même si la page contient un lien tentant.
6. Ajoutez un mécanisme de réflexion en cas d'échec. Si deux actions consécutives n'ont rien donné, l'agent passe en mode diagnostic : il fait une capture d'écran, décrit ce qu'il voit et replanifie. C'est plus cher qu'une étape ordinaire, mais moins que dix clics inutiles.
7. Prévoyez des points de reprise. Les scénarios longs doivent pouvoir reprendre après une panne de navigateur ou de réseau depuis un état sauvegardé, et non de zéro.

Exemple : comparer les résultats dans plusieurs régions

Tâche d'un marketeur : vérifier l'apparence du top des résultats pour dix requêtes dans cinq régions. Un agent naïf ouvre le moteur de recherche et vérifie tout séquentiellement — cinquante cycles, chacun avec ses erreurs. L'approche par ossature : état « établir le contexte régional » (via le proxy correspondant et les paramètres), état « exécuter la requête », état « extraire les positions », état « valider » (dix positions, chacune avec adresse et titre). En cas de résultat invalide — une seule répétition, puis marquage « à vérifier manuellement ». La planification se réduit à parcourir la matrice, le modèle n'intervient que sur l'extraction et la validation. Le coût chute d'un ordre de grandeur et la prévisibilité augmente.

Grille d'évaluation de la maturité de la boucle de contrôle

• Existe-t-il une liste explicite d'états et de transitions ?
• Le résultat de chaque action est-il vérifié ?
• Un budget d'étapes et de répétitions est-il fixé ?
• Les actions irréversibles sont-elles listées et protégées ?
• Existe-t-il une liste blanche de domaines ?
• Que fait l'agent quand il ne comprend pas ce qui se passe ?
• Peut-on reprendre une tâche en cours de route ?

Si ne serait-ce que deux réponses sont « non », l'agent n'est pas encore prêt à travailler sans surveillance.

Insight : le meilleur agent est celui qui réfléchit rarement

C'est paradoxal, mais la maturité d'un système se mesure à la rareté de ses appels au modèle. Tout ce qui peut être fait de manière déterministe — transitions, attentes, validation par schéma — doit être fait par le code. Le modèle est nécessaire là où la réalité est imprévisible : interprétation d'une page non standard, choix entre des éléments similaires, récupération après un échec. Un tel agent IA est moins cher, plus rapide et, surtout, plus explicable.

Méthode 3. Couche réseau et identité de session : le rôle des proxys mobiles

Passons maintenant à la couche que les développeurs sous-estiment le plus et que les marketeurs surestiment. Le développeur pense : « J'ai branché un proxy, c'est réglé. » Le marketeur pense : « Le proxy va résoudre tous les problèmes. » La vérité est entre les deux : la couche réseau détermine ce que l'agent verra et combien de temps il pourra travailler, mais elle exige la même rigueur d'ingénierie que les autres.

Pourquoi un agent a besoin d'une couche réseau maîtrisée

• Contexte régional. Prix, assortiment, langue de l'interface, résultats des moteurs de recherche, publicité affichée : tout dépend du point de sortie. Un agent qui vérifie les créatives d'un affilié ou les prix locaux doit sortir de la région voulue, sinon les données sont inutiles.
• Répartition de la charge. Cent agents parallèles depuis une même adresse ressemblent à une anomalie et créent une charge anormale sur le site. Répartir sur un pool d'adresses, c'est à la fois un comportement correct envers la ressource et la stabilité de votre travail.
• Isolation des sessions. Différentes tâches et différents comptes avec lesquels vous travaillez légalement ne doivent pas se croiser dans un même contexte réseau.
• Résilience. Les pannes réseau et la dégradation d'un canal ne doivent pas arrêter tout le pipeline.

Pourquoi précisément des proxys mobiles

Les proxys mobiles acheminent le trafic via les réseaux d'opérateurs cellulaires. Ils ont une propriété qui en fait le choix naturel pour les agents : les adresses des opérateurs sont utilisées simultanément par un nombre immense d'abonnés réels et changent constamment lors des reconnexions. Pour un site, ce trafic est indiscernable de celui d'utilisateurs ordinaires d'Internet mobile dans la région donnée, et c'est exactement ce dont on a besoin quand l'objectif de l'agent est de voir le site comme un visiteur ordinaire. Les adresses de datacenters, à l'inverse, sont rarement associées à des personnes réelles, et les systèmes de défense les traitent plus sévèrement en appliquant des limites de fréquence plus strictes.

Il existe un second avantage, spécifique à l'audience mobile : une part énorme des achats et des clics publicitaires se fait depuis un smartphone. Un agent qui vérifie la version mobile d'une landing page, les résultats mobiles ou l'application mobile d'une marketplace via l'interface web doit aussi ressembler à un client mobile sur le réseau. Proxy mobile plus profil de navigateur mobile donnent une image cohérente.

Le principe de cohérence de l'identité

L'erreur principale de la couche réseau, c'est l'incohérence. L'agent sort d'une région sur le réseau, mais le fuseau horaire du navigateur correspond à une autre, la langue de l'interface à une troisième, et la résolution d'écran à un moniteur de bureau alors que l'adresse est mobile. Ces contradictions, les sites les repèrent et y réagissent par une attention accrue : ils affichent plus souvent des vérifications, restreignent les fonctionnalités, renvoient une version dégradée. La tâche de l'architecte est de construire un profil de session dans lequel tous les paramètres sont cohérents : région de l'adresse, fuseau horaire, langue, type d'appareil, taille d'écran. Et ce profil doit rester stable pendant toute une tâche.

Configuration pas à pas de la couche réseau

1. Définissez la matrice des régions. Pour quels pays et quelles villes vous faut-il des données. À chaque point correspond un canal de proxy mobile distinct.
2. Associez le canal à un profil de navigateur. Un contexte de navigateur, un canal, une tâche. Ne mélangez pas.
3. Réglez la politique de rotation d'adresse. Deux modes : conserver l'adresse pendant la tâche (nécessaire pour les sessions authentifiées et les scénarios multi-étapes) et changer d'adresse entre les tâches (nécessaire pour collecter des données publiques avec répartition de charge). Un bon service de proxys mobiles permet de gérer la rotation via API et par planification.
4. Fixez des limites de fréquence. L'agent doit respecter le site : des pauses entre requêtes correspondant à un comportement humain, une limitation des sessions parallèles sur un domaine. Ce n'est pas seulement de l'éthique, c'est aussi du pragmatisme : les sites que vous surchargez commencent à renvoyer des erreurs, précisément à vous.
5. Respectez les règles des ressources. Vérifiez le fichier robots et les conditions d'utilisation des sites avec lesquels vous travaillez. Des informations publiques pour la veille tarifaire et les résultats de recherche, c'est une chose ; des actions dans des comptes, c'en est une autre, et elles doivent être réalisées uniquement dans le cadre de vos droits sur ces comptes.
6. Mettez en place une vérification de la santé du canal. Avant la tâche, l'agent effectue une requête de contrôle : l'adresse répond, la région est correcte, la latence est acceptable. Un canal défaillant est automatiquement exclu du pool.
7. Loguez le contexte réseau de chaque tâche. Quel canal, quelle adresse, quelle région, quelles réponses serveur. Sans cela, vous ne distinguerez pas une erreur de modèle d'une erreur réseau.

Exemple de configuration de profil de session

{ "task_id": "price-monitor-ru-msk-042", "proxy_channel": "mobile-ru-msk-03", "rotation": "hold_until_task_end", "browser_profile": { "device": "mobile", "locale": "ru-RU", "timezone": "Europe/Moscow", "viewport": "390x844" }, "rate_limit": { "min_delay_ms": 1800, "max_parallel_per_domain": 2 } }

Notez bien : région du canal, locale, fuseau horaire et type d'appareil sont cohérents. C'est exactement cette identité non contradictoire.

Goulet d'étranglement : le coût du trafic

Le trafic mobile est plus cher que celui des datacenters, et un navigateur tire des images, des polices, des scripts d'analyse. L'agent n'a pas besoin de la majeure partie de cela. Bloquez le chargement des médias et des trackers tiers au niveau du navigateur, si cela n'affecte pas la fonctionnalité de la page. Une économie de trafic de 60 à 80 pour cent est un résultat typique. L'exception concerne les agents visuels, qui ont besoin de l'image complète ; pour eux, choisissez quelles tâches exigent réellement des captures d'écran.

Checklist de la couche réseau

• Chaque tâche sort via un seul canal de proxy mobile de la région voulue.
• Les paramètres du navigateur sont cohérents avec la région et le type d'appareil du canal.
• La politique de rotation est choisie consciemment selon le type de tâche.
• Des limites de fréquence et de parallélisme par domaine existent.
• Les règles d'utilisation des ressources cibles sont prises en compte.
• Le canal est vérifié avant la tâche et exclu en cas de dégradation.
• Le trafic média inutile est désactivé.
• Le contexte réseau est consigné dans le log de chaque tâche.

Méthode 4. Observabilité et économie : comment mesurer et réduire les coûts

Un agent sans métriques, c'est comme une campagne publicitaire sans analyse : l'argent part et on ne sait pas où. Cette méthode explique quoi mesurer, comment déboguer et où chercher des économies.

Les cinq métriques clés d'un agent web

• Taux de tâches réussies. Et « réussie » doit être vérifié automatiquement selon le schéma de résultat, et non selon l'auto-déclaration de l'agent. Les agents ont tendance à déclarer le succès avec optimisme.
• Nombre d'étapes par tâche. S'il augmente, c'est que l'agent s'est mis à errer ; comparez avec la trajectoire de référence.
• Coût de la tâche. Tokens du modèle plus trafic plus temps de runtime. Comptez en argent, pas en tokens — c'est plus parlant pour le business.
• Durée de la tâche. Médiane et 95e centile. La queue de distribution indique généralement les bouclages.
• Causes d'échec par catégories. Réseau, protection du site, erreur de modèle, changement de mise en page, timeout. Sans catégorisation, vous ne savez pas quelle couche soigner.

La trace de tâche comme unité de débogage

Chaque tâche doit laisser une trace : la séquence des étapes, et pour chacune — l'observation (sous forme compressée), la décision du modèle avec justification, l'action, le résultat de la vérification de postcondition, la capture d'écran au moment de la décision. Une telle trace permet de comprendre en une minute où exactement les choses ont mal tourné. Stocker les traces de toutes les tâches coûte cher ; stockez-les intégralement pour les échecs et de façon sélective pour les succès.

Construire pas à pas un agent économique

1. Mesurez le coût de base. Lancez cent tâches typiques et calculez le coût moyen et la distribution. Sans base, pas d'optimisation.
2. Identifiez la couche la plus chère. C'est généralement la perception (60 à 80 pour cent des tokens). Appliquez la méthode 1.
3. Introduisez un routage des modèles. Extraction de données par schéma, vérification de postconditions, choix simples — modèle bon marché. Planification, récupération après échec — modèle coûteux. Répartition typique dans un système mature : 70 à 85 pour cent des appels vont au modèle bon marché.
4. Mettez en cache ce qui est stable. Instructions système, description des outils, dictionnaires de sites — tout cela peut être mis en cache côté fournisseur du modèle, en économisant le retraitement.
5. Remplacez le modèle par du code là où la trajectoire s'est stabilisée. Si l'agent a parcouru cent fois le même site par le même chemin, figez ce chemin comme scénario déterministe avec vérifications, et ne gardez le modèle que pour traiter les écarts. C'est ce qu'on appelle la compilation de trajectoire, et c'est la source d'économies la plus puissante sur les scénarios matures.
6. Introduisez des budgets. Limite de coût par tâche et par jour avec arrêt automatique. Les agents partis en boucle sont capables de brûler un budget hebdomadaire en une heure.

Repères chiffrés

D'après nos observations sur des tâches typiques de veille et de vérification, un agent naïf sur un modèle phare avec du HTML brut dépense pour une tâche en dix étapes une somme équivalente au prix de plusieurs cafés, et le fait en deux à trois minutes. Après application des quatre méthodes, la même tâche coûte 20 à 50 fois moins cher et s'exécute en 20 à 40 secondes, tandis que le taux de succès passe de 50–60 à 85–95 pour cent. La dispersion est grande, car elle dépend des sites, mais l'ordre de grandeur est stable. Les benchmarks publics d'agents web autonomes montrent une image similaire : les meilleurs systèmes résolvent environ deux tiers des tâches, les moyens la moitié, et l'écart est déterminé moins par le modèle que par l'ingénierie autour de lui.

Checklist de l'observabilité

• Le succès de la tâche est vérifié automatiquement par schéma.
• Les cinq métriques sont collectées et visibles sur un tableau de bord.
• Les échecs sont catégorisés par couches.
• Les traces des tâches échouées sont conservées intégralement.
• Des budgets par tâche et par jour existent.
• Un ensemble de régression de tâches est exécuté à chaque modification de prompts, de modèles ou d'outils.

Erreurs classiques dans la construction d'agents web

Rassemblons les pièges dans lesquels presque chaque équipe tombe. Certains ont déjà été mentionnés, mais les répéter ici se justifie : ce sont ces erreurs qui coûtent des mois.

Erreur 1. Commencer par l'autonomie totale

L'équipe construit d'emblée un agent de niveau quatre, qui se fixe lui-même ses sous-tâches. Résultat : un comportement imprévisible et un débogage impossible. Commencez par un mode semi-autonome avec un humain dans la boucle, accumulez les traces, stabilisez, puis augmentez l'autonomie.

Erreur 2. Faire confiance à l'auto-déclaration de l'agent

L'agent renvoie « tâche réussie », mais les données du résultat sont vides ou obsolètes. La vérification du succès doit être externe et formelle : schéma du résultat, plages de valeurs, champs obligatoires.

Erreur 3. Donner au modèle la page brute

L'erreur la plus chère au sens littéral. Elle dégrade aussi la qualité : dans le bruit, le modèle trouve moins bien ce qu'il cherche.

Erreur 4. Une seule adresse pour toutes les tâches

Cent sessions parallèles depuis une même adresse de datacenter, ce sont des restrictions garanties de la part des sites et des données faussées. La couche réseau doit être conçue, pas branchée en dernier recours.

Erreur 5. Identité de session incohérente

Adresse mobile de la région A, navigateur de bureau avec le fuseau horaire de la région B et la langue de la région C. Ces sessions reçoivent une expérience dégradée et des vérifications fréquentes.

Erreur 6. Trop d'outils

Quarante actions disponibles au lieu de huit. Le modèle réfléchit plus longtemps, se trompe plus souvent dans ses choix et le prompt gonfle. Un ensemble minimal de primitives plus quelques actions composées adaptées au scénario : voilà l'optimum.

Erreur 7. Absence de budgets

Un agent parti en boucle la nuit brûle d'ici le matin le budget mensuel de modèle et de trafic. Les budgets stricts ne sont pas une option.

Erreur 8. Ignorer les règles des ressources

Le travail avec les sites doit rester dans le cadre de leurs conditions d'utilisation et de la législation. L'agent est votre représentant sur le réseau, et son comportement est votre responsabilité. Des données publiques pour l'analyse, des actions dans vos propres comptes, le respect des limites : oui. Tout le reste : non.

Erreur 9. Ne pas distinguer les types d'échec

« Ça n'a pas marché » n'est pas un diagnostic. Une erreur réseau se soigne sur une couche, un changement de mise en page sur une autre, une hallucination sur une troisième. Sans catégorisation, l'équipe répare ce qu'il ne faut pas.

Erreur 10. Ne pas se protéger des injections via le contenu

La page est une source non fiable. Le texte qu'elle contient peut renfermer des instructions que le modèle prendra pour des commandes. Filtrage de la perception, séparation explicite des données et des commandes dans le prompt, liste blanche de domaines et interdiction des actions irréversibles sans confirmation : le minimum obligatoire.

Erreur 11. Absence d'ensemble de régression

On change le prompt : c'est mieux sur un site et pire sur cinq autres, mais on ne l'apprend qu'une semaine plus tard. Un ensemble de 30 à 50 tâches de référence avec vérification automatique du résultat, exécuté à chaque modification, protège de cela.

Outils et ressources pour construire des agents web

L'écosystème évolue vite, donc plutôt que des versions précises, donnons une carte des catégories et des critères de choix.

Pilotage du navigateur

• Playwright — le standard de fait pour les nouveaux projets : prise en charge de tous les navigateurs principaux, isolation des contextes, attente intégrée des éléments, accès à l'arbre d'accessibilité. La plupart des frameworks d'agents sont construits par-dessus.
• Puppeteer — le prédécesseur historique pour une famille de navigateurs, encore largement utilisé.
• Selenium — le vétéran, toujours pertinent là où une grande infrastructure de test existe déjà.

Frameworks d'agents pour le navigateur

• Des bibliothèques qui transforment le navigateur en ensemble d'outils pour le modèle et implémentent la boucle d'observation et d'action : projets ouverts de la famille browser-use , Stagehand et similaires. Ils font déjà la compression de la page en arbre avec identifiants, donc la méthode 1 sous sa forme de base est fournie d'emblée.
• Des orchestrateurs généralistes avec prise en charge des graphes d'états : LangGraph et équivalents. Utiles pour implémenter l'ossature de la méthode 2.
• Les kits de développement d'agents officiels des fournisseurs de modèles avec mode de pilotage d'ordinateur. Ils donnent un agent visuel « clé en main », mais exigent une attention particulière au coût.

Runtimes de navigateur

• Services cloud de navigateurs distants avec conservation de session, enregistrement et parallélisme. Ils éliminent le mal de tête de l'infrastructure, mais vérifiez qu'ils permettent de connecter vos proxys au niveau du contexte du navigateur — c'est critique pour la méthode 3.
• Déploiement autonome en conteneurs — plus de contrôle, plus de travail. Justifié à grande échelle.

Couche réseau

• Proxys mobiles avec gestion par API. Critères clés : choix de la région jusqu'à la ville et à l'opérateur, gestion de la rotation d'adresse à la demande et par planification, stabilité du canal, prise en charge des protocoles avec lesquels fonctionne votre stack navigateur, et tarification transparente du trafic. Un plus : la possibilité d'associer un canal à un profil précis sur le long terme.
• Gestionnaire de profils de navigateur. Pour une identité de session cohérente : fuseau horaire, langue, taille d'écran, type d'appareil. Peut être un produit distinct ou un module de votre système.

Observabilité

• Plateformes de traçage des appels de modèles et des étapes d'agents, avec stockage des captures d'écran et calcul des coûts.
• Systèmes classiques de logs et de métriques — ne les négligez pas ; les métriques réseau et d'infrastructure d'un agent ne diffèrent en rien de celles de n'importe quel service.

Évaluation de la qualité

• Benchmarks publics d'agents web (ensembles de tâches sur des sites réels ou reconstitués) — utiles pour comprendre le plafond des modèles actuels.
• Votre propre ensemble de régression — irremplaçable, car vos sites et vos tâches sont uniques.

Quoi lire et quoi suivre

Suivez trois directions. Premièrement, les modèles avec pilotage natif d'ordinateur : ils deviennent rapidement moins chers et plus rapides. Deuxièmement, les standards du trafic d'agents : le secteur discute de moyens par lesquels un agent peut s'annoncer ouvertement à un site via des requêtes signées, et de fichiers descriptifs par lesquels un site explique aux agents comment travailler correctement avec lui. Troisièmement, les navigateurs d'agents pour utilisateurs finaux : ils façonnent les attentes et modifient la façon dont les sites considèrent les visiteurs automatisés.

Cas et résultats : comment cela fonctionne en pratique

Voici quatre scénarios généralisés issus de la pratique d'équipes qui travaillent avec l'automatisation et les proxys mobiles. Les chiffres sont arrondis et donnés à titre de repères, non de garantie.

Cas 1. Veille tarifaire sur les marketplaces pour un vendeur

La tâche. Un vendeur avec un assortiment de 600 références voulait connaître chaque jour les prix et la disponibilité chez huit concurrents sur deux plateformes. Auparavant, un script sur sélecteurs le faisait, mais il cassait toutes les deux semaines et exigeait deux jours de réparation.

La solution. Un agent DOM sur arbre d'accessibilité, ossature d'états « recherche, sélection de fiche, extraction, validation », routage : modèle bon marché pour l'extraction, modèle coûteux uniquement en cas d'échec. Couche réseau — pool de proxys mobiles de la région voulue, conservation de l'adresse pendant la tâche par concurrent, limite de deux requêtes parallèles par domaine, pauses de 2 à 4 secondes.

Le résultat. Taux d'extractions réussies le premier mois — 93 pour cent contre 71 pour l'ancien script lors des « bonnes » semaines. Temps de réparation après un changement de mise en page — zéro : l'agent s'est adapté seul dans 9 cas sur 10. Le coût par fiche après compilation des trajectoires est comparable au coût d'une requête à une API de données payante, mais avec un contrôle total sur la fraîcheur.

Cas 2. Vérification des créatives publicitaires et des landings par région

La tâche. L'équipe d'un affilié lançait des campagnes dans six régions et voulait vérifier automatiquement que les landings s'ouvrent correctement depuis des mobiles dans chaque région, que les redirections mènent au bon endroit et que les offres correspondent à la locale.

La solution. Un agent hybride : arbre d'accessibilité plus capture d'écran obligatoire de la page finale. Profils de session strictement cohérents : canal de proxy mobile de la région, taille d'écran mobile, langue et fuseau horaire correspondants. Le résultat de la tâche est un rapport structuré avec les champs « ouvert, temps de chargement, adresse finale, langue du contenu, capture d'écran ».

Le résultat. La vérification manuelle prenait à un spécialiste environ trois heures par jour. L'agent fait un passage complet en 12 minutes et tourne toutes les deux heures. Le premier mois, 14 incidents de redirection vers une mauvaise région ont été détectés, incidents qui n'étaient auparavant repérés qu'après une chute de conversion un ou deux jours plus tard. L'économie de budget publicitaire est estimée par l'équipe à des dizaines de pour cent de la somme qui partait auparavant dans des combinaisons non fonctionnelles.

Cas 3. Audit des résultats de recherche régionaux pour une agence SEO

La tâche. L'agence gérait des clients dans douze villes et voulait voir les résultats réels et les blocs du moteur de recherche pour 300 requêtes dans chaque ville, chaque semaine.

La solution. Un agent planificateur-exécuteur : la matrice « ville par requête » est parcourue par le code, le modèle n'intervient que pour extraire et classer les éléments de résultats (organique, cartes, blocs produits, vidéo). Couche réseau — proxys mobiles avec association du canal à la ville, rotation d'adresse entre les requêtes, pauses strictes.

Le résultat. Le coût d'une requête vérifiée s'est révélé plusieurs fois inférieur à l'abonnement à un service spécialisé, à exhaustivité comparable, et surtout, il est devenu possible d'extraire des éléments de résultats arbitraires, que le service ne proposait pas. La part de résultats vides ou invalides est inférieure à 3 pour cent, tous passent automatiquement en revérification.

Cas 4. Tests d'acceptation d'un site avant release

La tâche. Une petite équipe e-commerce sans testeur dédié voulait exécuter des parcours utilisateurs (recherche, panier, commande jusqu'à l'étape de paiement) avant chaque release, sur profils mobiles et desktop.

La solution. Un agent semi-autonome avec interdiction des actions irréversibles (le paiement est exclu au niveau de la liste des actions interdites). Les scénarios sont décrits en langage naturel, ce qui a permis au chef de produit d'en ajouter sans développeur. Les profils mobiles passent par des proxys mobiles, pour que les conditions soient au plus près des utilisateurs réels.

Le résultat. Le passage de régression de 40 scénarios — 25 minutes au lieu d'une demi-journée en manuel. En un trimestre, l'agent a attrapé 9 régressions avant la mise en production. Effet secondaire intéressant : les traces de l'agent sont devenues une documentation des parcours utilisateurs qui n'existait pas auparavant.

Ce que les cas réussis ont en commun

• La tâche avait un contrat de résultat formel.
• L'autonomie était encadrée par une ossature d'états.
• La couche réseau était conçue comme partie de l'architecture, pas branchée à la fin.
• Le coût et le succès étaient mesurés dès le premier jour.
• Le modèle était utilisé avec parcimonie, le code déterministe partout où c'était possible.

FAQ : questions qui surgissent en deuxième semaine de pilote

En quoi un agent IA diffère-t-il fondamentalement d'un scraper avancé ?

Un scraper exécute une séquence prédéfinie et extrait des données selon des règles fixes. Un agent reçoit un objectif, construit lui-même un plan, observe le résultat de chaque action et s'adapte. Le scraper est déterministe et bon marché, mais fragile. L'agent est souple, mais plus cher et exigeant en contrôle. En pratique, l'optimum est un hybride : l'agent explore et se remet des échecs, tandis que les trajectoires stables sont compilées en code déterministe.

Quel modèle choisir pour un agent web ?

Pas un seul, mais au moins deux. Un modèle bon marché et rapide — pour extraire des données par schéma, vérifier et prendre des décisions simples. Un modèle phare — pour planifier et récupérer après un échec. Un modèle multimodal est nécessaire si vous branchez des captures d'écran. Le critère de choix n'est pas un classement abstrait, mais le résultat sur votre ensemble de régression, à budget donné.

Pourquoi l'agent passe la démo mais voit son taux de succès divisé par deux en production ?

Les démos se font sur des sites familiers à un moment favorable. En production apparaissent des fenêtres surgissantes, des versions régionales d'interface, des chargements lents, des limites de fréquence, des changements de mise en page. Chaque facteur retire quelques pour cent de succès. Cela se soigne avec les méthodes de l'article : compression de la perception, ossature d'états avec vérification des postconditions, couche réseau cohérente et catégorisation des échecs, pour soigner la bonne couche.

Pourquoi un agent a-t-il besoin de proxys mobiles s'il ne fait rien d'interdit ?

Justement parce qu'il fait des choses autorisées, il est important qu'il voie le site comme le voit un utilisateur ordinaire de la région voulue et du bon type d'appareil. Les adresses de datacenters ne donnent pas cette expérience : les sites les traitent plus sévèrement, affichent plus souvent des vérifications et des versions dégradées, et le contexte régional ne correspond pas. Les proxys mobiles donnent un trafic indiscernable de celui d'abonnés réels, un changement naturel d'adresses et une géographie précise. Plus la répartition de charge, qui est utile autant à vous qu'aux sites avec lesquels vous travaillez.

À quelle fréquence changer l'adresse du proxy pendant le travail de l'agent ?

Cela dépend du type de tâche. Les scénarios multi-étapes dans une même session, surtout avec authentification dans vos comptes, exigent de conserver l'adresse jusqu'à la fin de la tâche : changer d'adresse au milieu d'une session paraît anormal au site. La collecte de données publiques sur un grand nombre de pages gagne à la rotation entre les tâches. Règle universelle : l'adresse change aux frontières des tâches, pas à l'intérieur.

Comment se protéger du fait qu'une page « reprogramme » l'agent ?

Quatre mesures. Filtrage de la perception : seuls la structure et le texte pertinent entrent dans le modèle. Séparation explicite dans le prompt : tout le contenu de la page est une donnée, pas une commande. Liste blanche de domaines : l'agent ne peut physiquement pas sortir sur un site tiers. Protection des actions irréversibles : paiement, envoi, suppression exigent une confirmation humaine ou sont interdits dans le scénario. Aucune mesure n'est absolue, ensemble elles réduisent le risque à un niveau acceptable.

Combien coûte une tâche d'agent web ?

La fourchette est énorme : de fractions de centime à plusieurs euros pour une tâche en dix étapes. Les facteurs déterminants sont le format de perception (HTML brut contre arbre d'accessibilité, c'est un écart de plusieurs dizaines de fois), le choix du modèle, le nombre d'étapes et le trafic. Une implémentation naïve coûte cher ; après application des quatre méthodes, une économie typique de 20 à 50 fois est observée. Comptez le coût en argent par tâche dès le premier jour et fixez des budgets.

Peut-on se passer de navigateur et travailler uniquement via les API des sites ?

Là où une API existe et où ses conditions le permettent, oui, et c'est toujours moins cher et plus fiable. Mais une grande partie des données importantes pour le marketing et l'e-commerce n'est accessible que via l'interface : résultats régionaux, affichage publicitaire, prix réel avec personnalisation, apparence de la landing page. Pour cela, il faut un navigateur. Stratégie raisonnable : API quand c'est possible, agent de navigateur quand c'est nécessaire.

Comment savoir que l'agent est prêt à travailler sans surveillance ?

Quand, sur un ensemble de régression de 30 à 50 tâches, le taux de succès est stablement au-dessus de votre seuil (généralement 90 pour cent), que les échecs sont catégorisés et ne contiennent pas de « cause inconnue », que les actions irréversibles sont protégées, qu'il existe des budgets et des alertes, et que les traces permettent d'analyser tout incident en quelques minutes. Jusque-là, gardez un humain dans la boucle, au moins pour une vérification sélective des résultats.

Qu'est-ce qui changera dans les agents web dans un à deux ans ?

Trois tendances. Les modèles avec pilotage natif d'ordinateur deviendront moins chers et plus rapides, faisant pencher la balance vers les agents visuels. Des moyens consensuels apparaîtront par lesquels un agent s'annonce ouvertement à un site et le site explique aux agents les règles d'interaction — cela rendra les relations entre clients automatisés et ressources plus transparentes. Et les navigateurs d'agents pour utilisateurs ordinaires habitueront les sites au fait qu'une part significative des visiteurs agit via un intermédiaire. Pour ceux qui travaillent avec l'automatisation, cela signifie : l'ingénierie autour du modèle, y compris la couche réseau, restera le principal avantage concurrentiel, car les modèles eux-mêmes s'égalisent rapidement.

Conclusion : un agent est un système, pas un modèle

S'il ne fallait retenir qu'une idée de cet article, la voici : la qualité d'un agent web ne dépend pas du modèle qu'il a à l'intérieur, mais de la manière dont sont conçues les couches autour de lui. La perception décide de combien vous payez et de la qualité avec laquelle l'agent comprend la page. La boucle de contrôle décide s'il se perdra. La couche réseau décide de ce qu'il verra réellement et s'il pourra travailler de façon stable. L'observabilité décide si vous apprendrez les problèmes avant qu'ils ne deviennent chers.

Nous avons passé en revue l'architecture en sept couches et la carte des goulets d'étranglement, quatre méthodes pratiques avec checklists, onze erreurs classiques, une carte des outils et quatre scénarios où tout cela a fonctionné. Que faire ensuite ?

1. Choisissez une tâche à la valeur claire et au critère de succès formel. Veille tarifaire, vérification de landings par région, audit de résultats de recherche — n'importe quoi que vous faites aujourd'hui à la main ou avec un script fragile.
2. Construisez un agent semi-autonome sur arbre d'accessibilité avec ossature d'états et budget d'étapes. Ne courez pas après l'autonomie.
3. Concevez la couche réseau dès le départ. Proxys mobiles de la région voulue, profil de session cohérent, limites de fréquence, respect des règles des ressources.
4. Activez les métriques dès le premier lancement. Succès, étapes, coût, durée, catégories d'échec.
5. Accumulez cent traces, constituez un ensemble de régression et seulement ensuite optimisez : routage des modèles, compression de l'historique, compilation des trajectoires.

Le web a été construit pour les humains, et les agents n'y sont pas à leur aise. Mais c'est précisément pour cela qu'un agent IA bien conçu offre un tel avantage : il fait ce que seuls des humains faisaient auparavant, avec la vitesse et l'échelle d'une machine. La tâche de l'ingénieur est de faire en sorte que cette machine voie clairement, réfléchisse économiquement, agisse avec soin et se présente sur le réseau comme un visiteur respectable. Alors les goulets d'étranglement deviennent des problèmes d'ingénierie bien identifiés, et l'agent un collaborateur fiable qui ne se fatigue jamais.