Faut-il adapter sa PSSI à l’intelligence artificielle ?

La politique de sécurité des systèmes d’information (PSSI) est LE document de référence pour la sécurité de votre entreprise. C’est elle qui va définir les objectifs à atteindre, les règles à respecter et les mesures à mettre en œuvre pour y parvenir. Fondée sur l’analyse des risques, elle constitue la base de la sécurité du système d’information.

Une fois validée par la direction, elle est diffusée auprès des acteurs concernés et mise en application. Elle permet également de formaliser l’organisation de la sécurité du SI, les responsabilités de chacun, les risques identifiés et les mesures mises en œuvre pour s’en prémunir.

Toutes les entreprises devraient en avoir une.

Mais en 2026, la PSSI que vous avez mise en place en 2024 est-elle encore valable ? Est-elle adaptée à l’implémentation des agents IA et d’une manière générale à l’utilisation de l’IA en entreprise ? Probablement pas. Et pourtant, l’arrivée de l’IA en entreprise ne rend pas obsolètes les principes de base (gestion des identités, moindre privilège, classification des données, journalisation, etc.). En revanche, l’IA va introduire de nouveaux comportements et de nouveaux risques. Pour autant, faut-il créer une PSSI entièrement nouvelle pour l’IA ou adapter celle existante ?

Le CLUSIF (Club de la sécurité de l’information français, association loi 1901), a publié en 2025 un modèle de PSSI pour l’IA. C’est un bon point de départ et de référence. Mais les évolutions de l’IA depuis sa publication nécessitent certains ajustements. Notamment les agents IA qui introduisent une capacité d’action et de délégation au sein des systèmes d’information. 

Une PSSI conçue avant l’arrivée de l’IA est-elle dépassée ?

Votre PSSI mise en place couvre déjà beaucoup de sujets qui sont directement applicables à l’IA :

• Gestion des identités et des accès
• Principe du moindre privilège
• Classification et protection des informations
• Recours aux prestataires et externalisation
• Développement sécurisé
• Journalisation et traçabilité
• Gestion des changements
• Réponse aux incidents

Une IA utilisant les ressources et l’infrastructure reste donc une composante du SI de l’entreprise. L’enjeu est donc d’identifier ce que l’IA ajoute au système d’information : de nouveaux actifs à protéger, de nouveaux risques à prendre en compte et, dans certains cas, de nouvelles capacités d’action à encadrer.

Ce que l’IA ajoute réellement au périmètre de sécurité

L’IA, de par sa conception, apporte de nouveaux actifs à protéger :

• Quels modèles sont utilisés ? La cartographie des IA doit identifier les modèles utilisés
• Où les IA sont-elles hébergées : dans le Cloud, en local ou en mode hybride ? Les conditions d’accès aux données devront notamment tenir compte du mode d’hébergement de l’IA
• À quelles données a-t-elle accès ? Indépendamment du type d’hébergement, les données accessibles et avec quels droits (lecture, écriture, …) doivent être identifiées
• Quels sont les prompts système employés ? Qui les crée ? Les valide ? Sont-ils référencés ?
• Accède-t-elle à une base de connaissance ? Si oui dans quel but ?
• Quelles sont les configurations paramétrées ? Les IA doivent-elles mémoriser des données, des processus ? Utilisent-elles des API internes ou externes ?

Ces questions sont les mêmes que vous devez vous poser dans la gestion traditionnelle des fournisseurs et prestataires, mais adaptées à l’IA. Et tout comme eux, l’IA peut avoir des défaillances :

• Manipulation de données
• Exfiltrations
• Dérives comportementales
• Modifications des instructions, processus

Ces risques liés à l’IA viennent compléter des scénarios déjà existants, avec des impacts potentiels tout aussi importants qu’avec des humains. Sauf que selon les IA que vous utilisez, les conséquences ne sont pas toujours les mêmes.

Le Shadow IA : ce que la PSSI ne peut protéger si elle ne le connaît pas

La PSSI IA doit prendre en compte ce problème. L’utilisation de services IA non référencés ou non autorisés peut échapper aux règles définies par l’entreprise. Et le souci n’est pas limité à la fuite de données. L’inventaire des usages, l’identification des fournisseurs, les conditions contractuelles, les comptes utilisés et les fonctionnalités auxquelles les collaborateurs donnent accès sont autant de sujets à traiter. La PSSI ne pourra répondre aux usages de l’IA que pour les IA qu’elle autorise.

La PSSI devrait donc définir les services IA autorisés et leurs conditions d’utilisation. Les autres usages devraient être considérés comme non autorisés.

J’aborde plus en détail le Shadow IA dans cet article : https://laurent-ia.fr/shadow-ia/

Le code produit par IA

Les règles DevSecOps doivent s’appliquer au code généré par IA. Il ne doit en aucun cas bénéficier d’un régime particulier et le processus de base doit être appliqué comme pour un code créé par un humain :

1. Revue
2. Tests
3. Analyse de sécurité
4. Validation

La génération de code par IA fait gagner du temps mais ne doit pas faire oublier les principes fondamentaux du développement.

L’IA cachée dans un logiciel déjà autorisé

Un logiciel déjà implémenté et utilisé en entreprise depuis plusieurs années peut, du jour au lendemain, intégrer de nouvelles fonctionnalités IA à l’occasion d’une mise à jour ou de l’évolution d’une offre. Dans ce cas, il est impératif que le fournisseur dudit logiciel puisse répondre à ces questions :

• Quelle fonctionnalité IA a été ajoutée ?
• Est-elle activée par défaut ?
• Quelles données peut-elle traiter ?
• Ces données quittent-elles l’entreprise ?
• Quel fournisseur ou sous-traitant les traite ?
• La nouvelle fonctionnalité IA peut-elle accéder aux mêmes données et ressources que le logiciel qui l’intègre ?

La DSI doit également se poser la question de savoir si l’analyse des risques réalisée lors de l’adoption du logiciel est toujours valable.

Dans tous les cas, quand un éditeur de logiciel annonce une nouvelle fonctionnalité liée à l’IA, une période de tests et une validation du changement en CAB doivent s’appliquer. C’est la règle dans une PSSI traditionnelle qui s’applique également ici.

La problématique des IA agentiques

On vient de le voir, beaucoup de règles existantes dans une PSSI traditionnelle sont transposables dans une PSSI adaptée à l’IA. Mais avec les agents IA les choses se corsent.

Une IA générative classique va produire de la documentation, du code ou des images, des productions qu’un humain réalisait déjà auparavant. Ces tâches étaient déjà encadrées par une PSSI, l’adapter à une IA générative n’impose pas de grands changements, voire pas du tout.

Pour les agents IA ce n’est plus le cas. Le spectre des actions possibles est beaucoup plus large :

• Consulter une ressource
• Appeler un outil
• Modifier une donnée
• Envoyer une information
• Exécuter une opération
• Enchaîner plusieurs actions

Le sujet n’est donc plus uniquement ce que le modèle sait ou répond mais ce que le système lui permet de faire. Cette autonomie pour réaliser des actions complexes et agir sur le SI fait dès lors de l’agent un sujet d’identité, d’habilitation et de délégation.

L’agent IA doit avoir une identité propre

Un agent ayant accès au SI devrait donc disposer d’une identité technique identifiable, ou d’un mécanisme équivalent permettant d’attribuer précisément les actions qu’il réalise. L’utilisation de comptes génériques partagés entre plusieurs agents peut rendre cette attribution impossible. Par exemple :

service_ia.agent1@entreprise.fr

Si demain, dans les logs, on voit ceci :

service_ia.agent1@entreprise.fr a supprimé le fichier X à 14 h 32

On sait immédiatement quel agent a supprimé le fichier X, sans avoir à chercher pendant des heures ou des jours pour identifier l’origine de cette action.

Le principe du moindre privilège

Un agent IA peut avoir besoin d’accéder à des ressources déjà considérées comme sensibles par la PSSI :

• Messagerie
• Bases de données
• Espaces documentaires
• Applications métier
• Outils d’administration
• Journaux techniques et de sécurité
• SIEM et outils de supervision

Et accorder à une IA le droit d’analyser une information ne justifie pas automatiquement qu’elle ait un accès complet à cette information. Tout comme lire une boîte aux lettres ne doit pas autoriser à envoyer un message, consulter un fichier ne signifie pas avoir le droit de le modifier et préparer une opération n’est pas l’exécuter.

Un risque mal décrit par les PSSI : l’injection d’instructions

Quand vous demandez à un agent de traiter :

• Un document
• Une page Web
• Un email
• Une base documentaire
• Un résultat fourni par un autre outil

Vous ne savez pas ce que ces éléments contiennent réellement. Une instruction hostile peut y être contenue sans que vous le sachiez mais que l’agent IA lira. Et exécutera. Ce risque s’est notamment matérialisé en 2025 avec EchoLeak (CVE-2025-32711), une vulnérabilité de Microsoft 365 Copilot permettant, dans certaines conditions, à des instructions malveillantes contenues dans un email de provoquer l’exfiltration de données auxquelles la victime avait déjà accès.

Un contenu non fiable traité par un agent IA avec des permissions importantes et une capacité d’action élevée peut vite se révéler être une source de problèmes. La fiabilité des données utilisées par un agent IA est donc un point à intégrer dans la PSSI IA.

J’aborde plus en détail la sécurité des agents IA dans cet article : https://laurent-ia.fr/securite-agents-ia/

Journaliser la réponse n’est pas suffisant

Une journalisation proportionnelle et compatible avec la protection des données est nécessaire. Les procédures classiques de réponse aux incidents restent valables mais il faut s’assurer qu’elles permettent de :

• Révoquer les accès
• Invalider les secrets
• Couper les connecteurs
• Retirer les capacités d’action
• Suspendre l’agent concerné

En cas d’incident, la suspension d’un agent ou la révocation de ses accès doit pouvoir être déclenchée depuis un mécanisme indépendant de l’agent lui-même.

La PSSI peut-elle encore évoluer au même rythme qu’avant ?

À la base, une PSSI n’est pas un document figé. Elle se doit d’évoluer et d’être adaptée aux besoins de l’entreprise ainsi qu’aux évolutions technologiques. Et l’IA, avec ses évolutions particulièrement rapides, pose la question du rythme auquel certaines dispositions doivent être réévaluées.

L’utilisation de l’IA dans une entreprise apporte plusieurs changements potentiels :

• Un nouveau modèle
• Une nouvelle fonctionnalité IA dans un logiciel existant
• Un nouveau fournisseur
• Une nouvelle source de données
• L’ajout d’un connecteur
• Une nouvelle capacité d’un agent
• Un nouveau type d’usage interne
• Une nouvelle classe de menace

Il importe donc d’effectuer une révision régulière des éléments qui peuvent déclencher une réévaluation sans attendre une prochaine échéance planifiée. Dès lors, on peut se poser la question :

« Une PSSI revue une fois par an suffit-elle encore lorsque les capacités des outils qu’elle encadre peuvent évoluer plusieurs fois dans l’année ? »

Adapter plutôt que repartir de zéro

Les grands principes de la PSSI restent valables dans une PSSI adaptée aux IA :

• Identité
• Moindre privilège
• Classification
• Fournisseurs
• Journalisation
• Incidents
• Développement sécurisé

Ces principes ne changent pas et sont toujours présents. Ce qui doit être étendu, ce sont les éléments propres à l’IA :

• Inventaire des actifs IA
• Analyse des risques liés à l’IA
• Supply Chain
• Gestion des changements impliquant de l’IA
• Journalisation et protection des secrets

À cela il faut ajouter de nouveaux usages qui peuvent échapper à un inventaire traditionnel :

• Shadow IA
• Fonctionnalités IA ajoutées à des logiciels déjà autorisés

Et faire évoluer l’analyse de risques et certaines dispositions de la PSSI lorsque les capacités, fournisseurs, données ou usages IA changent.

Les ajouts les plus spécifiques sont finalement liés aux capacités des agents IA :

• Identité propre de l’agent IA
• Permissions par outil et capacité
• Contrôle des actions critiques
• Injection indirecte
• Traçabilité de la chaîne d’action
• Possibilité de confinement

Dans la plupart des cas, il s’agit donc moins de créer une nouvelle PSSI que d’adapter celle qui existe déjà aux nouvelles exigences de l’IA.

Conclusion

Avant de mettre à jour votre PSSI, la question à se poser est : que couvre-t-elle aujourd’hui ? Qu’est-ce que l’arrivée de systèmes capables d’interpréter, de décider et parfois d’agir vous oblige à ajouter ?

Les agents IA nous rappellent surtout qu’avant de déléguer une tâche à une machine, il faut être capable de répondre précisément à ces questions :

1. Quel agent ?
2. Pourquoi faire ?
3. Où ?
4. Quand ?
5. Comment ?

Finalement, l’arrivée des agents IA change-t-elle les principes de sécurité, ou nous oblige-t-elle surtout à les appliquer à une nouvelle catégorie d’acteurs du système d’information ?

Sources

Site du CLUSIF : https://clusif.fr

Vidéo de NoLimitSecu « Un modèle de PSSI pour l’IA » : https://youtu.be/wvBJzqFSB_k?si=-eBW9VRx3MhXPGdb

Site de l’ANSSI « Posture générale et actions de l’ANSSI sur l’IA » : https://cyber.gouv.fr/enjeux-technologiques/intelligence-artificielle/

Microsoft Security Insider : https://www.microsoft.com/fr-fr/security/security-insider/emerging-trends/ai-application-security-considerations-for-organizations

Pour aller plus loin

Je traite certains sujets abordés ici plus en détail dans ces articles :

Agents IA : https://laurent-ia.fr/securite-agents-ia/

IA Act : https://laurent-ia.fr/ia-act-entreprises/

Le Shadow IA : https://laurent-ia.fr/shadow-ia/