Selon le baromètre Cesin 2024 sur la cybersécurité des entreprises françaises, la surface d'attaque des organisations s'est élargie de manière continue avec l'introduction de nouveaux outils SaaS, dont les assistants conversationnels et les agents autonomes basés sur des LLM. En parallèle, l'ENISA publiait dès 2023 un rapport dédié à la sécurité des systèmes d'IA générative, listant une série de risques spécifiques : injection de prompt, exfiltration de données via contexte, empoisonnement de bases vectorielles, contournement de garde-fous. Trois ans plus tard, ces risques restent largement sous-traités dans les projets d'agents IA que je vois passer sur le terrain.
Le paradoxe est le suivant : un agent IA est souvent déployé plus vite qu'une application métier classique, parce qu'il ne nécessite pas de développement lourd. Or, cette vitesse d'installation masque la profondeur des accès qu'il obtient : lecture de documents internes, envoi d'emails, appel d'API, prise de rendez-vous, écriture dans un CRM. Chacun de ces accès est un vecteur potentiel de fuite ou de compromission.
Cet article s'adresse aux DSI, RSSI, DPO et dirigeants de PME-ETI qui s'apprêtent à mettre en production un agent IA — qu'il s'agisse d'un assistant support, d'un agent de prospection ou d'un réceptionniste vocal. Il propose une checklist opérationnelle en 40 points, organisée en huit domaines, à parcourir avant la mise en production et à réauditer tous les six mois. L'objectif n'est pas d'être exhaustif au sens ISO, mais d'être utilisable dès la semaine prochaine par une équipe de trois personnes.
Cartographie et périmètre : 5 points à valider avant tout
La première erreur observée sur le terrain n'est pas technique : elle est documentaire. La plupart des projets d'agent IA démarrent sans que le périmètre exact soit posé par écrit. Or, une checklist sécurité agent IA entreprise ne peut pas s'appliquer à un objet flou. Avant même de discuter garde-fous ou chiffrement, il faut cartographier ce que l'agent va faire, à qui il va parler, et sur quelles données il va s'appuyer.
Les 5 points de la cartographie
- 1. Cas d'usage explicitement borné : une phrase écrite décrivant les tâches autorisées, les tâches interdites, les canaux d'accès (web, email, WhatsApp, téléphone).
- 2. Liste des utilisateurs : internes, clients externes, partenaires. Chaque catégorie doit avoir un niveau de confiance différent et donc un périmètre d'agent différent.
- 3. Inventaire des sources de données : bases documentaires, CRM, ERP, drives partagés, boîtes email consultées. Chaque source doit être classée en confidentialité (public, interne, confidentiel, secret).
- 4. Cartographie des actions sortantes : envoi d'email, appel d'API, écriture en base, prise de rendez-vous, transfert d'appel. Chaque action doit être qualifiée en niveau de risque.
- 5. Désignation d'un propriétaire métier et d'un référent sécurité : deux personnes nommées, disponibles, avec un mandat clair pour arbitrer.
Ce socle documentaire prend une demi-journée à produire, mais il conditionne tout le reste. Sans lui, la checklist qui suit devient un exercice de style. Sur les agents standardisés comme ceux proposés par Praxia AI, ce périmètre est déjà cadré par la fiche produit de chaque agent, ce qui accélère l'étape.
Contrôle d'accès et authentification : 6 points
Un agent IA est un utilisateur technique de votre système d'information. À ce titre, il doit obéir aux mêmes règles que n'importe quel compte de service, avec une contrainte supplémentaire : il peut être manipulé par prompt injection pour agir hors de son périmètre. La checklist sécurité agent IA entreprise doit donc traiter l'agent comme un compte à privilèges limités par défaut.
Les 6 points du contrôle d'accès
- 6. Principe du moindre privilège : l'agent ne dispose que des permissions strictement nécessaires à sa tâche. Un agent support en lecture seule n'a pas besoin d'écrire dans le CRM.
- 7. Authentification distincte par agent : un compte de service dédié par agent, jamais partagé, avec rotation des secrets tous les 90 jours.
- 8. Authentification utilisateur en amont : quand l'agent parle à un client externe, le client est identifié (login, numéro de téléphone vérifié, adresse email confirmée) avant que l'agent ne divulgue une information personnalisée.
- 9. Séparation des environnements : les clés d'accès de production ne sont jamais utilisées en pré-production ni en test.
- 10. Journal des connexions : chaque appel d'API par l'agent est tracé avec horodatage, utilisateur final, action, résultat.
- 11. Révocation immédiate : procédure documentée pour couper l'agent en moins de dix minutes en cas d'incident, testée au moins une fois par trimestre.
Sur les agents à interface conversationnelle grand public — un chatbot support par exemple — l'authentification préalable de l'utilisateur est souvent absente. C'est un point d'attention majeur. Un agent comme Nina, agent IA support client Praxia doit être configuré pour distinguer les questions génériques (accessibles sans authentification) des demandes personnalisées (numéro de commande, statut de livraison) qui nécessitent une vérification d'identité côté client.
Données d'entrée et RAG : 6 points sur la base de connaissance
La plupart des agents IA en entreprise s'appuient sur une architecture RAG (Retrieval Augmented Generation) : ils interrogent une base vectorielle qui contient les documents internes, puis génèrent une réponse à partir des extraits récupérés. Cette base est un actif sensible. Elle contient souvent des documents confidentiels aspirés depuis Sharepoint, un drive ou un DMS, sans que personne ne vérifie ce qui a été réellement indexé.
Les 6 points de la base de connaissance
- 12. Filtrage des documents en amont : les documents indexés sont explicitement listés, pas aspirés par lot. Les grilles salariales, les CV et les documents RH nominatifs n'ont rien à faire dans un index accessible à un agent support.
- 13. Métadonnées de confidentialité : chaque document indexé porte un tag (public, interne, confidentiel) exploité par le moteur de recherche pour filtrer selon le profil utilisateur.
- 14. Anonymisation des données personnelles : les documents contenant des données identifiantes sont pseudonymisés avant indexation, sauf justification métier explicite.
- 15. Traçabilité des sources dans la réponse : chaque réponse de l'agent cite les documents sources utilisés, pour permettre un audit a posteriori.
- 16. Ré-indexation contrôlée : le processus d'ajout ou de suppression de documents est journalisé et validé par un référent métier.
- 17. Test d'empoisonnement : avant mise en production, on injecte volontairement dix documents piégés (instructions cachées, contenus erronés) pour vérifier que l'agent ne les exécute pas comme des commandes.
Ce dernier point est souvent négligé. L'empoisonnement de base vectorielle est pourtant une classe d'attaque documentée depuis 2023, y compris dans le rapport OWASP Top 10 for LLM Applications, dont la version 2025 la place parmi les risques prioritaires.
Garde-fous, prompt injection et sorties : 7 points
C'est le domaine où la maturité des équipes varie le plus. Les garde-fous d'un agent IA ne se résument pas à un prompt système bien écrit. Ils forment une pile défensive à plusieurs étages, chacun couvrant une faille des autres.
Les 7 points sur les garde-fous
- 18. Prompt système versionné : le prompt qui pilote l'agent est stocké dans un dépôt git, versionné, revu à chaque modification.
- 19. Filtrage des entrées utilisateur : détection de motifs suspects avant que le message n'atteigne le LLM (tentatives de jailbreak, injections classiques du type « ignore les instructions précédentes »).
- 20. Isolation des instructions et des données : les documents récupérés par le RAG sont clairement délimités dans le contexte, avec une consigne explicite au modèle de ne pas les traiter comme des instructions.
- 21. Filtrage des sorties : validation que la réponse ne contient pas de données confidentielles non autorisées (numéros de carte, RIB, données médicales), via un second modèle ou un filtre regex.
- 22. Limitation du périmètre conversationnel : l'agent refuse poliment de traiter les sujets hors de son mandat, avec une phrase de repli standardisée.
- 23. Validation humaine sur actions sensibles : envoi d'email externe, création de facture, prise de rendez-vous à fort enjeu — chaque action à impact franchit un point de contrôle humain ou une double confirmation utilisateur.
- 24. Tests de robustesse documentés : une batterie de 30 à 50 prompts adverses est passée avant chaque mise à jour majeure du prompt système, avec un taux d'échec cible inférieur à 5 %.
Pour un agent de prospection comme Sam, agent IA prospection B2B Praxia, le point 23 est particulièrement critique : l'envoi automatisé d'emails cold vers une liste externe engage la responsabilité de l'entreprise au regard du RGPD et de la loi pour une République numérique. Une validation humaine sur les templates et les segments cibles reste indispensable, quelle que soit la qualité du modèle.
Journalisation, auditabilité et supervision : 5 points
Un agent IA sans journalisation propre est un actif ingérable. Le jour où un client conteste une réponse, où un DPO demande la liste des données consultées à propos d'une personne, ou où un régulateur ouvre une enquête au titre de l'AI Act, il faut pouvoir produire des logs exhaustifs et interprétables.
Les 5 points de la supervision
- 25. Log complet des conversations : chaque échange utilisateur-agent est enregistré avec horodatage, identifiant utilisateur (ou pseudonyme), prompt, réponse, sources RAG utilisées, actions déclenchées.
- 26. Durée de conservation définie : la durée de rétention des logs est cohérente avec la finalité (support : 12 mois, prospection : 6 mois, réclamations : 5 ans), documentée dans le registre RGPD.
- 27. Séparation des logs métier et des logs techniques : les logs contenant des données personnelles sont chiffrés au repos et accessibles uniquement à un cercle restreint.
- 28. Tableau de bord de supervision : suivi hebdomadaire des indicateurs clés — taux de refus, taux d'escalade humaine, temps de réponse, coût par conversation, mots-clés fréquents dans les échecs.
- 29. Procédure d'alerte : seuil de détection d'anomalie défini (pic d'appels, pic de refus, contenu sensible détecté en sortie) avec notification à un référent en moins d'une heure.
Sur l'analyse a posteriori des conversations, un agent d'analyse de données comme Noé, agent IA analyse de données Praxia peut agréger les logs export CSV pour produire des cohortes et repérer les motifs récurrents d'échec — utile quand l'équipe sécurité veut objectiver un risque plutôt que le supposer.
Fournisseur, contrat et souveraineté : 6 points
Ce domaine est souvent traité en dernier, alors qu'il devrait être abordé en premier. Il ne s'agit pas de vérifier une plaquette commerciale, mais de lire attentivement le contrat, les CGU, la politique de confidentialité et l'annexe DPA (Data Processing Agreement).
Les 6 points du contrat fournisseur
- 30. Localisation des données : où sont hébergées les données de conversation, où tourne le modèle, où sont stockés les embeddings. Réponse précise, avec pays et région cloud, écrite au contrat.
- 31. Sous-traitants LLM : identité des fournisseurs de modèle (OpenAI, Anthropic, Mistral, Meta, un modèle open source hébergé) et localisation de leur traitement.
- 32. Clause de non-entraînement : engagement écrit du fournisseur à ne pas utiliser les conversations pour entraîner ses modèles.
- 33. DPA signée : annexe RGPD conforme, avec engagements sur les sous-traitants ultérieurs, les transferts hors UE, les mesures de sécurité.
- 34. Exposition au Cloud Act : identification claire des fournisseurs soumis à la loi américaine (fournisseurs US ou filiales de groupes US) et arbitrage documenté en fonction de la sensibilité des données.
- 35. Réversibilité et portabilité : capacité à exporter les données, les prompts, la base vectorielle, l'historique, dans un format standard, en cas de sortie du service.
Pour les organisations les plus exposées, une Édition Entreprise à 1 490 € en installation chez le client permet de maîtriser physiquement l'hébergement. Ce n'est pas la seule voie, mais c'est la plus lisible pour un RSSI qui veut réduire la surface juridique.
Conformité, RGPD et AI Act : 3 points structurants
Les obligations réglementaires ne sont plus une hypothèse. L'AI Act, règlement (UE) 2024/1689, est entré en vigueur le 1er août 2024, avec une application progressive jusqu'en 2027. Les obligations relatives aux systèmes à risque limité — dont la plupart des agents conversationnels — s'appliquent depuis août 2026.
Les 3 points de conformité
- 36. Analyse d'impact (AIPD) ou étude préalable : documentée pour tout agent traitant des données personnelles à grande échelle, conforme à l'article 35 du RGPD.
- 37. Information des utilisateurs : l'utilisateur sait qu'il parle à un système automatisé (obligation AI Act pour les chatbots), et il connaît la finalité, la base légale et ses droits (RGPD).
- 38. Registre des systèmes IA : chaque agent en production est inscrit dans un registre interne indiquant sa finalité, ses données, son fournisseur, sa classification de risque au sens de l'AI Act.
Pour les questions juridiques de premier niveau — rédaction de mentions légales, adaptation des CGV pour intégrer l'usage d'un agent IA, information des salariés — un agent comme Justine, juriste IA Praxia fournit un premier jet exploitable, à faire relire par un conseil pour les cas sensibles.
Ce qui peut mal tourner : 2 points sur le plan de repli
Aucune checklist ne prévient tous les incidents. Ce qui distingue une organisation mature d'une autre, c'est la capacité à réagir vite quand quelque chose se passe mal. Deux derniers points closent la liste, et ils comptent autant que les 38 précédents.
Les 2 points du plan de repli
- 39. Procédure d'incident documentée : qui fait quoi dans les deux heures qui suivent la détection d'une fuite de données, d'une hallucination critique publiée, d'un contournement de garde-fous. Rôles nommés, canaux de communication définis, message client type préparé.
- 40. Plan de continuité sans agent : les équipes savent traiter les demandes clients sans l'agent, y compris en volume dégradé. Les scripts humains sont disponibles, les accès sont maintenus, la formation minimale est faite.
Les incidents les plus fréquents que je documente ne sont pas des attaques sophistiquées. Ce sont des mises à jour de prompt système mal testées qui rendent l'agent trop bavard, ou des documents oubliés dans la base vectorielle qui remontent dans une réponse. La détection prend quelques heures, la correction quelques minutes, mais l'exposition médiatique peut durer des semaines si la communication n'est pas préparée.
En conclusion
La checklist sécurité agent IA entreprise que je propose ici n'est pas une norme. C'est un outil opérationnel de 40 points, à parcourir avant la mise en production et à réauditer semestriellement. Trois recommandations, dans l'ordre de priorité :
Un, cartographiez avant de configurer : le périmètre écrit, les données classifiées, les actions qualifiées. Sans cette base, tous les garde-fous techniques restent des rustines. Deux, traitez l'agent comme un compte à privilèges : moindre privilège, authentification distincte, journalisation exhaustive, révocation testée. Trois, lisez le contrat fournisseur ligne à ligne : localisation, non-entraînement, sous-traitants LLM, exposition au Cloud Act, réversibilité. C'est là que se cachent les surprises coûteuses.
Pour les TPE et PME qui n'ont pas les moyens d'internaliser cette expertise, choisir un fournisseur qui a déjà cadré ces 40 points par défaut est un raccourci légitime — à condition de vérifier la documentation, pas la plaquette.