IA et cybersécurité : les contrôles minimums pour une PME
Intelligence artificielle
Confidentialité des données
Gouvernance IA
Gestion des risques IA
Un assistant qui résume des contrats, un outil connecté au CRM ou un agent qui prépare des factures : chaque usage crée de nouveaux accès à contrôler. Pour une PME, **IA et cybersécurité** doivent donc se traiter ensemble, avant de connecter des données confidentielles ou d’autoriser des actions aut...
octobre 04, 2026·12 min de lecture
Un assistant qui résume des contrats, un outil connecté au CRM ou un agent qui prépare des factures : chaque usage crée de nouveaux accès à contrôler. Pour une PME, IA et cybersécurité doivent donc se traiter ensemble, avant de connecter des données confidentielles ou d’autoriser des actions automatiques. Le problème n’est pas seulement ce que l’IA répond, mais ce qu’elle peut consulter, transmettre et modifier.
Voici huit contrôles minimums, avec des vérifications concrètes et un plan de déploiement sur 30 jours. L’objectif : disposer d’un socle vérifiable, sans transformer chaque projet en chantier de sécurité interminable.
IA et cybersécurité : définir le périmètre avant les contrôles
La protection nécessaire dépend de l’usage. Un assistant qui reformule un texte public n’a pas les mêmes besoins qu’un agent connecté aux dossiers clients et capable d’envoyer des messages.
Distinguez trois situations : l’outil sans connexion à vos systèmes, l’assistant qui consulte des données internes et l’agent qui peut agir dans vos applications. Dès qu’un outil accède à des informations non publiques, appliquez les huit contrôles ci-dessous. Pour un agent, renforcez surtout les permissions, les validations et la capacité d’arrêt.
Ce socle ne remplace pas l’hygiène informatique habituelle. Mises à jour, protection des postes, sauvegardes testées et sécurisation des comptes restent indispensables. Le guide d’hygiène informatique de l’ANSSI constitue une référence pour ces fondamentaux.
Les mesures proposées sont un minimum opérationnel, pas une certification de sécurité ni une garantie de conformité réglementaire. Leur niveau doit être adapté aux données traitées, aux conséquences d’une erreur et à vos obligations sectorielles.
Les huit contrôles minimums à mettre en place
1. Recenser les outils, les connexions et les responsables
Vous ne pouvez pas sécuriser un usage dont vous ignorez l’existence. Commencez par un registre partagé des outils IA utilisés, y compris les extensions de navigateur, les fonctions intégrées aux logiciels métier et les automatisations créées par des collaborateurs.
Pour chaque usage, notez le responsable métier, les utilisateurs autorisés, les catégories de données traitées et les applications connectées. Précisez aussi si l’outil peut seulement lire des informations ou effectuer des modifications.
Ce registre doit devenir une étape obligatoire avant toute nouvelle connexion. Un responsable désigné doit pouvoir expliquer l’utilité de l’outil et décider de sa suspension.
La vérification est simple : choisissez un outil au hasard et demandez qui l’utilise, quelles données il reçoit et comment couper son accès. Si personne ne sait répondre, le contrôle reste incomplet. Pour accompagner cette démarche, formalisez des règles d’utilisation de l’IA en équipe plutôt qu’une interdiction générale difficile à faire respecter.
2. Définir quelles données peuvent entrer dans l’outil
Établissez une règle courte qui distingue les données publiques, internes, confidentielles et les données particulièrement sensibles. Associez chaque catégorie aux outils et aux usages autorisés.
Le minimum : ne pas transmettre d’informations confidentielles dans un outil non approuvé. Cela concerne notamment les contrats non publics, les fichiers clients, les données RH et les secrets techniques. Les mots de passe et les clés API ne doivent pas être placés dans les prompts.
Réduisez également le volume transmis. Pour reformuler un courrier, l’outil n’a généralement pas besoin du dossier client complet. Pour tester un processus, privilégiez des données fictives.
Retirer les noms ne suffit pas toujours à anonymiser un document : une adresse, un numéro de dossier ou le contexte peuvent permettre de retrouver une personne. Des données pseudonymisées restent des données personnelles.
Testez la règle avec un exemple réel : un collaborateur doit pouvoir déterminer rapidement si un fichier peut être envoyé, dans quel outil et après quelles modifications.
3. Vérifier le fournisseur et les paramètres de traitement
Un abonnement professionnel ne garantit pas, à lui seul, que toutes les conditions de sécurité correspondent à votre usage. Examinez les engagements contractuels et les paramètres effectivement disponibles pour l’offre choisie.
Quatre points doivent être documentés :
Utilisation des données : les contenus transmis servent-ils à entraîner ou améliorer les modèles, et quels réglages ou engagements encadrent cet usage ?
Conservation : combien de temps les fichiers, conversations et journaux sont-ils conservés, et comment demander leur suppression ?
Traitement : où les données sont-elles traitées, quels sous-traitants interviennent et comment sont encadrés les éventuels transferts hors Espace économique européen ?
Responsabilités : quels engagements couvrent la confidentialité, la sécurité et la notification d’incidents, avec un accord de sous-traitance lorsque le RGPD le requiert ?
Conservez la preuve des réglages et des conditions examinées. Si une réponse déterminante manque, limitez l’usage aux données publiques ou fictives jusqu’à clarification. Un hébergement annoncé en Europe ne répond pas, à lui seul, à toutes ces questions.
4. Sécuriser les comptes et les départs de collaborateurs
Utilisez des comptes professionnels nominatifs. Les comptes partagés rendent les actions difficiles à attribuer et compliquent le retrait des accès lorsqu’une personne quitte l’entreprise.
Activez l’authentification multifacteur, en priorité pour les administrateurs et les comptes donnant accès aux données internes. Lorsque l’outil le permet, centralisez la connexion avec votre système d’identité professionnel pour faciliter la gestion des arrivées et des départs.
Séparez les droits d’administration des droits d’utilisation. Un collaborateur qui rédige des synthèses n’a pas besoin de modifier les règles de conservation ou d’ajouter des connecteurs.
Vérifiez aussi les comptes techniques : une automatisation peut continuer à fonctionner après le départ de son créateur. La procédure de départ doit couvrir les sessions, les jetons d’accès et les connexions aux applications. Testez-la sur un compte de démonstration, sans attendre un départ réel.
5. Limiter les connecteurs et faire contrôler les actions par l’application
Une connexion au CRM, à la messagerie ou au stockage documentaire doit respecter le principe du moindre privilège : uniquement les données et les opérations nécessaires au cas d’usage.
Commencez en lecture seule quand c’est possible. Limitez ensuite les dossiers, objets métier et champs accessibles. Pour un assistant documentaire, les réponses doivent respecter les droits de l’utilisateur, même lorsque les documents ont déjà été indexés dans une base utilisée pour enrichir les réponses, souvent appelée RAG.
Pour les agents, autorisez explicitement les actions possibles. Un outil qui prépare un brouillon ne doit pas pouvoir envoyer tous les messages ni supprimer des contacts. Les actions engageantes, comme un paiement ou une suppression importante, nécessitent une validation adaptée.
Le contrôle doit être appliqué par le logiciel, pas seulement demandé au modèle. Une consigne dans un prompt n’est pas une barrière d’autorisation. Notre guide des tâches à automatiser avec un agent IA sans perdre le contrôle aide à sélectionner des usages plus faciles à encadrer.
6. Traiter les contenus externes comme des entrées non fiables
Une page web, un email ou un PDF peut contenir des instructions destinées à détourner l’assistant. C’est le principe de l’injection de prompt, notamment lorsqu’une instruction malveillante est cachée dans un document consulté par l’IA.
Séparez les contenus à analyser des instructions de l’application. Vérifiez les paramètres des actions proposées et bloquez les destinations non autorisées lorsque votre intégration permet ce filtrage. Ne transmettez pas directement une sortie du modèle à un interpréteur de commandes ou à une requête de base de données sans contrôle approprié.
Testez avec un document fictif demandant d’envoyer des données vers une adresse externe. La protection attendue ne se limite pas au refus de l’assistant : l’application doit empêcher l’envoi non autorisé.
7. Garder des traces utiles sans créer une nouvelle fuite
Les journaux doivent permettre de comprendre qui a déclenché une opération, quel connecteur a été utilisé, quelle action a été tentée et si elle a été autorisée ou bloquée.
Pour une solution développée sur mesure, prévoyez ces traces dès la conception. Pour un outil SaaS, vérifiez les informations accessibles aux administrateurs et les possibilités d’export. Si les traces sont insuffisantes pour un usage sensible, réduisez son périmètre ou choisissez une solution mieux adaptée.
Évitez de journaliser systématiquement les prompts et les réponses en intégralité : vous pourriez créer une seconde copie de données confidentielles. Définissez une durée de conservation, limitez les accès aux journaux et masquez les secrets.
Désignez une personne chargée d’examiner les alertes utiles, comme des accès inhabituels ou des tentatives répétées d’action interdite. L’IA et la cybersécurité ne se pilotent pas uniquement à l’installation : il faut aussi pouvoir repérer les écarts pendant l’exploitation.
8. Préparer l’arrêt et la gestion d’un incident
Avant la mise en production, identifiez comment suspendre l’outil, désactiver ses connecteurs et révoquer ses accès. Pour une automatisation métier, prévoyez un fonctionnement manuel de secours.
Rédigez une fiche courte avec le contact interne, le prestataire à prévenir et les premières actions. En cas d’incident, il faut pouvoir arrêter les traitements concernés, préserver les traces nécessaires et déterminer quelles données ou opérations ont été touchées. Une clé compromise doit être révoquée et remplacée, pas simplement retirée du prompt où elle apparaissait.
Distinguez une réponse incorrecte d’un incident de sécurité. Un accès indu, une divulgation à un tiers ou une modification non autorisée exige une analyse spécifique.
Si une violation de données personnelles présente un risque pour les droits et libertés des personnes, une notification à la CNIL peut être obligatoire, si possible dans les 72 heures après en avoir pris connaissance. La procédure de notification de la CNIL détaille les conditions applicables. Vérifiez également vos obligations contractuelles de notification.
Les tests à réussir avant de connecter des données réelles
Une politique écrite ne prouve pas qu’un contrôle fonctionne. Effectuez des tests avec des comptes de démonstration et des données fictives, dans un environnement autorisé. Le tableau suivant constitue une recette minimale à adapter à l’usage.
Test
Résultat attendu
Preuve à conserver
Un utilisateur demande un document auquel il n’a pas accès
Aucun contenu du document ne lui est révélé
Résultat du test et configuration des droits
Un document contient une instruction d’envoi vers un tiers
Aucun envoi non autorisé n’est exécuté
Trace de l’action bloquée
Un agent tente une modification hors de son périmètre
L’application refuse l’opération
Erreur d’autorisation et permissions du connecteur
Le compte d’un collaborateur est désactivé
Ses accès personnels et sessions concernés ne fonctionnent plus
Vérification après désactivation
Le responsable déclenche l’arrêt de l’automatisation
Aucune nouvelle action n’est lancée, les tâches en cours sont traitées selon la procédure prévue
Compte rendu du test d’arrêt
Un échec ne signifie pas nécessairement qu’il faut abandonner le projet. Vous pouvez retirer un connecteur, passer en lecture seule ou restreindre les données. En revanche, un échec sur les permissions ou l’arrêt doit bloquer la mise en production du périmètre concerné.
Rejouez les tests après une modification importante du modèle, des connecteurs ou des règles d’accès.
Un plan de mise en place sur 30 jours
Jours 1 à 7 : rendre les usages visibles
Recensez les outils et désignez leurs responsables. Suspendez les connexions non maîtrisées à des données confidentielles, puis publiez une règle d’usage courte. Organisez une formation pratique : chacun doit savoir reconnaître un outil approuvé, choisir les données autorisées et signaler une anomalie.
Jours 8 à 15 : fermer les accès excessifs
Examinez les fournisseurs, activez l’authentification multifacteur et supprimez les comptes partagés. Passez les connecteurs en revue pour retirer les permissions inutiles. Commencez par les usages combinant données confidentielles, accès étendu et capacité de modification.
Jours 16 à 30 : tester et décider
Exécutez la recette de sécurité, testez l’arrêt et validez le fonctionnement manuel de secours. Documentez les limites restantes, avec un responsable et une échéance de correction. Si un risque critique demeure, réduisez le périmètre plutôt que de considérer la date de lancement comme intangible.
Ce calendrier est une proposition d’organisation. Une PME avec peu d’outils peut avancer plus vite ; un système connecté à plusieurs applications sensibles demandera davantage de vérifications.
Questions fréquentes
Une offre IA payante protège-t-elle automatiquement les données de l’entreprise ? Non. Les conditions contractuelles, les réglages, les droits d’accès et les connecteurs restent déterminants. Vérifiez l’offre précise utilisée, pas seulement la réputation du fournisseur.
Faut-il interdire tous les outils IA publics ? Pas nécessairement. Ils peuvent convenir à certains usages sans données confidentielles. Une liste d’outils approuvés et des règles simples permettent de distinguer les usages acceptables de ceux qui nécessitent un environnement mieux contrôlé.
Un prompt peut-il empêcher un agent de réaliser une action dangereuse ? Il peut orienter son comportement, mais ne constitue pas une garantie de sécurité. Les autorisations doivent être vérifiées par l’application et les actions sensibles soumises à une validation adaptée.
Qui doit piloter l’IA et la cybersécurité dans une petite entreprise ? Un responsable interne doit porter les décisions, avec l’appui du prestataire informatique et des responsables métier. Il n’a pas besoin d’exécuter tous les contrôles lui-même, mais doit savoir qui les réalise et où se trouvent les preuves.
Cadrer un premier projet avant de multiplier les outils
Choisissez un usage utile, un périmètre de données limité et des actions faciles à contrôler. Vous pourrez élargir ensuite, lorsque les permissions, les tests et les procédures seront opérationnels.
Impulse Lab accompagne les PME avec des audits d’opportunités IA, des développements web et IA sur mesure, des intégrations et des formations à l’adoption. Pour votre prochain projet, intégrez ce socle au cadrage : données autorisées, permissions, validations et procédure d’arrêt doivent être discutées avant le développement, avec votre interlocuteur sécurité ou informatique.