Pair programming avec l’IA : travailler avec un agent

Le pair programming avec l’IA, c’est la pratique que les développeurs utilisent depuis des décennies, avec un siège occupé par un agent de code. L’un pilote : il tape le code. L’autre navigue : il tient le plan, guette les erreurs et décide de la suite. La différence, c’est qu’un agent tape bien plus vite que vous ne lisez : la difficulté n’est plus d’écrire du code, mais de garder le contrôle sur ce qui s’écrit.

Ce guide explique comment répartir les rôles avec un agent, quand le laisser piloter seul et quand relire chaque étape, comment les modes d’approbation de Claude Code, Codex et Gemini CLI s’inscrivent dans ce choix, comment garder des étapes petites et des diffs lisibles, comment travailler en binôme pour apprendre plutôt que simplement déléguer, et comment laisser deux agents travailler ensemble pendant que vous naviguez. Les noms de commandes et de modes suivent la documentation officielle d’octobre 2026.

Pilote et navigateur, avec un agent à l’un des sièges

En pair programming classique, les rôles s’échangent souvent. Avec un agent, deux configurations sont utiles.

Vous naviguez, l’agent pilote. C’est le choix par défaut pour la plupart des travaux. Vous décrivez l’objectif, les contraintes et l’étape suivante ; l’agent modifie des fichiers et lance des commandes ; vous lisez ce qu’il a fait et vous corrigez la trajectoire. Votre rôle est celui d’un bon navigateur : garder la vue d’ensemble, remarquer quand le code part dans une mauvaise direction, et l’arrêter tôt.

Vous pilotez, l’agent navigue. Vous écrivez le code vous-même et utilisez l’agent comme seconde paire d’yeux. Demandez-lui de relire la fonction que vous venez d’écrire, de proposer des cas limites, de trouver d’où vient une valeur, ou d’écrire le test avant que vous n’écriviez le code. C’est plus lent, mais c’est la bonne configuration quand vous devez comprendre chaque ligne, par exemple pour du code que vous maintiendrez seul ou quand vous apprenez un nouveau langage.

Choisissez la configuration avant de commencer une tâche, et dites-le dans le prompt : « J’écris le parser, tu relis chaque fonction que je colle et tu listes les cas limites » donne une session très différente de « Implémente le parser ; arrête-toi après chaque fonction pour que je relise. » Changer de rôle en cours de route sans le dire, c’est ainsi qu’on se retrouve avec du code que personne ne comprend entièrement.

Quand le laisser piloter et quand relire chaque étape

La question n’est pas de savoir si vous faites confiance à l’agent. C’est de savoir combien coûte une erreur et à quelle vitesse vous la remarqueriez. Une règle simple :

Deux choses rendent sûr le fait de laisser l’agent piloter : des tests qui échouent quand le comportement casse, et un moyen d’annuler. Si vous avez les deux, une fausse route coûte quelques minutes. Si vous n’avez ni l’un ni l’autre, relisez chaque étape, ou ajoutez d’abord des tests (écrire des tests unitaires avec l’IA explique comment).

Pour les tâches plus grosses, un bon compromis consiste à planifier d’abord. Dans Claude Code, le plan mode permet à l’agent de lire et de proposer un plan sans rien modifier ; vous relisez le plan, le corrigez, puis changez de mode et le laissez l’exécuter. Le plan mode de Claude Code le détaille pas à pas. Relire un plan prend une minute ; relire une mauvaise implémentation prend bien plus longtemps.

Modes d’approbation : ce que l’agent peut faire sans demander

Chaque grand CLI d’agent de code a un réglage qui fixe la fréquence à laquelle il s’arrête pour vous demander. Ce réglage, c’est votre style de binôme écrit sous forme de configuration.

Claude Code a des modes de permission, en octobre 2026 :

• default : demande avant les modifications de fichiers et avant les commandes qui ne sont pas déjà autorisées. C’est la relecture de chaque étape.
• acceptEdits : les modifications de fichiers dans le dossier de travail, ainsi que de simples commandes de fichiers comme mkdir et mv, sont acceptées sans demander ; les autres commandes demandent toujours.
• plan : lit et propose, ne modifie rien.
• auto : un classifieur en arrière-plan vérifie chaque action et bloque les plus risquées, si bien que l’agent demande moins souvent. La disponibilité dépend de votre offre et du modèle, et les administrateurs peuvent le désactiver.
• bypassPermissions : aucune vérification. La documentation ne le recommande que dans des environnements isolés comme des conteneurs ou des VM.

Appuyez sur Shift+Tab pour passer d’un mode à l’autre pendant une session, démarrez avec claude --permission-mode acceptEdits, ou définissez permissions.defaultMode dans les réglages. Quand vous répondez à une demande par « Yes, and don’t ask again », la règle est enregistrée et la même commande ne redemandera plus. Les permissions de Claude Code explique le bout risqué de l’échelle.

Codex CLI combine un sandbox et une politique d’approbation. Son preset Auto par défaut le laisse modifier des fichiers et lancer des commandes dans l’espace de travail, et demande avant d’en sortir (--sandbox workspace-write --ask-for-approval on-request). Utilisez /permissions pendant une session pour changer, par exemple vers Read Only, ou démarrez avec --sandbox read-only quand vous voulez seulement qu’il regarde.

Gemini CLI a --approval-mode avec default (demander), auto_edit (accepter les modifications, demander pour les autres outils), plan (lecture seule) et yolo (tout accepter).

Une correspondance pratique : relire chaque étape, c’est le mode par défaut partout. Laisser piloter sur du travail de routine, c’est accepter les modifications mais continuer à approuver les commandes shell, car c’est dans les commandes que se produisent les choses irréversibles. Le tout-automatique a sa place dans un conteneur ou un worktree jetable, jamais sur une machine qui a des identifiants de production.

Des petites étapes

Le pair programming fonctionne parce que chaque étape est assez petite pour en discuter. Avec un agent, c’est encore plus important, puisqu’il peut produire mille lignes avant que vous ayez fini de lire les cent premières.

• Demandez une étape à la fois. « Ajoute la fonction de validation et ses tests, puis arrête-toi » vaut mieux que « construis le parcours d’inscription ».
• Dites quand s’arrêter. Les agents ont tendance à enchaîner sur la prochaine chose évidente. « Arrête-toi après ça et résume ce que tu as changé » vous laisse maître du rythme.
• Commitez après chaque étape verte. Un commit par étape vous donne un point d’annulation propre et un historique lisible. git add -p vous permet de vérifier chaque bloc au passage.
• Utilisez les checkpoints pour l’entre-deux. Dans Claude Code, /rewind (ou deux appuis sur Échap) ramène le code et la conversation à un prompt précédent. Les changements faits par des commandes shell ne sont pas suivis, donc git reste votre vrai filet de sécurité. Annuler les changements de Claude Code couvre les deux.

Si une étape tourne mal, annulez-la et relancez le prompt avec ce que vous avez appris. Demander à l’agent de réparer sa fausse route par-dessus le mauvais code fait en général plus de dégâts que de recommencer l’étape.

Relire les diffs

En tant que navigateur, le diff est votre outil principal. Lisez-le avant d’accepter l’étape, pas après les trois suivantes.

git status
git diff --stat
git diff

Dans Codex, /diff affiche les changements en cours dans la session. Avec n’importe quel agent, vous pouvez demander : « Montre-moi le diff de ce que tu as changé et explique chaque bloc en une ligne. »

Ce qu’il faut regarder, au-delà du fait que le code marche :

• Le périmètre. Des fichiers modifiés qui n’ont rien à voir avec la tâche. Les renommages, le reformatage et les « petits nettoyages » cachent de vrais changements.
• Des tests supprimés ou affaiblis. Une assertion modifiée pour coller à la nouvelle sortie, ou un test marqué comme ignoré, c’est un signal d’alarme.
• Des erreurs étouffées. Des blocs catch vides, des casts any, des règles de lint désactivées, des options --force.
• De nouvelles dépendances. Chacune est du code que vous maintenez désormais.
• Ce que vous ne savez pas expliquer. Si vous ne pouvez pas dire pourquoi une ligne est là, demandez avant de l’accepter.

Le guide de la revue de code par IA va plus loin sur la relecture du travail des agents au stade de la pull request.

Apprendre ou déléguer

Travailler en binôme avec un agent peut vous rendre plus rapide sur ce que vous savez déjà, ou vous apprendre ce que vous ne savez pas. Ce sont deux sessions différentes.

Quand vous déléguez, c’est le résultat qui compte. Donnez des critères d’acceptation clairs, laissez l’agent piloter, relisez le diff et les tests. C’est très bien pour du code standard répétitif, des migrations et du code dans des domaines que vous maîtrisez déjà.

Quand vous voulez apprendre, ralentissez volontairement :

• Demandez un plan et une explication avant tout code : « Explique comment tu t’y prendrais et pourquoi, n’écris pas encore de code. »
• Tapez vous-même la logique centrale et demandez à l’agent de la relire.
• Demandez « pourquoi ceci et pas cela ? » sur ses choix, et demandez-lui de montrer l’alternative.
• Demandez-lui d’écrire d’abord un test qui échoue, puis faites-le passer vous-même.

Une habitude utile : si vous ne pourriez pas réécrire un morceau de code sans l’agent, vous ne l’avez pas encore appris, vous l’avez seulement accepté. C’est acceptable pour une partie du code, mais cela doit être une décision, pas un accident.

Deux agents en binôme : l’un écrit, l’autre relit

Le rôle de navigateur peut aussi revenir à un second agent. Un agent écrit ; un autre, idéalement un modèle différent pour que leurs angles morts diffèrent, relit ; vous décidez de ce qu’il faut traiter.

Une version simple avec deux CLI dans le même dépôt :

# Terminal 1: Claude Code implements the step
claude "Add rate limiting to the /login route. Stop when tests pass."

# Terminal 2: Codex reviews the uncommitted changes
codex review --uncommitted

codex review peut aussi relire par rapport à une branche de base (--base main) ou à un seul commit (--commit <sha>), et dans une session /review fait la même chose. Renvoyez à l’agent qui écrit les constats avec lesquels vous êtes d’accord, et ignorez les autres : la sortie du relecteur est un conseil pour vous, pas un ordre pour l’autre agent.

Quelques règles font fonctionner un binôme d’agents :

• Un modèle différent, ou au moins une session neuve. Un relecteur qui partage le contexte de l’auteur a tendance à lui donner raison.
• Le relecteur ne modifie rien. Lancez-le en lecture seule. Deux agents qui modifient les mêmes fichiers en même temps, c’est un conflit de fusion, pas une revue.
• Vous restez le navigateur. Ne branchez pas la sortie de la revue directement sur l’auteur dans une boucle sans fin. Lisez-la, choisissez les vrais problèmes, envoyez ceux-là.
• Écrivez les critères. « Vérifie les validations d’entrée manquantes, les erreurs non gérées et les changements de comportement » donne une revue bien plus utile que « relis ça ».

Pour les plus gros travaux, le même schéma s’étend à plusieurs auteurs dans des worktrees séparés avec un seul relecteur, ce que couvre les équipes d’agents IA.

Le faire dans AgentVera

AgentVera fait tourner Claude Code, Codex, Gemini CLI et d’autres agents en CLI côte à côte dans une seule fenêtre, si bien que les deux configurations de binôme tiennent dans une même vue.

• Workspace. Placez l’agent qui écrit et l’agent qui relit dans des volets côte à côte sur le même projet. Chaque agent a son propre réglage de permission (Ask, Auto ou Full access) : l’auteur peut accepter les modifications pendant que le relecteur ne fait que lire.
• Approbation automatique (Pro et Team, Claude Code). Les lectures, les commandes git en lecture seule et les commandes de test, de lint et de build sont approuvées pour vous, tandis que les commandes risquées comme git push, rm ou git reset --hard vous reviennent toujours. C’est la configuration « laisse-le piloter, mais les parties dangereuses sont à moi », sans cliquer sur chaque demande.
• Notifications et approbations. Quand un agent vous attend, un raccourci vous emmène directement à celui qui attend depuis le plus longtemps.
• Checkpoints. Chaque tour est enregistré, vous pouvez donc annuler une étape d’une session sans toucher à l’historique git.
• Revue de code. À la fin d’un tour, un modèle Claude de votre choix relit les changements et liste ses constats avec une sévérité et fichier:ligne, et vous pouvez les renvoyer à l’agent. C’est un second agent intégré au siège du navigateur.
• Boîte de revue. Le travail terminé attend sous forme de cartes avec les fichiers modifiés, des notes de risque et les diffs, où vous l’approuvez ou le renvoyez avec une note.
• Messagerie entre agents. Les agents d’un même projet peuvent s’envoyer des messages et partager une liste de tâches, entre différents CLI, si bien que l’auteur peut interroger directement le relecteur.

Pour conclure

Le pair programming avec l’IA fonctionne quand les rôles sont clairs. Décidez qui pilote avant chaque tâche. Réglez le mode d’approbation selon le risque, pas selon votre humeur. Gardez des étapes petites et commitez après chaque étape verte. Lisez chaque diff avant de l’accepter. Choisissez délibérément entre déléguer et apprendre. Quand vous voulez un second avis, laissez un deuxième agent relire pendant que vous restez le navigateur.

Si vous cherchez un long travail pas à pas pour vous exercer, migrer de JavaScript à TypeScript avec l’IA est un bon choix : chaque étape est petite, et le compilateur vous dit quand elle est terminée.