La curiosité, c’est ce qui vous rend doué pour utiliser l’IA

Avant les agents, je créais des automatisations avec l’IA dans n8n. Il fallait comprendre ce qui se passait, puisque vous construisiez vous-même chaque étape.

Vous ajoutez un nœud. Vous le lancez. Vous récupérez une charge utile JSON. Vous l’examinez et vous faites correspondre ses clés à l’étape suivante : ce champ alimente le prompt système, celui-là le message utilisateur, et cet autre définit la structure de la sortie structurée afin que vous puissiez réutiliser ses clés trois étapes plus tard.

La configuration prend du temps, mais elle vous apprend tout. Vous finissez par avoir une représentation très concrète de ce qu’est réellement un appel à l’IA : une étape, avec une entrée que vous avez choisie, un prompt que vous avez écrit et une sortie dont vous devez faire quelque chose.

Ce que cela vous obligeait à bien faire

Prenons un vrai exemple. Un ticket de retour produit arrive via un webhook. Vous transmettez le texte à un modèle chargé uniquement de le catégoriser : est-ce un bug ? Est-ce urgent ? Vous lisez la réponse et, si c’est urgent, vous l’envoyez dans une notification Slack accompagnée d’un résumé en deux lignes pour que l’équipe soit au courant.

Trois petites étapes. Chacune avec son propre prompt, qui ne contient que les éléments nécessaires à cette étape.

Personne ne donne toute l’entreprise au modèle en croisant les doigts. Vous ne pouviez pas le faire, l’outil ne le permettait pas.

Les agents ont fait disparaître tout cela

Aujourd’hui, j’ouvre Claude Code et je lui soumets le problème. Il lit mes fichiers, appelle les outils que j’ai connectés et décide tout seul de la suite. Ça marche, pour presque tout, et c’est précisément pour cela que ça vaut la peine de l’utiliser.

Mais les agents masquent aussi tous les concepts évoqués plus haut. Et dans certaines configurations, ils chargent la description de chaque outil de chaque connecteur avant même que vous posiez une question. Cela consomme beaucoup de tokens pour des capacités dont vous n’aurez pas besoin aujourd’hui.

Pourquoi cela vous concerne, même si vous ne lancez jamais de produit

Deux choses déraillent quand vous ne regardez pas.

Votre budget. Si vous avez brûlé en tokens le budget d’une semaine dès mercredi, le problème de jeudi et vendredi, vous l’avez créé lundi.

Votre cycle d’itération. Si chaque réponse prend quinze minutes, vous cessez d’itérer. Vous donnez une instruction, passez à autre chose, revenez, constatez que ça a déraillé et recommencez. Le coût, ce n’est pas les quinze minutes : c’est que vous n’avez plus que quatre essais dans la journée.

Il y a aussi le modèle que vous utilisez. La plupart d’entre nous en prennent un gros pour tout, alors que pour plus de la moitié de nos tâches, un modèle plus petit répondrait plus vite, aussi bien et pour moins cher. La règle générale tient : plus petit, c’est moins cher et plus rapide ; plus intelligent, c’est plus lent et plus coûteux. Savoir quelles tâches relèvent de l’une ou l’autre catégorie peut vous faire économiser beaucoup d’argent.

Et si vous lancez un produit, ce n’est pas un détail

Quand c’est vous qui êtes au clavier, une tâche qui prend dix ou douze minutes, c’est (à peu près) pareil. Vous vérifierez plus tard.

Présentez la même chose à un client et les chiffres prennent un autre sens. Quelqu’un téléverse un fichier, votre mappage automatique prend vingt-cinq secondes, et c’est terminé. Pas quatre minutes. Vingt-cinq secondes.

J’ai découvert la version la plus frappante de ce problème en créant Lookio. Entre une réponse qui arrive en cinq secondes et la même réponse en neuf, l’une convient à un widget de chat et l’autre non. Entre un centime par réponse et neuf centimes, ma marge est de 85% ou de 40%, et c’est ce qui détermine le prix que je peux demander.

Même modèle, même produit. La différence tenait à la façon dont il était assemblé.

À quoi ressemble concrètement la curiosité

Vous n’avez peut-être jamais créé la version avec n8n. Vous pouvez quand même tirer l’essentiel de cette compréhension de l’agent que vous utilisez déjà.

Consultez la liste des outils proposés par un connecteur

Quand vous connectez un service, la plateforme affiche généralement tous les outils auxquels elle donne accès, avec leur nom et leur description. Prenez le temps de la lire une fois. En deux minutes, vous comprendrez mieux les possibilités de cette intégration qu’après une semaine de questions.

Si le connecteur de votre CRM ne propose aucun outil pour supprimer un contact et que vous passez dix minutes à demander à un agent de le faire, il ne fait pas preuve de paresse. Cette fonction n’existe pas, et il ne peut pas l’inventer.

Vous pouvez aussi simplement demander :

Liste tous les outils proposés par ce connecteur. Pour chacun : son nom,
sa fonction et si tu l’utiliserais pour ce que je m’apprête à demander.
Signale tout ce que je semble croire disponible, mais qui ne l’est pas.

Cliquez sur les appels d’outils

À partir de votre message, l’agent choisit entre plusieurs possibilités : appeler un outil, rédiger une note intermédiaire pour vous dire ce qu’il va faire, ou vous répondre et s’arrêter là. Ensuite, il lit le résultat et choisit à nouveau. C’est cette boucle.

Dans Claude Code, vous pouvez cliquer sur n’importe lequel de ces appels pour voir ce qu’il contient.

Ouvrez-en quelques-uns et la magie disparaît, et c’est tant mieux. L’agent n’invente rien. Il lit ce qu’un outil lui a renvoyé, comme il lit un fichier, puis décide quoi en faire.

Demandez-lui comment il compte s’y prendre avant de le laisser faire

Imaginons que vous demandiez un MP4 créé à partir de code plutôt que d’images filmées. Demandez-lui comment il compte s’y prendre.

Il vous expliquera qu’il écrit le HTML et le CSS de l’animation, effectue le rendu dans un navigateur sans interface graphique, enregistre les images, puis les encode en vidéo.

Vous savez maintenant quelque chose d’utile. Vous avez déjà le HTML qui sert à construire votre site, avec ses polices et ses couleurs. Vous pouvez donc poser la question suivante : peux-tu réutiliser les styles de mon site pour que la vidéo lui ressemble ?

Vous n’auriez pas pensé à poser cette question une heure plus tôt. C’est en comprenant le processus que l’idée est venue.

Avant de commencer : comment comptes-tu t’y prendre ? Quels outils,
dans quel ordre, et que produit chaque étape ? N’écris pas encore de
code.

Demandez trois façons de faire, pas une seule

L’une sera rapide à construire, mais rigide. Une autre prendra du temps à construire, mais acceptera toutes les données que vous lui soumettrez. La troisième sera entre les deux.

Si on le laisse faire, un agent choisit la solution la plus simple qui fonctionne. C’est un bon choix par défaut, mais ce n’est souvent pas ce que vous voulez. Le remettre en question ne coûte qu’un message.

Donne-moi trois façons de faire, avec les compromis de chacune : le
temps de développement, les façons dont elle peut échouer et son coût
d’utilisation. Dis-moi laquelle tu choisirais et pourquoi.

Demandez ce qui a pris le plus de temps et ce qui lui a manqué

Après une tâche qui a coûté cher, demandez quelles étapes ont pris le plus de temps et s’il disposait des bons outils pour la réaliser.

C’est là que vous découvrez qu’il bricolait une solution de remplacement. Demandez-lui de récupérer des données sur des entreprises depuis LinkedIn : sans outil adapté, il improvisera une méthode lente et peu fiable. Donnez-lui un vrai service d’extraction de données, comme Apify, et tout se résume à un seul appel.

J’ai fait ça pour le rendu de mes propres vidéos. J’ai demandé si l’encodage pouvait être plus rapide. Le temps est passé de quinze minutes à trois. Même résultat. Ça m’a changé la journée : faire cinq essais n’occupait plus tout l’après-midi.

C’est fait. Maintenant, reviens sur ta méthode : quelles étapes ont pris
le plus de temps, où as-tu dû contourner l’absence d’un outil, et que
ferais-tu autrement ? Essaie la meilleure version, puis dis-moi ce qui
a changé et dans quelle mesure.

Essayez-en trois avant d’en traiter deux cents

Avant de confier à un agent l’analyse de 200 concurrents, demandez-lui d’en traiter 3. Puis demandez-lui ce qui a été difficile à trouver, ce qui a pris du temps et où il a dû deviner.

Vous corrigerez le processus tant que les changements ne coûtent pas cher. Parfois, il suffit de lui donner un outil qui lui manquait. Parfois, il faut simplement formuler la demande autrement.

Avant de le faire pour les 200, fais-le pour 3. Dis-moi ensuite ce qui a
marché, ce qui n’a pas marché et ce que tu changerais. Si ça peut aider,
recommence jusqu’à trois fois avec ces 3. Quand la méthode te convient,
explique-moi comment elle fonctionne et attends mon accord avant de
traiter les 197 autres.

Ce que cela apporte au final

Chacune de ces questions prend une minute et vous rend une partie de ce que les outils ne vous laissaient plus voir.

Au bout d’un moment, vous ne confiez plus tout le problème à l’agent en espérant que ça marche. Vous savez à peu près ce qui se passe en coulisses : vos demandes sont plus précises, vous repérez plus tôt les réponses erronées formulées avec assurance et vous reconnaissez, dans une tâche complètement différente, un schéma déjà rencontré.

C’est la dernière partie qui m’a le plus surpris. La plupart de mes meilleures idées de l’année écoulée sont venues de la compréhension du fonctionnement d’une chose, puis de la découverte qu’on pouvait l’appliquer tout à fait ailleurs.

Garder un espace pour expérimenter

J’ai un dossier appelé duv-lab. Son fichier AGENTS.md le décrit en une ligne : un laboratoire, rien n’est destiné à la production, et il faut s’attendre à du désordre sur les bords.

À la racine, quelques éléments sont prêts pour éviter de les configurer à nouveau : une clé OpenRouter pour tester des modèles et des identifiants Cloudflare pour mettre n’importe quoi en ligne en une minute.

Ensuite, un sous-dossier par idée, chacun autonome et supprimable avec rm -rf sans rien casser d’autre. Peindre des images avec du JavaScript, et rien d’autre. Démonter un modèle qui renvoie des probabilités plutôt que du texte. Animer une vidéo à partir de code.

L’intérêt, c’est qu’il n’y a aucun enjeu. Rien à casser, rien à justifier. La semaine dernière, j’ai enregistré l’écran de quelque chose que quelqu’un avait publié, déposé la vidéo dans un nouveau dossier et demandé : si je te demandais de créer ça, comment t’y prendrais-tu, et pourrais-tu essayer de trois façons ?

Il vous faut un espace comme celui-là. Un endroit où vous pouvez vous tromper vite, sans que cela touche au travail que vous devez réellement livrer.