L'IA en 2026, c'est puissant, et c'est dangereux si on s'y prend mal. Pas dangereux au sens Hollywood — dangereux au sens "votre fichier client chez OpenAI", "vos contrats dans un log qui traîne", "votre concurrent qui lit vos prompts".

Voici la checklist concrète que je déroule sur chaque mission IA. Elle n'est ni exhaustive ni bloquante — mais elle filtre 95% des vrais risques.

1. Où vivent les données, réellement ?

C'est la question numéro 1, et la plus floue. Dans l'ordre de sensibilité :

ProviderOù les données transitentConservation par défaut
OpenAI (API)USA30 jours pour abuse monitoring (peut être désactivé en Enterprise)
Anthropic (API)USA / UE30 jours (peut être désactivé)
Claude via AWS BedrockChoix de région (ex: eu-west-3 Paris)Zéro conservation
Mistral (API)UE (France)Variable, contractuel
Modèle open source auto-hébergéVos serveursVous décidez

Règle que j'applique : pour les données sensibles (RH, santé, finance, avocat), je n'utilise pas les APIs publiques sans garanties contractuelles. Je passe par Bedrock en région UE, ou par du modèle auto-hébergé.

2. Le problème des "prompts qui fuient"

Quand vous envoyez un prompt à un LLM, vous envoyez tout le contexte : le mail du client, le contrat, les chiffres que vous voulez analyser. C'est évident, et pourtant je vois régulièrement des PME qui envoient sans s'en rendre compte :

  • Des données nominatives à un modèle hors UE sans base légale.
  • Des logs de conversation client sans anonymisation.
  • Des contrats signés, avec noms et montants, dans des outils no-code grand public.

Les trois choses que je vérifie systématiquement :

  1. Qu'est-ce qui part dans le prompt, exactement ?
  2. Est-ce que le provider loggue les prompts (et où) ?
  3. Est-ce qu'on peut anonymiser avant d'envoyer (masquer noms, IBAN, numéros) ?

Sur 70% des projets, je fais passer le prompt par une étape de masquage local avant l'envoi au LLM. Pas compliqué, pas cher, ça change tout.

3. La conformité RGPD appliquée à l'IA

En 2026, le cadre est beaucoup plus clair qu'en 2023. Les points durs, dans l'ordre :

  • Base légale : pourquoi avez-vous le droit de traiter ces données ? Intérêt légitime pour la productivité, ou consentement explicite.
  • Transfert hors UE : si vous utilisez OpenAI ou Anthropic en direct, vous exportez des données vers les USA. Clauses contractuelles types obligatoires, et information claire aux personnes concernées.
  • Décision automatisée (article 22) : si l'IA prend une décision qui affecte une personne (embauche, crédit, licenciement, scoring client), la personne doit pouvoir demander une revue humaine. Toujours.
  • Droit d'accès et d'effacement : si un client demande ses données, vous devez pouvoir les extraire. Y compris celles ingérées par votre IA.

Concrètement, je refuse systématiquement les projets d'IA qui :

  • Scorent les salariés sans supervision humaine.
  • Décident d'une acceptation de dossier sans possibilité d'appel.
  • Traitent des données de santé ou RH sans environnement dédié.

4. Les permissions : donner le minimum, jamais plus

Un agent IA qui a accès à toute votre base de données est un risque de sécurité. Un agent qui a accès uniquement aux 3 tables dont il a besoin, en lecture seule, avec logs d'accès, c'est un outil maîtrisé.

Ce que je configure sur chaque déploiement :

  • Comptes techniques dédiés (jamais les identifiants d'un humain).
  • Scopes restreints : lecture seule par défaut, écriture uniquement sur les tables justifiées.
  • Rotation des tokens tous les 90 jours, automatique.
  • Logs immuables : qui a demandé quoi, quand, et avec quel résultat.

Vous devez pouvoir répondre à la question "qui a accédé à ce dossier client la semaine dernière ?" en 30 secondes — y compris si la réponse est "un agent IA automatique".

5. Ce que je fais côté code

Quelques règles de base, non négociables :

  • Aucun secret en dur — clés API dans un vault (HashiCorp, AWS Secrets Manager, ou à défaut variables d'environnement non versionnées).
  • Pas de prompt injection non protégé — quand un utilisateur peut influencer un prompt, on filtre, on encapsule, on ne fait jamais confiance.
  • Observabilité des coûts — un agent IA mal cadré peut coûter 500 €/jour au lieu de 5 € si un attaquant le boucle. Je fixe toujours un plafond mensuel.
  • Plan de rollback — toute automatisation écrit-action doit être désactivable en 10 secondes, idéalement via un flag Feature unique.

6. L'audit de sécurité simple que je livre à chaque mission

Pas de rapport de 50 pages. Un document d'une page qui dit :

  • Ce que l'IA traite, et ce qu'elle ne traite pas.
  • Où vivent les données (provider + région + rétention).
  • Quelles permissions ont été données, à quoi, et pour combien de temps.
  • Qui est alerté en cas d'anomalie.
  • Quelle est la procédure en cas de suspicion de fuite.

Une page. Lisible par votre DPO ou votre avocat en 5 minutes. C'est plus utile que 50 pages que personne ne lit.

Ce qu'il faut vérifier avant de signer avec un prestataire IA

Quatre questions que je vous invite à poser systématiquement — y compris à moi :

  1. Quel provider LLM, dans quelle région ?
  2. Les prompts sont-ils loggués ? Où ? Combien de temps ?
  3. Peut-on désactiver l'outil en 10 secondes si besoin ?
  4. À qui appartiennent les données et le code à la fin de la mission ?

Si le prestataire hésite sur une seule des quatre, changez de prestataire.

Par où commencer

Si vous déployez déjà de l'IA et que cette checklist vous met mal à l'aise, on peut faire un audit rapide — une heure suffit pour identifier les 2-3 points durs et vous dire ce qui vaut le coup d'être corrigé. Sans engagement, et sans vendre de prestation qui n'a pas lieu d'être.

Pour aller plus loin