Par Chahid Naoufel

Publié le · Modifié le · Vérifié le

Les points essentiels

  • La sécurité couvre tout le flux : saisie, modèle, recherche, outils, mémoire, journaux, sauvegardes et support.[3][4][5]
  • Des droits utilisateur ou administrateur étendus augmentent l’impact potentiel d’un détournement ou d’une erreur.[4][5]
  • Traitez contrat et certification comme des informations à examiner, puis vérifiez séparément votre configuration et votre usage.
  • Le moindre privilège, la séparation des environnements et les tests d’injection doivent précéder la connexion.[3][4][5]
  • La méthode recommandée ici associe une règle interne claire, une voie approuvée et un canal de signalement pour traiter les besoins à l’origine du shadow AI.

Suivre la donnée de bout en bout

Une information peut être copiée dans le prompt, transmise à un connecteur, enregistrée dans une mémoire, apparaître dans un journal ou être consultée par le support. Examiner uniquement le fournisseur du modèle laisse de nombreuses voies invisibles.[3][4][5]

Le diagramme de flux doit indiquer les catégories de données, les systèmes, les lieux de traitement, les accès humains et techniques, la durée et les mécanismes de suppression.[2][9]

Scénarios de risque à tester dans une PME

  • Salarié qui colle une donnée confidentielle dans un outil non approuvé.
  • Agent qui hérite de droits trop larges sur le CRM ou le stockage.
  • Document hostile qui contient une instruction destinée au modèle.
  • Mémoire qui mélange deux clients ou conserve une donnée corrigée.
  • Journal technique qui reproduit le contenu sensible.
  • Prestataire ou sous-traitant dont les accès et usages sont mal définis.

Par où les données peuvent-elles sortir ?

Par où les données peuvent-elles sortir ?
CoucheExposition possibleContrôle
InterfaceSaisie ou pièce jointeRègles, prévention et alternative approuvée
Modèle/APIRequête et réponseContrat, configuration et minimisation
Recherche/mémoireIndex et historiqueIsolation, droits, durée et suppression
OutilsLecture ou modification métierIdentité dédiée et moindre privilège
JournauxPrompts, erreurs et résultatsMasquage, accès et rétention
SupportIntervention humaineHabilitation et traçabilité

Les questions que le contrat et la documentation doivent trancher

  • Quelles données sont traitées et pour quelles finalités ?
  • Sont-elles utilisées pour améliorer ou entraîner un service ?
  • Quels sous-traitants et lieux de traitement interviennent ?
  • Quelles durées, suppressions et sauvegardes s’appliquent ?
  • Qui peut accéder pour le support et comment cet accès est journalisé ?
  • Comment sont signalés les incidents et changements substantiels ?

Cinq contrôles avant toute connexion

  • Identité dédiée, authentification forte et droits minimaux.[3][4][5]
  • Liste explicite des sources et actions autorisées.[3][4][5]
  • Validation séparée des destinataires, montants et opérations sensibles.[3][4][5]
  • Environnement de test sans effet réel, avec cas d’injection et de fuite.[3][4][5]
  • Journaux minimisés, protégés et reliés à une procédure d’arrêt.[3][4][5]

Comprendre ce qu’une certification ne démontre pas

Lorsqu’un fournisseur invoque une certification, demandez le schéma concerné, l’entité auditée, la période, les services, les sites et les exclusions au lieu de déduire sa portée de son seul intitulé.

Évaluez séparément vos permissions, vos connecteurs, vos scénarios d’attaque et vos obligations applicables : ces éléments propres à votre dispositif ne sont pas établis par la seule présentation d’un certificat fournisseur.

Réduire le shadow AI avec une règle utilisable

Pour traiter les besoins susceptibles de conduire à un usage non approuvé, fournissez une courte matrice : données autorisées, outils approuvés, actions interdites et canal pour demander un nouveau cas.

Traitez les signalements comme une source d’amélioration et vérifiez avec les équipes si la règle, l’outil approuvé ou le processus de demande répond au travail réel.

Préparer la détection, l’arrêt et la reprise

  • Définir les signaux et personnes alertées.[7][9]
  • Pouvoir révoquer rapidement le compte de l’agent.[7][9]
  • Conserver les éléments nécessaires à l’analyse sans surcollecter.[7][9]
  • Identifier les actions à annuler ou vérifier.[7][9]
  • Informer les personnes et autorités lorsque le cadre l’exige.[7][9]
  • Corriger puis rejouer les tests avant réouverture.[7][9]

Traiter les menaces propres aux systèmes connectés

Injection d’instructions

Un document, une page ou un message tente de détourner le modèle. Séparez contenu et politique, limitez les outils, validez les paramètres et testez les sources hostiles.[1][3][4][5]

Fraude, deepfake et usurpation

Une voix, une image ou un message crédible ne suffit pas à autoriser un paiement ou un changement sensible. Utilisez un canal indépendant et une procédure de vérification connue.[1][3][4][5]

Hallucination comme risque de sécurité

Une information inventée peut déclencher une action, révéler une donnée ou contourner une procédure. Conservez validation déterministe et confirmation humaine selon la conséquence.[1][3][4][5]

Vérifier cinq paramètres techniques avant connexion

Identité et moindre privilège

Chaque agent et intégration utilise une identité attribuable, des droits minimaux et une révocation testée. Évitez les jetons administrateur partagés.[4][5]

Environnements et données

Séparez test et production, fournissez des exemples minimisés et bloquez les catégories interdites avant l’appel au modèle.[4][5]

Actions et confirmations

Listez outils, paramètres, plafonds, idempotence et opérations toujours humaines. Une interface de chat ne doit pas devenir un accès implicite à tout le SI.[4][5]

Journaux et conservation

Tracez les événements nécessaires au diagnostic en masquant secrets et données inutiles. Attribuez accès, durée et suppression.[4][5]

Arrêt et reprise

Testez révocation, files en attente, restauration et communication d’incident avant le volume.[4][5]

Qualifier réglementation et certification sans raccourci

Rôle de l’entreprise utilisatrice

Finalité, données, catégorie de système, supervision et obligations dépendent du dispositif. Faites qualifier les rôles plutôt que déléguer la conclusion au fournisseur.[8][2]

Protection des données

Dans l’Union européenne, l’article 6 du RGPD prévoit plusieurs bases juridiques, chacune soumise à ses propres conditions ; le consentement n’est donc ni automatiquement requis ni automatiquement écarté. Qualifiez le traitement, puis documentez finalité, nécessité, base retenue, information, droits et acteurs. Pour une violation de données personnelles, les notifications à l’autorité ou aux personnes dépendent notamment des seuils de risque des articles 33 et 34 : toute alerte de sécurité ne déclenche pas automatiquement les deux notifications.[9]

Certification et périmètre

Demandez entité, services, sites, version, exclusions et date. Ne supposez pas que le périmètre présenté inclut vos connecteurs et permissions : vérifiez-les séparément.

Classer les données avant de choisir un outil

Public et interne

Pour une donnée publique, vérifiez fraîcheur, droits et adéquation au contexte. Pour l’interne, définissez les outils, finalités, durées et personnes autorisées au lieu d’autoriser toute copie par défaut.

Confidentiel et sensible

Distinguez secrets, catégories particulières de données personnelles, identifiants, dossiers individuels et informations contractuelles : ces catégories n’ont pas le même régime. Pour chacune, qualifiez minimisation, accès, isolation et transmission réelle au fournisseur.[2][9]

Cartographier le flux chez les fournisseurs et sous-traitants

Dessinez collecte, transit, régions de traitement, stockage, journaux, entraînement éventuel, sous-traitants, support et suppression. Pour chaque étape, associez finalité, base d’accès, chiffrement, durée, preuve contractuelle et moyen de tester l’effacement.[2][9][5][6]

Inclure les scénarios adverses dans la recette

  • Instruction hostile placée dans une page, un document ou un e-mail.
  • Tentative de lecture croisée entre utilisateurs ou espaces.
  • Secret ou identifiant présent dans une entrée, une sortie ou un journal.
  • Révocation d’un compte pendant une tâche en cours.
  • Action sensible proposée avec un paramètre inventé ou modifié.
  • Arrêt, conservation des preuves et reprise après incident.

Questions fréquentes

Qu’est-ce que le shadow AI ?

L’usage de systèmes IA en dehors des outils et processus approuvés. Il peut signaler un besoin non couvert, une règle mal comprise ou un écart volontaire ; vérifiez la cause au lieu de la supposer.

Qu’est-ce qu’une injection d’instructions ?

Un contenu tente d’influencer le modèle pour détourner ses consignes ou ses outils. Traitez les contenus externes comme non fiables.[3][4]

Une certification suffit-elle ?

Non. Vérifiez son périmètre puis évaluez votre configuration, vos flux, vos droits, votre usage et vos procédures.

Peut-on saisir des données personnelles ?

Seulement après qualification de la finalité, de la base applicable, des informations, droits, durées, fournisseurs et mesures de protection nécessaires.[2][9]

Comment sécuriser une plateforme d’automatisation ?

Utilisez des comptes dédiés, limitez connecteurs et champs, protégez les secrets, validez les actions sensibles et surveillez les exécutions.[4][5]

Les hallucinations sont-elles un risque de sécurité ?

Elles peuvent le devenir si une sortie fausse déclenche une action, masque un incident ou produit une instruction dangereuse. Séparez génération et contrôle.[1][3]

Sources

  1. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — National Institute of Standards and Technology. Publié le . Consulté le . ↩1↩2↩3↩4
  2. Les questions-réponses de la CNIL sur l’utilisation d’un système d’IA générative — CNIL. Consulté le . ↩1↩2↩3↩4↩5
  3. OWASP GenAI LLM Top 10 2026 — OWASP GenAI Security Project. Publié le . Consulté le . ↩1↩2↩3↩4↩5↩6↩7↩8↩9↩10↩11↩12↩13
  4. OWASP Top 10 for Agentic Applications 2026 — OWASP GenAI Security Project. Publié le . Consulté le . ↩1↩2↩3↩4↩5↩6↩7↩8↩9↩10↩11↩12↩13↩14↩15↩16↩17↩18↩19
  5. Recommandations de sécurité pour un système d’IA générative — ANSSI. Consulté le . ↩1↩2↩3↩4↩5↩6↩7↩8↩9↩10↩11↩12↩13↩14↩15↩16↩17↩18↩19
  6. Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations — National Institute of Standards and Technology. Consulté le . ↩1
  7. Incident Response Recommendations and Considerations for Cybersecurity Risk Management — National Institute of Standards and Technology. Consulté le . ↩1↩2↩3↩4↩5↩6
  8. Regulation (EU) 2024/1689 — Artificial Intelligence Act — EUR-Lex. Publié le . Mis à jour le . Consulté le . ↩1
  9. Regulation (EU) 2016/679 — General Data Protection Regulation — EUR-Lex. Publié le . Consulté le . ↩1↩2↩3↩4↩5↩6↩7↩8↩9↩10↩11

Poursuivre votre lecture