Charte IA en entreprise : un modèle d’usage en 12 règles

Une charte IA utile ne se contente pas d’interdire les données sensibles et de demander une relecture humaine. Elle dit qui peut utiliser quel outil, pour quelle tâche, avec quelles données, selon quel contrôle et vers qui se tourner lorsqu’un résultat pose problème.

Le document doit être court à lire, mais relié à des décisions plus précises. Une règle comme « vérifier les réponses » ne signifie rien si personne ne sait quels faits contrôler, quelle source ouvrir ou qui assume la décision finale. À l’inverse, une charte de vingt pages copiée sur un modèle juridique sera contournée si elle ne correspond pas aux pratiques réelles.

Le modèle proposé ici comporte douze règles, une matrice par rôle, dix scénarios de test et un plan de déploiement en quatre semaines. Il aide une direction, un référent IA, une équipe RH, un DPO ou un RSSI à produire une première version exploitable. Il ne remplace ni l’analyse juridique, ni la politique de sécurité, ni l’examen de chaque système utilisé.

Réponse en bref

Une charte IA d’entreprise doit répondre à douze questions :

1. qui est concerné et qui tient le document à jour ?
2. quels outils sont autorisés, tolérés ou interdits ?
3. quels usages peuvent être réalisés ?
4. quelles décisions ne doivent pas être déléguées ?
5. quelles données peuvent entrer dans chaque outil ?
6. comment réduire les informations transmises ?
7. comment vérifier une sortie avant de l’utiliser ?
8. qui approuve les effets sensibles ?
9. comment signaler l’assistance de l’IA lorsque c’est nécessaire ?
10. comment traiter sources, droits et réutilisation ?
11. que faire après une erreur ou un incident ?
12. comment former, tester et réviser les règles ?

La charte n’est pas une preuve automatique de conformité. Elle devient utile lorsqu’elle est reliée à un inventaire des outils, à des formations adaptées aux rôles, à des exemples testés, à un canal d’incident et à un historique de décisions.

Pourquoi formaliser les usages maintenant

La question n’est plus de savoir si quelques salariés essaient une IA générative. Elle consiste à distinguer les usages assumés des usages invisibles, puis à fournir une règle praticable avant qu’un document confidentiel, une décision concernant une personne ou une publication erronée ne révèle l’absence de cadre.

La Commission européenne rappelle que l’obligation de prendre des mesures en faveur de la maîtrise de l’IA s’applique depuis le 2 février 2025 aux fournisseurs et déployeurs concernés. Sa foire aux questions, mise à jour après les modifications entrées en vigueur à la mi-juillet 2026, précise qu’aucun niveau individuel unique ni certificat déterminé n’est imposé. L’approche doit tenir compte des connaissances, du rôle, du système et du contexte d’utilisation. La supervision prévue par le règlement commence au début du mois d’août 2026.

Cette actualité ne transforme pas une charte en certificat. La Commission indique qu’une organisation peut conserver un registre interne de ses formations et autres initiatives, mais qu’un exemple copié ne crée pas de présomption automatique de conformité.

La CNIL recommande de son côté d’encadrer l’utilisation d’une IA générative par des politiques ou chartes internes qui définissent clairement les usages autorisés et interdits. Elle demande aussi de partir de besoins concrets, d’examiner les risques, de former les utilisateurs et d’impliquer les fonctions compétentes.

Le bon objectif est donc plus simple : rendre les comportements attendus compréhensibles, applicables et vérifiables.

Ce qu’une charte peut faire, et ce qu’elle ne peut pas faire

Une charte peut :

• fixer une règle commune entre métiers, informatique, sécurité et direction ;
• rendre visibles les outils déjà utilisés ;
• définir des catégories de données et d’effets ;
• imposer un arrêt avant une décision sensible ;
• donner un canal pour demander une exception ou signaler un problème ;
• servir de base à une formation et à des exercices ;
• conserver les versions et les arbitrages.

Elle ne peut pas :

• rendre un outil sûr par déclaration ;
• remplacer le contrat avec un fournisseur ;
• décider seule si un traitement de données personnelles est licite ;
• garantir l’exactitude d’une sortie ;
• transformer une validation humaine décorative en contrôle réel ;
• couvrir un nouvel usage qui n’a jamais été analysé ;
• prouver qu’une règle est appliquée.

Une bonne charte est une interface entre plusieurs dispositifs. Les analyses de risque, contrats, paramétrages, listes d’accès, tests, formations et procédures d’incident restent leurs propres objets.

Avant d’écrire : inventorier les usages réels

Commencez par une table courte. Une ligne correspond à un usage, pas à un outil entier.

Rôle	Tâche	Outil	Données prévues	Personnes affectées	Effet final	Statut
communication	préparer trois variantes	assistant approuvé	informations publiques	lecteurs	brouillon	autorisé avec relecture
support	résumer une demande	outil à évaluer	message d’un client	client	préparation	pilote limité
RH	classer des candidatures	service grand public	données de candidats	candidats	pré-décision	interdit

Le statut peut rester simple :

• autorisé : usage défini, outil approuvé et contrôle disponible ;
• autorisé sous conditions : données, population ou effet limités ;
• pilote : périmètre et durée bornés, sans effet irréversible ;
• à analyser : décision manquante ;
• interdit : risque ou contexte incompatible.

Ce travail évite deux erreurs. La première consiste à autoriser « ChatGPT » en bloc alors que rédiger un brouillon public et analyser un dossier individuel n’ont pas le même risque. La seconde consiste à interdire tout usage, puis à laisser se développer une informatique fantôme sans alternative adaptée.

Si les pratiques réelles sont encore inconnues, commencez par l’audit du shadow AI en entreprise avant de figer les règles. Son inventaire distingue la tâche, les données, l’effet et les connexions sans demander de copier les conversations.

Les 12 règles du modèle

1. Nommer le périmètre et le propriétaire

La charte précise les salariés, prestataires, stagiaires ou partenaires concernés. Elle nomme une fonction propriétaire, un canal de question et une fréquence de revue.

Évitez « la direction surveille l’IA ». Écrivez qui reçoit une demande, qui peut arbitrer et qui publie la nouvelle version.

2. Tenir une liste des outils et configurations admis

Une marque ne suffit pas. Le même service peut exister en version gratuite, professionnelle, API ou instance dédiée, avec des conditions différentes de conservation et de réutilisation des données.

Pour chaque accès, conservez le propriétaire, la version ou l’offre, le mode de connexion, les fonctions activées, les catégories de données admises et la date de revue.

3. Décrire les usages autorisés par leur résultat

Autorisez des tâches comme « préparer un premier plan à partir d’informations publiques » ou « reformuler un texte déjà validé ». Une formule comme « usage professionnel raisonnable » demande à chacun d’inventer sa propre limite.

Ajoutez le résultat attendu et le contrôle : brouillon relu, synthèse comparée au document, code testé ou traduction validée par une personne compétente.

4. Écrire les usages interdits sans zone grise

La liste doit couvrir les décisions que l’organisation refuse de déléguer, les données qui ne peuvent pas être saisies, les outils non approuvés et les effets externes non autorisés.

Par exemple : décider seul d’un recrutement, envoyer automatiquement un message au nom d’une personne, produire une affirmation réglementaire sans vérification compétente ou contourner un contrôle d’accès.

5. Relier chaque outil à une classification des données

Utilisez les catégories déjà comprises dans l’organisation. À défaut, commencez par public, interne, confidentiel et données personnelles. La règle n’est pas « anonymiser avant envoi », car retirer un nom ne suffit pas toujours à empêcher une réidentification.

La CNIL recommande d’examiner le mode de déploiement, la réutilisation possible des données, l’hébergement, les transferts et le contrat. La catégorie autorisée dépend donc de l’outil et de sa configuration, pas seulement du texte du prompt.

6. Minimiser l’entrée avant de demander

L’utilisateur doit pouvoir expliquer pourquoi chaque information est nécessaire. Une synthèse structurée, un extrait limité ou un exemple fictif suffit souvent.

La règle pratique peut être : retirez les identifiants, les colonnes inutiles, l’historique complet et les pièces qui ne changent pas la réponse. Si l’usage exige encore une donnée sensible, arrêtez et demandez le circuit prévu.

7. Définir une vérification proportionnée

Une sortie destinée à l’idéation ne reçoit pas le même contrôle qu’un texte contractuel ou qu’un calcul financier. La charte doit relier la conséquence au niveau de vérification.

Usage	Contrôle minimal
idées internes	cohérence et respect du brief
synthèse d’un document	retour aux passages sources
fait externe	source primaire ouverte et datée
code	revue, tests et environnement isolé
décision concernant une personne	décision humaine compétente, critères autorisés et traçabilité adaptée

Le protocole de vérification d’une réponse IA fournit un contrôle court pour les usages ordinaires.

8. Placer l’approbation avant l’effet

« Un humain valide » doit devenir une étape précise : quelle personne, quelle version, quelles informations et quel délai ? L’approbation intervient avant l’envoi, la publication, le paiement, l’écriture dans un système ou une décision difficile à annuler.

Pour les workflows connectés, la validation doit être séparée de l’autorisation technique. Un bouton ne remplace ni les droits ni les contrôles du système cible.

9. Prévoir la transparence utile

Tous les brouillons n’exigent pas une étiquette publique. En revanche, l’organisation doit décider quand l’assistance de l’IA doit être signalée à un client, un partenaire, un lecteur ou une personne concernée.

La règle dépend du contexte, du rôle de l’IA, du risque de confusion et des obligations applicables. Évitez les mentions vagues qui donnent l’impression qu’aucune personne n’est responsable du contenu final.

10. Contrôler sources, droits et réutilisation

Une sortie fluide peut contenir un fait inventé, une attribution incorrecte ou un passage trop proche d’une œuvre. Demandez les sources lorsqu’elles sont nécessaires, ouvrez-les et conservez l’origine des éléments décisifs.

La charte doit aussi préciser qui peut réutiliser les prompts, modèles, documents, images et sorties, ainsi que les conditions propres au fournisseur et aux contenus d’entrée.

11. Donner une procédure d’incident courte

Un utilisateur qui a saisi la mauvaise donnée doit savoir quoi faire dans les minutes suivantes. Donnez un canal, les informations minimales à transmettre et les premières mesures : arrêter le partage, préserver les éléments utiles sans recopier le contenu, prévenir les fonctions compétentes et suivre leur décision.

Évitez de punir automatiquement le signalement. Une culture qui cache les erreurs réduit la capacité de correction.

12. Former, tester et réviser

La lecture de la charte n’est pas une formation suffisante pour tous les usages. Adaptez les exercices au rôle : vérifier une citation, classer une donnée, refuser une demande, traiter un incident ou superviser un outil.

Conservez les versions, les publics concernés, les actions réalisées et les décisions d’évolution. La Commission précise qu’aucun certificat unique n’est exigé par l’article 4, mais qu’un registre interne des formations ou initiatives peut documenter les mesures prises.

Le modèle prêt à adapter

CHARTE D’USAGE DE L’INTELLIGENCE ARTIFICIELLE
Version :
Propriétaire :
Champ d’application :
Canal de question ou d’incident :
Prochaine revue :

1. Outils
J’utilise uniquement les outils et configurations inscrits dans le registre interne.

2. Usages
Je limite l’usage aux tâches autorisées pour mon rôle et au résultat prévu.

3. Interdictions
Je ne délègue pas à l’IA une décision interdite et je ne contourne aucun contrôle.

4. Données
Je respecte la catégorie de données admise pour l’outil et l’usage concernés.

5. Minimisation
Je transmets uniquement les informations nécessaires à la tâche.

6. Vérification
Je contrôle la sortie selon sa conséquence avant toute réutilisation.

7. Approbation
J’obtiens l’approbation prévue avant un effet externe ou sensible.

8. Transparence
Je signale l’assistance de l’IA lorsque la règle ou le contexte l’exige.

9. Sources et droits
Je vérifie les sources, les droits et les conditions de réutilisation applicables.

10. Incident
J’arrête l’usage et j’utilise le canal prévu après une erreur ou une exposition.

11. Nouvel usage
Je demande une analyse avant d’utiliser un nouvel outil, une nouvelle donnée ou un nouvel effet.

12. Formation
Je réalise les exercices liés à mon rôle et j’applique la version en vigueur.

Ce modèle est volontairement court. Ajoutez en annexe le registre des outils, la matrice des usages et les procédures détaillées au lieu de transformer le texte principal en manuel technique.

Différencier les règles selon les rôles

Une personne qui reformule un texte public, une équipe RH et un développeur qui connecte une API ne doivent pas recevoir le même parcours.

Rôle	Doit savoir	Doit pouvoir faire	Doit savoir arrêter
utilisateur occasionnel	limites, données, vérification	réaliser un usage autorisé	entrée sensible ou sortie douteuse
manager	choisir un usage et un responsable	définir résultat et contrôle	bénéfice non prouvé ou effet mal attribué
référent IA	tenir le registre et organiser les tests	instruire une demande	outil ou usage non évalué
technique	permissions, erreurs, logs, dépendances	implémenter les contrôles	effet inconnu ou reprise dangereuse
DPO, RSSI, juridique	risques relevant de leur compétence	rendre un avis dans leur périmètre	information ou garantie insuffisante

Cette différenciation répond au principe de contexte rappelé par la Commission : le niveau d’action dépend des connaissances, de l’expérience, du système, du secteur, du but et des personnes affectées.

Tester la charte avec dix scénarios

Avant diffusion, demandez à plusieurs rôles de traiter ces cas :

1. un salarié veut résumer un document interne dans un service grand public ;
2. un manager propose de classer des candidatures ;
3. une personne copie une sortie factuelle sans source ;
4. un outil approuvé change ses conditions ;
5. un prestataire demande un accès temporaire ;
6. une équipe veut connecter l’assistant au CRM ;
7. une sortie semble reprendre un texte existant ;
8. une donnée personnelle a été saisie par erreur ;
9. un nouvel outil est essayé avec une adresse professionnelle ;
10. une publication préparée avec l’IA contient une erreur après diffusion.

Pour chaque scénario, observez : la règle trouvée, la décision prise, le canal utilisé, le temps nécessaire et l’information manquante. Si deux personnes raisonnables arrivent à des conclusions opposées, la charte ou son annexe doit être clarifiée.

Déployer la charte en quatre semaines

Semaine 1 : observer

Inventoriez les outils et cinq à dix usages réels. Recueillez les besoins sans demander aux équipes de justifier rétroactivement chaque essai. Repérez les données, les effets et les personnes concernées.

Semaine 2 : décider

Classez les usages, nommez les propriétaires et choisissez les outils admis. Faites relire les règles par les fonctions compétentes. Documentez les désaccords au lieu de les masquer par une phrase générale.

Semaine 3 : exercer

Testez les dix scénarios, organisez des ateliers par rôle et corrigez le vocabulaire incompris. Donnez une alternative aux usages interdits lorsqu’un besoin légitime existe.

Semaine 4 : activer et mesurer

Publiez la version interne, ouvrez le canal de question, conservez la trace des actions de formation et planifiez la première revue. Mesurez les demandes de clarification, les nouveaux usages, les incidents signalés et les contrôles réellement effectués.

Une baisse des signalements n’est pas toujours un succès. Elle peut indiquer que le canal n’est pas connu ou que les erreurs restent cachées.

Le dossier de preuve minimal

Conservez sans accumuler de données inutiles :

• la version datée de la charte ;
• l’inventaire des outils et usages ;
• les propriétaires et décisions ;
• les publics de formation ;
• les supports et scénarios utilisés ;
• les dates des actions réalisées ;
• les questions et évolutions significatives ;
• les incidents selon la procédure de sécurité ;
• la date et le motif de la prochaine revue.

Ce dossier montre un processus. Il ne certifie pas à lui seul la conformité d’un système ou d’un usage.

Limites

Ce modèle est un cadre opérationnel général. Il ne constitue ni un conseil juridique, ni une politique de sécurité complète, ni une analyse d’impact, ni un règlement intérieur prêt à annexer. Le droit applicable dépend du rôle de l’organisation, du système, des données, du secteur, de l’usage et des personnes affectées.

Les informations relatives à l’article 4 du règlement européen sur l’IA ont été vérifiées le 31 juillet 2026 sur la foire aux questions de la Commission. Les recommandations, autorités compétentes et modalités d’application peuvent évoluer. Toute affirmation réglementaire importante doit être relue sur la version officielle en vigueur et, si nécessaire, par une personne qualifiée.

Une charte ne réduit pas un risque si les outils réels restent inconnus, si les équipes n’ont aucune alternative ou si les contrôles ne sont pas testés. Elle doit rester reliée aux paramètres, contrats, droits d’accès, formations et procédures d’incident.

À propos de l’auteur

Je suis Ayoub Kahouadji, formateur et consultant IA. J’aide les équipes à transformer des usages dispersés en règles compréhensibles, exercices concrets et décisions de déploiement proportionnées.

Prochaine étape

Réunissez pendant quarante-cinq minutes un métier, un manager, l’informatique et la fonction chargée des données ou de la sécurité. Remplissez d’abord cinq lignes d’inventaire, puis testez les règles 2, 5, 7 et 11 sur un cas réel. Pour construire le parcours adapté aux rôles, consultez les formations en intelligence artificielle.