Agents IA et sécurité : durcir un SaaS, ses secrets et sa CI
Agent IA sécurité : comment une flotte d'agents durcit un SaaS dans sa CI. Secrets, dépendances, IAM, review de PR, avec un humain pour valider.
Quand on parle d'agent IA et de sécurité, on pense d'abord à protéger l'agent : ses clés, ses droits, ce qu'il a le droit d'exécuter. On l'a traité dans Black October : failles PHP, secrets volés, ce que ça change pour vos agents IA. Ici, on prend le sujet dans l'autre sens : des agents IA qui durcissent votre propre produit SaaS. Ils repèrent les secrets qui traînent, trient les dépendances vulnérables, relisent les configs et les droits, commentent les pull requests sensibles. Ils tournent dans votre CI et un humain garde la main sur les décisions qui comptent.
Pourquoi les scanners seuls ne suffisent plus
Le rapport State of Secrets Sprawl 2026 de GitGuardian a compté 28,65 millions de nouveaux secrets en clair dans les commits publics GitHub en 2025, soit 34 % de plus qu'en 2024. Les commits co-écrits avec un assistant de code IA en contenaient environ deux fois plus que la moyenne. Selon le même rapport, 64 % des secrets valides détectés en 2022 étaient encore exploitables en janvier 2026. Ils avaient été détectés, mais personne n'avait fait la rotation.
Côté failles, le Verizon DBIR 2026 place l'exploitation de vulnérabilités en tête des vecteurs d'accès initial, à 31 % des violations étudiées (20 % l'année précédente). Seules 26 % des vulnérabilités critiques du catalogue KEV de la CISA ont été entièrement corrigées en 2025, avec un délai médian de 43 jours.
Les outils de détection existent depuis longtemps. Le retard se joue après l'alerte : trier des centaines de résultats, comprendre lesquels touchent votre code, préparer le correctif, relancer le bon propriétaire. Ce travail de lecture et de contexte, un agent IA le fait bien.
Ce que l'agent ajoute à vos outils de sécurité
L'agent se branche sur vos scanners existants et reprend leurs résultats.
| Étape | Scanner classique | Agent IA branché sur le scanner |
|---|---|---|
| Détecter | Liste les secrets, CVE, écarts de config | Lit la même liste |
| Trier | Score générique (CVSS, type de secret) | Vérifie si le code vulnérable est appelé, qui possède le service, si la clé est encore utilisée |
| Corriger | Parfois une PR de montée de version | Prépare la PR, lit le changelog, adapte le code cassé, lance les tests |
| Suivre | Ticket ouvert, souvent oublié | Relance, regroupe, résume l'état chaque semaine |
La règle qu'on applique : l'agent propose et prépare, un humain valide ce qui est irréversible. Rotation d'un secret de production, changement de droits, merge d'un diff sensible : ça reste une décision humaine. On détaille ces niveaux (lire, proposer, préparer, exécuter) dans Le vrai risque des agents IA, c'est l'autorité.
Les quatre agents d'une flotte de durcissement SaaS
1. L'agent secrets
Il part des alertes de vos outils de détection (par exemple le secret scanning de GitHub avec la protection au push) et va plus loin que le dépôt. GitGuardian note que 28 % des incidents de secrets se produisent uniquement hors du code, dans Slack, Jira ou Confluence. L'agent :
- relit l'historique Git et les canaux où les clés fuient en pratique ;
- identifie le service et le propriétaire de chaque clé ;
- prépare la rotation (nouvelle clé dans le coffre, PR qui retire la valeur en dur) ;
- laisse l'humain lancer la rotation en production.
Sa propre clé d'accès au coffre ne passe jamais dans son contexte : elle est injectée côté serveur au moment de l'appel.
2. L'agent dépendances
Dependabot ou Renovate savent déjà ouvrir une PR de montée de version. Le problème, c'est la pile de PR que personne ne lit. L'agent dépendances :
- vérifie si la fonction vulnérable est réellement appelée dans votre code ;
- lit le changelog et signale les ruptures de compatibilité ;
- corrige le code cassé par la montée de version et fait passer les tests ;
- regroupe les mises à jour mineures pour éviter vingt PR par semaine.
Vous recevez moins de PR, mieux expliquées, et les failles atteignables passent en premier.
3. L'agent IAM et configuration
Il lit votre infra as code (Terraform, Pulumi), les policies cloud et les scopes OAuth de vos SaaS. Il cherche la dérive : un rôle élargi « pour un test », un bucket public, un compte de service dormant avec des droits d'admin. Il ouvre une PR qui ramène au moindre privilège, ou un ticket si le changement touche la production. En production, il reste en lecture seule.
4. L'agent de review PR sécurité
Les développeurs le voient tous les jours. Sur chaque pull request qui touche l'authentification, la crypto, la validation des entrées ou les permissions, il commente le diff avant le merge. Il ne bloque que sur des règles claires et écrites (un secret en dur, un contrôle d'accès supprimé). Le reste, ce sont des remarques que le relecteur humain tranche.
C'est d'autant plus utile que les assistants de code écrivent une part croissante des PR. Si vous déployez déjà un outil comme Claude Code, on explique comment le cadrer dans Déployer Claude Code en entreprise.
Le pipeline type, du commit au rapport hebdo
Dans une CI classique, on les enchaîne ainsi :
- Avant le push : hook local et protection au push contre les secrets.
- À chaque PR : scanners (secrets, dépendances, SAST), puis l'agent de review sécurité qui commente avec le contexte.
- Chaque nuit : l'agent dépendances traite les nouvelles CVE, l'agent IAM compare l'infra déclarée à ce qui tourne.
- Chaque semaine : un résumé lisible pour le CTO ou le RSSI, avec ce qui a été corrigé, ce qui attend une décision et ce qui traîne.
Chaque agent a un compte technique séparé, des droits minimaux et des logs. Si vous branchez ces agents sur vos outils via MCP, le périmètre se définit avant : outils autorisés, secrets côté serveur, exécution isolée. Voir Serveur MCP en entreprise.
Pourquoi des skills versionnés plutôt que des prompts
Un agent de sécurité vaut ce que valent ses règles. Chez vous, « un secret en dur » ou « une route sans contrôle d'accès » a une définition précise : vos frameworks, vos conventions, vos exceptions. On écrit ces règles une fois, sous forme de skills versionnés dans un dépôt, revus en PR comme du code. Toutes les équipes partent de la même base, et une règle améliorée profite à tous les dépôts le jour même.
C'est la logique qu'on applique avec Theodo : des Software Factories pour des centaines de développeurs, avec des outils, des agents et des skills standardisés, et la formation qui permet à chaque équipe de les adopter. La sécurité est un des domaines où cette standardisation paie le plus vite, parce qu'une règle oubliée dans un seul dépôt suffit à ouvrir une porte.
Par où commencer
Inutile de déployer les quatre agents d'un coup. On recommande cet ordre :
- Inventaire : dépôts, CI, cloud, SaaS critiques, et les secrets connus.
- Agent secrets en lecture seule : il trie et prépare, vous mesurez le volume réel.
- Agent dépendances sur un ou deux dépôts critiques, avec merge humain.
- Review PR sécurité une fois les règles maison écrites en skills.
- IAM et config en dernier, parce que c'est là que les droits de l'agent doivent être les plus fins.
Si votre produit traite des données de santé, l'agent tourne dans l'environnement conforme du client, pas à côté. On explique ce cadre dans IA et données de santé : ce que l'HDS impose vraiment.
Pour l'offre complète (cartographie, déploiement, intégration à votre CI), voir Agents IA pour durcir produit et SI.
FAQ
Un agent IA de sécurité remplace-t-il un scanner ou un SAST ?
Non. Le scanner détecte, l'agent trie, explique et prépare le correctif. Sans scanner fiable en dessous, l'agent n'a rien de solide à lire.
L'agent peut-il merger ou faire la rotation seul ?
On ne le recommande pas. L'agent prépare la PR ou la rotation, un humain valide. L'exécution automatique se limite à des cas réversibles et bien bornés, comme regrouper des mises à jour mineures dans une PR.
Quelle différence avec la sécurité des agents IA ?
Sécuriser un agent, c'est limiter ce qu'il peut faire et protéger ses secrets. Ici, l'agent est l'outil qui durcit votre produit. Les deux vont ensemble : un agent de sécurité mal borné devient lui-même un risque.
Notre code part-il chez un fournisseur de modèle ?
Ça dépend du modèle et du contrat choisis. Avant de brancher un agent sur vos dépôts, vérifiez la rétention, le non-entraînement et l'hébergement au niveau du contrat applicable, comme pour tout sous-traitant.
Durcir votre SaaS avec des agents
The Vibe Company est une agence IA à Paris. On déploie des agents et des skills dans votre CI pour durcir votre produit, avec des droits minimaux et un humain pour valider.
