RSSI et IA : les outils que vos équipes créent, vérifiés avant d’être partagés

Quels sont les risques de l’IA générative en entreprise ?

Les risques se rangent en quatre familles. La première est la fuite d’informations : un collaborateur colle des données clients, salariés ou contractuelles dans un outil dont l’entreprise n’a pas validé les conditions. La deuxième est l’usage hors cadre, que l’on appelle souvent « IA fantôme » : des outils adoptés par les équipes sans que la sécurité le sache.

La troisième famille concerne ce que l’IA produit. Un outil écrit par une IA peut fonctionner en démonstration et laisser pourtant une page sans protection ou un accès trop large. La quatrième vient des attaques propres à ces systèmes. L’injection de prompt, qui consiste à glisser des consignes malveillantes dans un texte lu par l’IA, arrive en tête du classement 2025 de l’OWASP sur les risques des applications d’IA générative. En France, l’ANSSI a publié en avril 2024 des « Recommandations de sécurité pour un système d’IA générative ». Tout cela s’ajoute au cadre que le RSSI connaît déjà : RGPD, règlement européen sur l’IA, NIS2 ou DORA selon le secteur.

Comment sécuriser les outils créés par l’IA ?

Ne vous fiez pas à la bonne foi de l’auteur, ni à la qualité apparente du résultat. Les failles typiques sont simples : une page de réglages ouverte à quiconque connaît son adresse, un lecteur qui peut finalement modifier, un vrai fichier client laissé comme exemple, un mot de passe écrit en clair dans l’outil. Elles se repèrent par des vérifications répétables, faites à chaque mise en ligne et pas seulement la première fois : des tests automatiques, un contrôle de ce que chaque profil peut voir ou modifier et un essai dans un vrai navigateur, comme le ferait un utilisateur.

Ajoutez trois habitudes. Rangez les informations de chaque outil à part, pour qu’une faille dans l’un n’ouvre pas les autres. Gardez les versions, pour pouvoir revenir en arrière si une modification pose problème. Et nommez un responsable, car un outil sans Propriétaire est un outil que personne ne met à jour.

Comment contrôler l’accès aux outils internes ?

Appliquez le principe du moindre privilège : chacun reçoit le droit nécessaire à son travail, pas davantage. Trois niveaux suffisent dans la plupart des cas : lire, modifier et être responsable de l’outil. Un salarié qui consulte un planning n’a pas besoin de pouvoir changer les règles de calcul.

Côté connexion, évitez les mots de passe partagés, qui ne disent pas qui a fait quoi. Une connexion par e-mail ou par OAuth (Google, Microsoft, etc.), réservée à une personne invitée nommément, laisse une trace claire et s’éteint quand l’invitation est retirée. Relisez la liste des invités à intervalles réguliers, surtout après un départ ou un changement de poste.

Que contrôler avant d’ouvrir un outil interne à toute l’équipe ?

Avant l’ouverture, posez cinq questions. Quelles informations l’outil contient-il et sont-elles sensibles ? Qui est invité, avec quel rôle ? Qui en est Propriétaire et un remplaçant est-il prévu ? Une version précédente est-elle conservée en cas de problème ? L’outil a-t-il été essayé par une personne qui n’est pas son auteur ?

Pour un outil qui traite des données personnelles, vérifiez en plus qu’il figure dans le registre des traitements. Faites tenir cette liste de questions sur une page : elle sera utilisée, alors qu’un long protocole restera dans un tiroir.