Scam.ai annonce un partenariat avec Qualcomm et lance Halo, son modèle de détection de deepfakes, au Computex 2026

OpenAI lance Daybreak, une initiative de cybersécurité qui place Codex au cœur de la détection de vulnérabilités et de la validation de correctifs

OpenAI a lancé Daybreak, une initiative de cybersécurité qui combine ses modèles d'IA de pointe avec Codex Security, son agent spécialisé dans la programmation, et un large réseau de partenaires industriels. Le programme s'adresse aux développeurs, aux équipes de sécurité en entreprise, aux chercheurs et aux défenseurs liés aux gouvernements qui cherchent à détecter, valider et corriger des failles logicielles plus tôt dans le cycle de développement. Codex Security n'est pas un produit inédit : il avait été lancé en mars 2026 comme agent de sécurité applicative d'OpenAI. Daybreak en élargit considérablement la portée et le repositionne comme une plateforme de sécurité enterprise. Concrètement, le système est capable de passer en revue du code, d'analyser des dépendances logicielles, de modéliser des menaces, de valider des correctifs et d'explorer des systèmes inconnus. OpenAI affirme que Codex Security peut réduire à quelques minutes des analyses qui prenaient auparavant plusieurs heures, en priorisant les failles à fort impact. Un réseau de partenaires majeurs soutient l'initiative, dont Cloudflare, Cisco, CrowdStrike, Palo Alto Networks, Oracle, Zscaler, Akamai, Fortinet, Intel, Qualys, Rapid7, Tenable, Trail of Bits et Specter. L'enjeu central de Daybreak est un changement de paradigme dans la façon dont la sécurité logicielle est abordée : plutôt que de traiter la correction de vulnérabilités comme un processus réactif déclenché après qu'une faille a été exploitée, OpenAI veut intégrer la sécurité dès la conception du code. Pour un développeur, au lieu de parcourir manuellement chaque chemin de code à la recherche de points d'injection ou de failles d'authentification, Codex Security peut raisonner sur l'ensemble d'une base de code, identifier les zones à risque élevé et générer des correctifs vérifiés dans un environnement isolé avant de les soumettre à une validation humaine. Ce point est important : OpenAI ne positionne pas cet outil comme un système de remédiation entièrement autonome. Les organisations peuvent également exporter les résultats et des preuves prêtes pour un audit vers leurs propres systèmes afin de suivre et vérifier les corrections. Le déploiement de Daybreak s'appuie sur une structure à trois niveaux de modèles, liée au cadre "Trusted Access for Cyber" d'OpenAI. GPT-5.5 standard reste le modèle par défaut pour les usages généraux, tandis que GPT-5.5 avec accès de confiance est destiné aux défenseurs vérifiés pour la revue de code sécurisé, le triage de vulnérabilités et la validation de correctifs. GPT-5.5-Cyber, un modèle en préversion limitée aux capacités plus étendues, est réservé aux flux de travail autorisés comme le red teaming et les tests d'intrusion. Cette hiérarchie est délibérée : plus un modèle est performant pour raisonner sur des vulnérabilités, plus il devient dangereux en cas d'accès non contrôlé. OpenAI conditionne l'accès à GPT-5.5-Cyber à une vérification d'identité, des contrôles d'accès limités, une surveillance au niveau des comptes et des exigences de supervision humaine, reconnaissant explicitement que les mêmes capacités défensives peuvent être détournées à des fins malveillantes.

Créer un pipeline de détection de type de fichier et d'analyse de sécurité avec Magika et OpenAI

Un tutoriel publié récemment sur Analytics Vidhya détaille la construction d'un pipeline d'analyse de sécurité combinant Magika, l'outil de détection de types de fichiers développé par Google, avec les modèles de langage d'OpenAI, notamment GPT-4o. Le système s'appuie sur la bibliothèque Python magika et l'API OpenAI pour analyser des fichiers directement depuis leurs octets bruts, sans se fier aux extensions ou aux noms de fichiers. Le pipeline couvre plusieurs scénarios concrets : scan par lot, détection de fichiers usurpés, analyse forensique, scoring de risque pour les flux d'upload, et génération de rapports structurés en JSON. À chaque étape, GPT-4o prend en entrée les résultats techniques de Magika, labels de type, scores de confiance, empreintes MIME, et les traduit en explications lisibles, en alertes de sécurité et en résumés exécutifs. Cette combinaison répond à un problème réel dans les systèmes qui acceptent des fichiers d'utilisateurs externes : les extensions de fichiers sont triviales à falsifier, et les vérifications basées sur le nom seul ne constituent pas une défense fiable. Magika, entraîné sur des dizaines de millions de fichiers, détecte le vrai type d'un fichier à partir de sa structure binaire interne, avec un score de confiance par prédiction. En greffant GPT dessus, le pipeline devient capable de transformer un résultat technique brut comme application/x-dosexec en une alerte de sécurité contextualisée, ou de scorer le risque d'un lot de fichiers uploadés avant leur traitement. Pour les équipes de sécurité ou les développeurs qui construisent des plateformes acceptant du contenu utilisateur, cela représente une couche de détection supplémentaire sans nécessiter d'expertise forensique interne. Magika a été open-sourcé par Google en février 2024 et présenté comme un outil destiné notamment à VirusTotal et à d'autres plateformes d'analyse de menaces. Il repose sur une architecture deep learning légère permettant une inférence rapide, là où les outils classiques comme file ou libmagic utilisent des règles statiques. L'intégration avec les LLM suit une tendance plus large dans la sécurité applicative : utiliser des modèles de langage non pas pour détecter les menaces directement, mais pour interpréter et contextualiser les sorties d'outils spécialisés. Ce type de pipeline hybride, où un modèle ML de bas niveau fait la détection et un LLM fait l'interprétation, commence à s'imposer comme un pattern architectural dans les outils de sécurité de nouvelle génération.

💬 Magika, j'en avais entendu parler à sa sortie en 2024, mais là c'est la première fois que je vois un pipeline complet qui l'exploite vraiment. Le pattern hybride (ML pour détecter, LLM pour interpréter) est intelligent : tu ne demandes pas à GPT de faire de la forensique, tu lui demandes de traduire un résultat technique en quelque chose d'actionnable. Reste à voir ce que ça coûte en tokens sur un flux d'upload à volume élevé.

Empoisonnement de modèles ML : fonctionnement et détection

L'empoisonnement des données constitue l'une des menaces les plus insidieuses pour les systèmes d'intelligence artificielle modernes. Dans une analyse publiée par Igor Maljkovic, quatre techniques principales sont décrites : le retournement de labels (label flipping), qui consiste à corrompre les annotations d'entraînement pour induire des erreurs systématiques ; l'injection de backdoors, qui implante des comportements cachés déclenchables à la demande ; le clean-label poisoning, qui manipule les données sans modifier les étiquettes pour échapper aux vérifications ; et la manipulation de gradients, qui perturbe directement le processus d'optimisation du modèle. Ces attaques représentent un risque concret pour toute organisation qui déploie des modèles en production. Un modèle empoisonné peut classer incorrectement des contenus, ignorer des anomalies critiques dans des systèmes de détection de fraude ou de sécurité, ou exécuter des comportements malveillants sur commande. La difficulté majeure réside dans la détection : les données corrompues peuvent paraître parfaitement légitimes lors des audits visuels ou statistiques habituels, rendant la compromission quasi invisible jusqu'au déploiement. L'article s'inscrit dans un contexte où les pipelines d'entraînement ML s'appuient de plus en plus sur des données externes, des dépôts publics et des contributions tierces, multipliant les surfaces d'attaque. Maljkovic présente des outils de défense pratiques ainsi que des pratiques opérationnelles pour sécuriser ces pipelines, notamment la surveillance des distributions de données, la validation croisée des sources et l'isolation des lots d'entraînement suspects. La sécurisation du cycle de vie des modèles devient ainsi un enjeu structurel pour les équipes MLOps.

Les modèles d'IA décrivent avec assurance des images qu'ils n'ont pas vues, et les benchmarks ne le détectent pas

Des chercheurs de Stanford ont mis en évidence un défaut majeur dans les grands modèles multimodaux : GPT-5, Gemini 3 Pro et Claude Opus 4.5 génèrent des descriptions d'images détaillées — voire des diagnostics médicaux — même lorsqu'aucune image n'a été fournie en entrée. Interrogés sans visuel, ces systèmes inventent des détails précis avec une assurance totale, sans signaler à l'utilisateur que le contenu décrit est fabriqué de toutes pièces. Ce comportement représente un risque concret dans les domaines où la fiabilité est critique. En radiologie ou en dermatologie, un modèle qui produit un diagnostic convaincant à partir de rien peut induire en erreur un professionnel de santé qui lui ferait confiance. Au-delà du médical, le problème touche tout usage où l'utilisateur suppose que la réponse est ancrée dans une donnée réelle : analyse de documents, surveillance visuelle, assistance à l'audit. La confiance apparente du modèle rend la détection de l'erreur particulièrement difficile. Ce qui aggrave la situation, c'est que les benchmarks standards d'évaluation des modèles multimodaux ne détectent pas ce phénomène : ils mesurent la qualité des descriptions quand une image est présente, mais ne testent pas systématiquement le comportement en l'absence d'entrée visuelle. Cette lacune dans les protocoles d'évaluation signifie que des modèles déployés en production peuvent présenter ce défaut sans qu'aucun indicateur de performance ne l'ait signalé. L'étude de Stanford plaide pour l'ajout de tests d'abstention dans les évaluations standard — c'est-à-dire vérifier qu'un modèle sait aussi dire qu'il ne voit rien.

💬 C'est pas la hallucination qui m'inquiète, c'est l'assurance avec laquelle elle arrive. Un modèle qui fabrique un diagnostic radio sans aucune image en entrée, sans jamais signaler qu'il ne voit rien, c'est un défaut de conception qu'aucun benchmark standard ne détecte, et donc que personne ne cherche à corriger. Le test d'abstention que Stanford propose, c'est pas une idée brillante, c'est le minimum qu'on aurait dû exiger depuis le début.