Claude Code au quotidien : pourquoi ça ne remplacera pas le métier d'ingénieur
Plusieurs mois d'usage intensif de Claude Code en première ligne sur du code en prod. Ce que ça change vraiment, ce que ça ne remplace pas, et pourquoi le métier mute plutôt qu'il ne disparaît.
Mon usage actuel
Je code avec Claude Code 80 % du temps. Pas en démo : c'est dans mon flux quotidien sur des projets clients en prod.
La répartition est nette entre ce qui part à Claude et ce qui reste sur mon clavier :
| Délégué à Claude | Gardé pour moi |
|---|---|
| Scaffolder un composant ou un endpoint API | Décider ce qu'on construit, et surtout ce qu'on ne construit pas |
| Écrire des tests sur du code existant | Cadrer un projet avec un client |
| Explorer une codebase inconnue ("où est gérée l'auth ?") | Débugger un bug subtil en prod |
| Refactor mécanique (renommer un type partout) | Choisir une architecture pour les 18 prochains mois |
| Migrer un fichier d'une API vers une autre | Évaluer la dette technique acceptable |
| Écrire les bouts de code qui demandent du goût |
Ce qui change vraiment
Le rapport au temps. Une tâche de scaffold qui me prenait 2 heures (lire la doc, copier-coller, adapter, tester) prend 15 minutes : je décris ce que je veux, Claude le génère, je relis, j'ajuste, je commit.
La barrière à essayer aussi. Avant, "tenter une refacto" coûtait 4 heures. Si je n'étais pas sûr du résultat, je ne le faisais pas. Maintenant ça coûte 30 minutes : je tente, je vois, je revert si c'est nul. Donc je tente plus souvent. Et parfois la refacto que je n'aurais pas tentée était la bonne.
Le débogage en première intention. Pour un message d'erreur que je n'ai jamais vu, Claude répond souvent juste, ou m'oriente. Plus rapide que Google. Mais ça plafonne vite : sur des bugs réellement nouveaux ou contextuels, il invente.
Ce qu'il ne remplace pas
Le piège classique : "Claude écrit le code, donc le métier disparaît". Ça confond le métier avec sa partie la plus visible.
Le vrai métier d'ingénieur, c'est :
Comprendre ce qu'il faut faire. Un client te dit "je veux un dashboard". Le bon ingénieur traduit ça en : "OK donc 3 vues, ces 5 KPI, mais en fait ce que tu veux mesurer c'est X, et pour ça il y a peut-être pas besoin de dashboard du tout". Claude n'a pas le contexte business. Il code ce que tu lui dis.
Savoir ce qu'il ne faut PAS faire. Plus de la moitié du travail d'un senior, c'est dire non. Non à la feature qui va créer 6 mois de dette. Non à l'over-engineering. Non à la techno hype dont on n'a pas besoin. Claude, par défaut, dit oui à tout. Si tu lui demandes 12 niveaux d'abstraction pour une fonction de 4 lignes, il les met.
Tenir la cohérence d'un système dans la durée. Sur un projet de 6 mois, les choix faits semaine 2 ont des conséquences semaine 24. Claude voit la session courante, pas l'histoire du projet, pas les vraies raisons de tel choix architectural fait il y a 4 mois.
Le débogage profond. Le bug qui n'arrive qu'en prod, sous charge, le mardi. La fuite mémoire qui apparaît au bout de 3 jours. La race condition qui ne se reproduit qu'avec une certaine combinaison de timing. Là, Claude est utile pour explorer, mais le diagnostic final demande de la patience, de l'intuition et de la connaissance fine du système. Pas un LLM.
La communication. Un dev sans communication coûte cher. Le métier inclut : aligner avec un client non-tech, pousser back contre une mauvaise demande, expliquer un trade-off à un PM, négocier un délai, écrire une post-mortem. Aucun de ces moments n'est du code.
Trois exemples concrets de ce mois-ci
| Cas | Situation | Verdict |
|---|---|---|
| Brillant | Migration Jest → Vitest sur 80 fichiers de tests | 20 min vs. ½ journée. Patterns mécaniques, terrain idéal pour l'outil |
| Calé | Workflow n8n qui se déclenchait deux fois | 4 fix logiques mais à côté. La cause était dans l'UI (trigger en double), pas dans le code |
| Faux ami | Génération de jeton, tests verts, code propre | Utilisait Math.random() au lieu de crypto.getRandomValues(). Sans relecture, ça partait en prod |
Le shift réel du métier
Le métier ne disparaît pas. Il se déplace.
| Avant | Maintenant |
|---|---|
| Du typing | De la relecture critique |
| Du boilerplate | De l'architecture |
| « Comment écrire ça » | « Pourquoi écrire ça » |
| Questions de syntaxe | Questions de trade-off |
Cela ressemble à ce que faisait un senior il y a 10 ans, sauf qu'il le fait maintenant 3x plus vite, et qu'on attend de lui qu'il livre des choses qui auraient demandé une équipe.
Ce qui devrait inquiéter quand même
Honnête : tout n'est pas rose pour la profession.
| Pour qui | Effet | Réponse |
|---|---|---|
| Juniors | Les tâches sur lesquelles on apprenait (CRUD, glue code) sont automatisées | Se mettre consciemment dans des situations d'apprentissage actif, ne pas regarder Claude faire |
| Boîtes "code jetable" | Ratio code/ingénieur en hausse, moins de postes pour le même output | Pas de réponse magique, c'est un déplacement d'emplois réel |
| Ingénieurs non-adaptés | Marché qui se ferme aux profils "tout taper soi-même par fierté" | Apprendre à diriger l'outil, pas à concurrencer la machine |
La dépendance qui se construit
Un point qu'on oublie quand on glorifie l'outil : il faut toujours quelqu'un qui comprend ce que l'IA produit. Pas pour le taper soi-même, mais pour pouvoir relire, valider, débugger et rattraper quand ça part en vrille.
Le vibe-coding marche tant que trois conditions sont réunies :
- Tu restes sur des choses simples
- Le modèle reste pas cher
- Rien ne casse en prod
Sur les trois, j'ai des doutes sérieux pour la suite.
Côté tarif. Aujourd'hui Claude Code est offert ou presque (20 USD/mois pour un usage généreux). C'est une stratégie d'acquisition classique. Anthropic et les autres ne perdent pas d'argent par philanthropie : à terme les prix vont monter. Quand un usage intensif coûtera 200 ou 500 USD/mois au lieu de 20, beaucoup vont devoir choisir entre continuer à payer ou réapprendre à coder. Ceux qui n'ont jamais vraiment appris auront le couteau sous la gorge.
Côté maintenance. Une app pondue par IA tourne le jour J. Six mois plus tard, une dépendance lâche, une API change, un edge case apparaît. Si tu ne sais pas lire ce qu'il y a dedans, tu redemandes à l'IA, qui te génère un patch que tu valides en croisant les doigts. Trois itérations comme ça et la codebase est ingérable. Tu ne peux ni la maintenir, ni la migrer, ni l'héberger ailleurs.
Côté indépendance. À chaque ligne que tu n'as pas comprise, tu transfères un peu de pouvoir au prestataire d'IA. Le jour où il change ses conditions, ses prix ou son modèle, tu n'as pas de plan B. Ce n'est pas un partenariat, c'est une dépendance.
Le métier d'ingénieur, ce n'est pas seulement "savoir taper du code". C'est savoir lire, comprendre, débugger, refactorer, transmettre. Ces compétences se construisent en faisant, pas en regardant l'IA faire à ta place. Les vibe-coders qui livrent vite et propre aujourd'hui sont en train de se constituer une dette de connaissance qui sera très chère à rembourser.
Ma règle pratique
Pour chaque tâche, je me demande : est-ce du code à produire ou de la décision à prendre ?
| Type de tâche | Décision |
|---|---|
| Code à produire | Je délègue, je relis, je commit |
| Décision à prendre | Je la prends moi-même ; seulement après, Claude la met en code |
Si on délègue les décisions à Claude, on récupère du code qui marche aujourd'hui mais qui sera ingérable dans 6 mois.
Conclusion
Claude Code est l'outil le plus puissant que j'aie ajouté à mon flux depuis Git. Mais c'est un outil. Il amplifie un ingénieur senior d'un facteur 3 ou 4. Il ne remplace pas un ingénieur senior par un junior + Claude.
La partie du métier qui consiste à taper des lignes va se réduire. La partie qui consiste à décider, cadrer, comprendre, intégrer, maintenir et communiquer, c'est-à-dire 80 % du métier, est intacte. Et elle demande maintenant plus de temps relatif, parce qu'on en a libéré sur le reste.
Le métier ne meurt pas. Il monte d'un cran.