IA et sécurité.

Les risques propres à l’IA

Le Top 10 de l’OWASP pour les applications d’IA.

L’OWASP, la référence mondiale de la sécurité applicative, classe les dix risques majeurs des applications qui utilisent un grand modèle de langage1OWASPOWASP Top 10 for LLM Applications 2025 (annonce officielle)novembre 2024Édition 2025, publiée en novembre 2024.Ouvrir la sourceVoir dans la liste. La dernière colonne indique les projets de ce site concernés.

1. LLM01
   Injection de prompt

   Un texte piégé (dans une page, un document, un e-mail) détourne les instructions du modèle.

   Lois, domotique
2. LLM02
   Divulgation d’informations sensibles

   Le modèle restitue des données qu’il n’aurait pas dû voir ou garder.

   Domotique
3. LLM03
   Chaîne d’approvisionnement

   Un modèle, une bibliothèque ou un jeu de données tiers compromis.

   –
4. LLM04
   Empoisonnement des données et du modèle

   Des données d’entraînement ou de référence modifiées pour fausser les réponses.

   Lois
5. LLM05
   Traitement non sûr des sorties

   Une réponse du modèle exécutée ou affichée sans contrôle (code, requête, HTML).

   –
6. LLM06
   Autonomie excessive

   Un agent qui dispose de plus d’outils et de droits que nécessaire.

   Domotique
7. LLM07
   Fuite du prompt système

   Les instructions internes, parfois avec des secrets, sont révélées.

   –
8. LLM08
   Faiblesses des vecteurs et embeddings

   Une base vectorielle mal cloisonnée ou manipulée, au cœur des systèmes RAG.

   Lois
9. LLM09
   Désinformation

   Des réponses fausses mais assurées, reprises sans vérification.

   Lois, finance
10. LLM10
    Consommation non bornée

    Des requêtes qui épuisent le budget ou les ressources.

    –

Des IA déjà à l’épreuve

Ce qu’elles ont déjà trouvé.

Premier chantier

Ce site, testé en premier.

Trois analyses non intrusives, le même jour : ce que le site et la partie en accès privé répondent à n’importe quel visiteur, avant les corrections, après les en-têtes de sécurité, puis après la politique de contenu de l’accès privé. Points conformes : 4 sur 118Relevé de l’auteurEn-têtes HTTP et configuration TLS de bertrand-didier.tech et de la partie des projets sensibles, lus avec curl et openssl2 novembre 2026Ouvrir la sourceVoir dans la liste, puis 10 9Relevé de l’auteurAnalyse 2, après remédiation : mêmes contrôles curl et openssl2 novembre 2026Ouvrir la sourceVoir dans la liste, puis 11 10Relevé de l’auteurAnalyse 3, après la politique CSP de l’accès privé : mêmes contrôles curl et openssl2 novembre 2026Ouvrir la sourceVoir dans la liste.

Analyse 1, recommandation, analyses 2 et 3

Ce qui a été mis en place

• Dans Traefik, un jeu d’en-têtes de sécurité commun au site, à l’API des cours et à l’accès privé, qui retire aussi les en-têtes révélant les versions.
• Une Content-Security-Policy stricte pour le site : seuls ses propres scripts s’exécutent, et les polices Google sont les seules ressources extérieures autorisées.
• Le site ne place plus aucun script directement dans ses pages, condition pour cette politique stricte.
• Pour l’accès privé, le module WordPress envoie une politique encore plus stricte (aucun script) sur la page des visiteurs non connectés ; l’administration, qui a besoin de ses propres scripts, n’est pas concernée.
• Pour l’accès privé, une double authentification : après le mot de passe, un code à 6 chiffres donné par une application comme Google Authenticator, avec des codes de secours. Elle repose sur l’extension officielle Two Factor de WordPress, gratuite.
• Après chaque déploiement, GitHub Actions vérifie ces en-têtes en ligne et fait échouer la publication s’il en manque un.

Le plan de test de remédiation

La suite du plan de test

1. 01

   En-têtes de sécurité

   Mozilla HTTP Observatory Fait : HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy et Permissions-Policy dans Traefik ; note passée de D à A+.

2. 02

   Masquer les versions

   curl Fait : les numéros de version de nginx, Apache et PHP ne sortent plus.

3. 03

   Configuration TLS complète

   SSL Labs Fait : A+ sur les deux adresses, TLS 1.2 et 1.3 seulement, sans avertissement.

4. 04

   Surface exposée du serveur

   nmap Lister les ports ouverts du VPS et fermer tout ce qui n’a pas à être public.

5. 05

   Accès privé (WordPress)

   WPScan Fait en partie : double authentification active et testée sur la connexion. Reste à scanner versions, extensions et comptes.

6. 06

   Scan applicatif

   OWASP ZAP Parcourir le site et l’API comme un attaquant, en mode passif puis actif.

7. 07

   Dépendances

   npm audit, Dependabot Signaler et mettre à jour les bibliothèques vulnérables.

8. 08

   Secrets et historique Git

   gitleaks Vérifier qu’aucune clé n’a jamais été publiée dans le dépôt.

9. 09

   Conteneurs

   Trivy Chercher les failles connues dans les images Docker.

10. 10

    Revue de code assistée

    Claude Code /security-review Faire relire chaque changement par l’IA, puis par moi.

Le cadre légal. Tester un système sans autorisation est un délit : accès frauduleux à un système informatique, article 323-1 du Code pénal en France, article 509-1 au Luxembourg. Ces tests ne portent que sur mes propres serveurs.