Vibe coding contre ingénierie agentique : la différence tient à une mesure

Un plugin qui refetchait la même page cinq fois

Cette semaine, j'ai patché un plugin Claude Code que j'utilise pour des audits SEO automatisés. Le symptôme : sur un audit complet, plusieurs agents spécialisés (technique, contenu, données structurées) rappelaient chacun la même page pour l'analyser, indépendamment les uns des autres. Mon intuition de départ : mutualiser ce fetch dans un cache partagé entre agents ferait baisser la consommation de tokens.

Cette intuition était fausse, et c'est justement ce qui m'a semblé intéressant à raconter.

L'intuition ne suffit pas, la mesure si

Dans l'architecture des agents IA de type Claude Code, chaque sous-agent tourne dans son propre contexte isolé. Un cache partagé évite de refaire tourner un rendu de page plusieurs fois (un vrai gain de temps et de calcul), mais il ne change rien au nombre de tokens consommés par chaque agent : que le contenu vienne d'un nouveau rendu ou d'un fichier en cache, l'agent doit de toute façon le charger dans son propre contexte pour l'analyser.

J'ai vérifié ça avant de coder quoi que ce soit. En creusant, le vrai point de friction n'était pas la répétition du fetch, mais la taille de ce que chaque agent récupérait : un résumé JSON tronqué à 500 caractères (quasi inutilisable) ou le HTML brut complet (plus de 80 000 caractères sur une page réelle), sans rien entre les deux. L'agent chargé de vérifier les données structurées (schema.org) devait systématiquement rappeler la page en entier pour être certain qu'aucun bloc n'avait été coupé par la troncature.

Le vrai patch : extraire les blocs de données structurées en entier, avant la troncature, et les exposer séparément dans le résumé. Résultat mesuré sur une vraie page : l'agent obtient sa certitude avec 9 000 caractères au lieu de 81 000, en un seul appel réseau au lieu de trois.

Ce que la mesure a changé dans ma décision

Sans avoir mesuré, j'aurais patché la mauvaise chose : un cache qui aurait coûté du temps de développement et de maintenance de fork pour un gain de tokens quasi nul. La mesure a redirigé l'effort vers ce qui comptait réellement : la taille du contenu qui entre dans le contexte de chaque agent, pas le nombre de fois où on va le chercher.

C'est exactement la ligne de démarcation entre le vibe coding et l'ingénierie agentique. Le vibe coding, c'est déléguer à un agent IA et accepter le résultat sans jamais vérifier ce qu'il a réellement consommé pour y arriver. L'ingénierie agentique, c'est traiter chaque délégation comme une hypothèse à confirmer : est-ce que l'agent a fait ce que je pensais, au coût que je pensais ?

Trois réflexes qui tiennent la route au quotidien

Mesurer avant de patcher. Une intuition sur "ce qui coûte cher" dans un pipeline d'agents se vérifie en quelques minutes (faire tourner le même agent deux fois, avant/après, sur un cas réel) avant d'investir du temps dans une correction qui pourrait ne rien changer.

Préférer des agents spécialisés par tâche à un agent généraliste. Un agent qui ne fait que vérifier les données structurées peut avoir des instructions précises sur où chercher et quoi ignorer. Un agent généraliste "fais l'audit SEO" doit deviner à chaque fois ce qui est pertinent, ce qui coûte en tokens de raisonnement.

Ne pas sur-cadrer la délégation. Donner le contexte nécessaire et laisser l'agent trouver son chemin produit souvent un meilleur résultat que de prescrire chaque étape. Dans mon cas, j'ai laissé l'agent de mesure décider lui-même comment vérifier le contenu de la page plutôt que de lui imposer une méthode : il a spontanément écrit un script d'extraction ciblé, ce que je n'avais pas anticipé.

Pourquoi ça compte pour un Delivery Manager

Piloter des projets avec des agents IA dans la boucle, ce n'est plus une question théorique pour la plupart des équipes digitales : c'est un choix opérationnel qui se prend cette année. La tentation est de mesurer le succès à la qualité du résultat produit, sans jamais regarder ce que ce résultat a coûté à obtenir. C'est une erreur de cadrage classique, la même que celle qu'on ferait en jugeant un prestataire uniquement sur son livrable sans jamais regarder son budget d'heures.