Publié le 2 novembre 2025 par Laurent PAITA.
Temps de lecture : 2 minutes.

Aardvark d’OpenAI : intérêt réel pour les équipes ou angle mort cyber à surveiller ?

OpenAI a dévoilé le 30 octobre "Aardvark", un agent “chercheur en vulnérabilités” qui lit le code, tente de reproduire les failles en sandbox, puis propose des correctifs.

L’outil, en version beta, s’intègre aux workflows de développement pour suivre les dépôts en continu. Sur le papier : moins de bruit, des alertes mieux priorisées, et des patches prêts à relire. C’est ambitieux et c’est précisément pour cela que le Club Experts Cybersécurité de Digital League doit l’examiner avec un œil critique.

Pourquoi c’est intéressant ?

Ce type d’agent excelle là où l’humain fatigue : surveillance permanente, lecture patiente de gros dépôts, tri des signaux faibles et capacité à valider une alerte en essayant réellement d’exploiter la faille avant de déranger l’équipe. Si la promesse se confirme, l’effet serait très concret sur nos indicateurs : moins de faux positifs, un temps de remédiation raccourci, des correctifs proposés plus tôt dans le cycle de développement. Dit autrement : l’agent n’est pas “plus intelligent” que l’expert, mais il est plus endurant et plus disponible, et peut devenir un accélérateur pour les développeurs comme pour les RSSI.

Là où ça se complique

Un agent branché sur vos dépôts ne lit pas seulement du “beau code”. Il absorbe aussi des README écrits à la va-vite, des tickets, des commentaires… autant de portes ouvertes à la manipulation. Le risque n’est pas théorique : les communautés cyber ont documenté les attaques par injection (des contenus qui incitent l’IA à contourner ses propres règles) et l’empoisonnement (des éléments semés pour fausser son jugement). Sans garde-fous, l’agent peut se faire berner, produire un diagnostic trompeur, ou proposer un patch qui règle un symptôme mais crée une dette technique ailleurs.

À cela s’ajoute la chaîne d’approvisionnement logicielle. L’affaire XZ Utils a montré qu’un composant bien installé pouvait être contaminé à la source et que la compromission pouvait passer sous les radars pendant des mois. Un agent qui bâtit et teste du code avec des dépendances vérolées peut devenir un relais bien involontaire de la compromission.

L’importance du “Secure by design”

Si l’on veut tester sérieusement Aardvark (ou un équivalent), il faut sans aucun doute inverser la logique habituelle : d’abord la conception sécurisée, ensuite l’outil. Concrètement, cela veut dire définir qui décide quoi (l’agent propose, l’humain dispose), tracer chaque action de l’agent (ce qu’il a lu, ce qu’il a exécuté, pourquoi il propose un patch), limiter ses droits d’écriture et cloisonner strictement son environnement d’exécution. Ce sont des principes connus du “secure by design”.

Intérêt vs limites

L’intérêt est réel : un compagnon infatigable qui lit, teste et propose des corrections peut réduire la charge mentale des équipes et améliorer la vitesse de traitement des vulnérabilités. La limite est tout aussi réelle : sans cadre, on externalise notre vigilance et on ajoute une nouvelle surface d’attaque au cœur même de la fabrique logicielle. L’agent peut être meilleur que l’humain sur la couverture et la cadence, mais il ne remplace pas l’humain pour le jugement comme l’arbitrage. En pratique, il faut le traiter comme un collègue junior, voir un alternant très rapide : utile, précieux mais qui doit être toujours relu.

Et pour le Club Experts Cybersécurité en 2026 ?

Ce sujet mérite une session dédiée et croisée avec notre club Tech4Tech. Un retour d’expérience où l'on comparerait “humain vs agent” sur un même dépôt et un focus “secure by design” pour montrer comment cadrer un POC sans mettre en risque la prod. Le but n’est pas de trancher pour ou contre, mais de donner aux membres une grille de lecture : où l’agent apporte un vrai gain, où il peut dégrader la cybersécurité et quelles pratiques de conception adopter de manière optimale.

Sources :

✅Lire l’article complet de OpenAI : https://openai.com/index/introducing-aardvark/

✅OWASP - Top 10 des risques des LLM : https://genai.owasp.org/llm-top-10-2023-24/

✅ Akamai - Histoire de UZ Utils : https://www.akamai.com/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know