Code source client et agents IA : comment encadrer Claude Code et Codex en ESN ?

La sécurité des agents IA de développement repose sur des autorisations explicites, des accès limités et des changements vérifiés. Dans une ESN, Claude Code ou Codex ne doivent pas recevoir du code client simplement parce qu'un développeur y a accès. Il faut aussi vérifier le contrat, le mode de traitement des données et les actions que l'outil peut exécuter.

Trois questions structurent le dispositif : que peut lire l'agent, où ces informations peuvent-elles circuler et quelles actions peut-il réellement effectuer ? Une bonne réponse doit être démontrée par la configuration et les tests, pas seulement écrite dans une charte.

Cadre opérationnel préparé avec assistance IA le 17 septembre 2026. Il ne constitue ni un audit de votre environnement ni un avis juridique. Les obligations applicables doivent être examinées avec vos responsables compétents. Illustration générée par IA.

1. Obtenir une autorisation adaptée au projet client

Avant le pilote, examinez les droits sur le code, la confidentialité et les restrictions du contrat. Une clause autorisant un prestataire à développer ne décrit pas nécessairement les traitements par un fournisseur d'IA. Le responsable de mission doit faire préciser les usages autorisés.

La décision doit identifier le dépôt, les données admises, le fournisseur, le mode d'exécution et les opérations permises. Elle peut exclure certaines branches, pièces jointes, données de test ou catégories de tickets. Une autorisation générale non documentée sera difficile à appliquer.

Lorsque l'examen est incomplet, utilisez un dépôt pédagogique ou un périmètre non confidentiel approuvé. Il ne s'agit pas de contourner la difficulté, mais d'éviter que le test lui-même crée l'incident qu'il devait prévenir.

2. Cartographier les flux réels

Un agent local peut lire des fichiers sur le poste tout en sollicitant un modèle distant. Inversement, un environnement hébergé peut exécuter des commandes sur une copie du dépôt. L'emplacement de l'interface ne suffit donc pas à déterminer où passent les données.

Dressez une carte simple : dépôt, poste ou environnement d'exécution, fournisseur du modèle, connecteurs, sorties de terminal et journaux. Pour chaque flux, demandez quelles informations sont transmises, conservées et accessibles à d'autres personnes.

Les paramètres relatifs à l'entraînement, la rétention et la localisation sont des sujets différents. Une politique de non-entraînement ne démontre pas une absence de stockage. Un abonnement professionnel ne vaut pas autorisation du client ni conformité automatique au contexte marocain.

Cette distinction complète le cadrage de gouvernance IA. Les responsables de sécurité et de protection des données doivent examiner les conditions contractuelles réellement applicables au projet.

3. Séparer les clients et réduire les privilèges

Ne testez pas ces contrôles avec un vrai mot de passe ou une base de production. Des identifiants factices et des environnements dédiés suffisent pour observer les refus attendus.

La documentation sécurité de Claude Code décrit permissions, isolation et risques d'injection. Le guide OpenAI d'administration rappelle que les droits du workspace et des systèmes connectés constituent des frontières distinctes. Leur simple existence ne prouve pas que votre configuration les utilise correctement.

4. Ne pas confondre instructions et contrôles techniques

CLAUDE.md, AGENTS.md et les consignes de tâche peuvent exprimer les conventions et les exclusions. Ils ne remplacent pas une restriction d'accès imposée par le système. Un dépôt malveillant peut également contenir du texte demandant à l'agent de sortir du périmètre.

Traitez les fichiers, tickets, commentaires et pages consultés comme des données à examiner, pas comme de nouvelles autorisations. Un commentaire qui demande d'envoyer une clé à une adresse externe ne devient pas légitime parce qu'il apparaît dans le contexte de l'agent.

Vérifiez également les commandes indirectes. Interdire un outil de navigation n'empêche pas nécessairement une commande shell d'accéder au réseau. La politique doit couvrir la capacité réelle, pas seulement le nom de l'outil visible.

5. Protéger les secrets et les données de test

Un fichier ignoré par Git n'est pas forcément illisible par les processus locaux. Ne vous fiez donc pas au seul fichier d'exclusion du dépôt. Limitez les secrets présents dans l'environnement et utilisez des accès dédiés au pilote.

Les logs et sorties de test méritent le même examen que le code. Une trace peut contenir un jeton, une adresse ou des données client, puis être ajoutée au contexte d'une conversation. Réduisez les sorties au nécessaire et utilisez des fixtures synthétiques.

Si un secret est réellement exposé, supprimer le message ne suffit pas. Le responsable doit déclencher la procédure d'incident, révoquer ou remplacer l'accès concerné selon les règles de l'organisation et examiner les actions effectuées. La formation doit apprendre à signaler immédiatement ce cas.

6. Encadrer les connecteurs MCP

Un serveur MCP ajoute des outils à l'agent. Il faut connaître l'opérateur du serveur, son authentification, les données qu'il voit et les effets de chaque action. Un connecteur en lecture seule n'a pas le même risque qu'un outil capable d'envoyer un email ou de modifier un ticket client.

Pour un premier pilote, exposez uniquement les opérations nécessaires. Écrivez un contrat fonctionnel : source autorisée, champs utiles, action permise, résultat attendu et validation requise. Testez les refus autant que les succès.

Notre page sur les MCP pour logiciels métier présente cette logique d'intégration. La présence d'un connecteur ne dispense pas de vérifier les permissions applicatives et la séparation des clients.

7. Garder une revue humaine et une trace proportionnée

La pull request doit montrer le changement, les tests exécutés et les limites. Le réviseur examine également les dépendances, scripts et configurations modifiés. Un résultat de test positif ne prouve pas l'absence d'une vulnérabilité ou d'une fuite.

La traçabilité doit rester proportionnée. Enregistrer systématiquement tous les prompts et toutes les sorties peut créer une nouvelle copie de données sensibles. Définissez ce qui est utile pour l'audit, qui peut le consulter et combien de temps il est conservé.

Pour organiser la montée en charge, reliez ces contrôles aux guides de déploiement Claude Code et de déploiement Codex.

Le dossier minimal avant ouverture du pilote

Le dossier doit réunir l'autorisation de périmètre, la carte des flux, la matrice d'accès, les restrictions testées, la procédure d'incident et la personne qui autorise la généralisation. Ajoutez les points non résolus et les usages explicitement exclus.

La décision peut être limitée à un seul projet ou à une seule catégorie de tâches. Elle ne doit pas être réutilisée automatiquement pour un autre client, un nouveau connecteur ou un environnement différent.

Si vous devez arbitrer entre les deux outils, utilisez le comparatif Claude Code et Codex pour ESN en traitant les exigences de sécurité non satisfaites comme des critères éliminatoires, pas comme une simple note à compenser par la vitesse.

Questions fréquentes

Peut-on garantir qu'aucun code ne quitte le poste ?

Pas en se fondant uniquement sur une exécution locale. Il faut examiner le fournisseur, les requêtes, les outils et les conditions du mode choisi. Ne formulez cette garantie que si l'architecture et les engagements la démontrent.

La désactivation de l'entraînement suffit-elle ?

Non. Elle ne traite pas à elle seule la conservation, les droits d'accès, les connecteurs, les journaux et les obligations contractuelles du client.

Faut-il interdire les agents sur tous les projets ?

La décision dépend du risque et des contrôles disponibles. Un périmètre pédagogique autorisé peut être acceptable alors qu'un dépôt client reste exclu. Documentez ces décisions au lieu d'appliquer une permission implicite.

Organiser un atelier de gouvernance

Hunter BI propose un atelier pour identifier les usages autorisés, les contrôles et les preuves attendues avant le pilote. Le périmètre de l'atelier ne remplace pas la validation juridique et sécurité propre à votre organisation.

Demander un atelier de gouvernance des agents IA en ESN.