Une responsable d’un centre de formation prépare une réponse à une entreprise intéressée par une session. Elle demande à son assistant IA de retrouver les places disponibles et l’offre validée. L’assistant propose alors de consulter aussi la liste nominative des inscrits. L’information existe peut-être dans l’outil, mais elle n’est pas nécessaire pour répondre au prospect.
Exemple fictif, outils et données simulés. Il illustre un contrôle à mettre en place, pas une fonction Pulse déjà déployée chez ce centre.
Le principe de moindre privilège consiste à donner à un système uniquement les accès nécessaires à une mission. Pour l’IA, cela ne concerne pas seulement les données : il faut aussi limiter les outils disponibles, les opérations permises, les dossiers accessibles et la durée de l’accès. OWASP décrit trois causes de l’autonomie excessive d’un agent : trop de fonctions, trop de permissions ou trop d’autonomie.
Transformer « aide-moi à répondre » en périmètre vérifiable
Dans ce scénario, l’assistant peut lire la capacité et les dates d’une session précise, ainsi que la version approuvée de l’offre. Il peut préparer une proposition de réponse à relire. Il n’a pas besoin d’ouvrir les dossiers des apprenants, de consulter la facturation, de modifier les inscriptions ni d’envoyer l’offre.
Voici la fiche d’accès de mission à remplir avant l’essai :
- Objectif : préparer une réponse sur la disponibilité de la session visée, sans engagement commercial automatique.
- Sources et champs : capacité disponible, dates, tarif de l’offre approuvée ; pas de liste nominative ni de dossier individuel.
- Opérations : lecture ciblée et proposition dans l’interface de revue ; aucune écriture dans les outils métier.
- Portée et fin : cette session et cette demande uniquement. Révoquer l’accès temporaire après la mission si l’outil le permet ; sinon, retirer manuellement l’autorisation inutilisée et prévoir sa revue.
- Responsable : la personne commerciale vérifie la source, le tarif, le destinataire et le texte avant toute suite.
La CNIL recommande de sélectionner les données strictement nécessaires dès la conception du système d’IA. Un assistant n’a pas à recevoir des données personnelles parce qu’elles se trouvent dans le même outil que l’information demandée.
Le vrai test : trois demandes qui doivent échouer
Avant d’ouvrir le pilote, essayez sur un environnement de test :
- Demander la liste des apprenants au lieu du nombre de places : la requête doit être refusée ou les champs nominatifs doivent être absents de la réponse.
- Demander les données d’une autre session : le contrôle du dossier autorisé doit rejeter la requête.
- Demander d’inscrire un participant ou d’envoyer l’offre : ces opérations doivent être indisponibles, pas simplement précédées d’un avertissement du modèle.
Le refus doit venir de l’application et de l’outil interrogé, avec une trace exploitable ; écrire « n’utilise pas cette fonction » dans les instructions de l’IA ne retire pas la permission technique. OWASP recommande de vérifier les autorisations dans les systèmes en aval plutôt que de confier cette décision au modèle. Une identité technique distincte et des droits revus régulièrement aident à voir qui a accédé à quoi ; AWS décrit cette séparation et l’usage de droits limités dans le temps pour les agents.
Attention : même en lecture seule, l’IA peut reformuler ou exposer à tort des données qu’elle a légalement reçues. La limitation des droits réduit la surface de risque ; elle ne remplace ni le filtrage des champs, ni la revue humaine, ni la protection des sorties. Aucun email n’est envoyé, aucune inscription effectuée, aucune tâche Cockpit créée et aucune écriture CRM réalisée sans validation humaine explicite. Si le tarif manque ou si deux versions de l’offre se contredisent, la réponse reste une proposition signalant l’incertitude.
À faire cette semaine : prenez une seule mission IA. Écrivez ce qu’elle peut lire et trois demandes qu’elle doit refuser ; testez les refus dans les outils, pas seulement dans la conversation avec le modèle. Si l’un d’eux passe, réduisez les droits avant d’élargir le pilote.
Pour définir les droits par outil, consultez la matrice CRM et emails ; pour comprendre qui exécute réellement un appel, lisez comment une API fonctionne avec une IA. Si vous souhaitez cadrer ce test pour vos outils, le Diagnostic Pulse peut servir de point de départ.