Entrer dans une nouvelle ère du code

Si vous pensiez que chaque nouvel outil n'apportait qu'un léger gain de productivité, il faut désormais changer de question. Ce qui se passe en ce moment n'est pas une simple automatisation : cela déplace l'endroit même où les développeurs investissent leur temps. Ce texte est une trace de la manière dont j'ai ressenti ce changement au cours des derniers mois et des critères avec lesquels j'ai fini par l'accepter.

Le sujet n'est pas la vitesse, mais le déplacement du rôle.

Moi, il y a trois mois#

Il y a à peine trois mois, je considérais encore l'IA générative comme un simple outil d'autocomplétion très intelligent.

La première fois que j'ai utilisé GitHub Copilot, j'ai été impressionné. En écrivant un nom de fonction ou en laissant un commentaire, il ajoutait une implémentation assez plausible, et il était clair qu'il réduisait le travail répétitif. Mais cela s'arrêtait là. Je pensais qu'il pouvait être un outil qui améliorait un peu la productivité, sans pour autant transformer le rôle même du développeur.

Ensuite, j'ai essayé Gemini CLI. L'expérience de créer et de modifier du code en dialoguant dans le terminal était assez fraîche. L'interaction semblait plus naturelle que celle de Copilot, et la compréhension du contexte paraissait meilleure. Pourtant, ma vision restait globalement la même. Au fond, je pensais qu'il ne s'agissait que d'un outil plus avancé, et que la vraie conception ainsi que les décisions importantes restaient toujours de ma responsabilité.

Puis j'ai découvert Cursor. Le fait d'avoir l'IA intégrée à tout l'IDE produisait clairement une expérience différente. Le voir naviguer entre les fichiers, modifier le code, saisir dans une certaine mesure la structure du projet et même proposer des refactorings m'a donné l'impression d'un nouveau cap franchi. Malgré cela, je pensais encore que la logique métier complexe et la conception de l'architecture devaient, au bout du compte, rester tenues par un humain jusqu'au bout. Pour être honnête, je croyais aussi que ma place ne serait pas vraiment ébranlée.

Avec le recul, je vois que je sous-estimais profondément la vitesse du changement. En réalité, le point d'inflexion a commencé avec la sortie d'Opus 4.5 à la fin du mois de novembre 2025.

Le choc#

Ce qui a fait évoluer ma manière de penser n'avait rien de spectaculaire. Le développement et l'exploitation de ce blog en sont la preuve.

Le service de blog lui-même n'est pas l'implémentation la plus difficile qui soit. Malgré tout, auparavant, j'aurais estimé qu'il faudrait au minimum quelques jours, au maximum quelques semaines, pour le planifier, construire les écrans, affiner la forme du déploiement et régler jusqu'aux petites tâches de connexion. Désormais, ce type de travail peut être mis en place en peu de temps, grosso modo en une journée.

Voir le design, l'implémentation, la mise au propre et la préparation de la publication être poussés jusqu'à l'étape de mise en ligne avec seulement quelques prompts m'a paru bien plus radical que je ne l'avais imaginé.

Ce que les agents de code m'inspirent aujourd'hui, c'est de la peur.

Parce que j'ai senti que l'expertise que j'avais accumulée pendant longtemps pouvait être comprimée sous une autre forme plus vite que je ne l'imaginais. Jusqu'ici, je comprenais l'évolution des outils d'IA pour le code de manière linéaire. De Copilot à Gemini CLI, puis de Gemini CLI à Cursor, je pensais que les choses s'amélioraient peu à peu. Puis, à un moment, le changement m'a frappé comme s'il comblait d'un seul coup un vide qui, jusque-là, semblait abstrait.

Pour celles et ceux qui n'ont pas encore vraiment expérimenté la combinaison de Claude Code et d'Opus 4.5, ce texte peut paraître un peu exagéré. Il y a quelques mois encore, j'aurais pensé la même chose. Mais avec le recul, il s'agit moins d'un simple confort supplémentaire dans l'écriture du code que d'un changement qui redéfinit l'endroit où les développeurs doivent consacrer leur temps.

De la peur aux critères#

Je ne pense pas qu'il faille cacher le fait que la première émotion qui m'a submergé a été la peur. Plus l'implémentation s'accélère, plus on peut avoir l'impression que la valeur du développeur diminue.

Dans le secteur, on entend effectivement de plus en plus qu'une époque arrive où des individus seuls, notamment des profils proches de l'application builder, peuvent créer des produits et obtenir de plus grands résultats avec moins de monde. Autrefois, cela me semblait une projection un peu exagérée. Après l'avoir ressenti directement, le poids de ces mots est devenu différent.

Cela ne rend pas la conclusion simple pour autant. Je ne pense pas que le rôle humain soit en train de disparaître. Au contraire, à mesure que moins de personnes deviennent capables d'accomplir des choses plus importantes, la capacité de jugement et les critères de revue de chacun deviennent bien plus cruciaux.

Avant, la vitesse d'implémentation était souvent la principale contrainte d'une équipe. Désormais, les questions les plus importantes sont ce qu'il faut construire, dans quel ordre le valider et à quel endroit maîtriser le risque.

C'est à cet endroit que j'ai retenu trois critères.

• Définir clairement le problème
• Concevoir un contexte que l'IA peut comprendre
• Assumer, côté humain, la responsabilité du résultat final

Plus la technologie va vite, plus ces trois éléments pèsent lourd.

L'évolution des outils, et Claude Code#

Si je résume simplement le mouvement que j'ai ressenti, voilà à quoi il ressemble.

• Copilot se rapprochait de l'autocomplétion. Une fois la direction posée, c'était un outil qui enchaînait rapidement sur la suite.
• Gemini CLI se rapprochait d'un assistant conversationnel. On posait des questions, on recevait des réponses, et le résultat se construisait progressivement.
• Cursor donnait l'impression d'un pair programmer intelligent. Il essayait de comprendre le contexte du projet et donnait la sensation de pousser l'implémentation avec moi.

À l'inverse, Claude Code m'a paru plus proche d'un agent qui franchit une étape supplémentaire. On lui donne un objectif, il examine les fichiers concernés, comprend la structure, relie les changements nécessaires et poursuit son raisonnement jusqu'aux points qu'il faut vérifier.

Bien sûr, le résultat n'est pas toujours parfait. Mais la différence importante, c'est que je passe rapidement du rôle de celui qui écrit lui-même chaque ligne à celui qui fixe la direction, énonce les critères et passe le résultat en revue.

Ainsi, mon rôle n'est plus seulement celui d'un exécutant ; il se rapproche davantage de celui d'un architecte et d'un relecteur. Plus que la vitesse à laquelle j'écris du code, ce qui compte désormais, c'est de décider quels objectifs découper, à quelle granularité les confier, ce qu'il faut automatiser et ce qu'il faut vérifier soi-même jusqu'au bout.

Moi aujourd'hui#

Aujourd'hui, j'utilise activement l'IA dans le développement. Dire que ma productivité a augmenté ne suffit même plus pour décrire à quel point ma manière de travailler a changé. Il n'est plus rare qu'une fonctionnalité qui aurait pris plusieurs jours auparavant prenne forme en une seule journée.

Cela ne veut pas dire que le rôle humain a diminué. Au contraire, la sécurité, la gestion des exceptions, l'intégrité des données, la cohérence structurelle et le jugement produit sont revenus avec une responsabilité encore plus forte.

Le changement intéressant, c'est que la vitesse de développement elle-même n'est plus le goulot d'étranglement. Avant, la contrainte clé était le nombre de jours nécessaires pour implémenter une fonctionnalité. Aujourd'hui, il est bien plus important de savoir si cette fonctionnalité est réellement nécessaire, selon quels critères on va l'expérimenter et la valider, et jusqu'où l'on considère qu'elle constitue la première version du produit. La qualité du jugement pèse désormais davantage dans le résultat que les limites techniques.

C'est pourquoi, ces jours-ci, avant de commencer un travail, j'écris d'abord en une phrase l'objectif de la fonctionnalité, les conditions de réussite et le périmètre exclu. Ensuite, je découpe le travail en petites unités, et à la fin je sépare les éléments qui doivent être revus directement par un humain. J'en viens à penser que bien utiliser l'IA ne consiste pas à lancer davantage de demandes vagues, mais à fixer des critères plus clairs.

Et maintenant#

Mon objectif est clair. Je veux développer des services de niveau production dans un temps court et transformer ce processus en quelque chose de répétable.

Pour moi désormais, développer ne consiste plus seulement à écrire du code, mais à hisser un produit jusqu'à un niveau capable de tenir dans un environnement réel d'exploitation. Je veux constater moi-même jusqu'où ce changement peut aller.

C'est pourquoi je veux continuer à écrire ce blog. Il ne sera pas simplement un espace où résumer des résultats, mais un journal de la manière dont j'ai accueilli ces outils, des endroits où mon point de vue a changé et des critères avec lesquels je suis en train de m'adapter. Que je réussisse ou que j'échoue, je crois que les idées et les tâtonnements de cette période valent largement la peine d'être consignés.

La nouvelle ère du code ne fait pas disparaître le rôle du développeur ; elle le rend plus compact et plus net. Le centre de gravité se déplace d'une époque où l'on écrivait soi-même chaque ligne vers une époque où l'on définit le bon problème et où l'on vérifie le résultat.

À l'avenir, l'écart ne viendra pas tant de la quantité de code produite que de la capacité à répéter plus vite de meilleurs jugements et à générer des livrables réellement exploitables.