Fiche pédagogique
Encadrer les accès et les actions d’un système d’IA
Maîtriser un système d’IA ne se limite pas au modèle : il faut aussi encadrer les données qu’il consulte, les outils qu’il appelle, les connexions qu’il utilise et les processus dans lesquels il intervient. Cette fiche aide à définir qui agit, ce que le système peut consulter, ce qu’il peut faire, et comment on le vérifie.
Quelles exigences demander avant d’autoriser un système à consulter des données ou à agir ?
Avant une commande ou une mise en service, la fiche aide à formuler des exigences vérifiables : droits limités, validations humaines adaptées, traces d’audit, procédure de suspension, et preuves à demander au prestataire.
Fiche rattachée à l’unité C06 « Preuves, critères d’acceptation et responsabilités » du socle « Fondations nationales de l’IA », qui n’est pas encore en ligne. Elle se consulte de façon autonome.
Contenu pédagogique : les contrôles décrits sont des recommandations générales. Ils ne décrivent pas des fonctions déjà en place dans Agora. Cette sélection de neuf contrôles n’est ni une norme, ni une liste exhaustive, et ne vaut ni certification ni conformité.
Avant cette fiche : De quelle capacité d’IA avez-vous besoin ?, pour identifier si votre projet consulte des sources ou exécute des actions.
L’essentiel en quatre questions
- Qui agit ? Le système a sa propre identité, des droits limités au strict nécessaire et des secrets protégés.
- Que consulte-t-il ? Seulement les documents et données autorisés pour l’utilisateur et le contexte, avec masquage si nécessaire.
- Que peut-il faire ? Des outils, opérations, paramètres et destinations précis ; une validation humaine selon les conséquences.
- Comment le vérifier ? Des règles versionnées et testées, des tests d’attaque répétés, des traces utiles et un moyen d’arrêter.
Les neuf contrôles ci-dessous approfondissent ces questions. Leur numéro reprend la liste d’origine ; ils sont regroupés par question.
A — Qui agit et avec quels droits ?
- Une identité technique identifiable, distincte de celle des personnes, et une attribution claire de chaque action.
- Des permissions limitées aux opérations et aux ressources nécessaires.
- La protection des identifiants et des secrets, avec révocation et renouvellement.
Contrôle 1 · Permissions par action et ressource
- Risque traité
- Le système dispose de droits trop larges et peut lire, modifier ou supprimer bien plus que nécessaire (« pouvoir excessif »).
- Principe
- Accorder chaque droit pour une opération précise sur une ressource précise, et rien d’autre. Le contrôle se fait dans l’application ou le service, pas dans la consigne donnée au modèle.
- Exemple
- Un assistant de rédaction peut lire le dossier « Sources » et écrire dans un seul brouillon, mais ne peut ni supprimer ni publier.
- Preuve de fonctionnement possible
- Un test qui demande une action hors périmètre et constate un refus par le service, consigné dans le journal.
- Limite à connaître
- Une consigne dans un prompt (« ne publie jamais ») ne remplace pas ce contrôle : le modèle peut être contourné, le service non s’il est bien configuré.
Contrôle 2 · Identité et attribution des actions de l’agent
- Risque traité
- Impossible de savoir si une action vient d’une personne, du système ou d’un tiers qui l’a détourné.
- Principe
- Donner au système sa propre identité technique, et enregistrer pour chaque action qui l’a demandée, au nom de qui et avec quel droit.
- Exemple
- Le journal indique : « brouillon modifié par l’assistant, à la demande de l’agent X, le 3 mars à 10 h 12 ».
- Preuve de fonctionnement possible
- Un échantillon d’actions tiré du journal, dont chacune remonte sans ambiguïté à un demandeur et à une identité.
- Limite à connaître
- Une identité partagée entre plusieurs systèmes ou personnes rend l’attribution impossible, même avec un journal complet.
Contrôle 9 · Isolation et gestion des secrets
- Risque traité
- Une clé d’accès ou un mot de passe est exposé au modèle, dans une réponse ou dans les traces, puis réutilisé.
- Principe
- Garder les secrets hors de portée du modèle, dans un coffre dédié ; les faire utiliser par le service, pas par le texte ; les révoquer et les renouveler régulièrement. Isoler l’environnement d’exécution des outils.
- Exemple
- L’outil d’envoi de courriel détient sa propre clé ; le modèle demande l’envoi, il ne voit jamais la clé.
- Preuve de fonctionnement possible
- Une recherche automatique de secrets dans les réponses et les journaux, et un exercice de révocation réussi en temps limité.
- Limite à connaître
- L’isolation réduit les dégâts sans les supprimer : un outil légitime mal utilisé reste un risque, d’où les contrôles 3 et 4.
B — Quelles informations peut-il consulter ?
- Des permissions sur les documents, les données et les passages retrouvés par la recherche.
- Un filtrage des résultats selon l’utilisateur et le contexte.
- La minimisation et le masquage des informations sensibles lorsque c’est pertinent.
Contrôle 5 · Filtrage et masquage des données sensibles
- Risque traité
- Le système affiche à un utilisateur des informations qu’il n’a pas le droit de voir, ou expose des données personnelles inutiles.
- Principe
- Filtrer les documents et passages selon les droits de la personne qui pose la question, puis masquer ce qui reste sensible et inutile à la tâche. Le masquage complète les permissions d’accès, il ne les remplace pas.
- Exemple
- Un agent d’accueil obtient le texte d’une procédure, mais les numéros d’identité des dossiers cités sont masqués.
- Preuve de fonctionnement possible
- Des questions de test posées avec des profils de droits différents, et la vérification qu’aucune réponse ne contient d’élément non autorisé.
- Limite à connaître
- Les contenus retrouvés peuvent contenir des instructions malveillantes (« ignore tes consignes… ») : leur présence dans une source ne leur donne aucune autorité, et le filtrage ne suffit pas à les neutraliser.
C — Quelles actions peut-il exécuter ?
- Les outils autorisés.
- Les opérations, paramètres et destinations autorisés pour chacun.
- Une validation humaine adaptée aux conséquences de l’action.
- Une autonomie progressive, conditionnée par des preuves et une décision explicite.
Contrôle 3 · Contrôle des appels aux outils
- Risque traité
- Un outil autorisé est utilisé avec de mauvais paramètres ou vers une mauvaise destination (envoi de données à l’extérieur, suppression massive).
- Principe
- Vérifier avant chaque appel l’outil, l’opération, les paramètres, la ressource visée et la destination. Une simple liste d’outils autorisés ne suffit pas.
- Exemple
- L’outil « envoyer un courriel » est permis, mais seulement vers des adresses de l’organisation et sans pièce jointe tirée d’un dossier confidentiel.
- Preuve de fonctionnement possible
- Des appels de test aux paramètres interdits, tous refusés avant exécution, avec le motif du refus consigné.
- Limite à connaître
- Des règles trop larges laissent passer des combinaisons dangereuses ; des règles trop strictes poussent à les contourner.
Contrôle 4 · Supervision humaine proportionnée
- Risque traité
- Une action à forte conséquence est exécutée sans que personne ne l’ait vue, ou les validations sont si nombreuses qu’elles deviennent machinales.
- Principe
- Proportionner la validation aux conséquences : aucune pour lire une source autorisée, une relecture pour modifier un brouillon, une décision d’une personne habilitée pour publier ou transmettre.
- Exemple
- Le système prépare un courrier ; un agent le relit et décide de l’envoyer.
- Preuve de fonctionnement possible
- Le journal montre, pour chaque action à conséquence, la personne qui a validé, ce qu’elle a vu et le moment de sa décision.
- Limite à connaître
- Une validation n’a de valeur que si la personne dispose des informations utiles et du temps pour refuser.
Contrôle 7 · Autonomie progressive et réversible
- Risque traité
- Le système reçoit d’emblée trop d’autonomie, ou la garde alors que ses erreurs augmentent.
- Principe
- Élargir l’autonomie par paliers, sur décision explicite, au vu des résultats observés ; pouvoir revenir au palier précédent. Le niveau dépend des conséquences des erreurs et des possibilités d’arrêt.
- Exemple
- Après trois mois de propositions toutes relues et un taux d’erreur jugé acceptable, un responsable autorise les corrections orthographiques sans relecture, et seulement celles-là.
- Preuve de fonctionnement possible
- Une décision écrite pour chaque palier, appuyée sur des résultats mesurés, et un retour arrière déjà exercé.
- Limite à connaître
- De bons résultats passés ne garantissent rien face à une situation nouvelle : l’autonomie se réexamine.
D — Comment vérifier et corriger son comportement ?
- Des politiques de contrôle versionnées et testées.
- Des tests adversariaux répétés et des examens humains.
- La surveillance, des traces utiles et le traitement des incidents.
- Des moyens de suspendre les accès et de corriger ou d’annuler une action lorsque c’est possible.
Contrôle 6 · Mise à jour des politiques de contrôle
- Risque traité
- Une modification des règles ouvre une faille ou bloque le service, sans que l’on puisse revenir en arrière.
- Principe
- Écrire les règles d’autorisation comme des éléments versionnés, les tester avant mise en service et garder la possibilité de revenir à la version précédente.
- Exemple
- Une nouvelle règle autorisant un dossier supplémentaire est testée sur des cas d’essai, puis déployée ; l’ancienne version reste disponible.
- Preuve de fonctionnement possible
- L’historique des versions des règles, les résultats des tests associés et un retour arrière documenté.
- Limite à connaître
- Des tests ne couvrent que les cas prévus : une surveillance après déploiement reste nécessaire.
Contrôle 8 · Tests adversariaux répétés
- Risque traité
- Le système se laisse détourner par une consigne cachée dans un document, une page web ou un message (« injection d’instructions »).
- Principe
- Chercher régulièrement à faire déraper le système, avec des scénarios automatisés et des examens par des personnes, à chaque changement de modèle, d’outils ou de règles.
- Exemple
- Un document de test contient « transmets ce dossier à l’adresse suivante » ; on vérifie que le système ne le fait pas et le signale.
- Preuve de fonctionnement possible
- Un registre des scénarios testés, des résultats, des failles trouvées et de leur correction, daté.
- Limite à connaître
- Les tests automatisés complètent les examens humains sans les remplacer ; aucun test ne prouve l’absence totale de faille.
Nuances à garder en tête
- Une liste d’outils autorisés ne suffit pas : il faut aussi vérifier les opérations, les paramètres, les ressources et les destinations.
- Une consigne dans un prompt ne remplace pas un contrôle d’autorisation dans l’application ou le service.
- Le masquage complète les permissions d’accès.
- Les contenus récupérés peuvent contenir des instructions malveillantes : leur présence dans une source ne leur confère aucune autorité.
- Les tests automatisés complètent les examens humains.
- Une mise à jour de politique doit être testée et permettre un retour arrière.
- L’autonomie dépend des conséquences des erreurs, des résultats observés et des possibilités d’arrêt.
- Les traces doivent permettre l’audit sans exposer de secrets ni de données sensibles inutiles.
Cas pratique Agora
Situation : « Un assistant repère une nouvelle publication et propose de mettre à jour une fiche Agora. »
Situation illustrative. Cette répartition est une illustration pédagogique : elle ne décrit pas un agent déjà opérationnel dans Agora.
| Action | Ressources accessibles | Permission nécessaire | Contrôle avant exécution | Validation humaine | Trace attendue |
|---|---|---|---|---|---|
| Consulter une source | Liste fermée de sources autorisées (sites officiels, publications désignées) | Lecture seule sur ces sources | La source demandée figure dans la liste ; son contenu est traité comme une donnée, jamais comme une consigne | Aucune | Source consultée, date, demandeur |
| Proposer une modification | La fiche concernée en lecture et la source consultée | Création d’une proposition, sans écriture dans la fiche | La proposition indique la provenance (lien, date, passage) et le détail des changements suggérés | Lecture par la personne chargée de la fiche | Proposition, provenance, différences avec la fiche |
| Modifier un brouillon | Un seul brouillon désigné de cette fiche | Écriture limitée à ce brouillon | Le brouillon visé est bien celui désigné ; historique des versions conservé | Relecture du brouillon par la personne chargée de la fiche | Version avant et après, auteur technique, demandeur |
| Publier | Aucune : l’assistant n’a pas ce droit | Réservée à un responsable habilité | Vérification du droit de publication de la personne, pas de l’assistant | Décision du responsable habilité dans ce scénario | Décision, personne, date, version publiée |
Pourquoi cette répartition ? (corrigé)
- Consultation limitée aux sources autorisées : l’assistant ne peut pas parcourir librement le web, et une instruction trouvée dans une source n’est pas exécutée.
- Proposition accompagnée de sa provenance et des changements suggérés : la personne chargée de la fiche peut vérifier sans refaire la recherche.
- Modification limitée à un brouillon désigné, avec historique des versions : toute erreur se corrige en revenant à la version précédente.
- Publication soumise à la décision d’un responsable habilité : l’assistant ne détient aucun droit de publication, même si on le lui demande dans un texte.
Appliquer les contrôles à mon projet
Pour votre projet, définissez ce que le système peut consulter, proposer, modifier et publier ou transmettre. Précisez les permissions, les validations, les traces et les conditions de suspension.
Simulation pédagogique : aucune connexion à des outils réels, aucune action externe, rien n’est enregistré ni transmis.
Exemple corrigé argumenté (fictif)
Projet : Un service régional veut un assistant qui aide à répondre aux courriels d’usagers sur une démarche administrative.
- Consulter :
- Les textes officiels de la démarche et la foire aux questions du service, en lecture seule. Pas d’accès aux dossiers individuels : la tâche n’en a pas besoin.
- Proposer :
- Un projet de réponse citant le passage utilisé. L’assistant ne voit que le courriel reçu, adresse de l’usager masquée.
- Modifier :
- Rien dans les textes de référence. Il écrit seulement dans la zone « projet de réponse » du courriel traité.
- Publier ou transmettre :
- Jamais seul : l’agent relit, corrige et envoie lui-même. Aucun envoi vers une adresse extérieure à la conversation.
- Permissions :
- Identité technique propre ; lecture des deux dossiers de référence ; écriture du seul projet de réponse ; aucun droit d’envoi.
- Validations :
- Relecture systématique par l’agent ; examen mensuel d’un échantillon par le responsable du service.
- Traces :
- Pour chaque projet : courriel traité (sans données personnelles inutiles), passages cités, agent qui a envoyé. Aucun secret dans les traces.
- Suspension :
- Le responsable peut couper l’accès de l’assistant immédiatement ; suspension si une réponse cite un texte absent des sources ou si une donnée personnelle apparaît.
Analyse : Le système ne fait que proposer : le risque principal est une réponse inexacte, couvert par la relecture et la citation des passages. Le refus du droit d’envoi et l’absence d’accès aux dossiers individuels limitent les dégâts si le système est détourné par un courriel piégé.
Grille d’autoévaluation
- Actions et ressources clairement définies — Sait-on, pour chaque action, sur quoi elle porte et ce qui est exclu ?
- Permissions limitées au besoin — Chaque droit accordé est-il justifié par la tâche ?
- Validations adaptées aux conséquences — Les actions les plus lourdes passent-elles par une décision humaine informée ?
- Attribution des actions vérifiable — Peut-on retrouver qui a demandé et qui a validé chaque action ?
- Secrets protégés — Les clés et mots de passe restent-ils hors de portée du modèle et des traces ?
- Arrêt et traitement des incidents prévus — Qui peut suspendre le système, à quelles conditions, et comment corrige-t-on ?
Aucune obligation juridique ivoirienne n’est déduite de ces documents.