--- title: "Les outils que je donne à chaque agent que je lance" description: "Cinq clés que j'intègre à tout agent utilisé : Linkup pour la recherche web, Apify pour le scraping, Softr pour le stockage, Cloudflare pour les déploiements, OpenRouter pour des appels de modèles peu coûteux. Leurs usages et les règles associées." date: 2026-09-20 language: fr canonical: https://gduv.club/fr/articles/agent-toolbox source: gduv.club --- Claude Code, Codex, ou un outil que j’ai écrit moi-même : au cours d’une semaine normale, j’en utilise trois ou quatre, et le modèle sous-jacent est plus ou moins le même. Ce qui détermine si une session aboutit, c’est ce à quoi l’agent a accès. C’est pourquoi je garde les cinq mêmes outils connectés partout. Recherche, données, stockage, déploiements, appels de modèles économiques. Aucun d’entre eux ne se soucie de l’agent qui l’appelle, et c’est là tout l’intérêt : chacun consiste en une clé dans un `.env` et une page de notes, plutôt qu’en une configuration à refaire pour chaque interface. ## Linkup, pour que la recherche web ne dépende pas de l’interface Chaque agent possède une certaine capacité web, mais on ne sait jamais exactement laquelle. Récupère-t-il la page ou une copie en cache ? Suit-il le lien qu’il a trouvé ? Abandonne-t-il discrètement face à une erreur 403 pour répondre de mémoire ? [Linkup](https://www.linkup.so) est une API de recherche conçue pour être appelée par des modèles. Une seule requête, et vous choisissez la forme du résultat : - **Des URL classées**, quand vous voulez choisir les sources vous-même. - **Une réponse sourcée**, quand le modèle a déjà parcouru plusieurs pages et que vous voulez la conclusion avec ses citations. - **Du JSON structuré**, basé sur un schéma que vous transmettez. C’est cette troisième option que j’utilise le plus. Le résultat arrive sous forme de données, ainsi un script peut l’utiliser directement au lieu qu’un agent lise de la prose pour resaisir les champs dans un fichier. Il existe également un point de terminaison de récupération qui transforme une URL connue en markdown propre en environ une seconde, ce qui est la version honnête de « lire cette page ». L’avantage sur l’outil intégré n’est pas une question de qualité, mais de cohérence. Quel que soit l’outil ouvert ce matin, la recherche web fonctionne et fonctionne toujours de la même manière. **L’avantage qui apparaît avec le volume** Un outil web natif correspond à un appel, dans une seule conversation, et la réponse n’existe qu’à cet endroit. Une clé permet à un script de lancer cinquante recherches en parallèle, de les écrire dans un fichier, et que l’agent lise ce fichier. Rechercher 80 entreprises ne demande plus 80 interactions. ## Apify, pour que toute plateforme soit accessible [Apify](https://apify.com) est une place de marché de scrapers, et il en existe pour presque tout. Mes propres posts LinkedIn avec leurs chiffres réels, les vidéos d’une chaîne YouTube, les commentaires, les transcriptions, les miniatures, les offres d’emploi. Le premier cas revient plus souvent que je ne l’aurais pensé. Quand je planifie du contenu, pouvoir dire « va chercher les chiffres réels de mes vingt derniers posts et dis-moi quelles accroches ont fonctionné » est bien plus efficace que n’importe quel tableau de bord, car la réponse arrive sous forme de tableau que je peux ensuite exploiter. Ce qui rend l’outil utilisable, ce sont les règles, contenues dans un fichier de compétences que l’agent lit avant de toucher à l’API : - **Un tableau des scrapers approuvés**, une ligne par plateforme, avec son prix par résultat et un payload que j’ai vérifié. Pour ceux-là, l’agent s’exécute sans poser de questions. - **Uniquement la tarification au résultat.** Beaucoup de scrapers demandent 25 $ par mois d’avance, ce qui est inutile si on n’en utilise un que deux fois par an. C’est un filtre strict : vérifier le modèle tarifaire, et si c’est un abonnement, passer au suivant. - **Lire le schéma d’entrée, ne pas deviner les noms de champs.** `maxItems` n’existe pas dans le scraper LinkedIn, c’est `maxPosts`. Découvrir cela via un échec d’exécution coûte un tour d’exécution. - **Toujours fixer la limite.** Une recherche par mot-clé sans limite peut renvoyer des milliers de lignes et facturer chacune d’elles. C’est la seule erreur dans toute cette installation qui coûte réellement de l’argent. Et pour une plateforme qui n’est pas encore dans le tableau : 1. **Chercher dans le store**. Tarification au résultat uniquement 2. **Lire le schéma d'entrée**. Écrire le payload à partir des champs réels 3. **En tester trois sur cinq lignes**. Comparer ce qui revient réellement 4. **Passer le gagnant à l'échelle**. Puis l'ajouter au tableau _La troisième étape est celle que les gens sautent. Deux scrapers pour le même site renvoient des payloads complètement différents, et le mieux noté n’est souvent pas celui dont la structure correspond à ce que vous construisez._ ## Softr, pour avoir un endroit où stocker les choses Un agent qui trouve des informations a besoin d’un endroit pour les garder, et cet endroit doit être accessible pour moi aussi. Un fichier JSON sur disque ne convient pas : personne ne trie, ne filtre ou ne corrige une seule cellule dans un fichier. Un Postgres avec quatorze tables que je n’ai pas conçues pose un autre problème. Une base de données [Softr](https://www.softr.io) se situe entre les deux. L’agent lit et écrit via l’API. J’ouvre la même table dans un navigateur, je la trie, la filtre, corrige une ligne, ou partage une vue avec quelqu’un. Cette seconde partie est celle que les gens oublient lorsqu’ils choisissent un stockage pour un agent, alors que c’est celle qu’on utilise quotidiennement. Je travaille chez Softr, gardez donc cela à l’esprit pour la recommandation. La raison pour laquelle je le choisirais quand même, ce sont les limites de requêtes, exceptionnellement généreuses pour ce type d’usage : **40 lectures et 30 écritures par seconde, par token**. Un agent bouclant sur une liste ne les atteint jamais. De nombreux projets n’ont d’ailleurs jamais besoin d’interface. C’est moi et les données, ou trois personnes et les données. La base de données est le produit, et construire un front-end serait un travail que personne n’a demandé. ## Cloudflare, pour transformer une expérience en URL Pour tout ce qui ne doit pas rester sur mon ordinateur. Un Worker se déploie en environ une minute : c’est suffisant pour une page, une petite API ou un agent que je souhaite tester via HTTP en utilisant leur SDK. Ce qui importe moins, c’est ce qu’il fait, et plus quand cela arrive. Une expérience qui peut être en ligne en une minute est montrée à quelqu’un ; celle qui nécessite un processus de déploiement meurt dans le dossier où elle est née. ## OpenRouter, pour que le gros modèle ne fasse pas tout La raison évidente est l’accès à tous les modèles avec une seule clé, et c’est vrai, mais ce n’est pas pour cela qu’il est dans cette liste. La vraie raison est que certains travaux ne devraient pas avoir lieu dans la conversation de l’agent. Disons que vous nettoyez 200 lignes. Si l’agent le fait tour par tour, cela fait 200 tours dans un contexte qui croît sans cesse, chaque tour relisant tout ce qui précède, sur le modèle le plus cher que vous possédez. S’il écrit plutôt un script qui lance 200 petits appels vers un modèle économique, chaque appel ne voit qu’une ligne, ils s’exécutent en parallèle, et le résultat arrive sous forme de fichier. **Ce que le script envoie** - Une ligne par appel - 200 appels simultanés - Aucun contexte partagé **OpenRouter** - Une clé, une facture - Le changement de modèle est une chaîne de caractères - Replis si l'un est indisponible **Ce qu'il atteint** - Un petit modèle rapide - Un modèle de pointe si besoin - Le dernier sorti la semaine dernière _Même travail, endroit différent. L’agent écrit le script et lit le résultat ; il ne détient jamais les 200 lignes._ C’est aussi ainsi que je teste un modèle que je n’ai jamais utilisé. Je change une chaîne de caractères, je lance le même script, je compare avec le précédent. Le compte et la clé restent les mêmes. ## Les notes comptent autant que les clés Rien de tout cela ne reste dans ma tête, et rien non plus dans une interface. Chaque outil a son fichier de compétences : le nom de sa clé, le point de terminaison qui fonctionne réellement, les limites et les erreurs que j’ai déjà commises. Celui d’Apify contient le tableau des scrapers. Celui de Softr note que `GET /fields` renvoie une erreur 405 et que le schéma provient du point de terminaison des tables. Ce sont des détails, mais un agent qui doit redécouvrir un point de terminaison à chaque session finira par le redécouvrir mal, et vous affirmera que cela a fonctionné. J’ai écrit il y a quelque temps que les serveurs MCP étaient [la dernière partie de mon installation qui avait encore une forme d’outil plutôt que de fichier](harness-agnostic-workspaces), car chaque interface nécessite une configuration séparée et finit par diverger. Une clé dans un `.env` et un fichier Markdown à côté n’ont pas ce problème. Tout agent capable de lire un fichier et de lancer `curl` possède toute la boîte à outils, et passer à un nouvel agent ne coûte rien. ## Ce que je n’ai pas encore essayé [Monid](https://monid.ai) agrège Apify, Apollo et quelques centaines d’autres fournisseurs de données derrière un seul solde, vous payez donc par appel plutôt que de vous abonner à chacun. Ils se décrivent comme l’OpenRouter des outils d’agents, ce qui correspond grosso modo à ce que je voulais. Je n’en ai pas encore eu assez besoin pour le tester sérieusement, je ne peux donc pas vous dire si cela tient la route. C’est le prochain sur la liste. Voilà l’installation. Cinq clés et quelques pages de notes, et je n’ai plus à vérifier si l’agent du jour peut accéder à l’outil dont j’ai besoin.