Utiliser Claude pour le développement

La façon la plus rapide de mal utiliser Claude est de le traiter comme un pilote automatique : coller une demande d'une ligne, accepter le code qui revient, et passer à autre chose. Claude ne tape pas plus lentement que vous, donc cette boucle semble productive. Le coût apparaît plus tard, dans l'écart entre ce que vous avez demandé et ce que le code a réellement supposé.

Imaginez un développeur demandant à Claude de « faire en sorte que le module d'authentification expire les sessions inactives après 30 minutes ». Claude renvoie un changement propre et bien formaté en quelques secondes. Le développeur le survole, voit un minuteur et une comparaison avec un horodatage, et le valide. Ce que le prompt n'a jamais mentionné : les sessions peuvent être rafraîchies simultanément à partir de deux onglets, et le code existant stocke l'heure de la dernière activité en UTC tandis que la nouvelle vérification la lit comme heure locale. Le changement passe le seul test que le développeur surveillait. Deux semaines plus tard, les utilisateurs de l'autre côté d'un fuseau horaire sont déconnectés après quelques minutes, et le bogue est maintenant enfoui sous une douzaine de validations non liées.

Rien de tout cela n'est un échec exotique du modèle. La sortie était plausible, elle a été compilée, et elle a passé le test visible. Une étude de CodeRabbit de décembre 2025 sur 470 demandes de tirage réelles a quantifié ce schéma : les changements coécrits par l'IA comportaient environ 1,7 fois plus de problèmes que ceux écrits par des humains, avec des défauts de logique et de correction en hausse de 75 % et des problèmes de performance apparaissant près de huit fois plus souvent. Les défauts ne sont pas du bruit aléatoire. Ils se regroupent exactement là où le modèle a dû deviner parce que le contexte ne précisait pas la réponse.

Le bénéfice de travailler avec Claude comme partenaire est concret et peut s'apprendre. Le modèle prédit une sortie plausible à partir de ce qui est dans son contexte, et plausible est le type dangereux, car cela survit à une lecture rapide d'une manière qu'une réponse manifestement erronée ne ferait jamais. Votre levier est constitué de trois étapes que le flux de travail vous offre gratuitement : le contexte que vous fournissez avant qu'il ne commence, le plan que vous acceptez avant qu'il n'écrive, et le diff que vous lisez avant de le conserver. Le mécanisme derrière ces étapes, comment Claude travaille réellement sur une tâche de développement, est ce que la section suivante décompose.

Claude est un modèle de langage qui prédit le prochain token à partir des tokens déjà devant lui. Pour une tâche de développement, cela signifie qu'il ne parcourt pas votre dépôt ni ne se souvient de votre projet entre les conversations. Il fonctionne entièrement à partir de ce que vous placez dans la fenêtre de contexte pour cet échange. Le flux de travail recommandé par Anthropic nomme les quatre phases où vous gardez le contrôle.

• Explorer. Claude lit les fichiers, erreurs et types que vous fournissez et répond aux questions à leur sujet avant de proposer quoi que ce soit. C'est là que vous confirmez qu'il a compris le problème.
• Planifier. Vous demandez l'approche, les fichiers impactés, les risques et les cas limites, puis vous lisez et modifiez ce plan avant que tout code n'existe. Le plan est l'endroit bon marché pour attraper une mauvaise supposition.
• Implémenter. Claude rédige le changement selon le plan convenu. Vous lui demandez d'exécuter une vérification qu'il peut lire, comme un test ou une construction, afin que « semble terminé » soit remplacé par un succès ou un échec.
• Valider. Vous examinez le diff, exécutez le code et validez par petites étapes avec un message clair. La fusion est votre décision, jamais celle du modèle.

Deux distinctions décident si cela fonctionne. La première est planifier versus construire. Les propres conseils d'Anthropic indiquent que la planification justifie son coût « lorsque vous n'êtes pas sûr de l'approche, lorsque le changement modifie plusieurs fichiers, ou lorsque vous ne connaissez pas bien le code », et que « si vous pouviez décrire le diff en une phrase, sautez le plan ». Une correction de faute de frappe n'a pas besoin de plan. Un changement qui touche trois fichiers et une interface en a besoin, car là, la mauvaise approche produit un grand diff construit sur la mauvaise base, et un grand mauvais diff est bien plus coûteux à examiner qu'un court plan.

La deuxième est auteur versus réviseur. Une conversation qui vient d'écrire un changement est prête à le défendre, de la même manière qu'un auteur relit son propre brouillon et voit ce qu'il voulait dire plutôt que ce qu'il a écrit. Une nouvelle conversation qui ne voit que le diff et les critères, sans le raisonnement qui l'a produit, évalue le résultat selon ses propres termes et attrape la supposition que l'auteur a intégrée. C'est pourquoi Claude est le plus utile sur une tâche réelle en tant que deux rôles, un Rédacteur et un Réviseur, exécutés dans des conversations séparées.

Le dernier élément est l'endroit où vit votre contexte. Tout ce qui est spécifique à une tâche, le test échoué et l'erreur, appartient au prompt. Tout ce qui s'applique à chaque tâche, la stack, les conventions, les règles « toujours faire X », appartient à un endroit que Claude lit automatiquement. Sur Claude.ai, cet endroit est un Projet, un espace de travail avec ses propres instructions personnalisées et des connaissances téléchargées que chaque conversation à l'intérieur hérite. Avec les parties nommées, la section suivante guide une tâche à travers les quatre phases.

Maya, une développeuse, doit faire expirer les sessions inactives après 30 minutes dans un module d'authentification existant. Elle a déjà été brûlée en acceptant un changement qui semblait plausible, alors cette fois-ci, elle travaille les trois étapes délibérément, en utilisant un Projet Claude qu'elle a configuré pour cette base de code.

1. S'appuyer sur le Projet pour le contexte permanent. Les instructions personnalisées du Projet indiquent déjà la stack, la règle selon laquelle une entrée invalide génère une RangeError, et que les heures sont stockées en UTC. Elle a téléchargé src/auth/session.ts comme connaissance du Projet. Elle ne recolle rien de tout cela.
2. Énoncer l'objectif et le contexte par tâche. Elle écrit un résultat : « Expirer les sessions inactives après 30 minutes d'inactivité dans src/auth/session.ts. » Elle colle la fonction refreshSession actuelle et le fichier de test mot pour mot, afin que les signatures exactes soient dans la fenêtre.
3. Planifier d'abord, ne pas construire. Elle termine le prompt par « Donnez-moi un court plan : approche, fichiers touchés, risques et cas limites. Ne pas écrire de code pour l'instant. Listez vos suppositions. » Claude propose de comparer now avec lastActiveAt, et signale trois cas limites : décalage d'horloge, deux onglets se rafraîchissant en même temps, et un token déjà expiré. Il demande également si lastActiveAt est stocké en UTC. Cette question vaut plus que le code, car c'est exactement le bogue de la première section.
4. Corriger le plan, puis implémenter. Maya confirme l'UTC et lui dit de lire la valeur stockée en UTC. Avec la supposition corrigée, elle demande à Claude d'implémenter selon le plan et d'ajouter un test pour le cas de rafraîchissement simultané, puis d'exécuter la suite et de montrer le résultat.
5. Revoir dans une nouvelle conversation. Elle ouvre un nouveau chat, colle seulement le diff et les trois contraintes, et demande « quelles suppositions ce code fait-il, et sont-elles sûres ? » Le nouveau réviseur, non investi dans le brouillon, souligne que le minuteur utilise une constante de 30 minutes dupliquée d'un autre fichier, un problème de maintenabilité que la conversation d'écriture n'a jamais mentionné.
6. Vérifier et valider. Maya lit elle-même le diff, exécute la suite (maintenant 18 tests réussis, contre 16), confirme que le test de rafraîchissement simultané couvre le cas des deux onglets, et valide le petit changement avec un message clair.

L'avant et l'après est toute la leçon. La version pilote automatique a produit le bogue de fuseau horaire et la constante dupliquée, tous deux invisibles à une lecture rapide. La version en partenariat a coûté à Maya peut-être quatre minutes et deux échanges de clarification, et elle a révélé deux défauts qu'elle aurait autrement livrés. Maya et ce même changement d'authentification se poursuivent dans les pièges ci-dessous.

Chacun de ces pièges donne l'impression de vous accélérer, et chacun supprime discrètement une étape qui maintenait l'intégrité du travail.

• L'acceptation en pilote automatique. Un diff qui semble propre invite à un coup de tampon. La solution est de lire le changement par rapport à vos contraintes énoncées et d'exécuter le code, en traitant chaque diff comme un brouillon. Si vous ne pouvez pas le vérifier, ne le livrez pas.
• La boucle d'amélioration sans fin. Dire à Claude « améliore-le » sur plusieurs tours sans relire le diff est la façon dont une refonte change silencieusement le comportement. Après deux corrections sur le même point, commencez une nouvelle conversation avec un prompt plus précis qui intègre ce que vous avez appris, plutôt que d'empiler plus sur un contexte encombré.
• Le chat fourre-tout. Une conversation pour « corriger le bogue de session, puis mettre à jour la documentation, puis examiner le test instable » remplit le contexte de trois tâches, et les réponses dérivent à mesure que les instructions précédentes sont évincées. Commencez un nouveau chat par tâche non liée afin que chacune commence proprement.
• L'auteur qui se révise lui-même. Demander à la même conversation qui a écrit le code de le réviser produit une défense, pas une révision. Déplacez le diff vers une nouvelle conversation qui n'a jamais vu le raisonnement, et dites au réviseur de signaler uniquement les problèmes qui affectent la correction ou les contraintes énoncées, afin qu'il ne sur-ingénieure pas.

Deux véritables cas limites se cachent sous ces pièges. Le réviseur trop zélé. Un modèle incité à trouver des lacunes en rapportera presque toujours, même lorsque le travail est solide, car c'est ce qu'on lui a demandé de faire. Poursuivre chaque constatation mène à des couches d'abstraction supplémentaires, du code défensif, et des tests pour des cas qui ne peuvent pas se produire. La gestion consiste à limiter la révision à la correction et aux exigences énoncées, et à traiter le reste comme des suggestions facultatives, pas des ordres.

La dépendance hallucinée. Une particularité de 2026 est que les modèles inventent encore des packages et des API qui n'existent pas, et environ un échantillon généré sur cinq fait référence à une dépendance inexistante. Claude proposant import { parseDuration } from 'time-utils' ressemble exactement à un import réel. Tout nouvel import dans un diff mérite une vérification délibérée que le package et le symbole sont réels avant de l'installer, et une règle permanente de « ne pas ajouter de nouvelles dépendances sans demander » élimine la plupart des risques. Maintenir ces gardes cohérents est d'autant plus important lorsque plus d'une personne partage la base de code, ce qui est là où l'échelle entre en jeu.

Un développeur peut garder les conventions en tête et les recoller au besoin. Dès qu'une deuxième personne, une deuxième machine ou un deuxième mois est impliqué, cette habitude doit vivre dans un artefact partagé, sinon Claude se comporte un peu différemment pour chacun et chaque prompt s'écarte de la façon dont le projet fonctionne réellement.

L'artefact durable est le contexte permanent, conservé en un seul endroit que l'outil lit à chaque fois. Sur Claude.ai, un Projet contient les instructions personnalisées et les documents de référence téléchargés contre lesquels toute l'équipe travaille, de sorte qu'un coéquipier rejoignant un Projet hérite du même socle sans l'assembler à la main. Pour le travail sur le dépôt, le même rôle est joué par un fichier de règles enregistré : CLAUDE.md pour Claude Code, ou AGENTS.md comme norme inter-outils. Gardez-le court et pertinent, la stack, les conventions, et une petite liste de ce qu'il faut préférer et éviter, et élaguer-le lorsqu'une défaillance révèle une lacune. Un fichier de contexte surchargé est pire qu'un court, car le modèle commence à ignorer les règles perdues dans le bruit.

Priya, qui dirige l'équipe, possède la partie qu'une configuration individuelle ne peut pas. Elle ajoute deux lignes au modèle de demande de tirage : quel assistant a produit un changement et le prompt ou la tâche qui l'a motivé. Cet enregistrement transforme le vague malaise d'un réviseur en une question concrète, car réviser la sortie de l'IA signifie demander « quelles suppositions ce code fait-il, et sont-elles sûres ? » plutôt que « cela semble-t-il raisonnable ? ». Elle soumet également les demandes de tirage coécrites par l'IA à la même barre de petit diff que toute autre, sous environ 400 lignes, puisque la capacité de révision, et non le volume de code, est maintenant le goulot d'étranglement, et un diff serré est le seul type qu'un humain peut réellement vérifier par rapport aux contraintes.

L'échelle change également l'ordre des étapes. Les linter et les scanners automatisés dans le CI capturent une grande part des problèmes de routine avant qu'une personne ne regarde, ce qui libère la révision humaine pour les jugements que les outils ne peuvent pas faire : si l'approche convient à l'architecture, si les cas limites sont traités, si une nouvelle dépendance est même réelle. La division Rédacteur puis Réviseur survit naturellement dans une équipe, puisque l'ingénieur réviseur est, par définition, un contexte frais qui n'a pas écrit le changement.

Le principe durable à garder, quelle que soit la taille de l'équipe, est que Claude propose et vous décidez. Fournissez le contexte, acceptez le plan, lisez le diff, et ne troquez jamais les trois pour la vitesse d'une boucle d'acceptation totale. Commencez par une petite chose : configurez un seul Projet pour une base de code avec vos trois conventions les plus répétées dans ses instructions, et exécutez votre prochain changement comme un plan d'abord, puis une construction, puis une révision de contexte frais.