Rédiger une politique d’usage de l’IA générative publique

Une politique d’usage de l’IA (Intelligence Artificielle) générative publique répond à trois questions : quelles données peuvent partir chez un fournisseur, par quel outil, et qui le vérifie. La plupart des chartes existantes n’en traitent qu’une, souvent sous forme d’interdiction générale, ce qui produit exactement l’inverse de l’effet recherché. La position défendue ici : une matrice courte qui croise la classification des données et les canaux autorisés, appliquée techniquement là où c’est possible et assumée comme déclarative ailleurs.

→ Lire l’explication complète de la marmotte

Classification des données et canaux d’IA générative : la matrice

Le prérequis non négociable est une classification des données qui existe déjà et que les gens appliquent. Sans elle, la politique repose sur le jugement de chaque utilisateur au moment de coller un texte, c’est-à-dire sur rien de vérifiable. Si la classification n’existe pas, c’est ce chantier-là qu’il faut ouvrir d’abord ; une politique d’IA ne le remplace pas.

Côté outils, trois canaux suffisent, et il faut résister à l’envie d’en inventer un quatrième :

Assistant grand public, compte personnel : aucune relation contractuelle, conditions modifiables unilatéralement, historique rattaché à une identité privée.
Offre entreprise sous contrat : comptes rattachés à l’annuaire de l’organisation, engagements écrits sur l’usage des données, administration centralisée.
API (Application Programming Interface) intégrée à une application interne : les données passent par un code maîtrisé, qui peut filtrer, journaliser et pseudonymiser avant l’envoi.

La matrice tient alors en douze cases. Données publiques : tout canal. Données internes : offre entreprise et API. Données confidentielles : API seulement, derrière un traitement qui retire les identifiants directs. Données de diffusion restreinte (secrets industriels, éléments d’enquête) : aucun canal public. Le compromis central est là : chaque niveau de granularité ajouté rend la règle plus juste et moins appliquée. Quatre niveaux croisés avec trois canaux restent mémorisables ; au-delà, les gens arrêtent de lire et reviennent à leur compte personnel. Vingt ans de chartes informatiques apprennent qu’une règle que personne ne retient est une règle que personne n’enfreint consciemment, ce qui ne l’empêche pas d’être enfreinte tous les jours.

La matrice doit aussi couvrir ce qui revient du modèle, pas seulement ce qui y entre. Une sortie d’assistant est un contenu non vérifié : du code à relire, un résumé à confronter à la source, un avis sans valeur de décision. Et tout document externe collé dans une conversation (courriel entrant, page web, pièce jointe) peut contenir des instructions cachées que le modèle suivra : la politique doit dire qu’un contenu externe ne se soumet à un assistant disposant d’outils ou d’accès internes qu’avec ces accès désactivés.

Registre des outils autorisés et critères d’inscription

La politique ne liste pas les outils dans son texte : elle renvoie à un registre versionné, tenu par la sécurité, que chaque nouvel outil rejoint après évaluation. Figer des noms de produits dans un document validé en comité garantit qu’il sera faux au trimestre suivant.

Le point que les politiques oublient : un outil déjà inscrit change de classe de risque quand le fournisseur active une fonction. La mémoire persistante, les connecteurs vers une messagerie ou un stockage de fichiers, le partage de conversations par lien : chacune modifie ce qui sort de l’organisation, et chacune fait l’objet d’une page dédiée sur le site. Le registre doit donc enregistrer les fonctions autorisées par outil, pas seulement l’outil, et prévoir une revue à chaque annonce produit du fournisseur. Côté slide commerciale, la fonctionnalité s’appelle « productivité augmentée » ; côté registre, elle s’appelle « nouveau flux sortant non évalué ».

Exemple : politique de classification en YAML

Le fichier suivant sert de source unique à trois consommateurs : la page intranet générée pour les utilisateurs, la configuration du proxy de sortie, et le contrôle d’intégrité du registre en revue trimestrielle. L’intérêt d’un format machine est d’éviter que ces trois vues divergent.

# politique-ia-generative.yaml : source unique de la matrice classification x canal
version: 2026-09-29           # date de validation, reprise dans la page intranet
proprietaire: [email protected] # responsable de la revue, pas une liste de diffusion

canaux:
  grand_public:               # compte personnel, aucun contrat
    authentification: aucune_maitrisee
  entreprise:                 # offre sous contrat, comptes de l'annuaire
    authentification: annuaire_entreprise
    fonctions_autorisees: [chat, analyse_fichier]
    fonctions_interdites: [memoire_persistante, connecteurs, partage_public]
  api_interne:                # appel depuis une application maîtrisée
    pretraitement: pseudonymisation   # identifiants directs retirés avant envoi
    journalisation: requete_et_reponse

# niveau de classification -> canaux autorisés
matrice:
  public: [grand_public, entreprise, api_interne]
  interne: [entreprise, api_interne]
  confidentiel: [api_interne]
  diffusion_restreinte: []    # aucun canal public, pas d'exception possible

exceptions:
  duree_max_jours: 90         # une exception sans date de fin devient la règle
  validation: [responsable_metier, securite]

Le champ exceptions compte plus que la matrice elle-même : une politique sans voie de dérogation documentée génère des dérogations non documentées.

Faire appliquer la politique sans la rendre inapplicable

L’application se découpe en trois couches, et il faut accepter qu’aucune ne soit complète.

La couche technique vit au proxy de sortie ou dans un CASB (Cloud Access Security Broker) : blocage des domaines d’assistants hors registre, distinction entre le locataire entreprise et les comptes personnels sur un même domaine (par en-tête de restriction de locataire quand le fournisseur le propose), et règles de DLP (Data Loss Prevention) sur les motifs reconnaissables (numéros de carte, IBAN (International Bank Account Number), étiquettes de classification présentes dans les documents). Ce que cette couche ne voit pas : le texte retapé à la main, la capture d’écran, le téléphone personnel sur le réseau mobile. La DLP arrête les accidents, pas les gens déterminés.

La couche déclarative porte le reste : formation courte centrée sur la matrice, rappel à l’ouverture de l’outil, signalement sans sanction des envois accidentels. Le signalement volontaire est la seule source d’information sur ce que la technique ne voit pas, et il disparaît au premier blâme public.

La troisième couche est l’offre elle-même. Une interdiction sans alternative sous contrat pousse l’usage vers les comptes personnels, sujet traité à part sous l’angle de la détection de l’IA fantôme. La règle opérationnelle : ne jamais interdire un canal avant d’avoir ouvert celui qui le remplace. Côté exploitation, la politique suppose une revue du registre au moins trimestrielle, des journaux de proxy conservés assez longtemps pour reconstituer un envoi signalé, et une reprise du fichier de politique à chaque changement de fournisseur. Les rubriques Gouvernance et Facteur humain détaillent le cadrage et la conduite du changement, et la page Observer un LLM (Large Language Model) en production couvre la journalisation côté API.

🐝 Ce qui arrive si on s’en passe

Sans politique écrite, un envoi de données clients dans un assistant grand public n’est ni une faute ni un incident : rien ne permet de le qualifier. La réponse à incident n’a pas de critère de déclenchement, le délégué à la protection des données ne sait pas s’il doit évaluer une violation au sens du RGPD (Règlement général sur la protection des données), et la notification éventuelle à l’autorité démarre sans savoir quel outil, quel compte ni quelle durée de conservation sont en cause. L’absence de règle ne supprime pas le risque, elle supprime la capacité à le constater.

🦫 Explication de la marmotte 🍫

Les assistants d’intelligence artificielle qu’on trouve sur Internet sont des services qui tournent chez une autre entreprise. Tout texte qu’on leur donne quitte donc l’organisation et part sur des serveurs qu’elle ne contrôle pas. Une politique d’usage sert à décider ce qui a le droit de partir, et par quel chemin. Elle commence par un classement des informations en quatre niveaux : publiques, internes, confidentielles, et très sensibles. Elle distingue ensuite trois façons d’utiliser un assistant : avec un compte personnel sans contrat, avec un compte fourni par l’organisation et encadré par un contrat, ou à travers un programme interne qui nettoie les données avant de les envoyer. Pour chaque niveau, la politique indique les chemins permis ; les informations très sensibles n’en ont aucun. Pour la faire respecter, un équipement sur le réseau bloque les sites non autorisés et repère certaines données reconnaissables, par exemple des numéros de carte bancaire. Il ne voit pas tout : un texte recopié à la main ou envoyé depuis un téléphone personnel lui échappe. C’est pourquoi la formation et le signalement des erreurs complètent le blocage. Enfin, si l’organisation interdit un outil sans proposer d’autorisation encadrée à la place, les salariés utilisent leurs comptes personnels, et le risque augmente au lieu de baisser.

Pages voisines

La citent

Rédiger une politique d'usage de l'IA générative publique

Elle cite