Pourquoi l’IA augmente aussi la surface d’attaque
De la prompt injection au contrôle des outils et des données, cet article examine les principes d’architecture nécessaires pour concevoir des systèmes d’IA plus sûrs.
6 avril 2026 · 3 minCybersécuritéDéveloppement logicielDevOps
Cet article présente l’approche DevSecOps et montre comment intégrer les contrôles de sécurité dans les pipelines CI/CD, tout en identifiant les limites de l’automatisation.

Dans une approche traditionnelle, la sécurité intervient souvent à la fin du cycle de développement.
Le logiciel est développé, testé, puis soumis à une analyse de sécurité avant sa mise en production.
Le problème est économique autant que technique : plus une vulnérabilité est découverte tard, plus sa correction peut être coûteuse.
Le DevSecOps cherche à déplacer progressivement la sécurité vers l'ensemble du cycle de développement.
Security as Code
Une politique de sécurité peut aujourd'hui être intégrée directement dans le pipeline :
Commit
↓
Tests
↓
SAST
↓
SCA / dépendances
↓ Build
↓
Scan du conteneur
↓
DAST
↓
Déploiement
↓
Monitoring
Cette automatisation permet de transformer certaines règles de sécurité en contrôles répétables.
Mais l'automatisation ne résout pas tout.
Une application peut passer tous les scanners disponibles et présenter malgré tout une faille logique.
La compétence humaine reste donc indispensable pour analyser les scénarios d'attaque et comprendre le contexte métier.
L'ENISA continue d'ailleurs de considérer l'exploitation des vulnérabilités et les dépendances numériques comme des éléments majeurs du paysage de menaces européen.