L’agent IA local de Google face à Hermes : nos conclusions après un vrai test

L’épreuve : du code vulnérable et des tests cachés

Nous avons repris l’exemple de Google lui-même : trois petits fichiers de code (connexion, facturation, base clients) dans lesquels nous avons placé huit failles de sécurité. Un jeton de connexion qui accepte un morceau du vrai jeton, une redirection qui envoie vers un site piégé, une remise qui peut dépasser 100 %, un chemin de fichier qui sort de son dossier, deux injections dans la base de données. La consigne donnée à l’agent : trouver les failles, les corriger, ne rien casser, et le dire.

La notation ne repose pas sur ce que l’agent affirme. Six tests visibles vérifient que le comportement normal est intact. Huit tests de sécurité, que l’agent ne voit jamais, sont lancés après son passage. Avant de noter qui que ce soit, nous avons vérifié le correcteur : le code vulnérable obtient zéro sur huit, une correction faite à la main obtient huit sur huit.

Les conditions sont les mêmes pour tous : un Mac mini de 48 Go, installé au cabinet, un seul modèle chargé à la fois, et le même modèle pour les deux agents, Gemma 4 dans sa version de 26 milliards de paramètres, celle que Google met en avant. Chaque agent a passé l’épreuve quatre fois, lancé dans son dossier de travail, sans outil de recherche sur le web. L’agent de Google était en plus cloisonné par ses propres règles : impossible de lire hors du dossier ou de lancer une commande réseau.

Résultat : égalité sur la qualité, et personne ne corrige tout

L’agent de Google a corrigé 5, 6, 6 et 6 failles sur 8, sans jamais casser le comportement normal. Hermes a corrigé 6, 6, 5 et 7 failles sur 8, et a cassé une fois une fonction qui marchait. Chacun a mis entre deux et trois minutes par passage. À modèle égal, l’écart entre les deux agents est plus petit que l’écart entre deux passages du même agent.

Ce qui frappe, ce sont les points communs. Les failles connues de tous (l’injection dans la base de données, le jeton mal comparé) sont corrigées à chaque fois. La règle métier, elle, est presque toujours oubliée : qu’une remise ne puisse pas dépasser 100 %, un seul passage sur les dix-sept menés au bout l’a traitée, tous agents et tous modèles confondus. Ce n’est pas une faille « de sécurité » au sens des manuels. C’est exactement le genre d’erreur qui coûte de l’argent.

Le point le plus important est ailleurs. Les deux agents annoncent régulièrement une correction complète là où elle est partielle. Hermes conclut un passage par « Toutes les vulnérabilités identifiées ont été corrigées » alors que la sortie de dossier reste ouverte. L’agent de Google déclare la redirection piégée corrigée : il bloque une variante, pas l’autre. Les tests visibles sont verts dans les deux cas. Des tests verts disent que rien n’est cassé ; ils ne disent pas que tout est sûr.

Où ils diffèrent vraiment : ce qui sort de la machine

Un agent branché sur un modèle local n’est pas forcément un agent qui ne parle à personne. Pour le vérifier, nous avons placé sur la machine un faux relais internet qui note chaque tentative de sortie, et la refuse. Pendant son passage, l’agent de Google n’a tenté aucune sortie. Hermes en a tenté deux, vers OpenRouter, une plateforme en ligne qui distribue des modèles d’IA : il télécharge la liste publique des modèles disponibles, même quand il n’utilise qu’un modèle local. Il la garde une heure en mémoire, et recommence aussitôt si l’appel échoue.

Soyons précis. Hermes n’envoie ni le code, ni la question, ni aucune donnée de travail : il lit un catalogue public, et il fonctionne normalement quand on le lui refuse. Mais une connexion sortante, même anodine, signale à un tiers qu’une machine est active, et elle suffit à faire échouer un audit qui exige « aucun flux sortant ». Limite de notre méthode : un programme qui ignorerait ce relais n’aurait pas été vu. C’est une mesure, pas une certification.

La leçon vaut pour n’importe quel outil : « local » est une promesse sur l’endroit où tourne le modèle. Ce qui sort réellement de la machine se mesure, outil par outil, version par version.

Où ils diffèrent aussi : la maturité

L’agent de Google a les garde-fous les plus fins que nous ayons vus : on peut le cantonner à un dossier, autoriser une commande et en refuser une autre, et le refus est vérifiable. Encore faut-il bien les régler. Dès qu’on pose une règle, tout ce qui n’est pas explicitement autorisé est refusé, y compris lire un fichier. Nous nous y sommes pris : l’agent, privé de ses outils, a bricolé ses modifications à la main, rendu des fichiers illisibles, et affirmé que les tests passaient alors qu’il ne les avait pas relancés. L’exemple officiel, lui, ouvre tout le terminal à l’agent. Ni l’un ni l’autre ne se copie tel quel.

Le reste montre un produit jeune, en version 0.1. Le branchement annoncé « prêt à l’emploi » avec Ollama, le moteur local le plus répandu, plante en cours de tâche : l’agent envoie un message vide que le moteur refuse. Il nous a fallu un petit relais de correction pour le faire tenir. L’outil qui installe le modèle au format de Google a affiché « réussi » sur un fichier téléchargé au tiers. Et sur notre Mac, ce format maison s’est montré deux à cinq fois plus lent que le même modèle servi par Ollama, pour la même qualité.

Hermes, en service chez nous depuis mai, a fonctionné du premier coup avec Ollama. Il est moins fin sur les règles par outil, plus bavard vers l’extérieur, et plus simple à mettre en route.

Nos conclusions

Premièrement, le modèle compte plus que l’agent. Dans l’agent de Google, nous avons aussi essayé trois autres modèles installés sur la même machine. L’un a atteint 7 sur 8 lors d’un passage, et s’est arrêté en plein travail lors d’un autre, juste après avoir écrit « corrigeons cela maintenant ». Un autre écrivait ses commandes au lieu de les exécuter, deux fois sur trois. Gemma 4, le modèle mis en avant par Google, s’est montré le plus régulier. Choisir un agent sans tester le modèle sur ses propres tâches, c’est choisir à l’aveugle.

Deuxièmement, aucun agent local ne signe seul. Ils font vite et bien le gros du travail, et ils le présentent parfois comme terminé quand il ne l’est pas. La bonne organisation est connue : l’agent propose, une personne relit ce qui compte, et des tests écrits par le métier vérifient ce que l’agent ne voit pas, comme cette remise à 150 %.

Troisièmement, « local » se vérifie. Ce que dit la documentation et ce qui passe réellement par la carte réseau sont deux informations différentes. Hermes reste notre agent au quotidien ; cet appel au catalogue est désormais sur notre liste à neutraliser. Nous suivrons l’agent de Google : ses garde-fous sont les bons, sa maturité viendra.

Les limites de ce test, pour être complet : une seule épreuve, en français, une vingtaine de passages, sur notre machine. C’est une tendance mesurée, pas une étude. Nous n’avons pas testé la partie « planificateur en ligne » de la démonstration de Google, qui envoie des informations hors de la machine par construction.