Un AI Coding Agent peut-il abîmer le code ? Quels sont les risques de Claude Code, Codex, Copilot et Gemini CLI ?

Un AI Coding Agent peut abîmer votre code et, si vous lui accordez les autorisations nécessaires, lancer des commandes risquées ; ne choisissez donc pas un outil sur la foi d’un classement de sécurité sans comparaison à configuration identique. Cette semaine, testez-le sur une branche récupérable, avec un accès minimal, puis relisez chaque modification avant intégration.

Cet article s’adresse aux développeurs qui confient des changements à Claude Code, Codex, Copilot ou Gemini CLI, aux responsables qui évaluent l’accès aux fichiers et au terminal, ainsi qu’aux équipes qui veulent isoler leurs essais. Si votre agent ne peut pas agir sur un dépôt ni appeler de commande, les risques décrits ici ne s’appliquent pas tous de la même manière.

Distinguer les dommages avant de comparer les outils

« L’agent a cassé le code » recouvre des situations différentes. Une modification fonctionnelle incorrecte peut être visible dans la différence de code et annulée avec le contrôle de version. Une commande destructive peut, elle, supprimer ou altérer des données au-delà du dépôt. Enfin, un secret lu puis envoyé vers un service externe ne se récupère pas en restaurant le code. Ces conséquences ne justifient donc pas une seule note de sécurité.

Un agent peut aussi modifier un fichier sans que vous ayez validé chaque ligne au préalable, selon le mode d’utilisation, les réglages et les confirmations configurés. Les documents de Copilot décrivent un mode agent capable d’examiner le projet, de modifier des fichiers et d’utiliser des outils ; ceux de Claude Code expliquent les règles de permission et l’environnement isolé. Les mécanismes exacts dépendent de l’outil et de sa configuration (mode agent de Copilot, utilisation de Claude Code en ligne de commande).

Le dommage peut également venir d’une chaîne d’actions qui semblait anodine :

• Vous demandez de « corriger les tests », mais la consigne est interprétée comme une invitation à réécrire une interface utilisée ailleurs.
• L’agent modifie davantage de fichiers que prévu, puis ajuste les tests pour qu’ils correspondent au nouveau comportement.
• Une commande lancée pour installer ou mettre à jour une dépendance change le fichier de verrouillage ou l’environnement local.
• Une commande ayant accès à des données ou à des identifiants les expose, alors même que la correction proposée paraît valide.

Le premier cas se repère en relisant les changements. Le dernier demande aussi de contrôler les droits, les secrets accessibles et les échanges réseau. Une branche permet de revenir sur des modifications de code ; elle ne révoque pas un jeton qui aurait déjà été divulgué.

Comparer les limites réelles plutôt que les noms

Les tableaux ci-dessous décrivent des mécanismes documentés, pas des résultats de tests menés dans un même dépôt avec des réglages identiques. Les versions, les interfaces et les autorisations changent ; vérifiez les paramètres actifs dans votre installation avant de confier une tâche sensible.

Cette comparaison ne permet pas de déclarer un outil « le plus sûr ». Elle permet de repérer ce qu’il vous reste à contrôler. Pour Codex, les informations de sécurité sur les environnements d’agents ne prouvent pas à elles seules que tous les parcours de l’outil appliquent le même isolement. Pour chaque outil, examinez la documentation correspondant à votre interface et à votre mode de lancement. Les consignes de sécurité publiées pour Codex rappellent également que les paramètres de l’environnement déterminent les capacités effectives (guide de sécurité Codex).

Dans un flux de création audio, vidéo ou de design, le risque ne se limite pas au code source. Un agent lancé depuis un projet peut toucher des scripts d’export, des fichiers de configuration ou des ressources partagées. Avant de lui demander d’automatiser une tâche de production, vérifiez qu’il ne peut pas écraser les originaux ni lire des éléments confidentiels sans nécessité.

Évaluer la vigilance selon la tâche et les accès

Pour rendre le choix actionnable, attribuez une appréciation qualitative au contexte, pas au nom du produit. La grille ci-dessous ne mesure ni une probabilité d’accident ni une performance comparative. Elle aide à décider du contrôle à mettre en place.

Le niveau augmente lorsque l’impact potentiel s’étend au-delà du dépôt, que la tâche est ambiguë, que l’agent peut exécuter des commandes librement ou que personne ne relit les modifications. Il baisse si l’accès est limité au strict nécessaire, si l’environnement est jetable et si un humain valide le résultat. Un bac à sable réduit certains chemins d’action, mais ne rend pas juste une réponse erronée et ne neutralise pas automatiquement les identifiants rendus accessibles à l’agent. Les explications de Claude Code sur l’isolation précisent les limites et le rôle du bac à sable (principes du bac à sable de Claude Code).

Un agent disposant du terminal peut appeler les commandes permises par son contexte. Le risque n’est donc pas « le terminal » en soi, mais la combinaison entre la commande proposée, ses droits et les ressources atteignables. L’accès réseau mérite une vérification séparée : une exécution locale isolée et une exécution pouvant joindre des services externes n’ont pas le même périmètre d’exposition. La documentation de Gemini CLI présente ses mécanismes de bac à sable ; vérifiez les réglages en vigueur plutôt que de supposer que l’isolation est active par défaut dans votre installation.

Réduire les erreurs avant de donner une tâche

Procédez comme pour une modification confiée à un contributeur qui peut agir rapidement, mais ne connaît pas forcément toutes les conventions du dépôt.

• Définissez un résultat vérifiable. Décrivez le comportement attendu et les fichiers ou composants concernés. Demandez à l’agent de signaler ce qu’il compte modifier avant d’élargir le périmètre.
• Commencez sans accès superflu. N’exposez pas les répertoires personnels, les secrets, les données clients ni les identifiants de production si la tâche peut être réalisée sans eux.
• Fixez un point de retour. Créez une branche dédiée ou une copie de travail isolée avant le changement. Vérifiez que les modifications antérieures sont sauvegardées et distinguables.
• Encadrez les commandes. Faites confirmer celles qui installent des dépendances, suppriment des fichiers, modifient l’environnement ou contactent un service externe. Les demandes d’approbation varient selon l’outil et ses réglages : contrôlez le comportement réellement présenté.
• Relisez la différence complète. Cherchez les fichiers inattendus, les changements de configuration, les tests retirés, les sorties de débogage et les références à des secrets.
• Vérifiez indépendamment le résultat. Exécutez les tests et contrôles adaptés dans l’environnement du projet ; ne considérez pas l’affirmation de l’agent comme une preuve que la correction est correcte.
• Intégrez après validation. Gardez la fusion séparée de la génération du changement, surtout si la modification touche un processus de livraison ou des données partagées.

Pour Copilot, la capacité d’utiliser des outils dans le mode agent rend particulièrement important le contrôle des actions disponibles et des politiques de votre organisation. La documentation officielle souligne que des paramètres de gouvernance et de réseau font partie des mesures d’atténuation ; ne déduisez donc pas la protection effective du seul nom du mode (mesures de sécurité pour Copilot).

Une branche récupérable protège surtout le travail versionné. Elle ne suffit pas si l’agent peut lire un secret, supprimer une ressource externe ou agir sur un service partagé.

Isoler l’essai et préparer la récupération

Une branche dédiée est utile pour examiner et annuler des modifications, mais elle n’isole pas les permissions de la machine. Un conteneur, une machine virtuelle ou un environnement de développement distinct peut limiter l’accès aux fichiers du poste et aux services voisins, à condition d’être configuré pour cela. La documentation sur les environnements d’agents met l’accent sur les contrôles d’accès et les limites de l’environnement, qui doivent être vérifiés avant l’exécution (sécurité des environnements OpenAI).

Pour préparer un retour arrière praticable, conservez une version propre du dépôt, séparez les données de test des données réelles et évitez de monter des répertoires sensibles dans l’environnement de l’agent. Si une commande a pu atteindre un service externe, examinez aussi ses journaux et révoquez les identifiants concernés. Restaurer les fichiers du projet ne suffit pas à réparer une action extérieure ni à effacer une donnée déjà transmise.

Choisissez l’option selon les contraintes :

• Si le changement est local et réversible, une branche dédiée avec une revue manuelle peut suffire.
• Si l’agent doit installer des outils ou modifier des fichiers générés, préférez un environnement isolé et reproductible.
• Si la tâche exige des secrets ou des accès de production, retirez-les du contexte de l’agent ou faites exécuter l’étape sensible par une personne autorisée.
• Si vous ne pouvez ni limiter les droits ni restaurer les ressources touchées, reportez l’essai plutôt que de compter sur le bac à sable seul.

Avant d’étendre l’usage, vérifiez ce que l’environnement choisi permet réellement. Vous pouvez consulter la présentation de VPSSpark et demander des informations sur les environnements disponibles ; ne supposez pas qu’une fonction d’isolation ou un mode précis est inclus sans confirmation.

En pratique, gardez cette règle de décision : si le dépôt est récupérable, les accès sont minimaux et une personne relit les changements, lancez un essai limité ; si l’agent peut atteindre des secrets, des données réelles ou des commandes à fort impact sans approbation, réduisez ses droits ou changez d’environnement. Votre vérification avant chaque tâche doit porter sur le périmètre des fichiers, les commandes permises, les accès réseau, le point de retour et la personne chargée de valider.

Si votre environnement actuel partage des fichiers personnels, des identifiants et des projets actifs, il peut être difficile de circonscrire une erreur ; une machine dédiée peut offrir une séparation plus nette, mais ne remplace ni les permissions minimales ni la revue. Pour un essai temporaire nécessitant macOS, la location d’un Mac auprès de VPSSpark peut être une piste à comparer avec votre poste local ou votre environnement actuel ; vérifiez d’abord auprès de l’équipe les modalités et les protections disponibles, puis appliquez la même grille d’accès et de récupération.