Strix est partout depuis quelques mois : 26 000 étoiles sur GitHub, une place en tête de Trendshift, et un pitch qui claque, « open-source AI hackers ». Des agents IA autonomes qui explorent votre application comme de vrais attaquants, trouvent des vulnérabilités et les prouvent par un proof-of-concept. J'ai voulu répondre à une seule question, celle qui compte quand un outil lit votre code source et liste vos failles : est-ce que je peux le faire tourner chez moi, sans rien envoyer dans un cloud américain ? J'ai passé une journée à le tester sur mes propres GPU. Voici le récit, et le verdict.
Ce que Strix promet
Strix orchestre des agents spécialisés dans un graphe : pendant que l'un cartographie l'application, un autre teste les entrées, un troisième tente l'exploitation. Le moteur manipule les requêtes via un proxy HTTP, pilote un navigateur pour les failles côté client, ouvre des sessions terminal et offre un environnement Python pour écrire des exploits. Le tout dans un sandbox Docker. Sur le papier, c'est le rêve : un pentester junior infatigable, open-source et gratuit.
La nuance, c'est le « gratuit ». Strix, le logiciel, est libre. Mais il ne fait rien sans un LLM derrière, et c'est là que tout se joue.
Le vrai sujet : quel modèle, et où tournent vos données
Strix se configure avec deux variables d'environnement : STRIX_LLM (le modèle) et
LLM_API_KEY (la clé). Par défaut, on lui branche GPT-5.4, Claude ou
Gemini. Ça marche, mais ça veut dire une chose : votre code et les
vulnérabilités découvertes partent chez un fournisseur tiers, le plus souvent
américain. Pour un outil de sécurité, c'est exactement la donnée qu'on ne veut pas
exfiltrer.
Un benchmark public de 18 modèles est sans ambiguïté sur le coût et la performance :
- GLM-5.1 domine (score moyen 61,1), suivi de GPT-5.4.
- Les modèles open-source ou petits s'effondrent :
gemma-4-31best « pas trop mal » relativement,deepseek-v3.2déçoit, etnemotron-120bscore zéro. - Claude se fait rate-limiter violemment (105 erreurs « rate limit » sur un seul test), et un run via OpenRouter a coûté 55,9 dollars contre une vingtaine pour GPT-5.4.
La conclusion de l'auteur résume tout : « pour du sérieux avec Strix, il faut de gros modèles, et chers ». Il n'existe pas de juste milieu économique.
La souveraineté, sur le papier
Bonne nouvelle, Strix documente officiellement les modèles locaux : on pointe
LLM_API_BASE vers un serveur Ollama ou LMStudio, et la doc met en avant ce
cas précis pour les scans sensibles, afin de réduire les données sortantes.
C'est exactement mon besoin. Sur le papier, la souveraineté est prévue.
Sur une machine équipée d'un GPU H100 (80 Go), avec Docker, Ollama et de quoi servir un gros modèle, j'avais tout pour le faire. J'ai donc déroulé.
Première claque : l'agent tourne en rond
Premier essai avec Ollama et un modèle de code de 7 milliards de paramètres.
Strix démarre, crée son sandbox, lance son premier agent... et boucle. Le
journal se remplit de la même ligne : agent produced non-lifecycle final output; forcing tool continuation (1/500, 2/500, 3/500...). Le modèle répond en texte
au lieu d'appeler un outil, Strix refuse cette sortie et le force à recommencer,
jusqu'à un plafond de 500 tentatives. Après dix minutes : zéro vulnérabilité,
zéro action utile.
Ce n'était pas ma configuration. Les issues GitHub de Strix décrivent exactement ce comportement, et elles sont ouvertes :
- #520 : « Tool calls returned as plain text instead of being executed when using Ollama ». Le modèle génère pourtant un appel d'outil valide, mais Strix ne l'exécute pas. Un commentaire précise : « ça n'arrive pas avec GPT-5, et il n'y a rien dans Strix pour forcer le tool call ».
- #514 : des modèles locaux partent en boucle et brûlent des tokens ; une régression depuis la version 0.8.3 a aggravé les choses.
- #580 : un testeur sur DGX Nvidia voit ses modèles locaux planter sur des
erreurs JSON ou « tool not found », même via
ollama_chat.
Le diagnostic est clair : le cadre agentique de Strix attend un format d'appel d'outil que les modèles locaux, via Ollama, ne produisent pas de façon fiable.
Deuxième round : réparer le format avec vLLM
Si le problème est le format des appels d'outils, la solution logique est
vLLM, le serveur d'inférence GPU
qui expose une API OpenAI-compatible avec un vrai function calling natif. On
l'active avec --enable-auto-tool-choice --tool-call-parser hermes, et Strix le voit
comme un endpoint OpenAI standard.
Et ça marche, côté inférence : un appel direct à vLLM renvoie un tool_calls
parfaitement structuré, là où Ollama renvoyait du texte. La brique de base est
réparée. J'ai relancé Strix, confiant.
Une fois le contexte étendu et un modèle de 32 milliards de paramètres (un modèle de code, servi en local sur l'H100, format AWQ), j'ai relancé le run souverain complet. Format d'appel réparé, contexte suffisant, modèle costaud, tout en local. Le décor idéal.
Verdict : ça boucle quand même
263 appels au modèle. 262 rejetés en boucle. 3 commandes réellement exécutées
(ls, find). Zéro vulnérabilité. Statut : échec.
Même avec un modèle agentique sérieux et le format d'appel réparé, Strix boucle. La cause est plus profonde que la taille du modèle ou le format : le cadre de Strix attend que le modèle émette toujours un appel d'outil tant que la mission n'est pas finie. Or les modèles locaux, même un 32B, produisent régulièrement une réponse en langage naturel (« j'ai analysé le code, voici les problèmes... »), que Strix interprète comme une tentative de conclure et qu'il rejette en forçant la continuation. La cible, pourtant, contenait quatre failles triviales sur vingt-cinq lignes : injection SQL, injection de commande, traversée de chemin, secret en dur. L'agent n'a jamais lu le fichier.
C'est le comportement décrit dans les issues, reproduit de bout en bout : Strix est calibré pour les modèles frontières (GPT-5.4, GLM-5.1, Claude), qui suivent son protocole agentique au token près. Les modèles ouverts, eux, ne le suivent pas assez strictement, et l'outil ne sait pas les rattraper.
Pour être juste : avec un modèle frontière, il brille
Pour ne pas accuser l'outil à tort, j'ai relancé exactement le même scan avec Claude Sonnet 4.6, via l'API Anthropic. Et là, plus de boucle : Strix explore, exécute ses outils, et trouve les quatre failles. Mieux, il les prouve :
- Injection SQL (CVSS 9.1, critique, CWE-89), démontrée par un proof-of-concept qui extrait réellement le contenu de la base.
- Injection de commande, traversée de chemin, et le secret en dur
(
sk-live-...) repéré dans le code, avec des recommandations concrètes (passer à un ORM, ajouter le secret-scanning en pre-commit).
Le bilan du run : 1,1 million de tokens en entrée, 11 000 en sortie, 3,39 dollars, en quelques minutes, sans le moindre rate-limit. Notez le chiffre : 1,1 million de tokens pour vingt-cinq lignes de code. L'agent multiplie les allers-retours, et la facture grimpe vite sur une vraie application (le benchmark cité parlait de 20 à 55 dollars par scan).
C'est ce qui rend le constat frustrant : l'outil fonctionne, et bien. Mais pour trouver ces failles, il a fallu envoyer mon code et les données qu'il en a extraites (le contenu de la base, le secret) chez un fournisseur américain. La seule version de Strix qui marche est celle qui contredit l'objectif de départ.
Ce que je retiens
La souveraineté avec Strix n'est pas une question de matériel. Mon H100 a chargé un 32B avec 64k de contexte sans broncher. Le verrou est logiciel, dans Strix, et c'est un bug ouvert et connu. Tant qu'il n'est pas corrigé, le seul Strix qui fonctionne vraiment est celui qui parle à une API frontière payante, donc celui qui envoie votre code et vos failles dans un cloud tiers. C'est le paradoxe complet : l'outil le plus intéressant à garder chez soi est justement celui qu'on ne peut pas y faire tourner.
Mon conseil, sans détour :
- Pour évaluer Strix : utilisez une API frontière, sur du code non sensible et jetable, en surveillant la facture (un run sérieux coûte 20 à 55 dollars).
- Pour du code sensible : attendez. Le support des modèles locaux est annoncé mais non fonctionnel aujourd'hui. Suivez les issues #514 et #520.
- Si vous tenez à essayer en local : vLLM avec
--tool-call-parser, un gros modèle et un contexte étendu sont des prérequis nécessaires mais pas suffisants. Vous verrez l'agent démarrer, pas aboutir.
Strix est une démonstration impressionnante de ce que les agents IA feront en sécurité offensive. Mais en 2026, « open-source » ne veut pas dire « souverain ». Un outil dont le cerveau vit chez OpenAI ou Anthropic reste un outil dont vous ne maîtrisez ni les coûts, ni les données, ni la disponibilité. Le jour où un modèle ouvert pilotera Strix de bout en bout, je referai le test. En attendant, je préfère le savoir, et vous le dire, plutôt que de relayer le pitch.
Sources et références
- Strix sur GitHub : le dépôt officiel, code, README et releases (version 1.0.4 au moment du test).
- strix.ai et la documentation officielle : présentation, installation et configuration des fournisseurs LLM, dont les modèles locaux via
LLM_API_BASE. - Les issues GitHub qui décrivent le bug : #520 - tool calls en texte avec Ollama, #514 - boucles et tokens brûlés sur modèles locaux, #580 - modèles locaux sur DGX Nvidia.
- Agentic AI pentesting with Strix : results from 18 LLM models (TheArtificialQ) : le benchmark comparatif des modèles, des coûts et du rate-limiting.
- Strix : open-source AI agents for penetration testing (Help Net Security) : la couverture du lancement.
Pour aller plus loin
- vLLM : servir un LLM en production sur GPU : le serveur que j'ai utilisé pour réparer le tool calling.
- Comparatif des backends d'inférence LLM : choisir entre Ollama, vLLM, SGLang et les autres.
- Tool calling et agents avec Ollama : pourquoi le format des appels d'outils est si déterminant.