Dans le quotidien d’une dev à l’ère de l’IA

Selon Claude Code, « coding is largely solved ».

Au point que l’IA remplace la production, la relecture, ou même le code tout court ?

Sans aller jusque-là (pour le moment…), si l’écriture du code devient de plus en plus automatisée, la vraie compétence des devs ne réside plus tant dans la production de code que dans le fait de savoir quoi en attendre, quoi en refuser et quoi en assumer.

Mon parcours donne peut-être déjà un aperçu du futur d’un métier en pleine mutation.

Je suis développeuse, et pourtant, je ne code (presque) pas

Je passe beaucoup plus de temps dans le cadrage, la formulation, la correction, la relecture, le test et la validation. Je suis développeuse depuis février 2023 — quelques mois après la sortie grand public de ChatGPT. Je n’ai pas connu le métier avant l’IA. J’ai appris vite, de manière assez frontale, en construisant des projets, en essayant des choses, et avec des LLM en toile de fond dès le début.

On peut dire que je fais partie de la première génération de développeurs « AI Native » qui ont appris à travailler avec l’IA dès le départ. Mes réflexes de travail se sont vraiment formés avec les LLM et pas autour d’eux. Je n’ai pas eu à déconstruire des années d’habitudes de travail pour intégrer ces outils.

Je suis arrivée après l’époque où Stack Overflow te remettait à ta place

J’ai très rarement bloqué sur un problème de code pendant des jours. Le nombre de fois où je suis allée sur Stack Overflow se compte sur les doigts d’une main, et j’ai très peu eu l’occasion de regarder des tutos YouTube de plusieurs heures.

Même quand les premiers modèles étaient encore très imparfaits, il y avait déjà ce filet de sécurité. Je savais que si je reformulais bien, si je donnais assez de contexte, si je testais plusieurs pistes, j’allais finir par avancer.

D’ailleurs, énorme avantage : l’IA est un professeur infatigable et disponible 24h/24. On peut lui poser cinquante fois la même question sans risquer la brûlure du jugement dans les yeux de l’interlocuteur. Au lieu de « T’as rien compris », j’ai eu « C’est une excellente question ! ». Dans mon cas, ça a poussé ma curiosité beaucoup plus loin.

Mes réflexes de travail se sont construits avec les LLM

Quelques exemples concrets : j’ai le réflexe de demander un résumé d’une documentation avant d’aller lire toute la doc brute. Quand j’arrive sur une nouvelle codebase, je commence souvent par me faire expliquer les mécanismes principaux, la logique générale de l’application, les endroits où se jouent les choses importantes.

Je m’en sers aussi pour structurer une approche, ou pour clarifier un concept que je manipule sans encore bien le maîtriser. J’ai de longues conversations avec Claude pour m’aider à structurer ma pensée avant de demander au mode agent d’implémenter le plan défini.

Actuellement, j’écris très peu de code brut from scratch. Mon temps passe beaucoup plus dans le cadrage, la formulation, la correction, la relecture, le test et la validation. Bien sûr, il ne s’agit pas de vibe coder comme une brute et d’envoyer en prod du code généré sans rien relire. Je suis tout autant responsable du code que j’envoie que si je l’avais tapé moi-même. Ça passe par une relecture attentive, brique par brique, du code généré, suivie d’une code review par les autres développeurs de l’équipe, qui ne laissent rien passer.

Quand le champ des possibles s’élargit

Le gros avantage de cette approche, c’est qu’elle a rendu beaucoup de choses accessibles plus tôt. Là où certaines barrières techniques demandaient un temps d’apprentissage long avant même de pouvoir essayer, je peux aujourd’hui me lancer beaucoup plus vite sur des sujets encore peu familiers. Cela me permet d’exécuter bien plus vite que ce que l’expérience seule aurait permis : là où on aurait auparavant donné certains sujets à des développeurs plus seniors, j’ai la possibilité de m’atteler à une grande variété de tâches, justement parce que l’implémentation n’est plus le cœur du métier. N’importe quelle idée devient testable rapidement.

Concrètement, ça change le rapport aux frontières classiques du métier. La séparation entre front et back me paraît déjà moins rigide : dès lors qu’on peut obtenir rapidement une première implémentation, une explication correcte et un accompagnement sur les ajustements, beaucoup plus de choses deviennent abordables. Grâce à l’IA, on a la possibilité de monter en compétences sur des sujets beaucoup plus larges plutôt que de se spécialiser dans un domaine.

Les fondamentaux reviennent par la fenêtre

C’est aussi là que mon expérience rejoint une évolution plus générale du métier : l’IA change l’exécution, mais elle ne supprime pas les exigences de fond.

Oui, l’IA facilite énormément la production de code. Elle réduit une partie de la friction technique, mais elle ne remplace pas la compréhension. On a toujours besoin de savoir ce qu’on veut lui demander techniquement pour produire du code utilisable en production. Elle a besoin qu’on lui explique ce qui est important dans notre contexte, les règles métier, les contraintes produit, d’architecture ou de maintenabilité.

Elle peut générer quelque chose qui marche et qui reste une mauvaise idée. C’est d’ailleurs le gros risque : quand le code est facile à produire, on peut avoir une impression de maîtrise et masquer les choses qu’on ne sait pas.

En réalité, les fondamentaux ne disparaissent pas. La difficulté se situe davantage dans la capacité à évaluer ce qui a été généré. Certaines compétences deviennent donc centrales beaucoup plus tôt, alors qu’auparavant les juniors étaient surtout concentrés sur l’implémentation du code. Les bases restent essentielles : architecture, clean code, sécurité, performance, infrastructure… et il est de mon devoir de me former constamment là-dessus. La veille technologique l’est aussi, pour rester au clair sur les nouveautés et savoir lesquelles valent la peine d’être adoptées.

Le vrai boulot commence après le prompt

Ce que ça l’IA change vraiment au métier de développeur, c’est la répartition du travail. Moins de temps à écrire ou relire le code ligne par ligne, plus de temps à poser le cadre, donner le bon contexte, tester les sorties, challenger les choix proposés, vérifier que tout tient ensemble. Le développement ressemble de moins en moins à un exercice de production continue, et de plus en plus à un travail de direction, d’édition, d’arbitrage.

C’est un glissement que beaucoup de seniors connaissent déjà : à mesure qu’on avance dans une carrière, on code moins et on pense plus. L’IA compresse simplement cette trajectoire. Elle fait arriver plus tôt ce qui venait avec l’expérience.

Ce que l’IA est en train de faire, c’est rendre visible ce qui a toujours compté : comprendre un problème avant de le résoudre, savoir évaluer une solution avant de la livrer, assumer ce qui part en prod. Des compétences qu’on associait à l’expérience, à l’ancienneté, aux années passées à déboguer seul à 23h. L’IA peut accélérer l’exécution, pas la maturité

L’agentique pousse cette logique encore plus loin. Quand ce n’est plus seulement une suggestion de code qu’on relit, mais un agent qui ouvre des fichiers, exécute des commandes, enchaîne des décisions, la question du contrôle devient centrale. Qui valide quoi, à quel moment, sur quelle base ? Le dev n’est pas prêt de disparaître : il est en train de devenir le seul humain dans une boucle qui tourne de plus en plus vite.