Pair programming avec Claude Code : accélérer avec l'IA sans perdre le contrôle

Faire du pair programming avec Claude Code ne veut pas dire laisser l’IA décider de tout. Le schéma qui fonctionne en production est plus simple : l’humain garde l’intention, les limites et les critères d’acceptation, tandis que Claude Code explore le dépôt, propose un plan, modifie le code par petites étapes, lance les vérifications et prépare la revue.

La page officielle Claude Code overview décrit Claude Code comme un outil de codage agentique capable de lire le code, modifier des fichiers, exécuter des commandes et s’intégrer aux outils de développement. C’est puissant, mais cela rend les consignes vagues plus risquées. Un prompt comme “améliore ça” peut produire du code vite, mais pas forcément dans la bonne direction.

Cet article complète le guide de démarrage Claude Code. Il présente un workflow concret pour corriger un bug, ajouter des tests, limiter un refactor et préparer une pull request lisible.

Clarifier les rôles avant de coder

Avant de demander une implémentation, décidez ce qui reste une décision humaine. Claude peut lire vite et produire des diffs, mais il ne doit pas changer silencieusement l’intention produit, les limites de sécurité ou les critères de merge.

Zone	Responsabilité humaine	Responsabilité de Claude Code
Objectif	Dire ce qui change et ce qui ne change pas	Trouver les fichiers et chemins possibles
Recherche	Fixer le périmètre de lecture	Lire code, tests, diff et logs
Implémentation	Valider la taille et le risque du diff	Faire des changements petits et ciblés
Vérification	Définir le signal de réussite	Lancer tests, lint, build ou captures
Revue	Décider si le merge est acceptable	Lister risques, tests manquants et alternatives

Avec cette séparation, Claude Code devient un binôme opérationnel, pas un remplaçant sans supervision. Pour apprendre, commencez par un bug, un fichier de tests ou un composant plutôt qu’une fonctionnalité entière.

Préparer le dépôt en 10 minutes

La préparation compte plus qu’un prompt sophistiqué. Les bonnes pratiques Claude Code insistent sur deux points : donner à Claude un moyen de vérifier son travail et séparer exploration, planification, implémentation et validation. En pratique, je vérifie trois choses.

D’abord, travailler sur une branche ou un worktree, jamais directement sur main. Ensuite, garder un CLAUDE.md court. La documentation mémoire explique que CLAUDE.md est chargé au début de chaque session comme instructions persistantes. Enfin, fournir les commandes qui prouvent que le changement est correct.

# CLAUDE.md

## Project rules
- Before editing, summarize the files you plan to inspect.
- Prefer small diffs and explain risky changes before applying them.
- After code edits, run `npm run lint` and the narrowest relevant test.
- Do not read `.env*` files or change deployment settings without approval.

## Common commands
- `npm run lint`
- `npm run test`
- `npm run build`

Ne transformez pas CLAUDE.md en documentation exhaustive. Plus il est long, plus les règles importantes se diluent. Les procédures répétables peuvent devenir des Skills, chargées uniquement quand elles sont utiles.

Suivre le cycle explorer, planifier, implémenter, vérifier

L’erreur fréquente est de demander “implémente ceci” avant que Claude comprenne le code existant. Un cycle plus fiable ressemble à ceci :

flowchart LR
  A[Décrire l'objectif] --> B[Explorer les fichiers utiles]
  B --> C[Revoir le plan]
  C --> D[Modifier par petites étapes]
  D --> E[Lancer les checks et lire le diff]
  E --> F{Succès?}
  F -- Non --> C
  F -- Oui --> G[Résumer pour la PR]

Le premier prompt peut rester court, mais il doit contenir objectif, périmètre, interdits et méthode de vérification.

Objectif : corriger l'erreur 500 sur la page profil après connexion.
Périmètre : commencer par `src/auth` et `src/pages/profile`.
Interdits : ne pas changer la stratégie d'auth, ne pas modifier le schéma DB, ne pas lire `.env`.
Processus : lis les fichiers utiles, liste 3 causes probables, puis montre un plan avant d'éditer.
Vérification : exécute les tests d'auth existants et `npm run lint`.

Quand Claude propose un plan, réduisez-le si nécessaire.

Le plan est raisonnable, mais écris d'abord uniquement le test de reproduction.
Confirme qu'il échoue avant de modifier le code de production.
Ensuite, propose les changements de production un fichier à la fois.

Cette approche fonctionne très bien avec le TDD, ou développement piloté par les tests. Le but n’est pas d’être dogmatique : un test qui échoue rend le problème visible et facilite la revue.

Un petit exemple exécutable

Pour s’entraîner, commencez avec une fonction sans risque. Enregistrez le code suivant dans pair-check.test.ts et lancez-le avec Vitest.

import { describe, expect, it } from "vitest";

type ClaudeMode = "direct" | "plan-first" | "human-review";

export function decideClaudeMode(input: {
  changedFiles: number;
  touchesSecrets: boolean;
  hasReliableTests: boolean;
}): ClaudeMode {
  if (input.touchesSecrets) return "human-review";
  if (input.changedFiles > 3) return "plan-first";
  if (!input.hasReliableTests) return "plan-first";
  return "direct";
}

describe("decideClaudeMode", () => {
  it("allows direct work for small, well-tested changes", () => {
    expect(
      decideClaudeMode({
        changedFiles: 1,
        touchesSecrets: false,
        hasReliableTests: true,
      }),
    ).toBe("direct");
  });

  it("requires a plan for broad changes", () => {
    expect(
      decideClaudeMode({
        changedFiles: 5,
        touchesSecrets: false,
        hasReliableTests: true,
      }),
    ).toBe("plan-first");
  });

  it("requires human review for secret-related work", () => {
    expect(
      decideClaudeMode({
        changedFiles: 1,
        touchesSecrets: true,
        hasReliableTests: true,
      }),
    ).toBe("human-review");
  });
});

npm install -D vitest typescript
npx vitest run pair-check.test.ts

Demandez ensuite à Claude Code d’ajouter une règle : “si le changement touche billing, utiliser human-review”. Faites-lui ajouter le test, constater l’échec, implémenter la règle et relancer Vitest. L’exemple est petit, mais la discipline est la même pour un handler API, un composant React ou une migration.

Quatre cas d’usage solides

Le premier cas est l’ajout d’une petite condition à une fonction existante, par exemple “masquer l’export CSV pour les comptes gratuits”. Cela oblige à vérifier UI, autorisation et tests sans redessiner tout le produit.

Le deuxième cas est l’investigation de bug. Donnez le message d’erreur, les étapes de reproduction et le résultat attendu. La page officielle Common workflows recommande de fournir commandes de reproduction et stack traces pour remonter à la cause.

Le troisième cas est l’ajout de tests. Demandez à Claude de lire le style existant, puis d’ajouter succès, non autorisé, entrée invalide et données vides. Pour structurer ce travail, utilisez aussi le guide testing strategies.

Le quatrième cas est la pré-revue. Faites lire git diff et demandez une priorité sur sécurité, compatibilité, tests manquants et noms ambigus. La documentation GitHub sur les pull request reviews rappelle que commentaires, approbations et demandes de changement protègent la qualité. Claude Code prépare la revue humaine, il ne la remplace pas.

Pièges concrets et parades

Piège	Effet	Habitude plus sûre
“Améliore ça”	Des refactors non demandés arrivent	Préciser périmètre, non-objectifs et acceptation
Diff trop grand	La revue devient lente	Une tâche, un diff, un plan
Pas de vérification	Le changement semble fini seulement en surface	Exiger tests, lint, build ou capture
CLAUDE.md trop long	Les règles importantes disparaissent	Déplacer les procédures vers Skills
Permissions larges	Secrets ou production deviennent accessibles	Utiliser permissions et hooks

Le risque discret est la fatigue d’approbation. Si tout demande confirmation, on finit par accepter mécaniquement. Si tout est autorisé, un mauvais prompt peut aller trop loin. La règle pratique : beaucoup de confiance pour ce qui est réversible, beaucoup de friction pour ce qui ne l’est pas. Pour les réglages, voir le guide approval and sandbox.

Transformer la session en PR lisible

En équipe, ne laissez pas la valeur dans le chat. Terminez par un résumé de pull request.

Résume ce diff pour une pull request.
Inclure :
- Pourquoi le changement existe
- Principaux fichiers modifiés
- Commandes de vérification et résultats
- Risques à examiner en revue
- Périmètre volontairement non modifié

Claude peut écrire le brouillon, mais l’humain doit ajuster la version finale. Pour sécurité, paiement, confidentialité et suppression de données, la confiance du modèle n’est pas une preuve. Les preuves sont le diff, les sorties de tests, les logs et la discussion de revue.

Résultat après essai

Quand Masa a utilisé ce cycle sur une petite correction Next.js, la revue a été plus rapide qu’avec un prompt “implémente ceci”. La raison n’était pas un code parfait. Le premier prompt limitait les fichiers, nommait les interdits et exigeait lint plus tests. Claude Code a touché moins de fichiers inutiles et a laissé les preuves de vérification dans la conversation. Sur une modification UI peu testée, la revue visuelle humaine restait nécessaire. La leçon est nette : le pair programming avec Claude Code ne consiste pas à abandonner la responsabilité, mais à concevoir la frontière de responsabilité.

Pour la prochaine session, choisissez une petite tâche et passez-la par explorer, planifier, implémenter, vérifier. Pour définir prompts partagés et critères de revue en équipe, consultez ClaudeCodeLab training.