- L’outil d’IA Claude Code n’est pas un simple générateur de code, mais un outil de productivité qui donne l’impression de déléguer des tâches à un collègue
- Il offre un environnement qui permet de se concentrer sur des capacités proprement humaines comme la conception système, la réflexion produit et la communication, plutôt que sur les implémentations répétitives
- Grâce au travail en parallèle, au débogage en plusieurs étapes et à l’intégration GitHub, il permet à une petite équipe de produire des livrables dignes d’une grande équipe de développement
- Il présente toutefois des limites et des particularités de comportement que l’utilisateur doit gérer, comme la rédaction excessive de tests ou le traitement trop lourd de tâches simples
- Au final, il déplace le rôle du développeur de l’exécutant vers le chef d’orchestre, ouvrant de vastes possibilités pour la formation des développeurs juniors, l’amélioration de la productivité des seniors et l’exécution de projets par des non-développeurs
Le code écrit par l’IA et l’évolution du rôle du développeur
- Tout le code écrit au cours des deux derniers mois a été rédigé directement non par des humains, mais par Claude Code
- L’utilisateur se concentre sur la conception de l’architecture et la définition du résultat, plutôt que sur l’implémentation
- La saisie répétitive et minutieuse devient progressivement moins nécessaire
- Dans ce processus, la valeur du développeur se déplace vers la conception produit, la pensée systémique et le jugement esthétique
Capacité de débogage en plusieurs étapes
- Face à un échec d’un job de file d’attente, Claude Code a analysé des milliers de lignes de code d’une bibliothèque externe pour en trouver la cause
- Il a résolu un problème de décalage entre les noms de file d’attente de l’environnement de développement et ceux de l’environnement de production
- C’est un exemple de problème qui aurait pris plusieurs heures, voire plusieurs jours, à un développeur classique, mais qui a pu être résolu en peu de temps
Travailler comme un chef d’orchestre
- En lançant plusieurs instances de Claude Code en parallèle, il est possible de développer simultanément plusieurs fonctionnalités
- Chaque tâche progresse dans un git worktree distinct, ce qui évite les conflits
- Au lieu d’écrire lui-même le code, le développeur assume un rôle de manager qui orchestre les tâches et effectue les revues
- Cela permet d’avancer efficacement même lorsque l’énergie ou la concentration baissent
Usage quotidien et friction minimale
- Contrairement aux outils basés sur l’IDE comme Cursor ou Copilot, Claude Code n’est pas lié à un environnement spécifique
- Il s’intègre naturellement aux workflows existants des développeurs, comme CLI, git ou tmux
- Commandes principales :
/issues→ création d’issues GitHub/work→ développement à partir d’issues et création de PR/review→ revue et amélioration de PR
- Cela permet de minimiser la friction entre les phases de recherche, d’implémentation et de revue
Limites et personnalité
- Il lui arrive parfois de rédiger trop de tests ou de traiter des tâches simples de manière trop complexe, un comportement excessif
- Lorsqu’il part dans une mauvaise direction, on peut l’arrêter immédiatement
- Son avantage est qu’il effectue volontiers aussi les tâches que les développeurs trouvent fastidieuses, comme les ajustements de style répétitifs
Développeurs juniors et apprentissage
- Les développeurs juniors peuvent utiliser Claude Code comme un mentor à qui poser des questions sans cesse
- « Quels sont les problèmes de ma PR ? »
- « Quelles sont les différences d’approche entre Python et Ruby ? »
- « Quels sont les pièges et points d’attention selon les langages ? »
- Cela améliore fortement la vitesse de progression et la capacité à contribuer en situation réelle
Exemple de workflow réel
- 9 h : transmission d’un rapport de bug à Claude Code → reproduction et création automatique d’une issue GitHub
- 9 h 20 : exécution en parallèle de tâches différentes dans 4 onglets (correction de bug, revue de PR, rédaction du changelog, investigation d’un travail de fond)
- 10 h–11 h : création automatique de chaque PR, avec documentation et gestion des erreurs incluses
- 11 h 30 : revue finale par un humain pour ajuster l’UX et le style de code
- 11 h 45 : analyse des retours clients et conversion automatique en issues
Conclusion et profils recommandés
- Une équipe de deux personnes investit 400 $ par mois pour atteindre des livrables de niveau grande équipe
- Profils recommandés :
- Développeurs seniors qui veulent se concentrer sur la stratégie et la qualité plutôt que sur l’implémentation
- Leads d’équipe qui veulent produire davantage
- Fondateurs non techniques et développeurs débutants
- Il est possible de débuter avec un abonnement à 20 $ par mois, et le plus efficace pour raccourcir la courbe d’apprentissage est de lui confier de vrais projets
- L’avenir du code se déplace de l’implémentation directe vers l’orchestration des résultats et la délégation
12 commentaires
Les humains se disputent, mais les programmes non, et ils sont rationnels..
Je trouve déjà que c’est très bien rien qu’en utilisant correctement le worktree.
Pour faire comme ça, avec Pro, ça ne passera absolument pas.
Je crée une app iOS en tant que non-développeur, et avec Pro, on atteint la limite beaucoup trop vite.
À chaque fois, ça s’arrête avant même deux heures.
D’un autre côté, le fait d’atteindre la limite marque aussi la fin du travail, donc au fond, ce n’est peut-être pas si mal…
(du genre « ça ira pour aujourd’hui… » lol)
Même avec la formule Max à 100 $, ça restait assez confortable. Je ne suis pas totalement non-développeur, mais c’était ma première fois en développement d’app, donc je l’ai utilisé pendant un mois. Jusqu’à présent, j’ai dépensé environ 566,93 $.
En l’utilisant 2 à 3 heures le matin, j’ai atteint la limite avant le déjeuner (utilisateur Pro)
Il est indiqué que ça se réinitialise à partir de 15 h, mais à moins d’être sur Max, ça semble difficile de l’utiliser toute la journée (et même sur Max, j’ai l’impression qu’atteindre la limite ne serait pas si compliqué)
On dirait un Pomodoro automatique de 2 heures, haha.
Même avec le plan Pro à 20 $, rien qu’en utilisant la méthode que tout le monde recommande — lui faire d’abord analyser pour établir un plan détaillé en mode plan, puis passer en mode edit — on atteint vite la limite.
La qualité du code s’améliore clairement, mais j’ai l’impression que la consommation de tokens est au moins trois fois plus rapide que lorsqu’on commence bêtement directement en mode edit.
Ce n’est pas disponible avec le forfait gratuit, n’est-ce pas ?
Avec l’abonnement à 100 dollars, j’ai l’impression que ça pourrait à peu près le couvrir.
Même avec une formule à 20 $, ce serait difficile de faire ça comme ça, du genre « tout le code écrit ces deux derniers mois a été rédigé directement par Claude Code, pas par un humain ».
Il ne faudrait pas d’abord cramer 200 $, puis, une fois la limite atteinte, en remettre encore 200 ?
J’utilise moi aussi l’offre à 100 $. Avant d’écrire le code, je fais le plan avec le modèle Opus, puis j’utilise Sonnet pour le codage proprement dit. Depuis environ deux mois, Claude Code a écrit directement presque tout le code (au minimum plusieurs milliers de lignes), et je n’ai presque jamais atteint de limite. En fait, cela ne m’est jamais arrivé, sauf quand j’ai rédigé du code par erreur avec Opus.
Actuellement, j’utilise le mode Opus Plan récemment lancé, et depuis que je l’utilise, le message d’avertissement « Approaching limit » apparaît lui aussi très rarement.
Je travaille déjà exactement comme ça~
Si on faisait un vote dans la communauté,
il semblerait que 80 à 90 % des gens soient en train d’évoluer dans ce sens