L'industrie du développement logiciel est en train de changer — définitivement

En 2003, j'ai fondé DCSL Software, qui est devenu plus tard One Beyond. J'en suis sorti en 2023 après avoir développé l'entreprise à l'international et l'avoir fait croître à plus de 300 personnes. Depuis, j'ai fondé une start-up de robotique et levé plus de 4 millions de livres sterling en financement d'amorçage.

Je ne m'attendais jamais à écrire à nouveau des logiciels de production. J'ai arrêté de coder au quotidien en 2014, non pas parce que je ne pouvais pas le faire, mais parce que c'est ce qui se passe lorsqu'une entreprise se développe. Vous embauchez des personnes meilleures que vous dans l'exécution, vous vous concentrez sur le leadership, et progressivement le clavier s'éloigne. Pendant près d'une décennie, cela m'a semblé tout à fait naturel.

Ce à quoi je ne m'attendais pas, c'est que, près de dix ans plus tard, je me retrouverais à nouveau dans le siège du développeur — non pas par nostalgie, mais de manière pratique. Non pas en m'amusant, mais en construisant une plateforme robotique véritablement complexe. Et non pas en réapprenant tous les frameworks ou langages qui m'avaient dépassé, mais en travaillant d'une manière fondamentalement différente.

Ce changement personnel est le signal le plus clair que j'ai vu qu'il y a eu un changement structurel dans le développement de logiciels.

Comment nous concevions les logiciels autrefois — et pourquoi

Lorsque j'ai commencé, nous étions fermement dans l'ère du cycle en cascade. Ce n'était pas une idéologie, c'était de l'économie. Les logiciels étaient lents et coûteux à construire, donc la seule approche sensée était de réfléchir très attentivement en amont.

Nous rédigions des spécifications détaillées parce que nous devions le faire. Les contrats en dépendaient. La livraison en dépendait. Rédiger une bonne spécification était une compétence spécialisée, et j'étais plutôt bon dans ce domaine. Je pouvais visualiser à quoi pourrait ressembler le produit fini avant qu'il n'existe, prévoir les zones de complexité et décrire le comportement avec suffisamment de précision pour qu'une équipe puisse le construire.

Cette capacité était rare et difficile à enseigner. Beaucoup de gens avaient du mal avec cela parce qu'imaginer un système complexe qui n'existe pas encore est vraiment difficile. Mais c'était important, car se tromper tard dans le processus était douloureux et coûteux.

Au fil du temps, l'industrie s'est orientée vers l'Agile. Publiquement, cela a été présenté comme une meilleure façon de répondre au changement. Discrètement, c'était aussi une reconnaissance que pour les grands systèmes à long terme, aucune spécification ne survit intacte. Les entreprises changent, les utilisateurs changent, la technologie change, et prétendre le contraire causait souvent plus de mal que de bien.

L'Agile était pragmatique, mais il avait un coût. Nous avons largement abandonné la conception approfondie en amont et l'avons remplacée par une découverte incrémentale. Cela fonctionnait, mais cela normalisait également un état d'esprit où penser trop loin à l'avance était considéré comme inutile ou même risqué.

Ce qui a changé — et pourquoi j'ai recommencé à construire

La raison pour laquelle j'ai pu revenir au développement pratique n'est pas que j'ai soudainement trouvé le temps ou le désir de réapprendre une décennie d'outils. C'est parce que l'IA a fondamentalement changé le coût de l'expérimentation.

C'est la partie qui est souvent mal comprise. Le véritable changement n'est pas que le code est plus rapide à écrire. C'est qu'essayer des choses est maintenant bon marché, rapide et largement réversible.

Des choses qui auraient autrefois pris des semaines de développeur peuvent maintenant être tentées en quelques minutes. Vous pouvez explorer une approche, voir comment elle se comporte, la rejeter entièrement et essayer une direction différente avec très peu de pénalité. Cela n'était tout simplement pas possible auparavant.

Dans le passé, il y avait un attachement émotionnel et financier fort au code. Si quelque chose prenait trois semaines à deux développeurs pour être construit, vous étiez naturellement réticent à 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 ce qui m'a ramené. Je peux maintenant opérer au niveau où je suis le plus fort — comprendre le problème, façonner le système, repérer quand la complexité s'installe — pendant que l'IA gère les mécanismes. Je n'écris pas de code comme je le faisais dans ma vingtaine. Je le dirige, je le raffine, je le corrige et parfois je l'empêche de partir dans une direction complètement erronée. En pratique, cela ressemble beaucoup plus à diriger une équipe qu'à écrire du code. Vous êtes effectivement le patron — définissant la direction, examinant la production, repérant les raccourcis paresseux et résistant lorsque quelque chose ne semble pas correct.

Pourquoi la conception reste importante — plus que jamais

Il serait facile de supposer que cette nouvelle liberté rend la conception moins importante. En réalité, elle la rend plus importante.

Avoir une idée claire et détaillée de ce que vous essayez de construire est toujours extrêmement précieux. En fait, cela améliore activement la production de l'IA. Plus l'intention est claire, meilleurs sont les résultats. Une pensée vague produit simplement des systèmes vagues plus rapidement. Ce qu'il est important de comprendre, c'est que l'IA se comporte beaucoup comme une personne. Elle veut être utile. Elle veut vous donner une réponse. Si vous êtes vague, elle comblera les lacunes. Si vous êtes négligent, elle fera des suppositions. Si vous ne la remettez pas en question, elle continuera avec confiance sur la mauvaise voie.

La différence est que la conception n'est plus un artefact fragile et unique qui doit survivre inchangé pendant des années. Elle est devenue un guide pour l'expérimentation plutôt qu'une contrainte. Vous pouvez avoir une vision forte de la direction que vous prenez tout en étant prêt à essayer, rejeter et faire évoluer le chemin qui vous y mène.

La nouvelle compétence consiste à savoir quand l'exploration est productive et quand elle n'est que du bruit. L'IA continuera joyeusement à générer de la structure bien après qu'elle aurait dû être simplifiée. Elle ne sait pas quand un fichier est devenu trop volumineux, quand une abstraction fuit, ou quand quelque chose qui "fonctionne" aujourd'hui causera de la douleur plus tard. Ces instincts viennent toujours de l'expérience.

Ce que cela brise dans l'industrie

Une fois que l'expérimentation devient bon marché, de nombreuses hypothèses de longue date ne tiennent plus. La planification ne consiste plus à tout verrouiller à l'avance. Il s'agit de définir l'intention, les contraintes et les limites.

L'estimation devient moins une question de prédiction de l'effort et plus une question de compréhension de l'espace que vous explorez.

Et notre relation avec le code change entièrement. Il y a beaucoup moins d'attachement aux implémentations spécifiques et beaucoup plus d'attention portée au comportement, à la structure et aux résultats.

C'est pourquoi l'industrie du développement de logiciels se sent troublée. Beaucoup de gens essaient d'appliquer d'anciens modèles mentaux à de nouveaux outils. Cela fonctionne pendant un certain temps, mais cela passe à côté de l'essentiel.

Le véritable changement

La raison pour laquelle je suis convaincu que ce changement est permanent est simple : je ne construirais pas à nouveau autrement.

La seule raison pour laquelle je peux de manière crédible revenir au développement pratique après une décennie d'absence est que les contraintes qui m'ont poussé dehors en premier lieu ne s'appliquent plus. Les logiciels peuvent maintenant évoluer grâce à une expérimentation guidée d'une manière qui n'était tout simplement pas possible auparavant.

Cela ne signifie pas que l'expérience compte moins. Cela signifie qu'elle compte différemment. La valeur ne réside plus dans le fait de se souvenir de la syntaxe ou des frameworks. Elle réside dans le jugement, la structure et le fait de savoir quand s'arrêter.

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