Sécuriser son SaaS avec des agents IA (leçons d'un pentest sauvage)

Un développeur a décidé de « pentester » le SaaS d'un confrère. Sans prévenir. Carte Stripe de test, une faille dans le flux de paiement, et un abonnement payant obtenu gratuitement. Il s'est fait repérer par les logs : son email en clair, visible côté victime.

La victime, c'est Benjamin (BenjaminCode), un ami. L'auteur, je ne le nommerai pas : c'est exactement l'attention qu'il cherche. Mais l'affaire n'est qu'un prétexte. Le vrai sujet, c'est celui-ci : l'IA rend le pentest trivial. N'importe qui peut aujourd'hui lancer un agent qui sonde ton SaaS en production. La seule réponse tenable, c'est une défense agentique qui tourne en continu.

Pourquoi c'est un problème maintenant

Avant, sonder une application demandait du temps et des compétences. Aujourd'hui, un agent IA génère des emails jetables, teste des endpoints, tente des paiements avec des cartes de test et documente tout, en quelques minutes. Le coût d'une attaque opportuniste est tombé à presque zéro.

Résultat : si tu as un SaaS en prod avec de vrais utilisateurs, tu seras sondé. Ce n'est pas une question de « si », mais de « quand ». La bonne nouvelle : les mêmes agents qui rendent l'attaque facile rendent la défense automatisable.

Les 3 agents qui gardent mon SaaS

Je m'appuie sur un triptyque : prévenir, corriger, surveiller. Trois agents, trois rôles.

1. Prévenir — l'agent d'audit

Un agent qui scanne le code en continu et cherche les failles avant qu'elles ne partent en prod : secrets exposés, dépendances vulnérables, routes non protégées, validation manquante. Je le fais tourner chaque semaine (repo-security-audit) et il me sort un rapport priorisé.

2. Corriger — l'agent de dépendances

Un agent qui surveille les CVE des dépendances, priorise par criticité et ouvre les pull requests de mise à jour tout seul. Pas un Dependabot brut : un agent qui trie, explique le risque, et propose le correctif.

3. Surveiller — l'agent d'analyse des logs

C'est celui qui a permis de repérer l'attaquant. Un agent qui lit les logs de production en continu et détecte les patterns anormaux :

• une carte de test qui apparaît dans un vrai paiement,
• des hits répétés sur des endpoints admin,
• des tentatives d'exploitation du flux de paiement.

Alerte en temps réel. C'est exactement ce type d'agent qui a « cramé » l'attaquant dans l'affaire : les logs ont tout enregistré.

Les leçons de la faille (hardening applicatif)

Au-delà des agents, l'incident rappelle quelques règles de base que trop de SaaS négligent :

• Séparer strictement test et prod. Une carte de test ne doit JAMAIS pouvoir valider un paiement en production.
• Valider le prix côté serveur. Ne jamais faire confiance au front pour un « gratuit » ou une réduction.
• Signer et vérifier les webhooks Stripe (signature secret obligatoire).
• Limiter le débit (rate limiting) sur les endpoints sensibles.
• Masquer les données sensibles dans les logs. L'ironie de l'affaire : l'attaquant n'a pas masqué son email. Toi non plus, ne logue rien en clair.

Et côté légal ?

Entrer dans le système d'un tiers sans autorisation n'est pas un « move malin », c'est un délit. En France, l'accès et le maintien frauduleux dans un système de traitement automatisé de données sont punis par les articles 323-1 et suivants du Code pénal. Une vidéo « discrète » qui laisse deviner la cible, sans prévenir la victime, ne protège pas la victime : elle protège l'auteur.

Ce qu'il faut retenir

L'IA a rendu l'attaque gratuite. La défense doit devenir automatique. Trois agents (prévenir, corriger, surveiller) plus quelques règles de hardening, et tu passes d'une posture réactive à une posture continue.

Je montre le setup complet en vidéo, avec la démo de l'agent d'analyse de logs : regarder sur YouTube.

Pour aller plus loin sur le dev agentique et la sécurité, rejoins ma newsletter The Agentic Dev.