Contexte technique
J'aime ces signaux de terrain plus que n'importe quel benchmark brillant. Quand quelqu'un écrit que Kimi est plus pratique pour les tests, Sonnet 4.6 plus flexible, et qu'au mot "cybersécurité" certains modèles se bloquent, je pense immédiatement non pas aux classements, mais à l'intégration réelle de l'IA dans le pipeline de travail.
Et ici le tableau est assez terre-à-terre. Kimi se comporte bien sur les tâches de sécurité structurées : CTF, forensics, analyse d'artefacts, investigation pas à pas. D'après mes observations, il cherche souvent à être plus complet que précis, ce qui peut être un plus dans un environnement de test.
Sonnet 4.6 me parle aussi. Il n'est pas toujours le plus audacieux en profondeur, mais il maintient généralement une ligne de pensée plus régulière et se désagrège moins sur les longues chaînes. Quand j'ai besoin non pas d'une magie ponctuelle mais d'un comportement prévisible en automatisation IA pour les processus d'équipe, cette stabilité vaut plus qu'un résultat "wow" isolé.
Avec Codex, l'histoire est différente. Il est intéressant non pas parce qu'il "pense mieux à la sécurité", mais parce qu'il amène plus vite les tâches au code fonctionnel, aux intégrations et aux résultats utiles. Si l'accès à la confirmation étendue et aux plugins est ouvert, il s'adapte bien aux scénarios d'ingénierie où il ne s'agit pas de discuter avec le modèle, mais de construire un outil.
Et les blocages chez Anthropic et les verrous de sécurité stricts des modèles frontier font désormais partie de l'architecture, pas du hasard. Donc choisir un modèle pour la cybersécurité doit prendre en compte non seulement la qualité des réponses, mais aussi sa capacité à survivre au simple contexte de sécurité sans refuser.
Ce que cela change pour les entreprises et l'automatisation
En bref, ceux qui séparent les rôles des modèles gagnent. J'envisagerais Kimi pour les tests de recherche et les labs, Sonnet 4.6 pour des processus de production plus stables, et Codex pour la construction d'utilitaires, d'agents internes et d'intégrations de sécurité rapides.
Les équipes qui essaient de tout faire reposer sur un seul modèle perdent. En pratique, vous vous heurterez soit à des blocages de sécurité, soit à une faible exécutabilité, soit au coût des erreurs sur les longs scénarios.
Je vois constamment ce genre de bifurcations dans les projets. Chez Nahornyi AI Lab, nous ne discutons généralement pas de quel modèle est "le meilleur", mais nous assemblons une architecture de solutions d'IA en fonction du risque, des accès et du type de tâche, pour que l'automatisation avec l'IA ne casse pas au premier prompt sensible.
Si votre équipe de sécurité passe des heures en analyse manuelle, triage ou outils internes, vous pouvez tranquillement décomposer cela en blocs exploitables. Et ensuite, avec ces blocs chez Nahornyi AI Lab avec Vadym Nahornyi, construire un développement de solutions d'IA sans belles histoires sur un modèle universel, mais avec un vrai résultat en production.