Je viens de réaliser une chose assez intéressante — le secteur du développement logiciel est en train de subir une transformation que je n'avais jamais vue en plus de 20 ans de carrière.

Il y a un peu plus de vingt ans, j'ai commencé chez DCSL Software (, qui est devenu plus tard One Beyond ). J'ai quitté l'entreprise en 2023 alors qu'elle comptait plus de 300 employés et opérait à l'échelle mondiale. Ensuite, j'ai fondé une startup dans la robotique et levé plus de 4 millions de livres sterling. En réalité, je n'ai jamais pensé que je reviendrais à coder.

Depuis 2014, j'ai arrêté d'écrire du code au quotidien. Ce n'est pas parce que je ne pouvais pas, mais simplement parce que c'était une évolution naturelle à mesure que l'entreprise se développait. Vous embauchez des personnes meilleures que vous, vous vous concentrez sur le leadership, et peu à peu, le clavier devient une étrangeté. Dix ans comme ça semblent tout à fait normaux.

Mais la surprise, c'est qu'il y a peu, je me suis retrouvé à revenir en tant que développeur — non pas par nostalgie, mais par nécessité concrète. Je construis une plateforme robotique vraiment complexe. Et ma façon de travailler est totalement différente de celle d'avant.

Ce changement personnel m'a clairement montré : quelque chose de fondamental a changé dans notre approche du développement logiciel.

En regardant en arrière, nous travaillions selon le modèle en cascade. Ce n'était pas une théorie, mais une économie pure. Le code coûte cher et prend du temps à construire, donc la seule approche rationnelle était de réfléchir soigneusement dès le départ. Nous écrivions des spécifications détaillées parce que c'était nécessaire — contrats, livraisons, tout dépendait d'elles. Rédiger une bonne spécification était une compétence rare, et j'étais plutôt bon dans ce domaine. Je pouvais imaginer à quoi ressemblerait un produit fini avant même qu'il n'existe, prévoir les parties complexes et décrire le comportement avec une précision suffisante pour qu'une équipe puisse s'en servir comme base.

Ensuite, l'industrie est passée à Agile. En public, parce que c'était mieux pour faire face au changement. En privé, parce que nous avons réalisé qu'aucune spécification ne pouvait exister intacte dans de grands systèmes à long terme. Les entreprises changent, les utilisateurs changent, la technologie change. Agile est utile, mais il a un coût. Nous avons abandonné la conception approfondie dès le départ, pour explorer progressivement. Cela fonctionne, mais cela a aussi normalisé une pensée selon laquelle penser trop loin en amont est considéré comme inutile ou même risqué.

Aujourd'hui, je réalise que la raison pour laquelle je peux revenir au code n'est pas parce que j'ai soudainement du temps ou envie d'apprendre une nouvelle décennie d'outils. C'est parce que l'IA a fondamentalement changé le coût des tests.

Les gens ont souvent une mauvaise compréhension de ce point. Le vrai changement n'est pas que le code s'écrit plus vite. C'est que tout peut maintenant être testé rapidement, à moindre coût, et la plupart du temps, de manière réversible. Ce qui prenait autrefois plusieurs semaines pour un développeur peut maintenant être testé en quelques minutes. Vous explorez une approche, voyez si ça fonctionne, puis l'abandonnez complètement et essayez une autre direction, presque sans pénalité. Cela était impossible auparavant.

Autrefois, le code créait une forte attache émotionnelle et financière. Si quelque chose prenait deux développeurs trois semaines à construire, il est compréhensible de ne pas vouloir le jeter. Les décisions se durcissaient tôt, pas toujours parce qu'elles étaient justes, mais parce que les inverser était trop coûteux. Cette contrainte a disparu, et c'est la raison pour laquelle je suis revenu.

Aujourd'hui, je travaille au niveau où je suis le plus à l'aise — comprendre le problème, façonner le système, repérer la complexité — pendant que l'IA gère les mécanismes. Je ne code pas comme à vingt ans. Je le dirige, l'affine, le corrige, et l'empêche parfois de partir dans la mauvaise direction. Ce sentiment ressemble plus à diriger une équipe qu'à coder. Vous êtes vraiment le maître — définir la direction, examiner les résultats, repérer les raccourcis.

Une idée fausse courante est que cette nouvelle liberté rend la conception moins importante. En réalité, c'est tout le contraire. Avoir une idée claire et détaillée de ce que vous construisez reste extrêmement précieux. Cela améliore même la sortie de l'IA. Plus votre intention est claire, meilleur sera le résultat. La pensée vague ne fait que produire des systèmes flous plus rapidement.

L'IA fonctionne comme une personne. Elle veut aider, fournir des réponses. Si vous êtes vague, elle comble les lacunes. Si vous êtes négligent, elle fait des hypothèses. Si vous ne la challengez pas, elle continue avec confiance dans la mauvaise direction.

Mais la conception n'est plus un produit fragile, qui doit durer des années sans changer. Elle devient un guide pour les tests, pas une contrainte. Vous maintenez une vision forte de votre objectif tout en étant prêt à tester, éliminer et faire évoluer le chemin pour y parvenir.

La nouvelle compétence consiste à savoir quand explorer efficacement et quand cela n'est qu'un bruit. L'IA continuera à créer des structures longtemps après qu'il aurait été préférable de simplifier. Elle ne sait pas quand un fichier est trop gros, quand une abstraction fuit, ou quand ce qui fonctionne aujourd'hui causera des douleurs demain. Ces instincts viennent toujours de l'expérience.

Quand les tests deviennent peu coûteux, beaucoup d'hypothèses à long terme ne tiennent plus. La planification ne consiste plus à tout verrouiller à l'avance. C'est définir des intentions, des contraintes et des limites. Moins prévoir l'effort, plus comprendre l'espace que vous explorez. Notre relation avec le code change radicalement. Moins d'attachement à des déploiements spécifiques, plus d'attention au comportement, à la structure et aux résultats.

C'est pourquoi le secteur du développement logiciel semble instable. Beaucoup essaient d'appliquer d'anciens modèles mentaux à ces nouveaux outils. Cela fonctionne un temps, mais rate l'essentiel.

Je suis convaincu que ce changement est permanent, pour une raison très simple : je ne reconstruirais pas autrement. La seule raison pour laquelle je fais confiance à revenir à un développement logiciel pratique après une décennie, c'est que les contraintes qui m'avaient initialement poussé à partir ne s'appliquent plus. Le code peut maintenant évoluer via des tests guidés d'une simplicité impossible auparavant.

Cela ne signifie pas que l'expérience est moins importante. Cela signifie qu'elle devient différente. La valeur n'est plus dans la mémorisation de la syntaxe ou des frameworks. Elle réside dans le jugement, la structuration et la capacité à savoir quand s'arrêter.

Ce n'est pas la fin du développement logiciel. Mais c'est la fin du vieux modèle. Et une fois que vous travaillez de cette manière, il n'y a pas de retour en arrière possible.