L’IA peut rapidement faire grimper les coûts des opérations de sécurité, sans toujours améliorer la qualité des détections. Matt Coons, Senior Manager of Security Operations chez GitLab, explique comment son équipe a réduit certaines dépenses liées à l’IA à environ un dollar par jour, en combinant filtrage des événements, modèles adaptés et intervention humaine ciblée.
Les modèles d’IA les plus performants coûtent trop cher pour les tâches quotidiennes à fort volume : c’est ce que découvrent les équipes de sécurité à la réception de leur première facture. En France, cette pression s’exerce de plus en plus sur des équipes déjà sous tension. Selon le baromètre 2026 du CESIN, 40 % des entreprises interrogées ont déclaré avoir subi au moins une cyberattaque majeure au cours de l’année 2025, et 81 % de ces entreprises ont constaté un impact sur leur activité. Pour s’adapter à ce contexte, les équipes françaises ont besoin de dispositifs de défense pilotés par l’IA, ce qui suppose également de maîtriser le coût de cette technologie. En tant que responsable d’une équipe d’opérations de sécurité, j’ai réussi à réduire les dépenses liées aux détections alimentées par l’IA dans le cadre de notre travail à environ un dollar par jour.
Ce chiffre surprend souvent, car l’IA en entreprise est réputée coûteuse à grande échelle. Mais ce n’est pas le cas si les workflows sont correctement définis. Les équipes qui épuisent leur budget font l’impasse sur ce travail de conception qui détermine quels cas d’utilisation doivent être soumis à un modèle.
Le filtrage des détections comme levier de coût
Le filtrage en entonnoir n’a rien de nouveau. Avant l’arrivée des grands modèles de langage (LLM), les équipes de sécurité mettaient déjà en place des filtres pour trier les flux d’événements volumineux et ne retenir que les cas qui justifiaient l’intervention d’un analyste. La même logique s’applique aux dépenses liées à l’IA : plus le filtrage en entonnoir qui alimente vos modèles est fin et précis, plus le coût par résultat fiable diminue.
En matière de confiance et de sécurité, la majorité des abus sont identifiables avant même l’exécution d’un modèle. Une détection déterministe, fondée sur des règles, permet de traiter en amont une part significative du volume. L’ancienneté du compte, le fournisseur de messagerie et les signaux comportementaux alimentent tous des filtres automatisés capables de résoudre les cas évidents et de réduire le volume restant. Seul le sous-ensemble qui franchit ces filtres parvient jusqu’au LLM. C’est de là que vient ce chiffre d’un dollar par jour. Un filtrage en entonnoir bien conçu réduit au minimum les tâches coûteuses.
Des modèles par niveaux, des coûts par niveaux
Pour les cas qui franchissent le filtrage initial, un modèle léger effectue une première analyse et livre des résultats structurés, classés par catégorie (« malveillant » ou « inoffensif »), assortis d’un niveau de confiance élevé ou faible. Les résultats assortis d’un niveau de confiance élevé se résolvent automatiquement, tandis que ceux assortis d’un niveau de confiance faible sont transmis à un modèle plus performant, doté d’un contexte plus large et de meilleures capacités de raisonnement.
Seule une fraction des événements atteint ce second niveau. Lors de tests d’efficacité structurés portant sur plusieurs modèles, nous n’avons constaté qu’une différence de précision de 1 à 2 % entre les modèles légers et les modèles de pointe pour nos cas d’utilisation. Or, les modèles de pointe coûtent environ cinq fois plus cher par token. Ils ne sont rentables que si les cas qui leur parviennent exigent véritablement ce niveau de performance.
L’ingénierie de prompt est tout aussi importante que le choix du modèle. Un prompt conçu pour des détections agentiques compte plus de 1 900 mots et couvre tous les scénarios auxquels l’agent est susceptible d’être confronté, y compris les situations où il doit faire remonter un cas et celles où il peut agir de façon autonome. Tous les cas ne nécessitent pas un tel niveau de détail. Certains prompts tiennent en deux ou trois phrases. C’est l’étendue du périmètre confié à l’agent qui détermine le niveau de précision requis par le prompt.
Le contexte fait également toute la différence entre une analyse précise et une hallucination de l’IA. Si vous soumettez à un modèle un signalement d’abus et lui demandez si l’utilisateur est fautif, il risque de le prendre pour argent comptant. Mais si vous lui fournissez également l’élément concret faisant l’objet du signalement, il pourra alors évaluer de manière indépendante si l’allégation est fondée.
Là où l’humain reste indispensable
L’automatisation traite les cas évidents. Ce sont les cas ambigus qui nécessitent un jugement dont les agents ne disposent pas encore.
Distinguer un chercheur en sécurité légitime qui héberge des échantillons de logiciels malveillants à des fins d’analyse d’un acteur malveillant hébergeant les mêmes contenus pour s’en prendre à autrui requiert un discernement qui échappe encore à l’IA. Il en va de même pour un différend dans un fil de discussion, où les conditions d’utilisation pourraient être interprétées de différentes manières. Ces cas sont transmis à un humain, car ils nécessitent un raisonnement contextuel que la génération actuelle d’agents ne peut pas fournir de manière fiable.
L’objectif est de libérer du temps pour que les relecteurs humains puissent se concentrer sur les cas qui requièrent véritablement leur expertise. Plutôt que de passer en revue chaque événement, les ingénieurs de mon équipe développent les systèmes, rédigent les prompts et définissent les schémas qui orchestrent la détection à grande échelle.
Ce que cela signifie concrètement
Les attaquants testent de nouvelles techniques d’obfuscation et nous adaptons nos prompts et nos modèles pour les détecter. Ce travail itératif s’apparente davantage à l’ingénierie de détection qu’à un déploiement ponctuel. L’ingénierie de prompt relève de la même logique : écrire la règle, tester le résultat, ajuster lorsque la précision se dégrade.
Les responsables de la sécurité en France observent déjà ce qui se produit lorsque les équipes négligent ce travail de conception. Dans ce même baromètre du CESIN, réalisé auprès de 397 directeurs de la cybersécurité et responsables de la sécurité des systèmes d’information, l’usage par les collaborateurs de services d’IA non approuvés (Shadow AI) arrive en tête des comportements numériques les plus risqués : 66 % des organisations lui attribuent un niveau de risque élevé ou très élevé. Lorsque les dirigeants ne parviennent pas à intégrer délibérément l’IA dans leurs processus, ils subissent des pertes financières et s’exposent également à davantage de risques de sécurité.
Ces deux écueils peuvent être évités en traitant l’intégration de l’IA comme un problème de conception dès l’origine. Le volume de données transmis au modèle, la forme sous laquelle ces données lui parviennent et le contexte qui les accompagne déterminent le montant des dépenses. Sans gouvernance, l’IA génère un risque financier qui s’ajoute aux risques de sécurité. Dans les deux cas, la solution passe par un choix assumé : définir où l’IA intervient et pourquoi.
