Quand je suis sorti de ma formation de développeur, je pensais que mon métier consistait à écrire du code. Quelques mois plus tard, l’IA générative est arrivée. Aujourd’hui, j’écris probablement moins de code qu’à l’époque — mais je développe davantage. Cette bascule, je ne l’ai pas choisie du jour au lendemain : j’ai hésité, comme le reste de ma promo, avant de sauter le pas pour ne pas décrocher des outils qui allaient de toute façon structurer le métier.
Le déclic n’était pas technique
Je n’ai pas adopté l’IA parce qu’elle codait plus vite que moi. Au début, c’était même l’inverse : relire, corriger, recadrer une suggestion prenait parfois plus de temps que d’écrire la fonction moi-même. Le déclic, c’était autre chose — la conviction que l’outil allait rester, et qu’il valait mieux apprendre à bien s’en servir maintenant plutôt que d’arriver dessus en retard dans deux ou trois ans.
Il y a un discours qui dit que l’IA tue le métier de développeur. Je ne le partage pas. Je pense que le métier évolue, comme il a évolué à chaque couche d’abstraction qu’on a ajoutée avant — l’assembleur, les frameworks, le cloud. Ce qui change avec l’IA, c’est la vitesse et l’ampleur du déplacement. Et concrètement, pour moi, ça s’est traduit par un déplacement précis : je passe de moins en moins de temps à écrire des lignes, et de plus en plus à décider ce qu’elles doivent faire.
Ce que je faisais avant, ce que je fais maintenant
En sortie de formation, une tâche ressemblait à ça : lire un besoin, réfléchir à la structure en l’écrivant, taper le code ligne après ligne, déboguer par itérations, avancer. Le code se pensait en même temps qu’il s’écrivait. Le clavier était l’endroit où la réflexion avait lieu.
Aujourd’hui, la même tâche se découpe autrement. La réflexion arrive avant : qu’est-ce que je veux exactement, quelles sont les contraintes réelles, qu’est-ce qui ne doit surtout pas se passer. Ensuite vient la production — souvent avec un agent qui écrit une bonne partie du code. Et le plus gros du temps, en vérité, part dans la relecture : est-ce que ce diff fait ce que j’ai demandé, est-ce qu’il introduit une faille, une dette, une incohérence avec le reste du projet. Je signe chaque ligne qui part en prod, que je l’aie tapée ou non.
Ce déplacement, je ne l’ai pas décidé un matin. Je l’ai constaté après coup, en regardant comment mes journées avaient changé de forme.
Quests : le projet qui a rendu ça concret
C’est sur Quests que ce changement de posture m’est vraiment apparu. Quests, c’est une application événementielle que j’ai imaginée après la Gamers Assembly 2025 — un système de quêtes et de classement en temps réel pour un salon gaming grand public, avec des centaines de participants et une partie du public mineure.
La partie technique ne m’inquiétait pas particulièrement — c’était un terrain que je connaissais déjà. Les vrais risques étaient ailleurs : l’afflux de données de centaines voire de milliers de joueurs, la saturation, l’infrastructure réseau à tenir sur deux jours sans rien casser au pire moment, et toute la partie légale, RGPD en tête.
Pour ces trois sujets, la méthode a été la même : faire lister par plusieurs IA les risques et points de rupture probables (bases légales et droits des mineurs côté RGPD, scénarios d’abus côté sécurité, endpoints les plus sollicités aux pics de connexion), confronter leurs réponses entre elles, et vérifier ce qui restait flou sur des sources fiables. Jamais de « écris-moi la sécurité » ou « rends-moi ça conforme » en une commande — des hypothèses à vérifier, des décisions à prendre ensuite. Le RGPD est la partie que j’ai le plus creusée, je l’ai racontée en détail dans un article dédié : quelles données garder, comment rattacher un mineur à un adulte, ce qui reste fermé par défaut.
Ce que j’ai réellement apporté sur ce projet n’était pas d’écrire plus vite du code. C’était d’utiliser des outils pour explorer des champs que je ne maîtrisais pas encore, avant de choisir moi-même ce qui compte vraiment.
Une période creuse qui a joué un rôle
Il faut que je sois honnête sur le contexte, parce qu’il compte dans cette histoire. À la sortie de ma formation, je n’ai trouvé aucun contrat de développeur junior — au moment où je suis sorti de formation, je suis tombé sur un marché particulièrement difficile pour les profils juniors. J’ai utilisé cette période creuse pour suivre une formation complémentaire en UI Design, histoire de muscler ma sensibilité à l’accessibilité et aux bonnes pratiques. Puis je suis reparti en recherche d’emploi, toujours sans résultat pour l’instant, tout en gardant une activité freelance : des projets clients, et des projets personnels menés à fond, comme Quests.
Je le dis parce que ça remet les choses à leur place. Je n’ai pas découvert ce rôle de pilote de conception en théorie, dans un article de blog sur l’avenir du métier. Je l’ai découvert en ayant du temps, l’envie de tenir un projet concret jusqu’au bout, et des outils qui m’ont permis de repousser mes propres limites sur un sujet — le RGPD — que je n’aurais probablement pas attaqué aussi sérieusement seul, ou pas si vite.
Ce qui ne change pas
Ce que l’IA ne fait pas à ma place, c’est juger si une décision est la bonne. Elle peut me proposer six façons de modéliser un compte de mineur rattaché à un adulte ; c’est à moi de choisir laquelle correspond à ce que je veux que l’appli protège vraiment, et de l’assumer si elle est un jour remise en question. Il m’arrive aussi de rejeter entièrement une proposition quand l’agent part dans une mauvaise direction : la rapidité de génération ne remplace jamais la compréhension du projet. Plus l’agent produit de code vite, plus cette relecture pèse lourd dans ma journée — pas l’inverse.
Ce changement de façon de travailler a aussi créé un problème auquel je ne m’attendais pas : mesurer mon propre travail est devenu beaucoup plus difficile. C’est pour ça que j’ai fini par construire Project Timeline, une extension VS Code qui mesure, projet par projet, mon temps de travail réel face à mon temps avec un agent actif. Pas pour prouver un gain de productivité, mais parce que je ne savais plus répondre simplement à une question toute simple : sur ce projet, j’ai fait quoi, et combien de temps ça m’a vraiment pris.
Ce que j’en retire
Le métier n’a pas rétréci, il s’est déplacé. Écrire du code reste une compétence nécessaire — sans elle, impossible de juger si ce qu’un agent produit est correct, sécurisé, adapté au projet. Mais la valeur que j’apporte n’est plus dans la vitesse de frappe. Elle est dans la capacité à poser le bon cadre avant de commencer, à repérer ce qui cloche dans un résultat produit vite, et à prendre les décisions qu’aucun outil ne peut prendre à ma place — parce qu’elles engagent quelque chose sur quoi il n’y a pas de bonne réponse générique : les données d’un mineur, la robustesse d’un système en prod le jour d’un événement, la dette qu’on accepte ou pas.
Je ne sais pas encore où ça mène pour le marché de l’emploi côté juniors — c’est une question plus large que ce billet. Mais pour ma pratique à moi, la réponse est déjà claire : je développe différemment, pas moins.