Agent IA de code : checklist RSSI avant un pilote

Assistant de code et agent de code : le niveau d’action change

Un assistant de code propose une complétion, explique une fonction ou génère un test. Le développeur choisit ensuite ce qu’il conserve. Un agent va plus loin : il décompose une tâche, explore le dépôt, écrit plusieurs fichiers, exécute des commandes et utilise parfois des outils externes.

Cette différence augmente le nombre d’actions possibles et la portée d’une erreur. La note publiée en juillet 2026 par la CNIL et le Conseil de l’IA et du Numérique décrit les caractéristiques qui rendent ces systèmes particuliers : autonomie décisionnelle, mémoire persistante, interaction avec plusieurs services et capacité d’agir au nom de l’utilisateur. Chacune ajoute un point de contrôle.

Le modèle n’est qu’une partie du système. La couche qui lui fournit du contexte, des outils et une mémoire détermine ce que l’agent peut voir et faire. Notre présentation de cette couche logicielle aide à comprendre cette mécanique. Pour le RSSI, la question utile devient : quelles données, quelles identités et quels outils cette couche met-elle à la portée du modèle ?

Pourquoi le modèle de menace s’élargit

Le code source contient souvent plus que de la logique applicative. Il révèle des noms de services, des architectures, des conventions internes et parfois des secrets qui n’auraient jamais dû être versionnés. Un agent peut aussi recevoir le contenu d’une issue, d’une documentation ou d’une sortie de commande. Une instruction malveillante placée dans l’une de ces sources peut tenter de détourner son objectif.

L’ANSSI et le BSI recommandent une analyse de risque avant l’introduction d’un assistant de programmation. Leur guide demande notamment de protéger les informations sensibles, d’utiliser des comptes d’entreprise contrôlés, de vérifier le code généré et de mesurer la charge supplémentaire supportée par les équipes AppSec et DevSecOps.

Les agents ajoutent les risques liés aux outils et aux permissions. L’OWASP Agentic Top 10 recense notamment le détournement d’objectif, le mauvais usage d’un outil, l’abus d’identité, la compromission de la chaîne d’approvisionnement et l’exécution inattendue de code. Le pilote doit tester ces chemins d’échec, pas seulement la qualité des réponses du modèle.

La checklist RSSI en 12 contrôles

Cette grille sert à préparer une décision. Une réponse vague compte comme une preuve manquante.

#	Question de contrôle	Preuve attendue	Signal de no-go
1	Le cas d’usage et les dépôts autorisés sont-ils nommés ?	fiche de pilote, propriétaire du risque, liste d’exclusions	pilote ouvert à tous les dépôts
2	Une analyse de risque spécifique existe-t-elle ?	scénarios de menace, risques acceptés, mesures compensatoires	confiance accordée à la seule documentation du fournisseur
3	Le trajet des données est-il connu ?	schéma des flux, régions, sous-traitants, rétention, usage pour l’entraînement	destination ou réutilisation inconnue
4	Les secrets et données sensibles sont-ils exclus ?	gestionnaire de secrets, caviardage, dossiers ignorés, scan préalable	clés présentes dans le contexte accessible
5	L’agent utilise-t-il une identité dédiée ?	droits lisibles, durée de vie courte, séparation dev/test/prod	compte humain partagé ou privilèges permanents
6	L’exécution est-elle isolée ?	environnement éphémère, limites système et réseau, nettoyage	exécution directe sur production ou poste sensible
7	Les outils et sorties réseau sont-ils contrôlés ?	liste d’outils, versions, destinations autorisées	ajout libre d’extensions ou accès Internet non borné
8	Les dépendances sont-elles vérifiées ?	registre approuvé, lockfiles, analyse des composants, SBOM si utile	installation automatique d’un paquet inconnu
9	Une personne approuve-t-elle chaque changement ?	branche dédiée, pull request, protection de branche, approbateur distinct	commit, push, merge ou déploiement autonome
10	Les contrôles suivent-ils le volume de code produit ?	tests, lint, SAST, analyse des dépendances, détection de secrets	hausse du débit sans capacité de revue suffisante
11	Les actions sont-elles attribuables ?	identité, commandes, outils, fichiers et décisions horodatés	impossible de reconstruire une action
12	Peut-on arrêter, révoquer et revenir en arrière ?	arrêt d’urgence, révocation, sauvegarde, retour à un état sain, procédure d’incident	aucun mécanisme testé d’arrêt ou de restauration

1. Borner le cas d’usage avant de choisir l’outil

« Aider les développeurs » ne définit pas un pilote. Choisissez des tâches précises : expliquer un module, proposer des tests, corriger un défaut borné ou préparer une migration sur un dépôt non critique. Nommez les équipes, les dépôts, les langages et les données exclus.

Cette première limite rend les autres décisions possibles. Les droits nécessaires pour générer des tests ne sont pas ceux d’un agent chargé de modifier une chaîne CI/CD. Si le périmètre bouge, l’analyse de risque doit être revue.

2. Cartographier les données réellement transmises

Demandez où passent les prompts, extraits de code, sorties de commandes, journaux et retours humains. Vérifiez leur durée de conservation, les régions de traitement, les sous-traitants, l’accès éventuel d’un opérateur et leur utilisation ou non pour l’entraînement.

Le lieu d’hébergement répond à une partie de la question. La qualification SecNumCloud, par exemple, porte sur un fournisseur et un périmètre de service définis. Elle ne qualifie pas automatiquement tous les logiciels exécutés sur cette infrastructure. Notre page SecNumCloud détaille cette distinction.

La CNIL recommande de minimiser les données, de contrôler les accès, de chiffrer les communications et de tracer les opérations. Pour un premier essai, des données fictives ou nettoyées permettent souvent d’évaluer l’outil sans exposer un dépôt sensible.

3. Traiter l’agent comme une identité technique

Créez une identité propre au pilote. Ses droits doivent être lisibles, temporaires et révocables. Séparez les environnements de développement, de test et de production. Évitez de transmettre au modèle des jetons ou des clés. Lorsqu’un outil a besoin d’un secret, le système doit l’injecter au moment de l’appel sans le placer dans le contexte du modèle.

Appliquez le moindre privilège à chaque capacité : lire un dépôt ne donne pas le droit d’écrire, écrire ne donne pas le droit de pousser, pousser ne donne pas le droit de fusionner, et aucun de ces droits n’implique un accès au déploiement. Un pilote ne doit pas dépendre de la prudence du modèle pour respecter ces frontières.

4. Isoler l’exécution et contrôler les outils

L’agent doit travailler dans un environnement que l’on peut recréer puis détruire. Limitez le processeur, la mémoire, la durée des commandes, les fichiers montés et les destinations réseau. Bloquez par défaut l’accès à la production, aux consoles cloud et aux services internes sans rapport avec le test.

Les extensions et serveurs d’outils entrent dans la chaîne d’approvisionnement. Tenez une liste approuvée, épinglez les versions et examinez les mises à jour. Vérifiez aussi les dépendances proposées par l’agent. Un nom de paquet plausible ne prouve ni son existence ni sa légitimité.

Les lignes directrices du NCSC et de ses partenaires demandent de protéger la chaîne d’approvisionnement, d’inventorier les actifs, de séparer les environnements sensibles et de choisir des réglages sûrs par défaut. Ces principes s’appliquent directement à l’environnement qui exécute l’agent.

5. Garder une revue humaine qui peut refuser

Le développeur doit comprendre le changement avant de l’accepter. Les tests automatiques ne remplacent pas cette responsabilité. Ils complètent la lecture du diff, l’analyse des dépendances, la détection de secrets et les contrôles de sécurité adaptés au langage.

Séparez la génération et l’approbation. L’agent peut préparer une branche et une pull request. Une personne identifiée décide ensuite de l’accepter, de la modifier ou de la fermer. Le pilote échoue si la pression de débit transforme cette revue en validation mécanique.

Mesurez également la charge déplacée. Si l’agent produit davantage de code mais augmente le temps de revue ou le nombre d’alertes, le bénéfice apparent disparaît. L’ANSSI et le BSI recommandent de suivre cette charge et de dimensionner les équipes de contrôle en conséquence.

6. Journaliser pour enquêter, puis prévoir l’arrêt

Conservez l’identité utilisée, les outils appelés, les commandes exécutées, les fichiers modifiés, les refus de permission et les validations humaines. Protégez ces journaux, car ils peuvent contenir du code ou des informations sensibles. Définissez une durée de conservation proportionnée au pilote.

Testez ensuite l’arrêt d’urgence. Pouvez-vous suspendre l’agent, révoquer ses identifiants, couper ses outils, annuler ses modifications et restaurer un environnement sain ? La procédure doit fonctionner avant l’incident. Un document non testé ne suffit pas.

Les preuves à demander au fournisseur

Un dossier de sécurité exploitable doit permettre de vérifier :

le schéma des flux, les lieux de traitement et la chaîne de sous-traitance ;
la conservation des entrées, sorties et journaux, ainsi que leur éventuel usage pour l’entraînement ;
les mécanismes d’identité, d’habilitation, de rotation et de révocation ;
les limites applicables aux fichiers, commandes, outils, extensions et accès réseau ;
les traces disponibles pour l’organisation et leur format d’export ;
les tests couvrant l’injection indirecte, la fuite de secrets, l’abus de permissions et l’exécution inattendue ;
la gestion des vulnérabilités, des mises à jour, des incidents et des limitations connues.

Une politique générale ne remplace pas les preuves correspondant à l’offre testée. Demandez ce qui change selon le modèle, la région, le mode d’hébergement et les options activées.

Un pilote de deux semaines qui produit une décision

Prenez un dépôt non critique et cinq à dix tâches représentatives. Nettoyez les données, créez une identité dédiée, placez l’exécution dans un environnement isolé et bloquez la production. Exigez une pull request et une revue humaine pour chaque modification.

Avant le premier test, mesurez le temps de réalisation et de revue sans agent. Pendant le pilote, suivez le taux de tâches acceptées après revue, les défauts introduits, les alertes de sécurité, les accès refusés, le temps de revue et la charge AppSec. Une évaluation sur des tâches reproductibles permet de comparer les résultats au lieu de retenir la meilleure démonstration.

La décision peut prendre trois formes :

go, si les contrôles sont prouvés et les objectifs atteints sans dégrader la sécurité ;
go sous conditions, si les écarts ont un propriétaire, une échéance et une mesure compensatoire ;
no-go, si le trajet des données, les permissions ou la capacité d’arrêt restent inconnus.

Questions fréquentes

Un agent IA de code peut-il accéder aux secrets ?

Il ne devrait pas recevoir un secret dans son contexte. Si un outil doit s’authentifier, utilisez une identité dédiée, des droits minimaux et des identifiants à durée de vie courte, injectés au moment de l’appel. Journalisez l’usage sans enregistrer la valeur du secret.

Faut-il interdire tout accès à la production ?

Oui pendant un premier pilote. Un besoin ultérieur doit faire l’objet d’une nouvelle analyse de risque, de droits distincts et d’une approbation humaine explicite. L’agent ne doit pas hériter de l’accès production du développeur qui le lance.

Quelles traces faut-il conserver ?

Conservez l’identité, les outils, les commandes, les fichiers touchés, les décisions de permission et les validations humaines. Fixez la durée selon le besoin d’audit et la sensibilité du contenu. Restreignez l’accès aux journaux et testez leur export avant le pilote.

Un hébergement souverain suffit-il à sécuriser l’agent ?

Non. Il peut réduire des risques juridiques ou de dépendance lorsqu’il couvre le bon périmètre. Il ne remplace pas le moindre privilège, l’isolation, la revue du code, la sécurité des dépendances, la journalisation ni la réponse à incident.

Agent IA de code en entreprise : la checklist RSSI avant un pilote