METATRON : le test d'intrusion qui reste chez vous

Publié le 8 septembre 2026 · Un assistant de test d'intrusion, local et sans clé, dont l'idée est juste. On l'a monté sur notre banc d'essai, et voici ce qu'on a appris ensemble.

Pourquoi cet outil nous a plu

L'idée est belle et rare : de vrais outils de reconnaissance, une intelligence artificielle qui tourne chez vous, aucune clé à louer, aucun envoi vers l'extérieur. L'auteur a assemblé nmap, whois, whatweb, curl, dig et nikto derrière une conversation, et il a écrit dans son code une liste des outils autorisés et des consignes d'exactitude. Ce sont de bons réflexes, et ils ne sont pas si courants.

Nous aimons ce genre de travail : du local, des outils qui existent, une trace. Alors nous l'avons essayé pour de bon, pas seulement lu.

Ce qui est bien fait, et qu'on tient à saluer

• Le choix du local. Le modèle tourne sur la machine de celui qui teste. Rien ne part chez un tiers, et aucune clé à payer. Le test reste chez celui qui le lance.
• De vrais outils, pas des imitations. nmap, whois, whatweb, curl, dig, nikto : ceux que les gens du métier utilisent. L'outil ne raconte pas un test, il en fait un.
• Une liste des outils autorisés, écrite dans le code. Le modèle ne peut lancer que ce qui figure dans cette liste.
• Des consignes d'exactitude dans le prompt. Le risque d'invention est nommé dans les consignes.
• Une conversation lisible. On suit ce que la machine fait, étape par étape. C'est ce qui nous a permis de repérer les deux points ci-dessous.
• Le code est ouvert. On a pu le monter sur un banc en une soirée.

Notre banc d'essai

Deux conteneurs, un réseau fermé, rien qui sorte. La cible est une petite « tour » que nous avons rendue faible exprès, en annonçant Apache 2.4.49, une version dont la faille est connue et documentée. La reconnaissance a bien travaillé : le port 80 vu, la version lue.

Deux endroits où une règle gagnerait à devenir une porte

Ensuite l'intelligence artificielle a pris la main, et notre banc a montré deux choses utiles à connaître pour la suite.

Un. Elle a proposé de regarder une autre machine que la cible : la passerelle du réseau, pas notre conteneur. L'outil a exécuté la commande, parce que sa liste d'autorisation regarde le nom de l'outil, pas l'adresse visée. Le périmètre est annoncé dans les consignes ; il gagnerait à être vérifié par le code.

Deux. Elle a cité un numéro de faille qui n'était pas le bon : celui d'une faille Java célèbre, au lieu de celui d'Apache. Le modèle a reconnu un nom de version et a complété de mémoire. C'est le comportement normal d'un modèle de langage, et c'est précisément pour cela qu'un contrôle mécanique est utile à côté.

Ces deux points ne retirent rien à l'outil : ils sont ce qu'un banc d'essai sert à trouver, et ils se corrigent sans toucher à l'idée.

Ce que ce test nous a appris, à nous aussi

Un test d'intrusion se juge sur deux questions : la machine a-t-elle touché seulement ce qu'elle devait, et chaque conclusion est-elle vérifiable ? METATRON a écrit ses règles dans ses consignes. Nous avons appris, chez nous, qu'une consigne se comprend et qu'une porte se traverse : la première demande de la bonne volonté, la seconde ne demande rien à personne.

C'est la différence entre « on m'a dit de ne pas me tromper » et « on m'a construit de façon à ne pas pouvoir me tromper ». Nous avons payé cette leçon sur nos propres agents, plusieurs fois.

Essayé sur un poste personnel, dans des conteneurs isolés, jamais contre une cible réelle.