Episode 18 - Prompts, CVE et nuits blanches : sécuriser sans péter les plombs à l'ère de l'IA | MiXiT On Air

Description

Dans cet épisode, nous discutons avec Philippe Laumay et Loïc Gudet de Moody's Analytics, et Willy Malvault de Bull, tous trois architectes sécurité, de l'impact de l'IA sur la cybersécurité. Entre l'affaire Mythos et sa vague de CVE découvertes dans des projets open source vieux de plusieurs décennies, les taux de faux positifs des scanners assistés par IA, et les enjeux de souveraineté numérique face aux modèles américains ou chinois, ils dressent un état des lieux concret des nouveaux risques et des réflexes à garder. Vibe coding, dépendances mal maîtrisées, formation des équipes : de quoi nourrir une réflexion sur la tech éthique appliquée à la sécurité.

Invité.es :
- Philippe Laumay
- Loïc Gudet
- Willy Malvault

Interviewers :
- Hubert Sablonnière
- Anne-Laure de Boissieu

Liens de l'épisode :
- https://mixitconf.org/en/2026/les-gardiens-du-prompt-menaces-genai-et-recettes-de-securite-pour-une-production-zen
- https://mixitconf.org/en/2026/objectif-cyber-resilience-act-cra-traquer-les-cves-dans-un-ocean-de-dependances
- https://owasp.org/www-project-top-ten/
- https://en.wikipedia.org/wiki/Cyber_Resilience_Act
- https://www.youtube.com/ibm
- https://www.youtube.com/watch?v=1SRoH82V-j4
- https://www.linkedin.com/in/gioria/?locale=fr

Enregistré le jeudi 16 avril 2026 à 11:45 lors de MiXiT 2026

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

Speaker #0
Bienvenue sur Mixit On Air, où la tech rime avec l'éthique. Je suis Hubert.
Speaker #1
Et moi, je suis Anne-Laure.
Speaker #0
Et à chaque épisode, nous plongeons dans les coulisses de la conférence Mixit pour vous faire découvrir les innovateurs et innovatrices qui façonnent notre avenir numérique. Aujourd'hui, on a le plaisir d'accueillir Philippe Lommé, directeur en générique chez Moody's Analytics, Loïc Budé, technical architect chez Moody's Analytics également, et Willy Malveaux, architecte sécurité chez Bull. Avec eux... Nous allons explorer ce que l'IA change vraiment à la sécurité entre nouvelles surfaces d'attaque, vieux réflexes qui tiennent bon et vagues réglementaires qui arrivent en
Speaker #2
2027.
Speaker #1
Philippe, Loïc et Willy, bienvenue sur Mixit On Air. On est là pour parler CyberCQ et IA. Personnellement, j'ai la sensation que ce que j'ai appris hier, c'est déjà périmé aujourd'hui. Donc ma première question, c'est aujourd'hui on est le 16 avril 2026. D'après vous, sur quoi on devrait porter notre attention si on est une équipe de devs qui ne veut pas se faire trouver sa prod ? Willy, tu commences ?
Speaker #2
Oui, je vais commencer. Alors déjà, l'IA, un petit peu comme dans tous les domaines, ça va augmenter la sécurité. Mais j'ai envie de dire, la première réponse, c'est déjà avoir des fondamentaux de sécurité traditionnels, donc essentiellement avec de la méthode de sécurité. Pour structurer, en fait, le lien entre l'IA et la sécurité, il y a une approche que j'aime bien, qui est issue du framework du NIST, en fait. Il parle de Secure. « Sécure » , ça veut dire, par rapport à nos méthodes de sécurité sur un SI traditionnel, aujourd'hui l'IA, ça rapporte une nouvelle brique et il va falloir la sécuriser avec des nouvelles méthodes. Je pense que c'est le domaine d'expertise de Philippe et de Loïc. Ensuite, l'IA, il y a « defend » , c'est-à-dire comment on utilise l'IA pour se défendre. Donc là, on va parler de tout ce qui est vulnérabilité, gestion de CV augmentée. Ensuite, il y a « twartz » . « Twartz » , c'est comment ? En fait, les hackers, ou même des fois, ça nous dépasse avec l'actualité, certaines IA peuvent devenir offensives. Et un dernier élément aussi que je rajouterais, c'est les petites questions de souveraineté sur ces outils-là.
Speaker #1
Donc d'après toi, les équipes devraient se focaliser sur ces quatre axes, du coup, si on rajoute la souveraineté. Et pour vous, Loïc ou Philippe ?
Speaker #3
Nous, c'est vrai qu'on est très axé sur essayer de défendre les outils à base d'IA contre des attaques. C'est un peu notre credo actuel. Et là, ça passe par beaucoup de compréhension déjà du fonctionnement de ces outils. Et après, je dirais, les approches, c'est du classique. C'est mettre en place des pentests qui vont vérifier spécifiquement certains axes, certains aspects. nouveaux au niveau technique et fonctionnel de ces outils-là. On s'inspire des grands classiques. Nous, on s'est basé sur OWASP, qui est un organisme bien connu. On connaît tous le Top 10 Web Vulnerability. Ils ont sorti, par exemple, en 2024 et 2025, ils l'ont mis à jour fin 2025, leur Top 10 Vulnerability sur les LLM apps. C'est vraiment une bible pour identifier déjà les failles potentielles et les menaces.
Speaker #0
C'est bon. C'est orienté sur les gens qui utilisent des LLM pour coder et faire d'autres choses, ou pour les gens qui utilisent des modèles dans les produits qu'ils construisent ?
Speaker #3
C'est essentiellement à destination des développeurs qui vont fournir des applications à base de LLM pour pouvoir les sécuriser. Alors, ce que vous utiliserez, typiquement un chatbot qui, derrière, utilise un LLM. Comment vous allez sécuriser votre chatbot, la base de technique de guardrail ?
Speaker #4
Je pense qu'il y a quelque chose qui est très important aussi quand on met en place des applications à base d'IA, c'est d'avoir une observabilité vraiment très importante sur absolument tout ce qui se passe. Parce qu'on voit que ça évolue très vite, les techniques d'attaque évoluent très vite aussi. On reçoit des promptes d'attaque qui sont assez complexes. On aime bien avoir nos plateformes pour identifier la menace, mettre en place des garde-fous pour pouvoir s'en prévenir et pouvoir après ajouter ces menaces dans notre CI pour pouvoir valider qu'elles tiennent dans le temps.
Speaker #3
Donc c'est des techniques classiques, observabilité, on s'en sert déjà.
Speaker #2
C'est la base de la sécurité, on en revient aux fondamentaux.
Speaker #3
On en revient aux fondamentaux mais après on les adapte. à ce que permettent désormais ces outils-là, qui sont vraiment de l'analyse de texte, le fait qu'on soit non déterministe, et puis surtout le fait que, je dirais, certaines personnes, surtout les dirigeants, je vais peut-être être un peu négatif comme ça, mais oublient un petit peu que c'est une technologie qui peut être facilement détournée, et donc il y a une volonté d'aller vite, de fournir des nouvelles solutions à base d'IA, et la sécurité, on verra après. Mais ça, ça a été vrai dans toute nouvelle technologie. Donc, ouvrez les fondamentaux. Qui n'a pas entendu son CEO dire, maintenant, vous m'ouvrez toutes les données de l'entreprise aux agents. Comme ça, on va pouvoir coder plus vite et accéder à toutes les infos. Non, ça, c'est des choses, l'excessive agency, c'est un peu des bases. Le Zero Trust Approach, c'est aussi des bases standards. Il faut juste les rappeler dans ces contextes-là. Et après, réadapter certaines façons de développer quand même.
Speaker #2
C'est super juste ce que tu dis Philippe. En fait, moi je ferais écho carrément à la keynote qu'on a eue ce matin, qui nous parlait, enfin le message je vais un petit peu beaucoup le vulgariser, mais qui dit qu'IA finalement c'est surtout une idéologie avant d'être une technologie. Et ça me fait penser à ce que tu dis, c'est vrai qu'on est dans une mouvance où on a des managers et même des clients, enfin tous nos stakeholders qui nous disent qu'il faut faire de l'IA si on veut être en retard. Mais en même temps, il y a un risque qui est lié à l'utilisation de cette IA. Et en fait, on est vraiment dans une course entre un manque à gagner et un risque d'avoir potentiellement des problèmes de sécurité et autres. Et en fait, ce qui se passe, c'est que ça accélère. En fait, on l'a vu sur le domaine de la sécurité avec Mythos. Ah, on parle de Mythos.
Speaker #0
Est-ce que tu peux nous en dire plus ? C'est assez récent, là, on enregistre le 16 avril. Ça fait flipper ? Pas trop ? Un peu ? Il y a de l'ail ?
Speaker #2
C'est compliqué, il faut prendre ce sujet avec un petit peu de recul. Moi, j'ai un retour d'expérience rapide là-dessus. Avant Mythos, il y avait Cloud Code Opus 4.6, je crois, si je n'ai pas de bêtises, qui a dû sortir fin février. Moi, j'ai eu la chance d'avoir un ami architecte sécurité dans mon réseau qui m'a dit « Willy, il faut que tu essayes ça, il y a vraiment un step qui a été franchi en termes de sécurité. » Donc je l'ai essayé et typiquement, il y a eu une période, on va dire pendant le mois de mars, où avant, avec la Prémitos, on parle, j'ai participé avec d'autres personnes à faire des expérimentations, donc d'audit de code en mode whitelist sur des projets open source. J'y reviendrai, c'est important, open source. Et effectivement, on trouve des vulnérabilités, quoi. On trouve ce qu'on appelle des zéro-tels, c'est-à-dire des failles qui ne sont pas référencées, qui ne sont pas connues, qui sont les plus dangereuses, en fait. Donc il y a un phénomène réel. Ça, on ne peut pas le nier. Après, ce qui s'est passé avec Mythos, c'est qu'Anthropic a sorti une version et a dit qu'on a un monstre. Clairement, je crois que c'est même les termes qui ont été employés par certains journalistes. On a quelque chose qui est trop fort pour découvrir des vulnérabilités. On a découvert des vulnérabilités dans l'OIO Linux, dans OpenBSD, des bugs qui étaient là depuis 27 ans et des choses assez importantes. Mais il y a un gros effet marketing aussi avec. Un gros fair marketing, et c'est vrai que quand on regarde cet aspect-là, on dit qu'en tropique, ils ont fait quelque chose qui a l'air monstrueux. Ils disent que c'est tellement monstrueux qu'ils ne peuvent pas se permettre de l'ouvrir à tout le monde. Mais aussi, à côté de ça, quand on réfléchit au coût associé, qui est à peu près estimé à 10 fois supérieur, si je ne dis pas de bêtises, il faudra peut-être vérifier les sources, mais à la version précédente, ça coûte très cher aussi. Et donc, du coup, ils ont décidé de l'ouvrir uniquement au groupe. grands fournisseurs d'infrastructures américains. Il y en a qui disent, qui ont un peu cette image d'América, c'est the world. On est un peu là-dedans avec Mythos, donc ce n'est pas évident. Il y a une réalité. Le truc trouve des vulnérabilités. Mais à côté, il y a aussi un peu un effet marketing, géopolitique, tout ça. Il faut faire attention.
Speaker #0
Je crois qu'OpenAIR avait déjà utilisé, il y a 2-3 ans, on retrouve des articles où ils disent, on a un modèle c'est... Pour l'instant, on ne le relise pas parce que c'est dangereux et tout. Et potentiellement, ça l'est un peu. Mais on sent aussi que cet argument de « on a un truc de ouf, mais on ne peut pas trop vous dire » , ça marche pas mal.
Speaker #3
Clairement, pour Anthropique, c'est tout à fait le cas. Leur IPO est censé avoir lieu en octobre. Donc là, ils ont intérêt à faire monter le buzz là-dessus. Comme tu le dis, Willy, je pense qu'il y a une réalité. C'est une réalité. Ces outils sont quand même hyper puissants et permettent de découvrir des failles très rapidement. Mais à côté de ça, il y a une grosse partie de buzz, de marketing. Leur objectif, c'est quand même de réussir leur IPO en octobre de façon très successful pour rentabiliser. C'est aussi des boîtes qui ont investi des milliards, des investisseurs qui ont investi des milliards sur ces entreprises-là et qui vont demander un retour sur investissement. Donc oui. Il y a un peu de buzz autour, mais ça ne veut pas dire qu'il faut tout jeter bébé avec le divan.
Speaker #4
Il y a du buzz, mais en vrai, on voit quand même que ça a des effets. Ça trouve des CVE. Là, je ne sais pas...
Speaker #0
Tu peux rappeler vite fait ce que c'est une CVE pour nos auditeurs ?
Speaker #4
Alors, le terme exact de CVE, je pense que Willy, tu...
Speaker #2
Common Vulnerability Exposure.
Speaker #4
Donc, c'est des vulnérabilités qui ont été trouvées et qui ont été du coup communiquées, qui sont enregistrées dans une base de CVE. Et du coup, on peut savoir si on utilise une dépendance, si cette dépendance dans telle version a des CVE, donc des vulnérabilités. et auquel cas on sait qu'il va falloir mettre à jour cette dépendance pour pouvoir ne plus l'être exposée. Et du coup, ce que je voulais dire, c'est que ces modèles, déjà ils trouvent des CVE actuellement. Moi je vois sur le logiciel sur lequel on travaille, il y a peut-être 5 ans en arrière, on devait traiter peut-être 1 à 2 CVE par semaine. Là j'ai l'impression qu'on en a peut-être 5 par jour. Donc il y a une multiplication du nombre de CVE qui sont trouvés. C'est un peu la course dans les deux sens. Il y a peut-être des attaquants qui vont trouver des failles 0D très rapidement. Mais d'un autre côté, si on utilise ces IA pour les détecter en amont et pouvoir être proactifs, je pense que oui, il y a un buzz, mais il y a quand même un vrai effet sur la sécurité derrière. Je ne sais pas si ça va augmenter la sécurité globalement, mais en tout cas, ça a un gros impact sur les équipes de dev standard parce qu'on va devoir gérer des quantités de CVE, des mises à jour de librairie. presque tous les jours en fait.
Speaker #3
Oui, et puis sur les process aussi de revue, nous on voit ça déjà des impacts, dans les équipes je le vois directement. C'est vrai que toutes ces CVE, on est censé les analyser pour savoir si elles nous impactent réellement, comme toujours, parce qu'elles ne sont pas impactantes parce qu'on n'utilise pas cette partie de la librairie, ou parce qu'on a déployé dans un contexte de type bastion qui nous protège, mais on est obligé de faire cette analyse. Et même si on cède des IA pour faire l'analyse de la CVE, c'est pas si trivial que ça. Il y a quand même un coût humain non négligeable.
Speaker #2
Je peux en parler un peu, c'est mon ballon d'expertise. J'ai la chance d'avoir une équipe de 7 personnes qui ne font que ça. Donc, faire de l'analyse de CVE et savoir si on est vraiment impacté ou pas. Ce dont on se rend compte, c'est que déjà, le tooling là-dessus, il est très compliqué, puisque chaque projet a ses spécificités, il a ses propres dépendances. On peut parler de comment on construit une image Docker, il n'y a pas deux équipes qui font la même chose. Donc voilà, c'est assez complexe. Là-dessus, l'IA nous aide aussi. Et en fait, on se retrouve dans un espèce d'entonnoir où d'un côté, l'IA peut nous aider, si on a les bons outils, à faire ces analyses-là. Donc moi, je peux le dire ouvertement, sur des projets open source, j'ai utilisé Cloud Code 4.6, Opus 4.6. Il est capable, typiquement, du JS où on retrouve... Pas mal de vulnérabilité quand on passe un scanner de vulnérabilité.
Speaker #0
Mais non, mais non.
Speaker #2
Ah, désolé, c'est une réalité. En fait, il est capable, si on le drive, et moi j'ai fait l'expérience, en fait, si je le laisse tout seul, il va me sortir une liste de vulnérabilité sur un petit projet. Il va me dire, il y a ta 10 critiques et 50 aïes. Si je le drive, on lui disait, non mais attends, là la critique, c'est une vulnérabilité low dash, il y a une seule fonction qui est affectée, la probabilité que mon code utilise cette fonction, elle est faible. Regarde, creuse. Et en fait, si tu le drives comme ça, il arrive simplement à te dire, mais oui, tu as raison, bien sûr, à raffiner l'analyse. Donc tout le travail manuel fastidieux d'aller chercher les choses, il va le faire lui. Toi, tu le pilotes et tu arrives à faire ton analyse de vulnérabilité et à raffiner. Ce qui est super chouette, c'est qu'il te produit le rapport deux fois plus beau que ce que tu pourrais faire toi. Et en fait, au final, moi, sur l'expérience que j'ai eue sur un projet JS, sur dix critiques, il y en avait une seulement qui était vraie. Donc ça fait quand même un taux de faux positifs de 90%, ce qui est à peu près les chiffres qu'on retrouve sur les scanners de vulnérabilité. 80-90% de faux positifs, c'est énorme. Et ça, en fait, il faut les aider. Donc ça, c'est vraiment une aide. C'est un côté de l'entonnoir, ça nous aide à raffiner cette analyse. Et l'autre côté, c'est qu'avec des trucs comme Mythos qui arrivent et qui découvrent plein de vulnérabilités et beaucoup plus, en fait, on va avoir, là clairement, nous on s'attend à avoir une vague. de vulnérabilité qui va nous arriver dans la tronche et qu'il va falloir pouvoir gérer. Donc en fait, on se retrouve vraiment avec un problème de ressources. On va avoir plein de vulnérabilités qui vont arriver. Et si on n'utilise pas l'IA, on va galérer pour les traiter.
Speaker #0
J'allais vous emmener un peu sur la futurologie, projection à 2028, où est-ce qu'on en est. Mais du coup, peut-être qu'on peut rebondir. Là, tu es un peu en train de nous... nous prédire qu'assez rapidement on va avoir une amplification du nombre de failles qui sont découvertes et dont il faut s'équiper et s'armer dans les équipes pour pouvoir les gérer. Vous avez des conseils, Philippe, Loïc, sur... Il faut recruter plus d'experts en sécu, il faut investir plus dans des logiciels, dans de la formation ? Pour gérer un peu cette vague qui va arriver ?
Speaker #4
Déjà, il faut former nos équipes à la sécurité, à lire des CVE, à comprendre, des fois, ne pas accepter bêtement la CVE, l'analyser, savoir si elle s'applique à nous ou pas, produire des rapports qui permettent à la fois, à l'instant T, de dire que oui ou non, on n'est pas impacté, mais qui permettent aussi de pouvoir traiter plus facilement les CVE qui viennent dans le futur. Ce que je vois chez nous, c'est souvent les mêmes patterns qui sont un peu... répliqués à chaque fois dans les CVE. Donc voilà, la formation. Je ne sais pas si on peut se permettre, toutes les équipes, de recruter des experts sécurité en plus.
Speaker #3
Oui, formation, recrutement. Et puis, je pense que pareil, les principes classiques de vérification, de pen testing ou de red team interne, c'est des choses qu'on a développées nous dans l'entreprise. On a des équipes de red team.
Speaker #0
C'est quoi une red team ?
Speaker #3
Une red team, c'est des personnes dont le temps est dédié à essayer de creuser, trouver des failles. Donc là, on n'est plus dans l'utiliser l'IA, mais ceci dit, ces équipes commencent à utiliser l'IA pour faire du red teaming. Bon bref,
Speaker #2
on dit sécurité offensive en français. Merci, merci, excusez-moi,
Speaker #3
c'est une boîte américaine, on est un peu très franglish là. Désolé pour les auditeurs. Voilà, et donc des red team ou des pentest, nous on a des... On prend des boîtes externes qui font des tests de surface d'attaque sur nos outils externalisés auprès de nos clients et qui lancent des campagnes de pen-test classiques avec maintenant une dimension IA un peu plus forte. Vu qu'on est beaucoup sur de l'échange textuel, il y a aussi une dimension de faire du prompt injection, ce genre de choses.
Speaker #1
Ce que vous nous dites aujourd'hui, c'est que ce sera avec l'arrivée d'IA et le déferlement de CVE qu'on va voir... à paraître, ce sera plus acceptable d'avoir une équipe qui va les ignorer ou qui travaille comme auparavant, fixer des CVE un petit peu comme ça. Mais on va devoir vraiment cranter dans les équipes de dev pour s'armer pour l'avenir. En fait,
Speaker #2
je pense qu'on est au cœur d'un moment où il va falloir prendre une décision stratégique. C'est-à-dire qu'effectivement, on a le sentiment que ceux qui n'utiliseront pas l'IA vont sûrement galérer un peu plus et potentiellement avoir un niveau de sécurité inférieur. Mais il y a un élément qui est très important à prendre en compte. Donc là, je mets ma casquette bulle IA souveraine. En fait, il y a un vrai risque à utiliser les IA les plus performantes tout de suite, qui sont généralement des IA proposées par les États-Unis, donc typiquement anthropiques. En fait, il est très probable. Donc là, je ne vais pas rentrer dans la preuve, tout ça, parce qu'on est sur du renseignement et des choses qui ne sont pas très palpables. Mais en fait, on est relativement sûr que les États-Unis, les services de renseignement, comme ils aiment bien le faire et comme ça a été démontré par le passé, s'ils arrivent à savoir que sur du code privé européen, il y a des vulnérabilités, s'ils peuvent en garder un peu pour eux, ces informations-là, ils ne vont pas se priver. Ça a une valeur inestimable pour eux. Donc ça, c'est un vrai risque. avec Mythos, il y a un nouveau risque, un truc encore plus haut qui est apparu, c'est que même les développeurs d'Anthropique le reconnaissent dans le communiqué qu'ils ont fait, c'est que ils ne sont pas sûrs que le modèle lui-même ne leur cache pas des choses. Donc il faut avoir conscience aussi dans le fait que le modèle pourrait trouver des choses, pourrait sous-performer. Typiquement, ce qu'ils décrivent, c'est que le modèle commence sur les phases d'alignement à avoir conscience qu'il est Merci. audités, en fait. Et ils ont des fortes présomptions sur le fait qu'ils sous-performent. Ça, c'est un risque qu'il faut prendre en compte. Et nous, chez Bull, clairement, en fait, ce qu'on essaie de promouvoir, c'est d'utiliser des IA type Mistral ou des IA qu'on peut mettre on-premise chez nous pour se protéger, en fait, de ça qu'il y a un vrai risque. Et je pense que c'est un risque, c'est une démarche qui est stratégique, au niveau même européenne, en fait, au niveau souverain. il faut quand même que... on arrive à résister à utiliser ces outils qui sont super forts et très récents parce que on a les moyens de faire en sorte que dans quelques mois peut-être, on ait un équivalent qui soit souverain. Et c'est ça qui est difficile, c'est résister à ces outils-là. Et il faut promouvoir le logiciel européen là-dessus. C'est hyper important, c'est très stratégique.
Speaker #1
On parle souvent du Cyber Resilience Act. C'est en lien avec ça ? Vous pouvez nous en parler ?
Speaker #3
Nous, on est un petit peu biaisés par notre appartenance. On fait partie d'une entreprise où ces considérations, il faut être honnête, mais ça rejoint ce que tu dis et c'est une réalité. Les considérations de souveraineté pour une boîte américaine et de co-reporteur américain, ce n'est pas des considérations importantes. C'est-à-dire qu'ils ne le prennent pas en compte parce qu'il faut qu'ils vendent aussi à des clients européens. Donc, comme nous, on a des questions auprès de nos clients européens qui nous disent « Vous êtes sur des data centers américains, vous dépendez du Cloud Act, et c'est d'autant plus vrai avec l'EI maintenant. » Donc, on a des clients qui demandent « Est-ce qu'on n'active pas l'EI dans certains de nos produits, sur les outils qu'on fournit en interne ? » Après, c'est vrai qu'on est plutôt, actuellement, nous, sur une course à l'usage interne, amélioration d'efficacité, trouver des CVE, etc. Et on n'a clairement pas tout à fait ces questions-là. Nous, on se les pose personnellement en tant qu'Européens et développeurs européens et français. Loïc, il pourrait en parler. Il a expérimenté d'utiliser Mistral, par exemple, en local. Mais c'est moins le cas. Je voulais juste rebondir sur un truc dont tu parlais, sur le fait d'utiliser des LLM en local, dont Mistral, etc. On sait qu'il y a des LLM qui sont très performants chinois, notamment d'Ipsi, qu'on peut installer en local, complètement isolés. Donc, on va se dire qu'on est protégé. Moi, j'ai des questions là-dessus. C'est peut-être très parano, je l'assume. Ces LLM, ils sont entraînés. On ne sait pas comment. On ne sait pas comment ils ont été entraînés. Ils ont peut-être des biais. On pourrait très bien imaginer que ces LLM open source sont entraînés en disant, si tu trouves des failles, tu ne les dévoiles pas. Ces failles-là, tu les gardes pour toi. Tu ne vas pas t'amuser à les dévoiler. Et du coup, ça peut permettre d'avoir des backdoors dans le futur sur les bout de code qui seraient utilisables par les personnes qui ont créé ces LLM-là. Parce qu'ils ont fait en sorte que les LLM ne dévoilent pas. dans son apprentissage, sur le champ de faille. Bon, encore une fois, c'est très projectif. Je suis tout à fait d'accord avec toi, Philippe, par exemple. Mais voilà, c'est des choses qui peuvent... Il faut se poser cette question-là, en tout cas.
Speaker #4
Il y a un autre risque, je dirais, sur les LLM open source. À la vitesse où les LLM sortent, on voit beaucoup de gens qui font des expérimentations sur leur machine, qui testent un modèle, qui testent un deuxième, un troisième. Ils passent leur temps à télécharger des nouveaux modèles depuis GingFace ou des choses comme ça. Et là, il y a des risques aussi de supply chain attack où on téléchargerait un modèle vérolé. Et potentiellement, en envoyant des données dedans, on penserait que c'est sécurisé, mais en fait, on ne sait pas vraiment de ce qu'on télécharge. On télécharge des gigas et des gigas de données qu'on déploie chez nous et on fait ça toute la journée en changeant de modèle. Là, je pense qu'il y a un gros risque. Il faut faire très attention à ce qu'on déploie et qu'on n'utilise que des modèles, des sources. sécurisés et des sources de confiance.
Speaker #1
Est-ce que du coup en 2030, les équipes sont super formées à la cyber-sécu, super parano ? C'est ça l'idée ?
Speaker #2
On ne peut pas, pour moi c'est illusoire en fait. La cyber-sécurité, grosso modo, c'est essayer de traiter le maillon plus faible de ta chaîne parce qu'en fait, quand tu as un système d'information, Le niveau global de sécurité de ton système, il est égal à ton composant le plus faible, celui qui va t'attaquer. Je schématise, mais c'est l'idée du truc. Et humainement, on ne peut pas demander à tout le monde d'être expert en cybersécurité, surtout quand on voit la vitesse à laquelle ça évolue. Moi, je suis en formation continue. Par contre, là, encore une fois, où l'IQE peut apporter, c'est que moi, j'ai donné à certains collaborateurs qui montent en compétence sur de la sécurité. C'est un super coach aussi. C'est un super coach si tu sais l'utiliser comme ça. Et là, peut-être qu'on n'est pas obligé d'aller chercher les modèles les plus performants pour dire, écoute, je dois faire de l'analyse de risque, comment je peux m'y prendre, enfin ce genre de choses.
Speaker #3
Oui, c'est un bon point, tu as raison. On est en train de déployer de plus en plus les pratiques de Cloud Code avec des agendes et skills.md. On pourrait très bien imaginer avoir un agent dédié qui, lorsque tu lui demandes de développer une fonctionnalité, tu lui demandes de relire et de faire un check de sécurité, d'apprendre aux développeurs. à comprendre ce que le code a été généré, quelles sont les faiblesses d'attaque qui pourraient être présentes, etc. Une partie formation, coaching, effectivement, ça peut être une bonne approche.
Speaker #4
Moi, je pense qu'il y a aussi un impact à prendre en compte, c'est que dans les années à qui viennent, la quantité de logiciels développés, de codes développés va être drastiquement augmentée. Je vois déjà beaucoup chez nous Si on ne guide pas les LLM, entre utiliser une dépendance qu'on sait qui est sécurisée, des fois le LLM va chercher à reproduire et recoder la fonctionnalité. Donc on va se retrouver avec des applications qui ont une quantité de code gigantesque et potentiellement des failles... présente.
Speaker #2
C'est super intéressant ce que tu dis, juste je mets le doigt, je rebondis je mets le doigt sur un truc super important il y a un truc qui paraît évident et j'en parlais dans ma conférence demain c'est qu'en fait quand on veut gérer de la vulnérabilité il y a un truc qui est au coeur c'est choisir ses dépendances et maîtriser ses dépendances et effectivement aujourd'hui on a des moyens de développement qui font que c'est facile d'accéder à plein de dépendances open source, des images docker qui elles-mêmes embarquent des dépendances, des sous-dépendances tout ça euh Avec une IA, en fait, quand on fait du développement, il faut quand même être maître, soit, des dépendances qu'on intègre et surtout pas faire confiance à l'IA pour les dépendances qu'on intègre. Et c'est valable, comme tu dis, c'est très juste ce que tu dis avec les modèles aussi. Le modèle qui va t'aider à développer, en fait, lui-même, est une dépendance de niveau plutôt supply chain.
Speaker #3
Je suis d'accord. Et en fait, ça, c'est vraiment le gros changement qu'on va avoir. C'est qu'on arrive dans une phase, j'ai l'impression, où tu vas avoir des... des développeurs qui vont avoir l'impression d'être super puissants, surtout des personnes qui ont peut-être moins de skills, qui sont peut-être un peu plus juniors, et qui, par contre, vont moins maîtriser ce qu'ils font. Et donc, rappeler, je pense que cet aspect formation, coaching, ça va être des choses essentielles sur la sécu, évidemment, c'est la base, sur plein d'autres aspects pour bien comprendre ce qu'on fait. Je pense que ça, c'est le risque de dérive qu'on a avec ces outils-là, notamment sur la sécurité, c'est l'impression que tu peux tout faire sans avoir besoin de comprendre ce que tu fais. C'est vrai que c'est quand même des tendances qu'on voit. J'étais à une conférence il y a un mois à Londres, à Kukon, et on voit des messages genre « write only code » , « n'essayez même plus de lire votre code » , ce genre de messages. Laissez faire l'IA complètement, oui, mais comprenez ce que vous faites quand même. Et ça, je pense que c'est essentiel.
Speaker #2
Je peux te donner une anecdote ? Moi, je suis tombé de ma chaise il n'y a pas longtemps. Il y avait... Une équipe qui me dit en fait nous là on a envie de travailler sur un POC un petit projet de dessous, on va faire ça avec le code et c'était super fine dans le contexte, il n'y a pas de soucis là-dessus ils me disent en fait ce qu'on va faire c'est qu'on va régénérer notre code, on va juste bosser sur nos specs et on va régénérer notre code pas à chaque itération mais à chaque version et finalement la qualité on s'en fout un peu parce qu'en fait on va mettre notre truc en preuve, on va faire tester par les utilisateurs et puis après on va tout régénérer depuis le début, parce que ça peut fonctionner Moi, avec ma casquette sécurité slash qualité, je suis tombé de ma chaise. Les gars, comprenez ce que vous faites quand même, s'il vous plaît. En fait, tu pourrais dire, je te mets une grosse tartine de pré-pronte, qualité, sécurité, machin, tout ça. Mais bon, sur le principe même, moi, ça m'a un peu choqué. Mais il y a des gens qui pensent comme ça.
Speaker #4
Et je veux revenir sur ce que tu disais, Philippe. Je pense qu'il y a un risque aussi. qui va apparaître surtout en tant qu'utilisateur. On va voir de plus en plus apparaître des personnes qui ne sont pas du tout dans le soft, qui vont générer du code. Ce matin, j'ai lu juste le début d'une news qui parlait d'un médecin américain qui avait généré une application pour gérer ses données de ses patients, qui était pleine de vulnérabilité et du coup qui s'est fait attaquer. Ça, on va le voir de plus en plus.
Speaker #3
Nous, en tant qu'utilisateur,
Speaker #4
il faudra qu'on fasse gaffe à ce qu'on va utiliser sur Internet comme service.
Speaker #3
Ça fait un peu peur. Cette tendance, on appelle le vibe coding, qui était un peu le renouveau du low-code, no-code, quelque part, d'une certaine façon, on peut le voir comme ça. C'est vrai qu'il y a une vraie tendance là-dessus et nous, ça fait vraiment flipper nos sit-ops, notamment. Pour rejoindre tous les deux ce que vous dites, c'est que la quantité d'informations qui va arriver ou de codes qui va arriver avec le risque, on va avoir un nouveau bottleneck, c'est les équipes sit-ops, les équipes cybersec dans les équipes ops qui veulent vérifier et ça, pour l'instant, Voilà, à part les bonnes pratiques coaching, un peu ce qu'on a donné comme idée de rappeler les principes, les fondamentaux. On ne sait pas trop comment cette vague va être gérée.
Speaker #1
Merci pour ces pistes.
Speaker #0
Nous arrivons à la fin de cet échange qui était passionnant, clairement. Philippe, Loïc et Willy, avant de vous laisser partir, on a une tradition sur Mixitonair, donc partagez avec nos auditeurs et auditrices une ressource incontournable, un site. Un auteur, une autrice ou un outil qui vous inspire pour une tech plus éthique ? Loïc, ce serait quoi un peu ta reco pour notre public ?
Speaker #4
Alors je dirais que ma reco, moi que j'ai beaucoup utilisé pour comprendre comment fonctionne l'IA et tous ces LLM, c'est la chaîne YouTube de IBM qui propose d'expliquer en détail comment ça fonctionne. C'est très illustré, très accessible et je trouve que c'est une super ressource à suivre pour comprendre comment ça fonctionne.
Speaker #0
Philippe ?
Speaker #3
Pour moi, c'est un peu adjacent au domaine de la sécurité en tant que tel, mais vu que je suis manager d'équipe, je préconise vraiment les podcasts de Simon Sinek, qui est un coach dans le management leadership et globalement le fonctionnement des équipes, et qui a fait des talks récemment sur comment l'IA va changer le fonctionnement des équipes et comment le rôle des managers est clé là-dedans. Donc j'encourage toutes les personnes, ou même leaders ou tech leaders d'équipe à écouter, parce qu'il y a vraiment des bons principes. Quelqu'un qui est très ouvert et très ouvert sur l'éthique et le relationnel.
Speaker #0
Winnie ? Alors, moi, je vais parler du blog de Sébastien Dioria, que j'ai eu la chance de rencontrer au Snowcamp cette année au mois de janvier. Donc, lui, il maîtrise vraiment la cybersécurité. Il travaille au chapter de l'OASP, en France, je crois. Et il donne des bonnes pratiques sur l'utilisation de l'IA. Donc, il est vraiment, pour moi, influenceur à la croisée des chemins entre l'IA et la sécurité. Donc, vraiment sur ce sujet-là. aller voir son blog. C'est impressionnant d'avoir aussi le travail qu'il fournit parce que c'est génial. Je crois qu'il publie son scénario. C'est un scénario de un mois à l'avance. C'est assez impressionnant.
Speaker #1
Merci infiniment pour votre participation aujourd'hui. Je rappelle à nos auditeurs et auditrices que vous pouvez retrouver les conférences complètes de Philippe et Loïc et de Willy. en replay sur la chaîne YouTube de Mixit. Si cet épisode vous a plu, n'hésitez pas à vous abonner et à partager le podcast autour de vous. Et d'ici là, gardez en tête que pour une tech éthique, il faut garder l'esprit ouvert et critique. A bientôt !

Description

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

Speaker #0
Bienvenue sur Mixit On Air, où la tech rime avec l'éthique. Je suis Hubert.
Speaker #1
Et moi, je suis Anne-Laure.
Speaker #0
Et à chaque épisode, nous plongeons dans les coulisses de la conférence Mixit pour vous faire découvrir les innovateurs et innovatrices qui façonnent notre avenir numérique. Aujourd'hui, on a le plaisir d'accueillir Philippe Lommé, directeur en générique chez Moody's Analytics, Loïc Budé, technical architect chez Moody's Analytics également, et Willy Malveaux, architecte sécurité chez Bull. Avec eux... Nous allons explorer ce que l'IA change vraiment à la sécurité entre nouvelles surfaces d'attaque, vieux réflexes qui tiennent bon et vagues réglementaires qui arrivent en
Speaker #2
2027.
Speaker #1
Philippe, Loïc et Willy, bienvenue sur Mixit On Air. On est là pour parler CyberCQ et IA. Personnellement, j'ai la sensation que ce que j'ai appris hier, c'est déjà périmé aujourd'hui. Donc ma première question, c'est aujourd'hui on est le 16 avril 2026. D'après vous, sur quoi on devrait porter notre attention si on est une équipe de devs qui ne veut pas se faire trouver sa prod ? Willy, tu commences ?
Speaker #2
Oui, je vais commencer. Alors déjà, l'IA, un petit peu comme dans tous les domaines, ça va augmenter la sécurité. Mais j'ai envie de dire, la première réponse, c'est déjà avoir des fondamentaux de sécurité traditionnels, donc essentiellement avec de la méthode de sécurité. Pour structurer, en fait, le lien entre l'IA et la sécurité, il y a une approche que j'aime bien, qui est issue du framework du NIST, en fait. Il parle de Secure. « Sécure » , ça veut dire, par rapport à nos méthodes de sécurité sur un SI traditionnel, aujourd'hui l'IA, ça rapporte une nouvelle brique et il va falloir la sécuriser avec des nouvelles méthodes. Je pense que c'est le domaine d'expertise de Philippe et de Loïc. Ensuite, l'IA, il y a « defend » , c'est-à-dire comment on utilise l'IA pour se défendre. Donc là, on va parler de tout ce qui est vulnérabilité, gestion de CV augmentée. Ensuite, il y a « twartz » . « Twartz » , c'est comment ? En fait, les hackers, ou même des fois, ça nous dépasse avec l'actualité, certaines IA peuvent devenir offensives. Et un dernier élément aussi que je rajouterais, c'est les petites questions de souveraineté sur ces outils-là.
Speaker #1
Donc d'après toi, les équipes devraient se focaliser sur ces quatre axes, du coup, si on rajoute la souveraineté. Et pour vous, Loïc ou Philippe ?
Speaker #3
Nous, c'est vrai qu'on est très axé sur essayer de défendre les outils à base d'IA contre des attaques. C'est un peu notre credo actuel. Et là, ça passe par beaucoup de compréhension déjà du fonctionnement de ces outils. Et après, je dirais, les approches, c'est du classique. C'est mettre en place des pentests qui vont vérifier spécifiquement certains axes, certains aspects. nouveaux au niveau technique et fonctionnel de ces outils-là. On s'inspire des grands classiques. Nous, on s'est basé sur OWASP, qui est un organisme bien connu. On connaît tous le Top 10 Web Vulnerability. Ils ont sorti, par exemple, en 2024 et 2025, ils l'ont mis à jour fin 2025, leur Top 10 Vulnerability sur les LLM apps. C'est vraiment une bible pour identifier déjà les failles potentielles et les menaces.
Speaker #0
C'est bon. C'est orienté sur les gens qui utilisent des LLM pour coder et faire d'autres choses, ou pour les gens qui utilisent des modèles dans les produits qu'ils construisent ?
Speaker #3
C'est essentiellement à destination des développeurs qui vont fournir des applications à base de LLM pour pouvoir les sécuriser. Alors, ce que vous utiliserez, typiquement un chatbot qui, derrière, utilise un LLM. Comment vous allez sécuriser votre chatbot, la base de technique de guardrail ?
Speaker #4
Je pense qu'il y a quelque chose qui est très important aussi quand on met en place des applications à base d'IA, c'est d'avoir une observabilité vraiment très importante sur absolument tout ce qui se passe. Parce qu'on voit que ça évolue très vite, les techniques d'attaque évoluent très vite aussi. On reçoit des promptes d'attaque qui sont assez complexes. On aime bien avoir nos plateformes pour identifier la menace, mettre en place des garde-fous pour pouvoir s'en prévenir et pouvoir après ajouter ces menaces dans notre CI pour pouvoir valider qu'elles tiennent dans le temps.
Speaker #3
Donc c'est des techniques classiques, observabilité, on s'en sert déjà.
Speaker #2
C'est la base de la sécurité, on en revient aux fondamentaux.
Speaker #3
On en revient aux fondamentaux mais après on les adapte. à ce que permettent désormais ces outils-là, qui sont vraiment de l'analyse de texte, le fait qu'on soit non déterministe, et puis surtout le fait que, je dirais, certaines personnes, surtout les dirigeants, je vais peut-être être un peu négatif comme ça, mais oublient un petit peu que c'est une technologie qui peut être facilement détournée, et donc il y a une volonté d'aller vite, de fournir des nouvelles solutions à base d'IA, et la sécurité, on verra après. Mais ça, ça a été vrai dans toute nouvelle technologie. Donc, ouvrez les fondamentaux. Qui n'a pas entendu son CEO dire, maintenant, vous m'ouvrez toutes les données de l'entreprise aux agents. Comme ça, on va pouvoir coder plus vite et accéder à toutes les infos. Non, ça, c'est des choses, l'excessive agency, c'est un peu des bases. Le Zero Trust Approach, c'est aussi des bases standards. Il faut juste les rappeler dans ces contextes-là. Et après, réadapter certaines façons de développer quand même.
Speaker #2
C'est super juste ce que tu dis Philippe. En fait, moi je ferais écho carrément à la keynote qu'on a eue ce matin, qui nous parlait, enfin le message je vais un petit peu beaucoup le vulgariser, mais qui dit qu'IA finalement c'est surtout une idéologie avant d'être une technologie. Et ça me fait penser à ce que tu dis, c'est vrai qu'on est dans une mouvance où on a des managers et même des clients, enfin tous nos stakeholders qui nous disent qu'il faut faire de l'IA si on veut être en retard. Mais en même temps, il y a un risque qui est lié à l'utilisation de cette IA. Et en fait, on est vraiment dans une course entre un manque à gagner et un risque d'avoir potentiellement des problèmes de sécurité et autres. Et en fait, ce qui se passe, c'est que ça accélère. En fait, on l'a vu sur le domaine de la sécurité avec Mythos. Ah, on parle de Mythos.
Speaker #0
Est-ce que tu peux nous en dire plus ? C'est assez récent, là, on enregistre le 16 avril. Ça fait flipper ? Pas trop ? Un peu ? Il y a de l'ail ?
Speaker #2
C'est compliqué, il faut prendre ce sujet avec un petit peu de recul. Moi, j'ai un retour d'expérience rapide là-dessus. Avant Mythos, il y avait Cloud Code Opus 4.6, je crois, si je n'ai pas de bêtises, qui a dû sortir fin février. Moi, j'ai eu la chance d'avoir un ami architecte sécurité dans mon réseau qui m'a dit « Willy, il faut que tu essayes ça, il y a vraiment un step qui a été franchi en termes de sécurité. » Donc je l'ai essayé et typiquement, il y a eu une période, on va dire pendant le mois de mars, où avant, avec la Prémitos, on parle, j'ai participé avec d'autres personnes à faire des expérimentations, donc d'audit de code en mode whitelist sur des projets open source. J'y reviendrai, c'est important, open source. Et effectivement, on trouve des vulnérabilités, quoi. On trouve ce qu'on appelle des zéro-tels, c'est-à-dire des failles qui ne sont pas référencées, qui ne sont pas connues, qui sont les plus dangereuses, en fait. Donc il y a un phénomène réel. Ça, on ne peut pas le nier. Après, ce qui s'est passé avec Mythos, c'est qu'Anthropic a sorti une version et a dit qu'on a un monstre. Clairement, je crois que c'est même les termes qui ont été employés par certains journalistes. On a quelque chose qui est trop fort pour découvrir des vulnérabilités. On a découvert des vulnérabilités dans l'OIO Linux, dans OpenBSD, des bugs qui étaient là depuis 27 ans et des choses assez importantes. Mais il y a un gros effet marketing aussi avec. Un gros fair marketing, et c'est vrai que quand on regarde cet aspect-là, on dit qu'en tropique, ils ont fait quelque chose qui a l'air monstrueux. Ils disent que c'est tellement monstrueux qu'ils ne peuvent pas se permettre de l'ouvrir à tout le monde. Mais aussi, à côté de ça, quand on réfléchit au coût associé, qui est à peu près estimé à 10 fois supérieur, si je ne dis pas de bêtises, il faudra peut-être vérifier les sources, mais à la version précédente, ça coûte très cher aussi. Et donc, du coup, ils ont décidé de l'ouvrir uniquement au groupe. grands fournisseurs d'infrastructures américains. Il y en a qui disent, qui ont un peu cette image d'América, c'est the world. On est un peu là-dedans avec Mythos, donc ce n'est pas évident. Il y a une réalité. Le truc trouve des vulnérabilités. Mais à côté, il y a aussi un peu un effet marketing, géopolitique, tout ça. Il faut faire attention.
Speaker #0
Je crois qu'OpenAIR avait déjà utilisé, il y a 2-3 ans, on retrouve des articles où ils disent, on a un modèle c'est... Pour l'instant, on ne le relise pas parce que c'est dangereux et tout. Et potentiellement, ça l'est un peu. Mais on sent aussi que cet argument de « on a un truc de ouf, mais on ne peut pas trop vous dire » , ça marche pas mal.
Speaker #3
Clairement, pour Anthropique, c'est tout à fait le cas. Leur IPO est censé avoir lieu en octobre. Donc là, ils ont intérêt à faire monter le buzz là-dessus. Comme tu le dis, Willy, je pense qu'il y a une réalité. C'est une réalité. Ces outils sont quand même hyper puissants et permettent de découvrir des failles très rapidement. Mais à côté de ça, il y a une grosse partie de buzz, de marketing. Leur objectif, c'est quand même de réussir leur IPO en octobre de façon très successful pour rentabiliser. C'est aussi des boîtes qui ont investi des milliards, des investisseurs qui ont investi des milliards sur ces entreprises-là et qui vont demander un retour sur investissement. Donc oui. Il y a un peu de buzz autour, mais ça ne veut pas dire qu'il faut tout jeter bébé avec le divan.
Speaker #4
Il y a du buzz, mais en vrai, on voit quand même que ça a des effets. Ça trouve des CVE. Là, je ne sais pas...
Speaker #0
Tu peux rappeler vite fait ce que c'est une CVE pour nos auditeurs ?
Speaker #4
Alors, le terme exact de CVE, je pense que Willy, tu...
Speaker #2
Common Vulnerability Exposure.
Speaker #4
Donc, c'est des vulnérabilités qui ont été trouvées et qui ont été du coup communiquées, qui sont enregistrées dans une base de CVE. Et du coup, on peut savoir si on utilise une dépendance, si cette dépendance dans telle version a des CVE, donc des vulnérabilités. et auquel cas on sait qu'il va falloir mettre à jour cette dépendance pour pouvoir ne plus l'être exposée. Et du coup, ce que je voulais dire, c'est que ces modèles, déjà ils trouvent des CVE actuellement. Moi je vois sur le logiciel sur lequel on travaille, il y a peut-être 5 ans en arrière, on devait traiter peut-être 1 à 2 CVE par semaine. Là j'ai l'impression qu'on en a peut-être 5 par jour. Donc il y a une multiplication du nombre de CVE qui sont trouvés. C'est un peu la course dans les deux sens. Il y a peut-être des attaquants qui vont trouver des failles 0D très rapidement. Mais d'un autre côté, si on utilise ces IA pour les détecter en amont et pouvoir être proactifs, je pense que oui, il y a un buzz, mais il y a quand même un vrai effet sur la sécurité derrière. Je ne sais pas si ça va augmenter la sécurité globalement, mais en tout cas, ça a un gros impact sur les équipes de dev standard parce qu'on va devoir gérer des quantités de CVE, des mises à jour de librairie. presque tous les jours en fait.
Speaker #3
Oui, et puis sur les process aussi de revue, nous on voit ça déjà des impacts, dans les équipes je le vois directement. C'est vrai que toutes ces CVE, on est censé les analyser pour savoir si elles nous impactent réellement, comme toujours, parce qu'elles ne sont pas impactantes parce qu'on n'utilise pas cette partie de la librairie, ou parce qu'on a déployé dans un contexte de type bastion qui nous protège, mais on est obligé de faire cette analyse. Et même si on cède des IA pour faire l'analyse de la CVE, c'est pas si trivial que ça. Il y a quand même un coût humain non négligeable.
Speaker #2
Je peux en parler un peu, c'est mon ballon d'expertise. J'ai la chance d'avoir une équipe de 7 personnes qui ne font que ça. Donc, faire de l'analyse de CVE et savoir si on est vraiment impacté ou pas. Ce dont on se rend compte, c'est que déjà, le tooling là-dessus, il est très compliqué, puisque chaque projet a ses spécificités, il a ses propres dépendances. On peut parler de comment on construit une image Docker, il n'y a pas deux équipes qui font la même chose. Donc voilà, c'est assez complexe. Là-dessus, l'IA nous aide aussi. Et en fait, on se retrouve dans un espèce d'entonnoir où d'un côté, l'IA peut nous aider, si on a les bons outils, à faire ces analyses-là. Donc moi, je peux le dire ouvertement, sur des projets open source, j'ai utilisé Cloud Code 4.6, Opus 4.6. Il est capable, typiquement, du JS où on retrouve... Pas mal de vulnérabilité quand on passe un scanner de vulnérabilité.
Speaker #0
Mais non, mais non.
Speaker #2
Ah, désolé, c'est une réalité. En fait, il est capable, si on le drive, et moi j'ai fait l'expérience, en fait, si je le laisse tout seul, il va me sortir une liste de vulnérabilité sur un petit projet. Il va me dire, il y a ta 10 critiques et 50 aïes. Si je le drive, on lui disait, non mais attends, là la critique, c'est une vulnérabilité low dash, il y a une seule fonction qui est affectée, la probabilité que mon code utilise cette fonction, elle est faible. Regarde, creuse. Et en fait, si tu le drives comme ça, il arrive simplement à te dire, mais oui, tu as raison, bien sûr, à raffiner l'analyse. Donc tout le travail manuel fastidieux d'aller chercher les choses, il va le faire lui. Toi, tu le pilotes et tu arrives à faire ton analyse de vulnérabilité et à raffiner. Ce qui est super chouette, c'est qu'il te produit le rapport deux fois plus beau que ce que tu pourrais faire toi. Et en fait, au final, moi, sur l'expérience que j'ai eue sur un projet JS, sur dix critiques, il y en avait une seulement qui était vraie. Donc ça fait quand même un taux de faux positifs de 90%, ce qui est à peu près les chiffres qu'on retrouve sur les scanners de vulnérabilité. 80-90% de faux positifs, c'est énorme. Et ça, en fait, il faut les aider. Donc ça, c'est vraiment une aide. C'est un côté de l'entonnoir, ça nous aide à raffiner cette analyse. Et l'autre côté, c'est qu'avec des trucs comme Mythos qui arrivent et qui découvrent plein de vulnérabilités et beaucoup plus, en fait, on va avoir, là clairement, nous on s'attend à avoir une vague. de vulnérabilité qui va nous arriver dans la tronche et qu'il va falloir pouvoir gérer. Donc en fait, on se retrouve vraiment avec un problème de ressources. On va avoir plein de vulnérabilités qui vont arriver. Et si on n'utilise pas l'IA, on va galérer pour les traiter.
Speaker #0
J'allais vous emmener un peu sur la futurologie, projection à 2028, où est-ce qu'on en est. Mais du coup, peut-être qu'on peut rebondir. Là, tu es un peu en train de nous... nous prédire qu'assez rapidement on va avoir une amplification du nombre de failles qui sont découvertes et dont il faut s'équiper et s'armer dans les équipes pour pouvoir les gérer. Vous avez des conseils, Philippe, Loïc, sur... Il faut recruter plus d'experts en sécu, il faut investir plus dans des logiciels, dans de la formation ? Pour gérer un peu cette vague qui va arriver ?
Speaker #4
Déjà, il faut former nos équipes à la sécurité, à lire des CVE, à comprendre, des fois, ne pas accepter bêtement la CVE, l'analyser, savoir si elle s'applique à nous ou pas, produire des rapports qui permettent à la fois, à l'instant T, de dire que oui ou non, on n'est pas impacté, mais qui permettent aussi de pouvoir traiter plus facilement les CVE qui viennent dans le futur. Ce que je vois chez nous, c'est souvent les mêmes patterns qui sont un peu... répliqués à chaque fois dans les CVE. Donc voilà, la formation. Je ne sais pas si on peut se permettre, toutes les équipes, de recruter des experts sécurité en plus.
Speaker #3
Oui, formation, recrutement. Et puis, je pense que pareil, les principes classiques de vérification, de pen testing ou de red team interne, c'est des choses qu'on a développées nous dans l'entreprise. On a des équipes de red team.
Speaker #0
C'est quoi une red team ?
Speaker #3
Une red team, c'est des personnes dont le temps est dédié à essayer de creuser, trouver des failles. Donc là, on n'est plus dans l'utiliser l'IA, mais ceci dit, ces équipes commencent à utiliser l'IA pour faire du red teaming. Bon bref,
Speaker #2
on dit sécurité offensive en français. Merci, merci, excusez-moi,
Speaker #3
c'est une boîte américaine, on est un peu très franglish là. Désolé pour les auditeurs. Voilà, et donc des red team ou des pentest, nous on a des... On prend des boîtes externes qui font des tests de surface d'attaque sur nos outils externalisés auprès de nos clients et qui lancent des campagnes de pen-test classiques avec maintenant une dimension IA un peu plus forte. Vu qu'on est beaucoup sur de l'échange textuel, il y a aussi une dimension de faire du prompt injection, ce genre de choses.
Speaker #1
Ce que vous nous dites aujourd'hui, c'est que ce sera avec l'arrivée d'IA et le déferlement de CVE qu'on va voir... à paraître, ce sera plus acceptable d'avoir une équipe qui va les ignorer ou qui travaille comme auparavant, fixer des CVE un petit peu comme ça. Mais on va devoir vraiment cranter dans les équipes de dev pour s'armer pour l'avenir. En fait,
Speaker #2
je pense qu'on est au cœur d'un moment où il va falloir prendre une décision stratégique. C'est-à-dire qu'effectivement, on a le sentiment que ceux qui n'utiliseront pas l'IA vont sûrement galérer un peu plus et potentiellement avoir un niveau de sécurité inférieur. Mais il y a un élément qui est très important à prendre en compte. Donc là, je mets ma casquette bulle IA souveraine. En fait, il y a un vrai risque à utiliser les IA les plus performantes tout de suite, qui sont généralement des IA proposées par les États-Unis, donc typiquement anthropiques. En fait, il est très probable. Donc là, je ne vais pas rentrer dans la preuve, tout ça, parce qu'on est sur du renseignement et des choses qui ne sont pas très palpables. Mais en fait, on est relativement sûr que les États-Unis, les services de renseignement, comme ils aiment bien le faire et comme ça a été démontré par le passé, s'ils arrivent à savoir que sur du code privé européen, il y a des vulnérabilités, s'ils peuvent en garder un peu pour eux, ces informations-là, ils ne vont pas se priver. Ça a une valeur inestimable pour eux. Donc ça, c'est un vrai risque. avec Mythos, il y a un nouveau risque, un truc encore plus haut qui est apparu, c'est que même les développeurs d'Anthropique le reconnaissent dans le communiqué qu'ils ont fait, c'est que ils ne sont pas sûrs que le modèle lui-même ne leur cache pas des choses. Donc il faut avoir conscience aussi dans le fait que le modèle pourrait trouver des choses, pourrait sous-performer. Typiquement, ce qu'ils décrivent, c'est que le modèle commence sur les phases d'alignement à avoir conscience qu'il est Merci. audités, en fait. Et ils ont des fortes présomptions sur le fait qu'ils sous-performent. Ça, c'est un risque qu'il faut prendre en compte. Et nous, chez Bull, clairement, en fait, ce qu'on essaie de promouvoir, c'est d'utiliser des IA type Mistral ou des IA qu'on peut mettre on-premise chez nous pour se protéger, en fait, de ça qu'il y a un vrai risque. Et je pense que c'est un risque, c'est une démarche qui est stratégique, au niveau même européenne, en fait, au niveau souverain. il faut quand même que... on arrive à résister à utiliser ces outils qui sont super forts et très récents parce que on a les moyens de faire en sorte que dans quelques mois peut-être, on ait un équivalent qui soit souverain. Et c'est ça qui est difficile, c'est résister à ces outils-là. Et il faut promouvoir le logiciel européen là-dessus. C'est hyper important, c'est très stratégique.
Speaker #1
On parle souvent du Cyber Resilience Act. C'est en lien avec ça ? Vous pouvez nous en parler ?
Speaker #3
Nous, on est un petit peu biaisés par notre appartenance. On fait partie d'une entreprise où ces considérations, il faut être honnête, mais ça rejoint ce que tu dis et c'est une réalité. Les considérations de souveraineté pour une boîte américaine et de co-reporteur américain, ce n'est pas des considérations importantes. C'est-à-dire qu'ils ne le prennent pas en compte parce qu'il faut qu'ils vendent aussi à des clients européens. Donc, comme nous, on a des questions auprès de nos clients européens qui nous disent « Vous êtes sur des data centers américains, vous dépendez du Cloud Act, et c'est d'autant plus vrai avec l'EI maintenant. » Donc, on a des clients qui demandent « Est-ce qu'on n'active pas l'EI dans certains de nos produits, sur les outils qu'on fournit en interne ? » Après, c'est vrai qu'on est plutôt, actuellement, nous, sur une course à l'usage interne, amélioration d'efficacité, trouver des CVE, etc. Et on n'a clairement pas tout à fait ces questions-là. Nous, on se les pose personnellement en tant qu'Européens et développeurs européens et français. Loïc, il pourrait en parler. Il a expérimenté d'utiliser Mistral, par exemple, en local. Mais c'est moins le cas. Je voulais juste rebondir sur un truc dont tu parlais, sur le fait d'utiliser des LLM en local, dont Mistral, etc. On sait qu'il y a des LLM qui sont très performants chinois, notamment d'Ipsi, qu'on peut installer en local, complètement isolés. Donc, on va se dire qu'on est protégé. Moi, j'ai des questions là-dessus. C'est peut-être très parano, je l'assume. Ces LLM, ils sont entraînés. On ne sait pas comment. On ne sait pas comment ils ont été entraînés. Ils ont peut-être des biais. On pourrait très bien imaginer que ces LLM open source sont entraînés en disant, si tu trouves des failles, tu ne les dévoiles pas. Ces failles-là, tu les gardes pour toi. Tu ne vas pas t'amuser à les dévoiler. Et du coup, ça peut permettre d'avoir des backdoors dans le futur sur les bout de code qui seraient utilisables par les personnes qui ont créé ces LLM-là. Parce qu'ils ont fait en sorte que les LLM ne dévoilent pas. dans son apprentissage, sur le champ de faille. Bon, encore une fois, c'est très projectif. Je suis tout à fait d'accord avec toi, Philippe, par exemple. Mais voilà, c'est des choses qui peuvent... Il faut se poser cette question-là, en tout cas.
Speaker #4
Il y a un autre risque, je dirais, sur les LLM open source. À la vitesse où les LLM sortent, on voit beaucoup de gens qui font des expérimentations sur leur machine, qui testent un modèle, qui testent un deuxième, un troisième. Ils passent leur temps à télécharger des nouveaux modèles depuis GingFace ou des choses comme ça. Et là, il y a des risques aussi de supply chain attack où on téléchargerait un modèle vérolé. Et potentiellement, en envoyant des données dedans, on penserait que c'est sécurisé, mais en fait, on ne sait pas vraiment de ce qu'on télécharge. On télécharge des gigas et des gigas de données qu'on déploie chez nous et on fait ça toute la journée en changeant de modèle. Là, je pense qu'il y a un gros risque. Il faut faire très attention à ce qu'on déploie et qu'on n'utilise que des modèles, des sources. sécurisés et des sources de confiance.
Speaker #1
Est-ce que du coup en 2030, les équipes sont super formées à la cyber-sécu, super parano ? C'est ça l'idée ?
Speaker #2
On ne peut pas, pour moi c'est illusoire en fait. La cyber-sécurité, grosso modo, c'est essayer de traiter le maillon plus faible de ta chaîne parce qu'en fait, quand tu as un système d'information, Le niveau global de sécurité de ton système, il est égal à ton composant le plus faible, celui qui va t'attaquer. Je schématise, mais c'est l'idée du truc. Et humainement, on ne peut pas demander à tout le monde d'être expert en cybersécurité, surtout quand on voit la vitesse à laquelle ça évolue. Moi, je suis en formation continue. Par contre, là, encore une fois, où l'IQE peut apporter, c'est que moi, j'ai donné à certains collaborateurs qui montent en compétence sur de la sécurité. C'est un super coach aussi. C'est un super coach si tu sais l'utiliser comme ça. Et là, peut-être qu'on n'est pas obligé d'aller chercher les modèles les plus performants pour dire, écoute, je dois faire de l'analyse de risque, comment je peux m'y prendre, enfin ce genre de choses.
Speaker #3
Oui, c'est un bon point, tu as raison. On est en train de déployer de plus en plus les pratiques de Cloud Code avec des agendes et skills.md. On pourrait très bien imaginer avoir un agent dédié qui, lorsque tu lui demandes de développer une fonctionnalité, tu lui demandes de relire et de faire un check de sécurité, d'apprendre aux développeurs. à comprendre ce que le code a été généré, quelles sont les faiblesses d'attaque qui pourraient être présentes, etc. Une partie formation, coaching, effectivement, ça peut être une bonne approche.
Speaker #4
Moi, je pense qu'il y a aussi un impact à prendre en compte, c'est que dans les années à qui viennent, la quantité de logiciels développés, de codes développés va être drastiquement augmentée. Je vois déjà beaucoup chez nous Si on ne guide pas les LLM, entre utiliser une dépendance qu'on sait qui est sécurisée, des fois le LLM va chercher à reproduire et recoder la fonctionnalité. Donc on va se retrouver avec des applications qui ont une quantité de code gigantesque et potentiellement des failles... présente.
Speaker #2
C'est super intéressant ce que tu dis, juste je mets le doigt, je rebondis je mets le doigt sur un truc super important il y a un truc qui paraît évident et j'en parlais dans ma conférence demain c'est qu'en fait quand on veut gérer de la vulnérabilité il y a un truc qui est au coeur c'est choisir ses dépendances et maîtriser ses dépendances et effectivement aujourd'hui on a des moyens de développement qui font que c'est facile d'accéder à plein de dépendances open source, des images docker qui elles-mêmes embarquent des dépendances, des sous-dépendances tout ça euh Avec une IA, en fait, quand on fait du développement, il faut quand même être maître, soit, des dépendances qu'on intègre et surtout pas faire confiance à l'IA pour les dépendances qu'on intègre. Et c'est valable, comme tu dis, c'est très juste ce que tu dis avec les modèles aussi. Le modèle qui va t'aider à développer, en fait, lui-même, est une dépendance de niveau plutôt supply chain.
Speaker #3
Je suis d'accord. Et en fait, ça, c'est vraiment le gros changement qu'on va avoir. C'est qu'on arrive dans une phase, j'ai l'impression, où tu vas avoir des... des développeurs qui vont avoir l'impression d'être super puissants, surtout des personnes qui ont peut-être moins de skills, qui sont peut-être un peu plus juniors, et qui, par contre, vont moins maîtriser ce qu'ils font. Et donc, rappeler, je pense que cet aspect formation, coaching, ça va être des choses essentielles sur la sécu, évidemment, c'est la base, sur plein d'autres aspects pour bien comprendre ce qu'on fait. Je pense que ça, c'est le risque de dérive qu'on a avec ces outils-là, notamment sur la sécurité, c'est l'impression que tu peux tout faire sans avoir besoin de comprendre ce que tu fais. C'est vrai que c'est quand même des tendances qu'on voit. J'étais à une conférence il y a un mois à Londres, à Kukon, et on voit des messages genre « write only code » , « n'essayez même plus de lire votre code » , ce genre de messages. Laissez faire l'IA complètement, oui, mais comprenez ce que vous faites quand même. Et ça, je pense que c'est essentiel.
Speaker #2
Je peux te donner une anecdote ? Moi, je suis tombé de ma chaise il n'y a pas longtemps. Il y avait... Une équipe qui me dit en fait nous là on a envie de travailler sur un POC un petit projet de dessous, on va faire ça avec le code et c'était super fine dans le contexte, il n'y a pas de soucis là-dessus ils me disent en fait ce qu'on va faire c'est qu'on va régénérer notre code, on va juste bosser sur nos specs et on va régénérer notre code pas à chaque itération mais à chaque version et finalement la qualité on s'en fout un peu parce qu'en fait on va mettre notre truc en preuve, on va faire tester par les utilisateurs et puis après on va tout régénérer depuis le début, parce que ça peut fonctionner Moi, avec ma casquette sécurité slash qualité, je suis tombé de ma chaise. Les gars, comprenez ce que vous faites quand même, s'il vous plaît. En fait, tu pourrais dire, je te mets une grosse tartine de pré-pronte, qualité, sécurité, machin, tout ça. Mais bon, sur le principe même, moi, ça m'a un peu choqué. Mais il y a des gens qui pensent comme ça.
Speaker #4
Et je veux revenir sur ce que tu disais, Philippe. Je pense qu'il y a un risque aussi. qui va apparaître surtout en tant qu'utilisateur. On va voir de plus en plus apparaître des personnes qui ne sont pas du tout dans le soft, qui vont générer du code. Ce matin, j'ai lu juste le début d'une news qui parlait d'un médecin américain qui avait généré une application pour gérer ses données de ses patients, qui était pleine de vulnérabilité et du coup qui s'est fait attaquer. Ça, on va le voir de plus en plus.
Speaker #3
Nous, en tant qu'utilisateur,
Speaker #4
il faudra qu'on fasse gaffe à ce qu'on va utiliser sur Internet comme service.
Speaker #3
Ça fait un peu peur. Cette tendance, on appelle le vibe coding, qui était un peu le renouveau du low-code, no-code, quelque part, d'une certaine façon, on peut le voir comme ça. C'est vrai qu'il y a une vraie tendance là-dessus et nous, ça fait vraiment flipper nos sit-ops, notamment. Pour rejoindre tous les deux ce que vous dites, c'est que la quantité d'informations qui va arriver ou de codes qui va arriver avec le risque, on va avoir un nouveau bottleneck, c'est les équipes sit-ops, les équipes cybersec dans les équipes ops qui veulent vérifier et ça, pour l'instant, Voilà, à part les bonnes pratiques coaching, un peu ce qu'on a donné comme idée de rappeler les principes, les fondamentaux. On ne sait pas trop comment cette vague va être gérée.
Speaker #1
Merci pour ces pistes.
Speaker #0
Nous arrivons à la fin de cet échange qui était passionnant, clairement. Philippe, Loïc et Willy, avant de vous laisser partir, on a une tradition sur Mixitonair, donc partagez avec nos auditeurs et auditrices une ressource incontournable, un site. Un auteur, une autrice ou un outil qui vous inspire pour une tech plus éthique ? Loïc, ce serait quoi un peu ta reco pour notre public ?
Speaker #4
Alors je dirais que ma reco, moi que j'ai beaucoup utilisé pour comprendre comment fonctionne l'IA et tous ces LLM, c'est la chaîne YouTube de IBM qui propose d'expliquer en détail comment ça fonctionne. C'est très illustré, très accessible et je trouve que c'est une super ressource à suivre pour comprendre comment ça fonctionne.
Speaker #0
Philippe ?
Speaker #3
Pour moi, c'est un peu adjacent au domaine de la sécurité en tant que tel, mais vu que je suis manager d'équipe, je préconise vraiment les podcasts de Simon Sinek, qui est un coach dans le management leadership et globalement le fonctionnement des équipes, et qui a fait des talks récemment sur comment l'IA va changer le fonctionnement des équipes et comment le rôle des managers est clé là-dedans. Donc j'encourage toutes les personnes, ou même leaders ou tech leaders d'équipe à écouter, parce qu'il y a vraiment des bons principes. Quelqu'un qui est très ouvert et très ouvert sur l'éthique et le relationnel.
Speaker #0
Winnie ? Alors, moi, je vais parler du blog de Sébastien Dioria, que j'ai eu la chance de rencontrer au Snowcamp cette année au mois de janvier. Donc, lui, il maîtrise vraiment la cybersécurité. Il travaille au chapter de l'OASP, en France, je crois. Et il donne des bonnes pratiques sur l'utilisation de l'IA. Donc, il est vraiment, pour moi, influenceur à la croisée des chemins entre l'IA et la sécurité. Donc, vraiment sur ce sujet-là. aller voir son blog. C'est impressionnant d'avoir aussi le travail qu'il fournit parce que c'est génial. Je crois qu'il publie son scénario. C'est un scénario de un mois à l'avance. C'est assez impressionnant.
Speaker #1
Merci infiniment pour votre participation aujourd'hui. Je rappelle à nos auditeurs et auditrices que vous pouvez retrouver les conférences complètes de Philippe et Loïc et de Willy. en replay sur la chaîne YouTube de Mixit. Si cet épisode vous a plu, n'hésitez pas à vous abonner et à partager le podcast autour de vous. Et d'ici là, gardez en tête que pour une tech éthique, il faut garder l'esprit ouvert et critique. A bientôt !

Embed