Demandez à un ingénieur ce qu'il a fait cette semaine, et bien peu de la réponse consistera à taper de la nouvelle logique dans un fichier vide.
Où passe réellement le temps
L'image publique du métier, c'est la composition. La réalité se rapproche davantage de l'archéologie, de la négociation et de la réparation.
Lire du code existant pour comprendre ce qu'il fait. Reproduire un bug signalé. Relire le changement de quelqu'un d'autre. S'intégrer à un système dont la documentation est obsolète. Attendre un build. Discuter d'une approche. Déployer. Enquêter sur pourquoi le déploiement s'est comporté différemment de l'environnement de test. Réparer quelque chose qui fonctionnait depuis deux ans et qui s'est arrêté.
Écrire du nouveau code est une part réelle du travail, et ce n'est pas la plus grande part, et c'est rarement ce qui détermine si le projet réussit.
La contrainte sur la plupart des équipes logicielles, c'est la compréhension et la coordination, pas la vitesse de frappe.
Cela a une implication directe pour la formation. Un programme de développement entièrement centré sur les langages et les frameworks forme à la plus petite moitié du métier. Les compétences qui décident du résultat, lire des systèmes inconnus, bien relire, concevoir pour le changement, communiquer une décision technique, sont enseignables et généralement laissées à l'imprégnation.
Ce que couvre la direction
Le périmètre : architecture, code, tests, interfaces de programmation, gestion de version, déploiement et travail en équipe.
Quatre domaines.
Construction. Langages, conception, interfaces, et l'art d'écrire du code que d'autres peuvent modifier.
Vérification. Tests à tous les niveaux, relecture, et la discipline de savoir ce qui a réellement été vérifié.
Livraison. Gestion de version, intégration continue, déploiement et pratique de mise en production.
Collaboration. Travailler en équipe sur un système partagé, où vit l'essentiel de la difficulté du logiciel commercial.
La plus forte hausse d'emplois de tout le tableau
Cela mérite d'être posé précisément, car la conversation publique sur ce métier s'est brouillée.
Le Bureau of Labor Statistics des États-Unis projette une croissance de 15,8 % de l'emploi de développeur logiciel entre 2024 et 2034, soit 267 700 emplois de plus. Dans ce même ensemble de projections, c'est la plus forte hausse en valeur absolue parmi les métiers technologiques suivis, supérieure en chiffres bruts aux data scientists et aux analystes en sécurité de l'information réunis, même si ces deux métiers croissent à des taux en pourcentage plus élevés. L'emploi total, tous métiers confondus, est projeté à 3,1 % de croissance sur la même période.
Deux nuances doivent accompagner immédiatement ce chiffre, et les omettre serait malhonnête.
C'est une projection. Les projections sont des modèles bâtis sur des hypothèses d'adoption technologique et de croissance sectorielle, et elles sont révisées. Celle-ci intègre une hypothèse selon laquelle l'intelligence artificielle relève la productivité, ce qui explique pourquoi le même tableau montre plusieurs métiers administratifs en déclin.
L'embauche au niveau junior a été difficile. Diplômés et personnes en reconversion ont affronté un marché plus tendu que ne le laisse penser le chiffre de croissance affiché, et une croissance agrégée sur dix ans ne dit rien de la facilité à obtenir un premier emploi une année donnée.
La réconciliation, c'est qu'une grande part des postes projetés vient du remplacement plutôt que de l'expansion, et que la demande penche vers les personnes capables de travailler avec des systèmes existants. C'est une indication sur quelle formation paie, pas un argument disant que la croissance est fictive.
La relecture est la compétence qui fait passer une équipe à l'échelle
La compétence enseignable au meilleur effet de levier en ingénierie logicielle, et que presque aucune organisation n'enseigne délibérément.
La relecture de code est le moment où les défauts sont attrapés avant de coûter quoi que ce soit, où la connaissance se diffuse dans l'équipe, où les standards deviennent réels plutôt que documentés, et où les ingénieurs juniors apprennent le plus vite. C'est aussi là que beaucoup de temps se gaspille et que naît une part surprenante des conflits en entreprise.
Quatre éléments distinguent une relecture utile d'un rituel.
Savoir quoi chercher. Correction, gestion des erreurs, sécurité, comportement à l'échelle, et si ce sera compréhensible dans un an. Le formatage relève d'un outil, et c'est ce à quoi les relecteurs inexpérimentés consacrent leur attention.
Relire la conception, pas le diff. Le commentaire le plus précieux est fréquemment que le changement ne devrait pas exister sous cette forme, et ce commentaire est bien moins coûteux avant que le travail ne soit fait.
Séparer ce qui doit changer de ce que vous auriez fait différemment. Confondre préférence et exigence est la plus grande source de friction en relecture, et cela apprend aux gens à arrêter de proposer.
Rendre l'exercice sûr. Une culture de relecture où l'on craint d'être critiqué produit des changements plus petits, plus tardifs, moins honnêtes, et cache les problèmes jusqu'à ce qu'ils coûtent cher.
Rien de tout cela n'est difficile à enseigner. C'est simplement supposé s'apprendre par exposition, et chacun apprend ce que faisait sa première équipe.
Où cela se situe dans le domaine
L'ingénierie logicielle est la deuxième des huit directions du domaine IA, données et informatique d'Astra Trainer, et c'est la plus importante en effectifs chez presque tous les partenaires. Elle s'appuie sur l'informatique fondamentale pour le modèle sous-jacent et se connecte en aval au cloud computing et DevOps, où vit désormais la moitié livraison du métier.
Elle se connecte aussi à la cybersécurité, car une grande part des vulnérabilités sont des défauts logiciels ordinaires, et à l'intelligence artificielle et l'apprentissage automatique, où les systèmes autour d'un modèle relèvent de l'ingénierie logicielle classique. Vous pouvez découvrir les huit directions ici.
La maintenance est le métier, pas l'après-coup
Un logiciel n'est pas terminé une fois livré. L'essentiel de l'argent dépensé sur un système au cours de sa vie l'est après la première mise en production, et la plupart des ingénieurs passent l'essentiel de leur carrière sur du code qui existe déjà.
Pourtant, presque toute la formation technique utilise des exercices en terrain vierge. On apprend à construire du neuf, isolément, avec des exigences propres et sans historique, puis on est recruté sur un système avec quinze ans de décisions accumulées, de migrations partielles et de commentaires décrivant un comportement qui a changé depuis longtemps.
Les compétences que cet écart exige sont précises et enseignables.
Lire du code inconnu. Trouver le point d'entrée, tracer un chemin, construire un modèle mental opérationnel sans tout lire.
Modifier du code en sécurité. Ajouter des tests à du code non testé avant de le modifier, faire des changements petits et réversibles, et utiliser les types et les contrats pour limiter l'effet d'une modification.
Comprendre pourquoi les choses sont ainsi. Une grande part de ce qui paraît irrationnel dans du code ancien était une réponse correcte à une contrainte qui n'existe plus ou à un bug qu'on ne se rappelle plus. Le supprimer sans savoir lequel des deux, c'est comme ça qu'arrivent les pannes.
Gérer la dette technique honnêtement. Distinguer les décisions qui étaient des compromis raisonnables de la négligence accumulée, et rendre visible le coût de chacune aux personnes qui décident des priorités.
Migrer par incréments. Presque chaque grande réécriture tentée comme un remplacement d'un bloc est une mise en garde. La migration incrémentale est une compétence aux schémas connus, rarement enseignée.
Les postes, nommés
Ingénieurs logiciels, front end, back end et full stack.
Ingénieurs plateforme, construisant l'outillage interne dont dépendent les autres équipes.
Ingénieurs mobile.
Ingénieurs qualité et test, y compris l'automatisation.
Ingénieurs de fiabilité des sites (SRE), où l'ingénierie logicielle rencontre l'exploitation.
Architectes techniques.
Responsables d'ingénierie et référents techniques, où la contrainte est généralement le jugement plutôt que la capacité à coder.
Ingénieurs developer experience, une spécialité en croissance visant le goulot de compréhension et de coordination.
Ingénieurs d'intégration, connectant des systèmes qui n'étaient pas conçus pour se rencontrer.
Qui peut être formé pour cela
Ingénieurs qualité et test. La meilleure conversion interne. Ils connaissent déjà le produit, savent comment il échoue et connaissent la base de code depuis l'extérieur.
Ingénieurs support et exploitation. Vers le développement, avec une connaissance de la production que les équipes de développement n'ont souvent pas et dont elles ont besoin.
Analystes de données. Déjà en train d'écrire du code, avec besoin de pratique d'ingénierie : gestion de version, tests, relecture et conception pour le changement.
Business analysts et personnel produit avec une appétence technique, vers des postes proches de l'ingénierie où la connaissance métier est la moitié rare.
Ingénieurs d'autres disciplines. Les ingénieurs mécaniques, électriques et civils se convertissent bien, apportant une méthode systématique.
Scientifiques et chercheurs qui écrivent déjà du code pour leurs propres travaux, avec besoin de pratique collaborative plutôt que de programmation.
Développeurs expérimentés sur des technologies vieillissantes. Fréquemment négligés, avec une connaissance système profonde et besoin d'une chaîne d'outils actuelle plutôt que d'un changement de carrière.
Sur le code généré et la responsabilité. Le code produit par des outils de génération relève de la responsabilité de l'organisation qui le livre, et peut comporter des défauts, des vulnérabilités de sécurité, des implications de licence ou un comportement que personne dans l'équipe ne peut expliquer. Les obligations de relecture, de test et de provenance ne se transfèrent pas à l'outil. Les secteurs à logiciel réglementé, dont le médical, l'automobile, l'aéronautique et la finance, ont des exigences spécifiques de processus de développement et de traçabilité qui s'appliquent quelle que soit la façon dont le code a été produit.
Ce qu'il faut retenir
Produire du nouveau code est la minorité du métier, et une formation qui ne couvre que les langages et les frameworks traite la plus petite moitié.
Les développeurs logiciels devraient gagner 267 700 emplois d'ici 2034, la plus forte hausse en valeur absolue parmi les métiers technologiques suivis par le BLS, une projection qui coexiste avec un marché junior réellement difficile.
La relecture de code est la compétence enseignable au meilleur effet de levier dans une équipe, et elle est presque universellement laissée à l'imprégnation.
La maintenance et le travail sur l'existant sont là où se passent réellement les carrières, et la formation forme massivement au terrain vierge.
Et les meilleurs candidats internes se trouvent généralement en test, en support et en exploitation, avec déjà la connaissance qu'une nouvelle recrue met un an à acquérir.
Sur quoi les ingénieurs logiciels passent-ils réellement leur temps ?
À lire du code existant, reproduire des bugs, relire des changements, s'intégrer à des systèmes dont la documentation est obsolète, déployer et enquêter sur les différences entre environnements. Écrire du nouveau code est réel mais n'est pas la plus grande part.
Le développement logiciel est-il toujours un métier en croissance ?
Le BLS projette 15,8 % de croissance entre 2024 et 2034, soit 267 700 emplois de plus, la plus forte hausse en valeur absolue parmi les métiers technologiques suivis. C'est une projection plutôt qu'une observation, et elle coexiste avec un marché de l'embauche junior difficile.
Pourquoi la relecture de code compte-t-elle autant ?
Parce qu'elle attrape les défauts avant qu'ils ne coûtent quoi que ce soit, diffuse la connaissance dans l'équipe, rend les standards réels et forme les ingénieurs juniors plus vite que tout le reste. C'est aussi là que naît le plus de friction technique quand c'est mal fait.
Pourquoi le travail sur du code existant est-il sous-formé ?
Parce que la formation technique utilise des exercices en terrain vierge avec des exigences propres, alors que la plupart des ingénieurs passent l'essentiel de leur carrière à modifier des systèmes avec des années d'historique accumulé, de migrations partielles et de raisons non documentées.
Qui se convertit bien vers l'ingénierie logicielle ?
Les ingénieurs test et qualité en premier, puis le personnel support et exploitation, les analystes de données qui écrivent déjà du code, les ingénieurs d'autres disciplines, et les développeurs expérimentés sur des technologies vieillissantes ayant besoin d'une chaîne d'outils actuelle plutôt que d'un changement de carrière.