Sécurité et IA générative : bonnes pratiques et audits à mettre en place en PME

Quatre risques reviennent le plus souvent avec l'IA générative en PME : un prompt collé sans réflexion dans un outil grand public, un agent connecté aux systèmes internes avec des droits trop larges, une clé API oubliée dans du code généré, et l'absence de traçabilité des actions d'un agent. Aucun ne nécessite une équipe sécurité dédiée, mais tous demandent d'être identifiés avant, pas après, un incident.

Quels sont les risques de sécurité propres à l'IA générative en entreprise ?

Ces risques ne sont pas hypothétiques : ils découlent de la façon dont un outil IA générative est utilisé au quotidien, le plus souvent sans intention malveillante.

• La fuite de données via un prompt. Coller un extrait de contrat, une liste de clients ou des données personnelles dans un outil grand public non cadré par l'entreprise fait sortir ces données du périmètre habituel, sans garantie sur leur usage ultérieur.
• Des droits d'accès mal cadrés pour un agent connecté. Un agent branché à un système interne (messagerie, CRM, base de données) hérite souvent des droits du compte qui l'a connecté, plus larges que ce que sa tâche exige.
• Des secrets exposés dans du code généré. Une IA qui écrit du code place volontiers une clé API en clair dans un fichier de configuration, un point détaillé dans l'article sur GitHub et .gitignore : ne jamais exposer ses clés API avec l'IA générative.
• L'absence de traçabilité des actions d'un agent. Sans journal des actions exécutées, impossible de savoir après coup ce qu'un agent a réellement lu, modifié ou envoyé.

Comment cadrer les droits d'un agent IA au strict nécessaire ?

Le principe du moindre privilège consiste à n'accorder à un agent que les droits indispensables à sa tâche, jamais plus par facilité. Un agent qui doit résumer des tickets support n'a besoin d'aucun droit d'écriture sur la base clients, ni d'un accès à la messagerie de la direction. Ce cadrage passe par les mécanismes d'autorisation présentés dans l'article mère Bases de données, OAuth, clés API : ce qu'il faut comprendre avant de coder avec l'IA : des jetons OAuth à portée limitée (lecture seule quand c'est possible), une clé API dédiée par intégration plutôt qu'une clé unique partagée, et des règles RLS côté base de données dès que plusieurs agents accèdent à la même table.

Pourquoi garder un humain dans la boucle sur les actions à enjeu ?

Un agent qui lit et résume ne présente pas le même risque qu'un agent qui envoie un email, modifie une donnée client ou déclenche un paiement. Sur ces actions à enjeu, une validation humaine avant exécution reste la protection la plus fiable : configurer l'agent pour qu'il propose l'action et attende une confirmation, plutôt que de l'exécuter directement, chaque fois qu'une erreur serait coûteuse à corriger.

Comment auditer régulièrement les accès et les clés actives ?

Un audit de sécurité IA en PME tient dans une revue périodique de trois listes simples, sans outillage complexe.

1. Les outils IA connectés aux systèmes de l'entreprise : quels comptes, agents ou intégrations ont un accès actif à la messagerie, au CRM, aux fichiers ou à la base de données.
2. Les clés API actives : leur date de création, leur dernière utilisation, et si elles correspondent encore à un usage réel.
3. Les droits accordés à chaque agent : est-ce que le niveau d'accès correspond toujours à la tâche pour laquelle il a été configuré, notamment après un changement de projet ou de prestataire.

L'ANSSI publie des recommandations de sécurité dédiées aux systèmes d'IA générative, utiles comme référence pour construire cette revue. Un rythme trimestriel suffit pour la plupart des structures, en resserrant la fréquence si de nouveaux agents sont ajoutés régulièrement.

Comment sensibiliser les équipes sans bloquer l'usage de l'IA ?

Interdire l'IA générative pousse les équipes à l'utiliser quand même, hors de tout cadre, avec des comptes personnels et sans traçabilité : c'est le pire scénario. La règle simple à répéter : ne jamais coller de données sensibles (clients, financières, RH, contrats) dans un outil grand public non cadré, et privilégier les outils validés en interne, en s'appuyant aussi sur les repères de la CNIL sur l'intelligence artificielle.

En pratique, quels réglages de sécurité connaître selon l'outil IA ?

Claude (Claude Code, Claude Cowork)

Claude Code demande une confirmation avant les actions sensibles (écriture de fichiers, commandes système) et permet de restreindre les outils et permissions accordés à un projet. Un skill ou un hook peut aussi bloquer systématiquement une action donnée (par exemple un git push direct) tant qu'un humain ne l'a pas validée.

ChatGPT et Codex

Codex peut créer, modifier et pousser du code dans un dépôt connecté : vérifier les permissions de l'intégration (lecture seule ou écriture, quels dépôts) avant de la connecter à un projet sensible. Pour l'usage quotidien de ChatGPT, distinguer le compte professionnel de l'entreprise, avec ses réglages de confidentialité propres, d'un compte personnel gratuit jamais utilisé pour des données de l'entreprise.

Antigravity (agent IDE Google)

Antigravity travaille avec un accès potentiel au terminal, aux fichiers et à Git de l'environnement de développement. La vigilance porte sur la revue systématique des commandes proposées avant validation, en particulier celles qui touchent à des identifiants ou à un dépôt distant, et sur la limitation des dossiers réellement accessibles à l'agent.

Aucun de ces réglages ne remplace un audit régulier : ce sont des garde-fous au moment de l'action, l'audit reste le moyen de vérifier après coup que rien n'a dérivé.