Deux politiques d’IA circulent dans les entreprises. La première tient en une phrase : « l’usage des outils d’IA générative est interdit ». La seconde fait quarante pages de principes éthiques sans une seule règle applicable.
Les deux produisent le même résultat : les usages continuent, hors de tout contrôle.
Commencer par mesurer, pas par écrire
Une politique rédigée sans connaître les usages réels vise des pratiques imaginaires et rate celles qui existent.
Les sources qui donnent une image utilisable sont les mêmes que pour le shadow IT : journaux DNS et de proxy, connexions par identité d’entreprise à des services tiers, extensions installées sur les navigateurs, abonnements en notes de frais.
Le chiffre obtenu — « 280 postes ont contacté au moins un service d’IA générative ce mois-ci » — est ce qui débloque l’arbitrage en direction, comme pour tout budget sécurité.
Ajoutez à cela les systèmes déjà présents sans avoir été identifiés comme tels : fonctions d’IA intégrées à des outils métier existants, tri automatique dans un logiciel de recrutement, détection comportementale dans une solution de sécurité.
Classer par usage, pas par technologie
C’est le principe structurant de l’AI Act, et il est opérationnellement juste : la même technologie n’appelle pas les mêmes règles selon ce qu’on en fait.
Une grille en quatre niveaux, alignée sur le règlement, suffit à la plupart des organisations :
Interdit. Usages relevant des pratiques prohibées, et usages que vous excluez pour vos propres raisons — par exemple toute décision individuelle prise sans intervention humaine.
Encadré strictement. Usages relevant du haut risque : décisions touchant l’emploi, l’évaluation des personnes, l’accès à un service. Ils supposent une supervision humaine effective, une journalisation, une information des personnes, et le plus souvent une analyse d’impact.
Encadré simplement. Assistants de productivité connectés à des données internes. Règles d’accès, de journalisation et de classification des données autorisées.
Libre. Usages sans donnée sensible ni décision : traduction de contenu public, aide à la formulation, brouillons.
Le quatrième niveau est important. Une politique qui ne comporte aucun usage libre sera contournée, parce qu’elle nie un gain de productivité que les gens constatent.
Les règles qui doivent figurer dans la politique
Sur les données
Une règle simple et mémorisable, adossée à votre classification existante. Par exemple : aucune donnée classée confidentielle ou personnelle dans un outil non validé.
Une règle que personne ne retient n’est pas appliquée. Trois lignes valent mieux qu’une matrice.
Sur la vérification
Ce qui est produit par un système d’IA doit être vérifié avant usage engageant : livrable client, réponse réglementaire, décision. La responsabilité reste celle de la personne qui signe.
Ce point mérite d’être écrit explicitement, parce qu’il tranche une ambiguïté que les gens se posent réellement.
Sur la transparence
Informer les interlocuteurs lorsqu’ils interagissent avec un système automatisé. C’est une obligation de l’AI Act pour certains usages, et une question de confiance dans tous les cas.
Sur les outils autorisés
Une liste, tenue à jour, avec un processus court pour en ajouter. Sans processus rapide, la liste devient obsolète et le contournement reprend.
L’instance d’arbitrage
Une politique sans lieu de décision se périme en six mois. Il faut quelqu’un pour trancher les cas nouveaux — et il y en aura.
Inutile de créer un comité dédié dans une organisation de taille moyenne : le comité sécurité existant peut absorber le sujet, à condition d’y adjoindre le juridique et un représentant métier.
Ce qui doit y remonter : les demandes d’ajout d’outil, les usages classés en haut risque, les incidents, et la revue annuelle de l’inventaire.
Les rôles à désigner
Trois responsabilités doivent être attribuées nominativement :
- Qui tient l’inventaire des systèmes d’IA utilisés et de leur classification.
- Qui valide un nouvel usage, et sous quel délai.
- Qui assure la supervision humaine pour les usages à haut risque — avec la compétence et l’autorité de s’opposer à une proposition du système. Une validation mécanique ne constitue pas une supervision.
Les questions à poser aux fournisseurs
À intégrer au processus d’achat, et à contractualiser — voir les clauses de sous-traitance :
- Les données transmises servent-elles à l’entraînement ?
- Où sont-elles traitées et conservées, et combien de temps ?
- Les droits d’accès de l’utilisateur sont-ils appliqués à la source au moment de la requête ?
- Quelles actions le système peut-il déclencher sans validation humaine ?
- Quels journaux sont disponibles et exportables ?
- Quelle documentation est fournie au titre de l’AI Act ?
La troisième question est celle qui met le plus souvent les fournisseurs en difficulté — voir pourquoi les assistants n’héritent pas des droits.
Articuler avec l’existant
Une politique d’IA autonome, déconnectée du reste, crée un silo de plus.
Elle doit s’articuler avec le registre des traitements — un système d’IA traitant des données personnelles y figure —, avec la classification des données, avec la gestion des fournisseurs, et avec le processus de gestion des changements.
Le plus simple, dans la plupart des cas, est d’ajouter un volet IA aux politiques existantes plutôt que de créer un corpus parallèle.
Ce qui fait échouer une politique d’IA
L’interdiction sans alternative. Produit du contournement immédiat et invisible.
Le délai de validation trop long. Quatre mois pour valider un outil signifie que personne ne demandera.
Les principes sans règles. « Nous utilisons l’IA de manière responsable et éthique » n’aide personne à décider s’il peut coller un contrat client dans un assistant.
L’absence de sanction et de pédagogie. Une politique jamais rappelée ni illustrée n’est pas connue. Deux cas concrets valent mieux que dix principes.
Sources
- Règlement (UE) 2024/1689 — AI Act
- NIST AI Risk Management Framework — fonctions gouverner, cartographier, mesurer, gérer
- CNIL — recommandations sur l’intelligence artificielle
- OWASP Top 10 for LLM Applications
- ISO/IEC 27002:2022, mesures 5.9, 5.10, 5.23 et 8.19
Aller plus loin
Nous construisons ces dispositifs en gouvernance, risques et conformité, et auditons les déploiements existants dans le cadre de l’audit 360.