Claude Code et agents de code IA en 2026 : comment les utiliser et les encadrer

En 2026, Claude Code, Codex, GitHub Copilot et Cursor ne se contentent plus de compléter des lignes : ce sont des agents qui lisent un dépôt, modifient plusieurs fichiers, lancent les tests et préparent une pull request. Les gains sont réels sur des tâches bien délimitées. Les risques aussi : un agent exécute des commandes avec les droits de la personne qui le lance, lit des contenus qui peuvent contenir des instructions malveillantes, et envoie du code à un fournisseur externe. Voici comment nous les utilisons et, surtout, comment nous les encadrons.

Trois familles d’outils

Les frontières bougent vite, mais les outils se rangent en trois familles selon l’endroit où ils travaillent.

Dans l’éditeur. Cursor est un éditeur dérivé de VS Code, construit autour de l’IA, avec un mode agent. GitHub Copilot s’intègre à VS Code, aux IDE JetBrains et à d’autres éditeurs, avec lui aussi un mode agent. Le développeur garde la main à chaque étape et voit les modifications au fil de l’eau.

Dans le terminal. Claude Code (Anthropic) et Codex (OpenAI) sont nés en ligne de commande : on décrit une tâche, l’agent explore le dépôt, propose un plan, modifie les fichiers et lance les commandes autorisées. Les deux existent aussi en extension d’IDE et en application. Gemini CLI (Google) et OpenCode sont des alternatives open source ; OpenCode, comme Cline dans VS Code, laisse choisir le fournisseur de modèle.

En arrière-plan, dans le cloud. On confie une tâche, l’agent travaille dans un environnement isolé et rend une pull request. C’est le cas de l’agent cloud de GitHub Copilot (on lui assigne un ticket, il travaille dans un conteneur GitHub Actions et ne peut pas fusionner son propre travail), des tâches cloud de Codex, de Claude Code dans le navigateur ou des agents cloud de Cursor.

Deux standards rapprochent ces outils. MCP (Model Context Protocol) connecte un agent à des outils et à des sources de données ; les principaux agents de code le prennent en charge. AGENTS.md, lancé par OpenAI en août 2025, est un fichier placé à la racine du dépôt qui décrit aux agents les commandes, conventions et zones sensibles du projet. Les deux sont confiés depuis décembre 2025 à l’Agentic AI Foundation, sous l’égide de la Linux Foundation.

Ce que ces agents changent vraiment

Sur nos projets, les gains sont nets sur :

• l’écriture de tests pour du code existant ;
• les migrations mécaniques (montée de version d’une bibliothèque, renommages, changements d’API) ;
• l’investigation d’un bug à partir d’une trace ou d’un ticket ;
• la documentation technique et les scripts d’outillage ;
• la prise en main d’une base de code inconnue.

Ils sont moins fiables dès que la tâche est ambiguë : règles métier implicites, arbitrages d’architecture, performances sous charge, sécurité. C’est là que l’expérience de l’équipe fait la différence, et que la revue de code reste indispensable. Nous l’avons détaillé dans Vibe coding : du prototype à la production.

Sécurité : ce qu’un agent peut faire, lire et envoyer

Un agent de code combine souvent trois capacités : il accède à des données privées (votre code, vos variables d’environnement), il lit du contenu non fiable (un ticket, une dépendance, une page web, le README d’un paquet) et il peut communiquer vers l’extérieur (réseau, commandes, pull requests). Quand les trois sont réunis, une instruction cachée dans un contenu lu par l’agent peut le pousser à exfiltrer des secrets ou à exécuter une commande : c’est l’injection de prompt.

Le risque n’est pas théorique. En août 2025, Microsoft a corrigé la vulnérabilité CVE-2025-53773 : une injection de prompt pouvait amener Copilot à modifier les réglages de VS Code pour s’auto-approuver, puis exécuter du code. En 2026, des chercheurs ont montré que des instructions cachées dans le titre d’une pull request ou le corps d’un ticket pouvaient pousser des agents intégrés à l’intégration continue à divulguer leurs propres jetons. Des failles ont été publiées sur la plupart des outils du marché ; les éditeurs les corrigent, mais la mesure de fond reste de limiter ce que l’agent peut atteindre.

Les règles que nous appliquons

1. Permissions explicites. Liste des commandes autorisées sans confirmation (tests, lint, lecture Git), commandes interdites (push, déploiement, suppression), confirmation pour le reste. Le mode « tout accepter » n’est utilisé que dans un environnement jetable.
2. Bac à sable. Écriture limitée au dossier du projet, réseau coupé ou restreint à une liste de domaines. Claude Code et Codex proposent un bac à sable au niveau du système d’exploitation ; les agents cloud tournent dans des conteneurs isolés, avec un pare-feu pour l’agent de Copilot.
3. Secrets hors de portée. Fichiers .env et dossiers de secrets interdits en lecture, aucun secret de production sur le poste ou dans l’environnement de l’agent, jetons à portée minimale pour les agents dans l’intégration continue.
4. Réglages imposés. Les offres entreprise permettent d’imposer ces règles à toute l’organisation (réglages gérés de Claude Code, politiques d’administration de Codex) et d’interdire le contournement des permissions.
5. Revue humaine avant fusion. L’agent propose, le développeur et le lead technique valident. Aucune fusion automatique.
6. Journalisation. Qui a lancé quoi, avec quel outil, sur quel dépôt. Les changements produits avec un agent restent traçables dans l’historique Git.
7. Dépendances contrôlées. Un agent qui ajoute un paquet passe par les mêmes règles que les humains : fichier de verrouillage relu, scripts d’installation bloqués, délai minimal de publication. Voir npm install et sécurité.

Exemple de réglages de projet pour Claude Code (.claude/settings.json) :

{
  "permissions": {
    "allow": [
      "Bash(npm run test *)",
      "Bash(npm run lint *)",
      "Bash(git diff *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push *)"
    ]
  },
  "sandbox": {
    "enabled": true
  }
}

Et l’équivalent pour Codex (.codex/config.toml) :

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

Ces fichiers se versionnent avec le projet et se relisent comme du code.

Confidentialité du code et coût

Le code utile à la tâche est envoyé au fournisseur du modèle. Avant de déployer un outil, vérifiez le contrat : conservation des données, usage pour l’entraînement, localisation, sous-traitants. Les offres professionnelles encadrent en général ces points, mais pas toutes de la même façon. Si les conditions ne conviennent pas, deux options restent possibles : exclure certains dépôts de l’usage des agents, ou passer par des modèles auto-hébergés.

Le coût est surtout lié à l’usage : abonnements par poste, crédits ou facturation à la consommation selon les offres. Un agent qui tourne longtemps sur une tâche mal cadrée coûte cher pour peu de résultat. Mesurez-le dès le pilote.

Adopter un agent de code : un pilote mesuré

La décision est moins technologique qu’organisationnelle : où sont vos goulots d’étranglement, et quel niveau de contrôle exige votre gouvernance ?

Une trajectoire simple :

1. Cadrer un pilote de six à huit semaines sur un périmètre précis : génération de tests, migrations de dépendances, dette technique simple.
2. Comparer deux outils au plus, choisis selon vos contraintes : un agent de terminal (Claude Code ou Codex), un outil d’éditeur (Cursor ou Copilot), éventuellement une option open source si la maîtrise du fournisseur est un critère.
3. Poser les règles avant le premier jour : permissions, bac à sable, fichiers exclus, fichier AGENTS.md ou équivalent, circuit de revue.
4. Mesurer trois indicateurs qui parlent au comité de direction : temps de cycle des pull requests, taux de réouverture ou de retour en arrière, satisfaction des développeurs. Suivre aussi le coût par tâche.
5. Étendre progressivement si les résultats sont là, en durcissant les règles (réglages imposés, journaux, politiques d’accès).

Comment nous travaillons avec ces outils

Nos équipes utilisent des agents de code au quotidien, dans le cadre décrit sur notre page ingénierie assistée par l’IA : l’outil est choisi avec le client, les règles sont posées dans son dépôt, et le lead technique Etixio reste responsable de ce qui est livré. Revue de code systématique, tests automatisés, intégration continue, gestion des secrets et environnements séparés s’appliquent au code écrit avec un agent comme au reste. Vos dépôts, vos accès et vos comptes restent à vous : nos équipes travaillent dans votre environnement, avec vos outils et vos règles de sécurité.

Nous connectons aussi ces agents à vos outils internes quand c’est utile, par exemple avec un serveur MCP qui leur donne un accès contrôlé à votre documentation ou à vos tickets.

Vous voulez cadrer un pilote, ou faire évoluer un logiciel sur mesure avec une équipe qui maîtrise ces outils ? Parlons-en.

FAQ