← Tous les carnetsAll notes

10 règles de sécurité à donner à votre IA avant d'écrire une ligne de code10 security rules to give your AI before it writes a single line of code

29 sept. 2026Sep 29, 20263 min de lecture3 min readSécurité · IASecurity · AI

Construire une application avec une IA n'a jamais été aussi simple. Mais une IA sans consignes, c'est un développeur junior brillant, rapide… et sans aucune notion de ce qui peut mal tourner. Elle ne connaît pas vos clients, vos données, ni vos obligations.

Avant chaque projet, je lui donne un fichier de règles. Voici les dix qui comptent le plus. Copiez-les, adaptez-les, donnez-les-lui dès le premier message.

Les dix règles

  1. Aucun secret dans le code. Clés d'API, mots de passe, accès à la base de données : uniquement dans des variables d'environnement, jamais dans un fichier envoyé sur GitHub.
  2. Tout ce qui vient de l'utilisateur est suspect. Formulaires, liens, fichiers envoyés : tout doit être vérifié côté serveur, pas seulement dans le navigateur.
  3. Pas d'authentification « maison ». Pour gérer des comptes, on utilise un service éprouvé. Réinventer la connexion, c'est réinventer ses failles.
  4. Chaque accès est vérifié. Pour chaque action, le serveur doit se demander : qui est cette personne, et a-t-elle le droit sur cette donnée précise ?
  5. Aucune dépendance ajoutée sans validation. Nom exact, utilité, popularité. Certaines bibliothèques « suggérées » par une IA n'existent même pas — et des pirates créent parfois des paquets à ces noms-là.
  6. Le minimum de données personnelles. Ce que vous ne collectez pas ne peut pas fuiter.
  7. Les en-têtes de sécurité, toujours. Une politique de sécurité du contenu stricte, HTTPS obligatoire, protection contre l'intégration dans une page piégée.
  8. Des erreurs muettes. L'utilisateur voit « une erreur est survenue ». Les détails techniques restent dans les journaux du serveur.
  9. Aucune action irréversible sans confirmation. Supprimer, déployer, payer : l'IA propose, l'humain valide.
  10. Jamais « c'est sécurisé ». L'IA doit dire ce qu'elle a fait, et ce qui reste à vérifier.

Pourquoi ça marche

Une IA suit remarquablement bien des règles claires. Le problème n'est presque jamais qu'elle refuse de sécuriser : c'est qu'on ne le lui a pas demandé. Dix lignes au début d'un projet évitent des semaines de correction — ou pire, une fuite de données le jour où votre projet décolle.

La sécurité coûte peu quand elle est prévue. Elle coûte très cher quand elle est découverte.

Et si vous voulez aller plus loin, relisez ce que l'IA a produit avec une seule question en tête : si je voulais attaquer ceci, par où commencerais-je ?

Building an app with AI has never been easier. But an AI without instructions is a brilliant, fast junior developer… with no idea of what can go wrong. It doesn't know your customers, your data, or your obligations.

Before every project, I give it a rulebook. Here are the ten rules that matter most. Copy them, adapt them, and give them to your AI in the very first message.

The ten rules

  1. No secrets in code. API keys, passwords, database credentials: environment variables only, never in a file pushed to GitHub.
  2. Everything from the user is suspect. Forms, links, uploaded files: all must be validated on the server, not just in the browser.
  3. No home-made authentication. To manage accounts, use a proven service. Reinventing login means reinventing its flaws.
  4. Every access is checked. For every action, the server must ask: who is this person, and do they have rights on this specific piece of data?
  5. No dependency added without approval. Exact name, purpose, popularity. Some libraries "suggested" by an AI don't even exist — and attackers sometimes publish packages under those very names.
  6. The minimum personal data. What you don't collect can't leak.
  7. Security headers, always. A strict Content Security Policy, mandatory HTTPS, protection against being embedded in a malicious page.
  8. Silent errors. Users see "something went wrong". Technical details stay in server logs.
  9. No irreversible action without confirmation. Delete, deploy, pay: the AI proposes, a human approves.
  10. Never "it's secure". The AI must state what it did and what remains to be checked.

Why it works

AI follows clear rules remarkably well. The problem is almost never that it refuses to secure things — it's that nobody asked. Ten lines at the start of a project save weeks of fixes — or worse, a data leak on the day your project takes off.

Security is cheap when it's planned. It's very expensive when it's discovered.

And to go further, review what the AI produced with one question in mind: if I wanted to attack this, where would I start?

Vous lancez un projet et voulez qu'il soit solide ?Launching a project and want it built right?

Parlons-enLet's talk