Vous n'êtes pas ingénieur logiciel, et ce n'est pas grave

Vous n'êtes pas ingénieur logiciel, désolé, mais ce n'est pas grave.

Je sais, cela peut être difficile à entendre. Mais je suis sûr que vous avez d'autres qualités.

Si vous avez trouvé cet article par vous-même, vous n'êtes peut-être pas la personne ciblée. En revanche, si je vous l'ai envoyé personnellement, vous devriez probablement le lire et prendre un moment pour y réfléchir.

De plus, cet article est axé sur le développement web et les domaines connexes. Je ne parlerai pas d'autres domaines de l'ingénierie logicielle comme les systèmes embarqués ou la science des données.

Avant d'aller plus loin, comment en sommes-nous arrivés là et de quoi discutons-nous ?

Je fais face à un réel défi ici. Alors que le code devient de plus en plus accessible, les gens ont tendance à penser qu'ils peuvent simplement se lancer et commencer à construire des systèmes complexes sans aucune connaissance, que les développeurs de logiciels ne sont qu'un trou financier sans valeur réelle. Je suis juste fatigué d'expliquer encore et encore mon métier. J'ai la liberté de rédiger mes pensées une bonne fois pour toutes de manière claire et de les partager avec quiconque pense qu'il peut faire mon travail. Alors nous y sommes.

Dans le monde d'aujourd'hui, de plus en plus de personnes écrivent du code. Toute la société se numérise. Cela signifie qu'il n'y a jamais eu un besoin aussi important d'écrire des logiciels.

Certaines personnes ont vu une opportunité de gagner de l'argent. Que diriez-vous de dire aux gens qu'ils peuvent devenir riches facilement, d'un bureau, juste en apprenant pendant 2 à 6 mois en vendant une formation ? Super idée ! Les bootcamps sont nés.

C'était une arnaque.

Apprendre à coder est beaucoup plus difficile et prend beaucoup plus de temps que 2 à 6 mois. De plus, seuls les bons développeurs peuvent gagner beaucoup d'argent. Vous ne deviendrez pas riche. Et pire encore, vous n'aurez pas de travail car le marché a été saturé par des développeurs juniors inexpérimentés, espérant trouver un emploi bien rémunéré.

Mais l'histoire ne s'arrête pas là.

Ce mouvement est arrivé avant les LLM. Avec des assistants IA comme ChatGPT ou Claude Code, et des constructeurs IA comme Loveable, V0 ou Bolt.new, la programmation n'a jamais été aussi accessible qu'aujourd'hui, et c'est terrible.

Absolument tout le monde peut maintenant écrire du code. La phrase exacte devrait être « Absolument tout le monde peut demander à un LLM de générer du code pour eux. » La barrière à l'entrée était déjà basse avec des langages comme Python. Maintenant, avec l'IA, les barrières ont disparu.

Ne vous méprenez pas. Si cela peut créer une vocation, ou permettre aux individus de s'exprimer à travers le code sans avoir à gérer toute la complexité, c'est une bonne chose.

La vérité est que l'écriture de code est la partie la plus facile du travail. Si vous la trouvez difficile, c'est probablement parce que vous êtes au début de votre parcours. Si vous pensez être ingénieur logiciel parce que vous avez suivi un bootcamp ou utilisé des outils IA, vous devriez faire une pause et continuer à lire. J'écris cet article pour vous.

Le monde réel, le monde des adultes, est beaucoup plus complexe qu'une liste de tâches en frontend écrite en HTML et CSS.

Les entreprises ont des besoins commerciaux spécifiques. La plupart du temps, elles ont du mal à les exprimer clairement. Les personnes ayant un besoin ne proviennent pas de ce domaine ; elles ne comprennent pas ce que nous faisons. C'est ok, mais en tant qu'ingénieur logiciel, votre rôle est de faire le lien.

L'un de vos défis est d'extraire le besoin, de le comprendre, de le remettre en question et de construire une vision claire et cohérente à partir de celui-ci. Ensuite, vous devez concevoir une solution appropriée. Cela fait partie de l'emploi d'ingénieur impliqué par le titre "ingénieur logiciel".

Les assistants IA et les constructeurs IA ne le feront pas magiquement seuls. Bien sûr, ils peuvent vous aider, mais ils ne comprendront pas tout le contexte commercial car il y a beaucoup de connaissances implicites et de contextes que seul un humain peut saisir.

Maintenant que nous avons tous en tête l'histoire, examinons de plus près le titre "ingénieur logiciel".

Selon la définition de Wikipédia, l'ingénierie logicielle est une branche de l'informatique et de l'ingénierie axée sur la conception, le développement, le test et la maintenance des applications logicielles. Elle consiste à appliquer des principes d'ingénierie et une expertise en programmation informatique pour développer des systèmes logiciels répondant aux besoins des utilisateurs. Les termes programmeur et codeur se chevauchent avec ingénieur logiciel, mais ils impliquent uniquement l'aspect construction d'une charge de travail d'ingénieur logiciel typique.

J'adore vraiment cette définition car elle dit absolument tout sur le travail.

Construire des logiciels implique de la science, à la fois théorique et pratique. Ce n'est pas juste une question de chance ou d'intuition. Il s'agit de comprendre, d'analyser et de résoudre des problèmes. De plus, quatre tâches sont mises en avant : concevoir, développer, tester et maintenir. Lorsque j'ai dit plus tôt que l'écriture de code est la partie la plus facile du travail, c'est parce que c'est seulement une des quatre tâches, même si c'est la plus visible. Et comparé aux autres tâches, écrire du code est un jeu d'enfant.

Et n'oubliez pas que tout cela doit être fait pour résoudre un véritable besoin utilisateur. Sinon, vous écrivez juste du code pour le simple plaisir d'écrire du code, ce qui est inutile. En utilisant des outils IA pour écrire la majeure partie de votre code, et en vous concentrant uniquement sur le code, il y a de fortes chances que vous soyez davantage un programmeur ou un codeur qu'un ingénieur logiciel.

Il y a quelque temps, j'ai écrit sur les tests. Vous devriez le lire pour avoir une première appréciation du sujet, car ce ne sont pas les constructeurs IA qui garantiront la qualité de votre code, et les tests sont vraiment difficiles.

Je ne vais pas approfondir les aspects de conception et de maintenance, mais si vous essayez de me vendre une base de données NoSQL dans une architecture microservices, j'espère que vous avez une solide compréhension des compromis impliqués, et que vous ne suivez pas simplement une tendance ou ne me récitez pas des mots à la mode que vous avez entendus sur un blog de marchand de complexité.

Faire de mauvaises hypothèses et avoir une mauvaise compréhension de l'écosystème conduit à de mauvaises décisions de conception. Cela crée ce que nous appelons de la dette technique. Et comme toute dette, vous devrez la rembourser un jour, et plus vous en accumulez, plus il devient difficile de la gérer. En essayant de construire des logiciels sans les connaissances requises, vous devenez un générateur de dette technique. Rien de plus.

Dans un contexte personnel, ce n'est pas un problème. C'est votre bac à sable, amusez-vous avec. Vous pouvez jeter votre code ou le réécrire. Dans un contexte commercial, les enjeux sont beaucoup plus élevés. De mauvaises décisions de conception peuvent conduire à des échecs de projet, à des ressources gaspillées et à des occasions perdues. Il est crucial de prendre le temps de prendre des décisions éclairées.

Si vous lisez encore, j'espère vous avoir convaincu de la complexité du rôle d'un développeur logiciel. Si ce n'est pas le cas, laissez-moi vous montrer quelque chose.

Les applications modernes ne sont pas simples d'un point de vue externe et selon l'échelle à laquelle vous travaillez, la complexité peut rapidement escalader. Pour cette partie, imaginons une application assez standard avec un trafic gérable. (c'est-à-dire pas à l'échelle de Facebook, Uber ou Twitter)

Votre application a un frontend. Avec ce frontend, écrit en utilisant HTML, CSS, certainement avec un framework comme Tailwind CSS ou Panda CSS, et JavaScript. Pour le JavaScript, vous pouvez utiliser une bibliothèque comme Alpine, Unpoly, HTMX, Hotwire ou Livewire si vous utilisez Laravel. Mais vous pourriez décider d'utiliser un framework plus robuste comme React, Vue.js, Angular, Svelte, etc. Vous pourriez également préférer utiliser un méta-framework comme Next, React Router, Nuxt, SvelteKit. Mais nous n'avons pas encore terminé. Le frontend fournit une interface utilisateur pour offrir une expérience utilisateur à un utilisateur, une personne réelle qui a un besoin réel. Vous devrez donc considérer l'accessibilité, la performance, la réactivité. Cela nécessite de passer un certain temps à réfléchir à l'interface utilisateur (UI) et à l'expérience utilisateur (UX). Honnêtement, c'est beaucoup de travail, donc vous pourriez envisager de choisir une bibliothèque de composants, ou de construire la vôtre sur la base du système de design de votre entreprise. Si vous utilisez Vue, vous pourriez choisir Nuxt UI, PrimeVue, Quasar, Vuetify, Reka UI, Shadcn-vue, Native UI, Volt UI, Daisy UI, Flowbite Vue, Element Plus, Ant Design Vue, Ark UI ou Vuestic UI. Peut-être devrais-je aussi mentionner qu'en fonction de l'architecture, vous pourriez avoir besoin d'une couche de récupération de données comme TanStack Query, et si vous construisez beaucoup de tables, TanStack Tables. Je vous épargne les bibliothèques de gestion de stock et les bibliothèques d'animation, vous pourriez être submergé.

C'est juste le frontend, et je n'ai pas mentionné Vite. Oui, c'est déjà beaucoup.

Maintenant, imaginez le backend, avec tous les différents langages et frameworks disponibles, les systèmes de bases de données avec SQL, NoSQL, TimeSeries, bases de données graphiques et chaque variante pour chacune, les systèmes de queue comme RabbitMQ, Kafka, ou une simple table de base de données, les systèmes de cache comme Redis ou Memcached, toutes les versions gérées fournies par les fournisseurs de cloud, les différentes techniques utilisées pour tester, construire et déployer votre application, en utilisant un pipeline CI/CD, Docker, Compose, Swarm, ou Kubernetes, avec un environnement de staging, et toute la gestion des dépôts. Il y a tant à prendre en compte, tant à apprendre, et tant de nouveautés chaque jour qu'il est instantanément facile de prendre du retard si vous ne restez pas à jour.

Ai-je mentionné la sécurité, l'observabilité, la haute disponibilité, l'évolutivité, l'élasticité ou le déploiement ? Parce que cela fait également partie du travail.

Honnêtement, vous n'avez pas à savoir comment utiliser tout ce que j'ai mentionné. Mais si 90% des mots vous semblent inconnus, alors essayer de faire semblant de savoir ce que vous faites est une terrible idée. Pour vous, pour votre équipe, et pour toute l'entreprise pour laquelle vous travaillez.

La dette technique est réelle. Dire "je ne sais pas" est une réponse honnête et complète.

L'informatique est devenue une infrastructure, mais cela ne fonctionne pas comme une infrastructure.

Cet article vaut également la peine d'être lu :

Programmers: Stop Calling Yourselves Engineers

Et cette vidéo vaut la peine d'être regardée :

Building High-Trust Environments par John Drexler

Si vous souhaitez commencer une carrière en tant qu'ingénieur logiciel ou développeur logiciel, je dois vous informer que cela nécessite des sacrifices et de la dévotion. Comme beaucoup d'autres professions, vous ne deviendrez pas bon simplement en lisant ou en regardant une vidéo ou en écoutant un professeur pendant quelques heures. Vous ne deviendrez pas le meilleur sans vous immerger complètement dans le domaine.

Peut-être qu'en voyant un développeur logiciel à l'œuvre, tout semble simple. C'est probablement parce qu'il connaît son travail sans avoir à vous vendre de la complexité pour justifier son existence.

Il est difficile de vendre du simple, car le simple semble facile, et qui veut payer pour cela ? D'après Merchants of Complexity de David Heinemeier Hansson