GSM : Qu’est-ce que Checkmarx en 2026 ?
J. R. N.O’M. F.M. : Le cycle de développement logiciel a changé fondamentalement. Les équipes de développement utilisent l’IA pour la conception et les exigences. Certains chefs de produit soumettent eux-mêmes des demandes que les ingénieurs relisent. Avec l’IA, l’ingénieur.e est devenu.e un.e architecte logiciel. Nous ne parlons désormais plus de SDLC, mais d’AI Development Lifecycle (AI-DLC), le cycle de développement de l’IA. Nous avons consacré quatre ans à bâtir Checkmarx One, une plateforme SaaS unique qui réunit tous les moteurs de scanning de vulnérabilités dans un ASPM (Application Security Posture Management, gestion de la posture de sécurité applicative) afin d’offrir une vision globale du risque. Environ 80 à 85 % de nos 1 600 clients y ont migré.
GSM : Comment intégrer la sécurité dès la conception de logiciels ?
J. R. N. O’M. F. M. : En injectant qualité et sécurité à des points clés, de façon transparente. Notre famille d’agents Assist se place au-dessus de l’ASPM et des moteurs : elle agrège leurs résultats, priorise et corrige. L’agent apprend de chaque vulnérabilité, identifiée de manière unique par client et par dépôt logiciel, ce qui garantit la non-régression.
Plus de code généré par l’IA et plus de risques
GSM : L’adoption de l’IA apporte-t-elle plus de risques que de bénéfices au développement logiciel ?
J. R. N. O’M. F. M. : Le volume de code explose, jusqu’à être multiplié par huit ; chez nous, il a augmenté de 50 % depuis l’adoption de l’IA. Or 40 à 80 % du code généré par IA serait non sécurisé. On génère plus de code, et il est moins sûr qu’avant. Les modèles vont s’améliorer, mais ce n’est pas encore le cas. Ce risque est aujourd’hui entendu au plus haut niveau des entreprises. Nous avons récemment demandé à 40 responsables de la sécurité des systèmes d’information (RSSI) à quelle fréquence ils présentaient l’état du risque à leur comité exécutif. Avant cette année, c’était une fois par an, au mieux une fois par trimestre. Aujourd’hui, tous répondent : une fois par mois.
GSM : Comment responsabiliser les développeurs sans les bloquer ?
J. R. N. O’M. F. M. : L’IA accélère la découverte et l’exploitation de vulnérabilités, mais bien utilisée, elle est aussi une opportunité pour anticiper les risques et concevoir des logiciels encore plus sécurisés. L’IA permet d’intégrer la sécurité dans le processus de développement logiciel sans qu’il y ait besoin d’être expert. Checkmarx apporte cette expertise. Nous agissons à chaque étape du développement : de la création du code aux tests d’intégration jusqu’à sa mise en production.
GSM : Peut-on avoir un code 100 % sécurisé ?
J. R. N. O’M. F. M. : C’est une vision et un objectif à atteindre. Nous posons des points de contrôle. Pendant la création du code, le développeur reçoit des propositions de correctifs, qu’il peut accepter ou non. Nos agents IA peuvent analyser une grande quantité de code. Nos moteurs d’analyse et de scan ont une approche exhaustive : à commencer par l’analyse statique (SAST) et l’analyse de composition logicielle (SCA). D’où une approche hybride, déterministe et probabiliste.
Mythos et le moteur hybride Checkmarx Fusion
GSM : Que vous apporte le Cyber Verification Program d’Anthropic ?
J. R. N. O’M. F. M. : Checkmarx participe au Cyber Verification Program d’Anthropic : nous utilisons Claude Mythos pour renforcer nos propres pratiques de sécurité internes et partager nos résultats avec l’ensemble de la communauté de la sécurité. Les modèles frontières excellent sur trois catégories : la logique métier, les IDOR (Insecure Direct Object References) et les vulnérabilités chaînées (failles faibles ou moyennes qui deviennent critiques une fois combinées). Ces modèles sont perfectibles sur les failles connues, comme le cross-site scripting ou l’injection SQL. Sur un projet open source de référence, un scan avec Claude Security et Mythos a trouvé 110 vrais positifs ; notre moteur hybride Checkmarx Fusion, qui mélange approche classique et IA, en a trouvé 700. Selon les projets, le rapport va de trois à huit.
Supply chain et shadow AI
GSM : Et la chaîne d’approvisionnement logicielle ?
J. R. N. O’M. F. M. : C’est là que se produisent la plupart des attaques aujourd’hui. Au-delà de la SCA, des conteneurs et des secrets, l’IA ajoute trois vecteurs d’attaque : les modèles, les serveurs MCP (Model Context Protocol, qui connectent les agents aux outils et aux données) et les « skills », les fichiers de compétences des agents, un sujet encore très récent. Nous développons des moteurs dédiés à ces risques, associés à un inventaire global, l’AI BOM (nomenclature des composants IA), appelé à converger avec la SBOM (software bill of materials).
GSM : Comment associer les métiers à cette démarche ?
J. R. N. O’M. F. M. : Notre agent Developer Assist fonctionne en arrière-plan dans l’environnement IA du développeur ; à défaut, la détection se fait à la soumission du code. Le reste relève de la conduite du changement, avec les lead developers en première ligne. Pour la visibilité, notre AI Inventory parcourt les dépôts et recense modèles, MCP et agents. Avant son lancement, chez une douzaine de clients, 50 000 scans en deux mois ont révélé 25 000 actifs IA dont ils ignoraient l’existence. Reste le code éphémère créé par des non-développeurs, hors dépôt : c’est un risque d’entreprise qu’il est possible de diminuer avec l’acculturation et la sensibilisation des collaborateurs.
Ne pas tout construire soi-même
GSM : Du code à la production, quelle est votre vision ?
J. R. N. O’M. F. M. : Code to Cloud intègre déjà CrowdStrike, AWS ou Wiz pour une vue unique du risque. Notre graphe de contexte, qui décrit les standards de codage et les environnements de chaque client, intégrera la production : une vulnérabilité présente en production devient la priorité absolue. Notre stratégie repose sur cinq piliers : l’orchestration d’agents, une gouvernance unique avec l’ASPM, des moteurs hybrides couvrant toutes les faiblesses (CWE) et vulnérabilités référencées (CVE), la sécurité de l’IA, et le contexte propre à chaque client.
GSM : Beaucoup d’entreprises construisent leurs propres agents de sécurité.
J. R. N. O’M. F. M. : Avec l’IA, chacun croit pouvoir tout construire. On veut tout faire, puis on découvre que ce n’est pas rentable. Un prototype réalisé en vibe coding est rarement adapté à la production. Le prompt engineering n’est que la pointe de l’iceberg ; en dessous, l’ingénierie du contexte et du harness exige une équipe dédiée.
Vendre des résultats, pas des tokens
GSM : Comment maîtriser le coût des tokens ?
J. R. N. O’M. F. M. : Nous vendions par développeur. L’IA est désormais un coût réel, que nous absorbons : nous ne vendons pas des tokens, nous vendons des actions qui apportent de la valeur. Nous avons créé une monnaie, les Checkmarx Credits : un crédit pour un triage, trois pour une remédiation, une unité de scan pour 10 000 lignes de code analysées avec succès, en six paliers jusqu’à plus de 600 000 crédits. Les tokens sont optimisés en coulisse.
GSM : Et le post-quantique ?
J. R. N. O’M. F. M. : Notre moteur SAST contient déjà des requêtes dédiées à la cryptographie. Ce n’est pas une question de si, mais de quand.
« Nous ne vendons pas des tokens, nous vendons des actions qui apportent de la valeur. »
Propos recueillis par Eric Singer
