Sécuriser les usages de l’IA générative avec un audit ISO 27001

L’essentiel en 30 secondes :

• Un audit ISO 27001 permet d’identifier les usages d’IA générative qui exposent réellement les données, les clients et l’activité.
• Les outils autorisés, les données interdites et les contrôles attendus doivent être définis avant que les pratiques ne s’installent.
• L’équipe informatique ne peut pas décider seule : métiers, direction, RH et QSE partagent la maîtrise des risques.
• Former les équipes et vérifier les usages protège la confidentialité sans empêcher les gains de temps utiles.

Temps de lecture :

8 minutes

Pourquoi l’IA générative devient un risque de cybersécurité à auditer

Un audit ISO 27001 permet de transformer ce constat en questions vérifiables. Quels usages sont autorisés ? Quelles informations ne doivent jamais être saisies ? Qui valide un nouvel outil ou une nouvelle fonctionnalité ? Quels fournisseurs traitent les données, selon quelles garanties, et avec quels paramètres de conservation ? Les équipes savent-elles signaler un usage douteux ou une erreur produite par l’outil ?

Dans de nombreuses entreprises, l’IA générative n’est plus un projet cantonné à la DSI. Elle est déjà utilisée pour reformuler des offres, résumer des réunions, analyser des tableaux, préparer des réponses clients ou produire du code. Cette diffusion rapide crée un écart entre les usages réels et les règles de sécurité de l’information. Le sujet n’est donc pas seulement technologique : il devient une question de gouvernance, de confidentialité et de maîtrise des risques.

Le premier danger vient souvent des pratiques ordinaires. Un collaborateur peut copier dans un outil public une synthèse client, une procédure interne, un extrait de contrat ou une donnée issue d’un incident, sans mesurer ce qui est transmis au fournisseur. D’autres risques apparaissent ensuite : compte personnel employé pour travailler, droits d’accès mal paramétrés, réponse erronée intégrée à un livrable, absence de traçabilité ou outil connecté à des applications internes sans évaluation préalable. Dans ce contexte, l’organisation ne peut pas se satisfaire d’une consigne générale invitant à « utiliser l’IA avec prudence ».

L’objectif n’est pas d’interdire l’IA par principe. Il consiste à établir un niveau de contrôle proportionné aux activités, aux données et aux impacts métier. Direction, RSSI, DSI, responsables QSE et managers doivent ainsi pouvoir arbitrer sur des éléments concrets, plutôt que réagir après un incident. Cette première photographie des usages fournit la base d’un diagnostic cybersécurité, puis d’actions priorisées : règles d’usage, paramétrage, sensibilisation, revue des fournisseurs et preuves de contrôle.

Commencer par voir les usages réels, avant d’écrire des règles

Avant de rédiger une règle sur l’intelligence artificielle, il faut savoir comment elle est déjà utilisée. Dans beaucoup d’équipes, les usages ont commencé sans projet officiel : préparation d’un compte rendu, recherche d’idées, correction d’un texte, traduction, tri d’informations ou aide au développement informatique. Cette réalité ne signifie pas que les équipes ont mal agi. Elle montre surtout que l’entreprise doit reprendre la main avec des règles compréhensibles et adaptées au travail réel.

La première étape consiste à interroger quelques métiers représentatifs : commerce, production, ressources humaines, achats, service client, fonctions support et informatique. L’objectif est simple : repérer les outils utilisés, les tâches concernées et les types d’informations qui y sont saisis. Une attention particulière doit être portée aux données clients, aux prix, aux contrats, aux documents internes, aux données personnelles et aux informations liées à la sécurité.

Ce relevé ne doit pas devenir un contrôle intrusif. Il sert à distinguer trois situations. Certaines pratiques peuvent être autorisées rapidement, par exemple produire un premier brouillon à partir d’informations publiques. D’autres demandent des précautions : utilisation d’un outil choisi par l’entreprise, relecture humaine obligatoire ou suppression préalable des informations sensibles. Enfin, certains usages doivent être interdits tant que les risques n’ont pas été examinés, notamment lorsqu’ils impliquent des données confidentielles ou une décision qui concerne une personne.

Cette étape donne à l’audit ISO 27001 une base concrète. Au lieu de vérifier des règles théoriques, l’auditeur peut comparer les usages observés avec les protections réellement en place. L’entreprise identifie alors les priorités : choisir des outils fiables, limiter les accès, informer les équipes et vérifier que les règles sont comprises. Elle évite aussi deux écueils fréquents : ignorer des usages déjà installés ou imposer une interdiction générale que personne ne peut appliquer durablement.

Quels usages de l’IA doivent être contrôlés en priorité ?

Tous les usages de l’IA ne présentent pas le même niveau de risque. Demander à un outil de reformuler un texte public n’a pas les mêmes conséquences que lui transmettre un fichier client, lui faire trier des candidatures ou lui confier une décision qui touche à la sécurité. L’audit doit donc commencer par les pratiques qui peuvent exposer l’entreprise, ses clients ou ses salariés.

Ce tableau aide à choisir les premiers contrôles.

Source officielle : Cadre réglementaire de l’AI Act — Commission européenne.

Qui doit décider lorsque l’IA entre dans les pratiques de travail ?

Lorsqu’un outil d’IA entre dans les habitudes de travail, le réflexe est souvent de confier le sujet à l’équipe informatique. Elle vérifie les accès, les données et le fournisseur. Mais elle ne peut pas décider seule si l’usage est pertinent ou suffisamment sûr. Il faut réunir les personnes qui connaissent le travail, les risques et les décisions à prendre.

La direction définit l’objectif : gagner du temps, protéger une information stratégique ou éviter une pratique trop risquée. Les responsables métier décrivent ensuite le travail réel. Ils savent quelles données sont manipulées, quelles erreurs seraient les plus graves et à quel moment une vérification humaine reste nécessaire. Ils doivent aussi faire remonter les besoins, afin que les équipes ne cherchent pas seules leurs solutions.

L’équipe informatique et le responsable de la sécurité informatique examinent les outils : comptes, données transmises, possibilité de retirer un accès et conditions du fournisseur. Les RH interviennent lorsque l’IA touche au recrutement, à l’évaluation ou à la formation. La fonction qualité ou QSE aide à inscrire les décisions dans des règles simples, à suivre les actions prévues et à vérifier qu’elles sont appliquées.

Cette répartition évite deux dérives. Une règle uniquement technique peut être trop éloignée du quotidien des métiers. À l’inverse, un outil adopté sans vérification peut fragiliser la sécurité de l’information. Lors d’un audit ISO 27001, il faut donc vérifier non seulement les règles, mais aussi qui les a décidées, comment elles sont expliquées et comment un problème est signalé.

L’objectif n’est pas de créer un comité pour chaque nouvel outil. Il est de prévoir un circuit court pour les usages simples, puis une validation plus complète lorsque des données sensibles, des clients ou des décisions importantes sont concernés. Les équipes disposent ainsi d’un cadre clair pour expérimenter sans mettre l’entreprise en difficulté.

Former les équipes pour éviter les erreurs les plus courantes

Une règle écrite ne suffit pas si les équipes ne savent pas reconnaître une situation à risque. Face à un outil d’IA, chacun doit pouvoir se poser quelques questions simples : puis-je lui transmettre cette information ? Dois-je vérifier sa réponseavant de l’utiliser ? À qui signaler un doute ? Sans ces repères, même une procédure bien conçue reste peu appliquée.

La formation doit partir de situations proches du quotidien. Une équipe commerciale peut apprendre à retirer les éléments confidentiels d’une demande client avant de demander une reformulation. Un service RH peut identifier les cas où l’IA ne doit pas trier ou noter des candidats sans intervention humaine. Les équipes techniques doivent vérifier tout code ou document produit avant sa mise en service.

L’enjeu n’est pas de faire de chaque salarié un spécialiste de la cybersécurité. Il est de donner à chacun les bons réflexes : ne pas saisir de données sensibles dans un outil non validé ; ne pas croire automatiquement une réponse ; ne pas utiliser un compte personnel pour une tâche professionnelle ; demander de l’aide avant de connecter un outil à un fichier ou à un logiciel de l’entreprise.

Les managers doivent expliquer pourquoi ces limites existent, montrer l’exemple et faire remonter les difficultés. Cette écoute compte : une interdiction qui ne répond pas aux besoins du travail sera contournée. À l’inverse, une règle claire, avec des outils autorisés et du temps de formation, renforce la confiance.

Dans un audit ISO 27001, la formation ne se résume pas à une liste de présence. Il faut montrer que les messages sont compris et appliqués : cas pratiques, rappels ciblés, questions des équipes ou corrections apportées après un incident. Cette preuve d’application transforme une consigne en protection réelle.

Auditer les usages de l’IA sans ralentir l’activité

Un audit sur l’IA ne consiste pas à passer en revue chaque demande faite à un outil. Cette méthode serait longue, intrusive et peu utile. L’objectif est plutôt de vérifier que l’entreprise connaît ses usages importants, applique des règles adaptéeset peut réagir lorsqu’un problème apparaît.

L’auditeur commence par choisir quelques situations représentatives. Il peut examiner un usage commercial, un usage RH, un usage technique et un usage lié à une information confidentielle. Pour chacun, il vérifie des points simples : l’outil a-t-il été choisi par l’entreprise ? Les personnes qui l’utilisent connaissent-elles les limites ? Les informations saisies sont-elles protégées ? Une personne relit-elle le résultat avant qu’il soit envoyé ou utilisé ?

Cette méthode permet de chercher des preuves concrètes. Une règle d’usage doit être accessible. Les outils autorisés doivent être connus. Les accès doivent pouvoir être retirés lorsqu’une personne quitte l’entreprise ou change de poste. Si un incident survient, les équipes doivent savoir qui prévenir et quoi faire. Ces éléments montrent que la sécurité ne repose pas sur une simple consigne affichée.

L’audit doit également regarder ce qui change. Un nouvel outil, une fonction ajoutée par un fournisseur ou une équipe qui commence à utiliser l’IA pour une nouvelle tâche peuvent modifier le niveau de risque. Une revue régulière permet alors d’ajuster les règles avant qu’un problème ne prenne de l’ampleur.

Le résultat attendu n’est pas une longue liste de défauts. Il s’agit d’un plan d’action clair : ce qui doit être corrigé vite, ce qui doit être mieux expliqué aux équipes et ce qui peut être amélioré dans les mois qui suivent. Cette approche donne à la direction une vision fiable des risques et aide les équipes à progresser sans arrêter les usages utiles.

Quand un logiciel ajoute une fonction d’IA, que faut-il vérifier ?

Une nouvelle fonction d’IA peut apparaître du jour au lendemain dans un logiciel déjà utilisé par les équipes. Résumé automatique, assistant de rédaction, aide à l’analyse ou recherche améliorée : ces options changent parfois les données envoyées à l’éditeur du logiciel. Avant de les activer, l’entreprise doit savoir ce qu’elles font réellement.

La première question est simple : quelles informations l’outil reçoit-il ? L’éditeur peut-il utiliser les contenus saisis pour améliorer son service ? Les données sont-elles conservées, et pendant combien de temps ? Il faut aussi vérifier où elles sont hébergées, quels prestataires interviennent et comment l’entreprise peut récupérer ou supprimer ses informations si elle cesse d’utiliser le service.

Le contrat, les conditions d’utilisation et les réglages disponibles apportent une partie des réponses. Mais ils ne suffisent pas. Il faut les confronter aux usages prévus. Un outil acceptable pour produire une présentation interne ne le sera pas forcément pour traiter une réclamation client, un dossier RH ou une information technique confidentielle. Cette distinction évite de choisir un outil sur la seule promesse de gain de temps.

Les éditeurs font évoluer leurs logiciels rapidement. Une fonction désactivée aujourd’hui peut devenir active par défaut demain ; une condition de conservation peut aussi changer. Prévoir une revue régulière permet de garder une maîtrise réelle. Cette revue peut être courte : vérifier les évolutions importantes, confirmer les personnes autorisées à utiliser l’outil et décider si les règles internes doivent être mises à jour.

Pour un audit ISO 27001, l’enjeu est de montrer que l’entreprise ne laisse pas son éditeur fixer seul son niveau de protection. Elle doit pouvoir démontrer qu’elle a choisi ses outils en connaissance de cause, qu’elle limite les usages sensibles et qu’elle réévalue ses choix lorsque les conditions changent. Cette vigilance protège les données, mais aussi la confiance des clients et des équipes.

FAQ : les questions à régler avant d’autoriser les usages d’IA