Pilier 3 : sécurité et hébergement pour builder IA (OWASP, pen test, scaling)

L’IA ne pense pas comme un attaquant

La semaine dernière, j’ai demandé à Claude de faire un audit de sécurité sur une API que j’avais générée avec lui. Il a trouvé une injection SQL dans un paramètre de recherche. Bien joué.

Ce qu’il n’a pas trouvé : une combinaison de trois failles mineures qui, enchaînées, permettaient d’accéder au panneau admin.

Un endpoint qui retournait l’ID utilisateur dans la réponse. Un autre qui acceptait cet ID sans vérification d’autorisation. Et un troisième qui exposait les sessions actives en debug mode. Trois failles “bénignes” individuellement. Un accès admin complet quand on les combine.

C’est la différence fondamentale entre l’IA et un attaquant.

L’IA fait du pattern matching. Elle cherche des signatures connues : eval(user_input), des requêtes SQL concaténées, des tokens en dur dans le code. Elle regarde ligne par ligne. Fichier par fichier.

Un attaquant pense en chaîne. Il se demande : “Si je peux obtenir ça, est-ce que ça me donne accès à ça ?” Il cartographie le système entier, cherche les points de contact entre les composants, teste les hypothèses.

L’IA est un excellent premier filtre. Mais elle ne remplace pas la pensée adversariale. Elle ne remplace pas les 30 minutes où vous vous asseyez devant votre app et vous demandez : “Comment est-ce que je la casserais ?”

Ce que Clean Coder dit sur le professionnalisme

“C’est pas moi, c’est l’IA qui a écrit ce code.”

Cette phrase n’existe pas pour vos utilisateurs.

Dans The Clean Coder, Robert C. Martin définit le professionnalisme par un mot : responsabilité. Un professionnel est responsable de ce qu’il shippe. Point.

Pas de ce qu’il a écrit. De ce qu’il a shippé.

Si votre application fuit les données de vos utilisateurs, personne ne va vérifier si c’est Claude ou vous qui avez écrit le handler d’authentification. Vos utilisateurs s’en fichent. Le RGPD s’en fiche. Votre réputation s’en fiche.

Martin insiste : si vous ne comprenez pas le code, vous ne le shippez pas. C’est une règle qui existait bien avant l’IA. Mais elle est devenue critique avec le vibe coding, parce que la tentation de shipper du code que vous n’avez pas compris est maintenant permanente.

L’IA vous donne la vélocité d’un senior. La sécurité, c’est votre responsabilité de professionnel.

OWASP Top 10 : le minimum

L’OWASP (Open Web Application Security Project) maintient depuis 20 ans la liste des failles les plus courantes dans les applications web. Si vous ne connaissez pas cette liste, c’est le moment.

Les 5 failles que l’IA génère le plus

1. Injection (SQL, NoSQL, commandes)

L’IA adore concaténer des chaînes dans les requêtes. C’est la réponse la plus “naturelle” à la question.

// Ce que l'IA génère souvent
const user = await db.query(
  `SELECT * FROM users WHERE email = '${req.body.email}'`
)

// Ce que vous devez shipper
const user = await db.query(
  'SELECT * FROM users WHERE email = $1',
  [req.body.email]
)

Même pattern avec MongoDB :

// Vulnérable
const user = await User.find({ email: req.body.email })
// Si req.body.email = { "$ne": "" } → retourne tous les users

2. Broken Authentication

L’IA génère des systèmes d’auth qui marchent pour le happy path. Les sessions qui n’expirent jamais. Les tokens JWT sans vérification de la signature. L’absence totale de rate limiting sur les endpoints de login.

// L'IA oublie presque toujours ça
app.post('/login',
  rateLimit({ windowMs: 15 * 60 * 1000, max: 5 }),
  async (req, res) => { /* ... */ }
)

3. Security Misconfiguration

Debug mode en production. Credentials par défaut. Le .env commité dans le repo. Les headers CORS à *. L’IA génère du code pour le développement. Elle ne pense pas à la production.

// L'IA génère ça pour "que ça marche"
app.use(cors({ origin: '*' }))

// Ce que vous devez shipper
app.use(cors({
  origin: ['https://votre-domaine.com'],
  credentials: true
}))

4. SSRF (Server-Side Request Forgery)

L’IA adore faire des appels HTTP. fetch, axios, got… elle génère des requêtes vers des URL fournies par l’utilisateur sans aucune validation.

// L'IA génère ça volontiers
const response = await fetch(req.body.webhookUrl)

// Un attaquant envoie : http://169.254.169.254/latest/meta-data/
// → accès aux credentials AWS de votre serveur

5. Insecure Deserialization

L’IA utilise JSON.parse() sans validation, accepte des objets sérialisés sans vérifier leur structure, fait confiance au payload.

// Vulnérable
const config = JSON.parse(req.body.config)
db.query(config.query) // L'attaquant contrôle la requête

// Sécurisé : validez avec Zod ou Joi
const configSchema = z.object({
  theme: z.enum(['light', 'dark']),
  lang: z.enum(['fr', 'en'])
})
const config = configSchema.parse(JSON.parse(req.body.config))

Comment scanner

Les outils ne remplacent pas la réflexion. Mais ils attrapent les erreurs évidentes.

Semgrep (gratuit, open source). Pattern-based. Vous le lancez sur votre codebase, il trouve les injections SQL, les eval(), les secrets hardcodés. C’est le minimum vital.

semgrep --config=p/owasp-top-ten ./src

Snyk scanne vos dépendances. Cette bibliothèque npm que l’IA a ajoutée à votre package.json ? Elle a peut-être une CVE connue. Snyk le sait.

npx snyk test

Claude Code en mode review. Demandez-lui de chercher les failles de sécurité. Il trouvera les patterns connus. C’est utile comme premier passage.

claude "Fais un audit de sécurité de src/api/ en te concentrant sur les injections, l'authentification et la validation des inputs"

La limitation : ces outils trouvent des patterns, pas des failles logiques. Semgrep attrape eval(user_input). Il n’attrape pas le fait que votre endpoint /api/users/:id ne vérifie pas que l’utilisateur connecté a le droit de voir le profil demandé. Ça, c’est de la logique métier. Et ça demande un cerveau humain.

Pen testing

Le pen testing, c’est l’art de casser votre propre application avant que quelqu’un d’autre le fasse. Vous n’avez pas besoin d’être un expert en sécurité. Vous avez besoin de 30 minutes et des bons outils.

Le minimum solo

OWASP ZAP (Zed Attack Proxy). Gratuit, open source, maintenu par l’OWASP. Vous pointez ZAP vers votre application et il lance des scans automatisés : XSS, injections, configurations faibles.

Burp Community Edition. L’outil standard de l’industrie en version gratuite. Plus manuel, mais plus puissant pour comprendre ce qui se passe entre votre frontend et votre backend.

La checklist manuelle (30 minutes) :

• Auth bypass : essayez d’accéder à des routes protégées sans token. Modifiez un token JWT (changez l’ID utilisateur). Testez avec un token expiré.
• IDOR (Insecure Direct Object Reference) : changez les ID dans les URL. /api/orders/123 → /api/orders/124. Pouvez-vous voir les commandes d’un autre utilisateur ?
• XSS : injectez <script>alert(1)</script> dans chaque champ de formulaire. Testez les XSS stockés (qui persistent en base) et réfléchis (qui reviennent dans la réponse).
• CSRF : vos formulaires ont-ils un token anti-CSRF ? Pouvez-vous soumettre un formulaire depuis un autre site ?

Vous n’avez pas besoin de trouver des zero-day. Vous avez besoin de trouver les portes que vous avez oublié de fermer.

Quand payer un vrai pen test

Si votre application gère des paiements, des données de santé, ou des données personnelles sensibles, le pen testing DIY ne suffit plus.

Budget réaliste : 2 000 à 5 000 € pour un audit web complet.

Plateformes :

• YesWeHack (européen, conforme RGPD)
• HackerOne (global, programmes de bug bounty)
• Un pentester freelance avec des références vérifiables

Ce n’est pas un luxe. Si votre app gère de l’argent ou des données personnelles, c’est une obligation professionnelle. Une fuite de données coûte infiniment plus cher qu’un pen test.

Hébergement

Vous avez testé votre code, scanné les failles, pensé comme un attaquant. Maintenant il faut mettre ça en production quelque part.

Les fondamentaux

Type	Coût	Contrôle	Complexité	Pour qui ?
Shared hosting	5-15€/mois	Faible	Faible	Sites vitrines, pas d’API
VPS (Hetzner, OVH)	5-30€/mois	Total	Moyen	Builders qui veulent tout contrôler
Managed (Vercel, Railway)	0-20€/mois	Moyen	Faible	La plupart des builders IA
Serverless (AWS Lambda, Cloudflare Workers)	Pay-per-use	Faible	Moyen	APIs à trafic variable

Pour la majorité des builders solo, Vercel ou Railway est le sweet spot. Deploy en un push. SSL automatique. Scaling géré.

Trois choses non négociables :

• SSL/HTTPS : Let’s Encrypt est gratuit. Il n’existe aucune excuse pour servir du HTTP en 2026. Aucune.
• DNS : comprenez votre configuration. Un A record, un CNAME, un NS record. Ça prend 15 minutes à apprendre.
• CDN : Cloudflare free tier. Vos assets statiques servis depuis le edge. Ça change les performances et ça ajoute une couche de protection DDoS.

Load testing

La question que personne ne se pose avant le premier crash : combien d’utilisateurs simultanés votre app supporte-t-elle avant de tomber ?

k6 est l’outil. Gratuit, scriptable, résultats clairs.

// load-test.js
import http from 'k6/http'
import { check } from 'k6'

export const options = {
  stages: [
    { duration: '30s', target: 50 },   // montée à 50 users
    { duration: '1m', target: 50 },     // plateau
    { duration: '10s', target: 0 },     // descente
  ],
}

export default function () {
  const res = http.get('https://votre-app.com/api/health')
  check(res, {
    'status 200': (r) => r.status === 200,
    'response < 500ms': (r) => r.timings.duration < 500,
  })
}

k6 run load-test.js

Le bug #1 que k6 va révéler dans du code généré par IA : les requêtes N+1. L’IA génère systématiquement l’approche naïve.

// Ce que l'IA génère : N+1 queries
const orders = await db.query('SELECT * FROM orders')
for (const order of orders) {
  order.items = await db.query(
    'SELECT * FROM items WHERE order_id = $1', [order.id]
  )
}

// Ce que vous devez shipper : JOIN
const orders = await db.query(`
  SELECT o.*, json_agg(i.*) as items
  FROM orders o
  LEFT JOIN items i ON i.order_id = o.id
  GROUP BY o.id
`)

Avec 10 commandes, ça passe. Avec 10 000, votre base de données s’effondre.

Scaling basics

Vous n’avez probablement pas besoin de scaler maintenant. Mais vous devez connaître vos limites et savoir quoi faire quand elles arrivent.

Scaling vertical : un plus gros serveur. Simple, cher, limité. Passer de 1 Go de RAM à 4 Go. Ça marche jusqu’à un certain point.

Scaling horizontal : plus de serveurs. Complexe, économique à grande échelle. Ça demande que votre application soit stateless (pas de session en mémoire, pas de fichiers temporaires locaux).

Connection pooling : votre base de données a un nombre limité de connexions simultanées. PgBouncer pour PostgreSQL. Sans ça, chaque requête ouvre une nouvelle connexion, et à 100 requêtes simultanées, PostgreSQL refuse les nouvelles connexions.

Caching : Redis pour les données fréquemment lues qui changent rarement. CDN pour les assets statiques et les pages rendues. Un cache bien placé divise votre charge serveur par 10.

Le piège : ne scalez pas prématurément. Comprenez d’abord pourquoi c’est lent. 90 % du temps, c’est une requête N+1 ou un index manquant, pas un problème d’infrastructure.

La checklist sécurité avant de shipper

Capture d’écran bienvenue. Imprimez-la. Cochez-la avant chaque déploiement.

• HTTPS partout (aucune exception)
• Authentification testée (sessions, tokens, expiration)
• Validation des inputs sur TOUTES les entrées utilisateur
• Rate limiting sur les endpoints d’authentification
• Secrets dans les variables d’environnement, jamais dans le code
• Dépendances scannées (npm audit / Snyk)
• CORS configuré correctement (pas de * en production)
• Backups base de données automatisés
• Messages d’erreur qui ne leakent pas les stack traces
• Routes admin protégées

Chaque ligne non cochée est une porte ouverte. L’IA ne l’a pas fermée pour vous. Parce que vous ne lui avez pas demandé. Et parce que ce n’est pas son job.

En résumé

L’IA vous donne la vitesse. Ces 3 piliers vous donnent la confiance.

Pilier	Objectif	Article
Tests	Vérifier que le code fonctionne	Pilier 1 : tester son code IA
CI/CD & monitoring	Automatiser et surveiller	Pilier 2 : CI/CD & monitoring
Sécurité & hébergement	Protéger et déployer	Cet article

Le vibe coding sans ces piliers, c’est construire sur du sable. Avec eux, c’est du béton.

Vous avez la vélocité d’un senior grâce à l’IA. Vous avez le filet de sécurité des tests grâce au Pilier 1. Vous avez l’automatisation grâce au Pilier 2. Et maintenant vous avez la rigueur sécurité du Pilier 3.

Tout ça s’inscrit dans une vision plus large. Si vous voulez voir la checklist complète pour shipper du code IA avec confiance, lisez le manifeste. Et si vous pensez encore que “le bon prompt suffit”, allez lire les anti-mythes du prompt engineering.

Shippez. Mais shippez en pro.