Teknik - Stratégie de sécurité applicative adaptée à l'IA (Cybereco) - Parce que... c'est l'épisode 0x2FF! — PolySécure Podcast

Teknik - Stratégie de sécurité applicative adaptée à l'IA (Cybereco) - Parce que... c'est l'épisode 0x2FF!

PolySécure Podcast · 26/05/2026 04:00 · 33 min
Informatique

Contenu de l'épisode

Parce que… c’est l’épisode 0x2FF! Shameless plug Description

Le défi fondamental : le volume dépasse les humains

Jonathan Marcil part d’un constat simple mais vertigineux : l’IA génère du code à une vitesse que les équipes de sécurité ne peuvent plus suivre humainement. Le volume de code produit est tel qu’il devient impossible de tout réviser avec rigueur sans y perdre sa santé mentale. Cette réalité impose une réponse stratégique, et c’est précisément l’objet de sa présentation à Cybereco : proposer des stratégies qui utilisent l’IA pour répondre aux problèmes que l’IA elle-même crée.

L’humain reste une variable limitante

Même si l’IA ne connaît pas de fatigue propre, les humains qui travaillent avec elle, eux, s’épuisent. Jonathan illustre ce point avec l’exemple du programme de bug bounty de cURL, qui a dû être fermé parce que les participants utilisaient l’IA pour générer des rapports de bogues en masse. Le résultat : une surcharge humaine impossible à gérer, même pour des experts qui connaissent le système depuis des dizaines d’années. L’IA peut amplifier le bruit autant que le signal.

Le prompting : une compétence éphémère

Un thème central de la discussion est la nature instable de la compétence en prompt engineering. Chaque nouveau modèle frontier réagit différemment, ce qui rend les techniques de prompting acquises partiellement obsolètes à chaque mise à jour majeure. Jonathan voit néanmoins une vertu dans cette diversité des modèles : elle empêche une standardisation totale et maintient une forme de compétition saine entre les fournisseurs. Cela dit, il met en garde contre la tentation de consacrer trop d’énergie à suivre chaque lancement au détriment des compétences fondamentales en sécurité.

Le vibe coding et la perte de compétences

L’un des points les plus préoccupants soulevés par Jonathan est le risque de dépendance cognitive. Le « vibe coding » — cette pratique de générer du code sans vraiment le comprendre — crée une illusion de productivité. Tant que tout fonctionne, personne ne pose de questions. Mais le jour où un bug survient ou qu’une faille est découverte, si les développeurs n’ont plus les compétences fondamentales pour diagnostiquer le problème, ils se retrouvent à demander à l’IA de corriger ce qu’elle a elle-même mal produit. Jonathan cite un exemple personnel : il a demandé à un modèle de réviser ses diapositives, et le modèle a omis un élément important — sans le signaler spontanément. L’autocritique reste un angle mort des LLM.

Les stratégies proposées

La réponse de Jonathan à ces défis repose sur plusieurs axes concrets :

1. Diversifier les modèles. Utiliser plusieurs IA en parallèle — demander à l’un de valider ce que l’autre a produit — est une pratique simple mais efficace pour introduire un regard critique dans le processus. Il suggère aussi de soumettre d’anciens travaux aux nouvelles versions des modèles, qui peuvent en faire de meilleures révisions.

2. Charger les bonnes pratiques de l’entreprise dans le LLM. Plutôt que d’utiliser un modèle générique, Jonathan propose d’alimenter le LLM avec la gouvernance, les politiques et les standards de sécurité propres à l’

Plus d'informations