Référentiel
Référentiel de durcissement des agents IA personnels
Vos équipes vont en déployer de toute façon. Voici les sept points à fermer avant — dans l'ordre où ils se ferment.
Pourquoi ce référentiel
Les agents IA personnels open source comptent aujourd'hui parmi les projets les plus étoilés de GitHub. Un salarié peut en installer un sur son poste en une soirée et le brancher sur sa messagerie professionnelle — beaucoup l'ont déjà fait, sans que personne l'ait décidé. Les métriques à jour de ces briques sont suivies sur notre Radar.
Le problème n'est pas l'outil. C'est qu'un agent personnel branché sur les outils de l'entreprise cumule trois propriétés rarement réunies : il lit du contenu écrit par des tiers, il agit à votre place, et il se souvient. Chacune se gère ; les trois ensemble demandent une méthode.
Ce référentiel est cette méthode. Il ne dit pas quel outil choisir : il dit ce qu'il faut avoir fermé avant de brancher quoi que ce soit, et ce que nous vérifions quand nous le faisons pour un client.
D1 → D7
Les sept points de contrôle
Chaque point suppose le précédent : on n'audite pas la mémoire d'un agent qu'on n'a pas su journaliser, et on ne journalise pas ce qu'on n'a pas su isoler. L'ordre est notre méthode, pas une norme publiée.
- D1
Périmètre d'accès
- Le risque
- Un agent installé avec les droits de son utilisateur hérite de tout : la boîte mail complète, le drive partagé, les canaux internes. La première fuite n'est pas une attaque — c'est une lecture parfaitement légitime, au mauvais endroit.
- Ce que nous vérifions
- Un compte de service dédié, des droits accordés dossier par dossier et canal par canal, et une revue écrite de ce que l'agent peut atteindre. Jamais les identifiants personnels d'un salarié.
- D2
Isolation d'exécution
- Le risque
- Exécuté sur le poste d'un salarié ou sur un serveur partagé, l'agent devient un point de pivot vers le reste du réseau — et ses secrets vivent en clair à côté de ceux de la machine.
- Ce que nous vérifions
- Conteneur dédié, trafic sortant restreint aux domaines nécessaires, secrets injectés à l'exécution et jamais écrits dans un fichier de configuration ni dans un historique de conversation.
- D3
Surface d'attaque des entrées
- Le risque
- Un agent branché sur une messagerie lit du texte écrit par des tiers. Une consigne dissimulée dans un e-mail, une pièce jointe ou une page web devient une instruction : c'est l'injection de prompt, et elle sert à exfiltrer autant qu'à faire agir.
- Ce que nous vérifions
- Séparation stricte entre les instructions du système et le contenu reçu, liste blanche des expéditeurs et des canaux de confiance, et validation humaine obligatoire sur toute action sortante — envoi, paiement, publication, suppression.
- D4
Journal d'actions auditable
- Le risque
- Sans journal, une action de l'agent est indistinguable d'une action humaine. Après un incident, personne ne peut dire ce qui a été lu, écrit ou envoyé — ni prouver le contraire.
- Ce que nous vérifions
- Un journal horodaté, hors du périmètre d'écriture de l'agent, qui enregistre l'action, la donnée touchée et le mode de décision (automatique ou validé). Durée de conservation définie, et accès au journal séparé de l'accès à l'agent.
- D5
Arrêt d'urgence et reprise de la main
- Le risque
- Un agent qui boucle, se trompe de destinataire ou part sur une mauvaise consigne continue tant que personne ne l'arrête. « Couper le conteneur » n'est pas une procédure si personne ne sait qui a le droit de le faire un dimanche à 22 h.
- Ce que nous vérifions
- Un arrêt d'urgence documenté, testé, actionnable par une personne d'astreinte nommée — et l'état de ce qui a été fait avant l'arrêt, lisible sans redémarrer l'agent.
- D6
Mémoire persistante et RGPD
- Le risque
- La mémoire continue fait tout l'intérêt de ces agents et concentre leur risque : elle accumule des données personnelles — collègues, clients, patients — que personne n'a décidé de collecter. Le droit à l'effacement s'y applique, et une mémoire qu'on ne sait pas fouiller est une mémoire qu'on ne sait pas purger.
- Ce que nous vérifions
- Base légale et durée de conservation écrites, capacité démontrée à retrouver puis effacer les données d'une personne donnée, exclusion explicite des catégories sensibles, et inscription de l'agent au registre des traitements.
- D7
Maîtrise humaine
- Le risque
- Un agent confié à des équipes qui ne savent pas ce qu'il fait produit deux dérives symétriques : la confiance aveugle et le contournement clandestin. L'article 4 du règlement européen sur l'IA impose par ailleurs un niveau de maîtrise suffisant aux personnes qui l'utilisent.
- Ce que nous vérifions
- Une charte d'usage écrite — ce qui est permis, ce qui ne l'est pas, ce qui exige une validation —, une formation tracée des utilisateurs, et un référent nommé à qui remonter un comportement anormal.
Ce que ce référentiel ne dit pas
Il ne classe pas les outils. Ces projets évoluent chaque semaine ; une comparaison de fonctionnalités serait périmée avant d'être lue. Notre veille sur ces briques — licence, gouvernance, activité — vit sur le Radar, où elle est mise à jour automatiquement.
Il ne remplace pas une analyse d'impact. Un agent qui touche des données de santé, des données RH ou des données de mineurs relève d'obligations que sept points de contrôle ne couvrent pas.
Il n'est pas une norme. C'est un référentiel de cabinet, publié pour être repris et discuté. Si un point vous paraît mal placé dans l'ordre, l'argument nous intéresse.