Se reconvertir pour l’avenir : pourquoi les développeurs et les experts de l’infrastructure doivent-ils sortir de leur zone de confort ?

Matthew Finio : Comment évolue la relation entre les développeurs et les experts de l’infrastructure ?

Miha Kralj : L’ensemble de la profession de développeur a changé à l’aube du « tout défini par logiciel » : les réseaux, le stockage et l’informatique.

Auparavant, nous avions les spécialistes de l’infrastructure à gauche et les spécialistes du développement logiciel à droite, et ils échangeaient très peu. L’un s’occupait de la plomberie et des actifs sous-jacents, tandis que l’autre s’occupait du codage et de concrétiser les rêves.

Aujourd’hui, tout cela s’effondre. Aucune des deux parties n’est préparée à l’ère dans laquelle nous vivons. Aucune ne comprend la sécurité, ce qui nous permet de l’aborder également. Ils doivent commencer à apprendre les uns des autres, ce qui est difficile pour les deux parties.

C’est comme dans le livre Qui a piqué mon fromage ? Aucun des deux camps ne se sent à l’aise s’il vient de l’ancien monde traditionnel. Les jeunes générations qui ont grandi avec Gmail et YouTube vivent dans ce nouveau monde combiné. Mais les personnes qui viennent de l’infrastructure ou du développement traditionnel rencontrent des difficultés parce qu’elles n’ont pas appris à connaître l’autre côté au début de leur carrière.

MF : Les développeurs et les responsables de l’infrastructure devraient donc repenser leurs descriptions de poste ?

MK : Exactement. Les développeurs ne devraient plus se voir comme de simples développeurs d’applications. Les responsables de l’infrastructure ne doivent plus penser qu’elles sont simplement chargées des opérations. Les structures d’équipe modernes des environnements d’ingénierie de produits s’appliquent ici, où chacun peut effectuer le travail d’une autre personne si nécessaire. Il existe toujours des spécialisations, mais un développeur doit être capable, en cas de besoin, d’écrire un script Terraform, une tâche traditionnellement très axée sur l’infrastructure.

Lorsque vous demandez à quelqu’un quel est son travail, il ne devrait pas vous répondre « Je suis un développeur de logiciels » ou « Je suis responsable de l’infrastructure ou des opérations ». Toutes ces personnes construisent un produit ou contribuent à la création d’un service, qui ne pourra jamais être lancé sans que toutes les pièces et tous les éléments soient correctement assemblés. Chacune doit comprendre la chaîne dans son intégralité, le cycle de vie complet, de bas en haut.

MF : Vous avez mentionné Terraform. Quels autres concepts d’infrastructure les développeurs doivent-ils apprendre ?

MK : Souvent, les développeurs ne comprennent pas exactement comment l’infrastructure sous-jacente fonctionne réellement, ce qui peut être durable et ce qui peut être éphémère.

Ainsi, si vous apportez une modification à l’hôte, au conteneur ou au composant sans serveur qui exécute une action, cette modification va-t-elle persister lorsque ce composant, cette machine virtuelle passe ailleurs ? Le concept de systèmes qui stockent leurs états ailleurs, les systèmes sans état, est l’un des précurseurs que les développeurs peuvent commencer à comprendre. Comment les rendre infiniment évolutifs ? Comment créer des systèmes très durables et flexibles ? Tous ces concepts architecturaux sont mis en œuvre dans des logiciels, mais ils sont en fait basés sur des modèles d’infrastructure.

Il est également utile de comprendre tous les modèles de sécurité qui permettent de créer une surface minimale dans le code afin de réduire au maximum les possibilités d’attaque. Et comment communiquer correctement avec un service éloigné. Allez-vous écrire un petit service qui envoie une centaine de petites questions chaque seconde ? Ou préférez-vous regrouper toutes les demandes et les envoyer en masse, mais moins fréquemment ?

Ce sont des décisions extrêmement importantes que tout développeur de logiciel doit prendre, mais il ne comprendra pas pourquoi il les prend s’il ne comprend pas ce qui se passe sous le capot, c’est-à-dire comment les systèmes réels fonctionnent. Cette compréhension du système de bas en haut est primordiale. Le développeur doit écrire un code propre et de qualité, qui ne ralentit pas le système, qui ne bloque pas la base de données, qui n’exécute pas d’actions qui nuisent.

Si vous revenez 20 ou 30 ans en arrière, nous avions une profession spécialisée dans l’optimisation des requêtes de base de données pour le nombre minimum de cycles requis par l’unité centrale, le minimum de verrouillage des données. Une grande partie de ces connaissances archaïques est perdue. Mais il est toujours très important de comprendre comment créer un système à haute performance et comment créer un système à coût optimisé. Il ne faut pas oublier toutes ces leçons.

Vous vous dites : « Nous sommes en 2025, laissez la place ! Le monde moderne est totalement différent. Vous ne savez pas ce que vous faites ! » Nous avons construit ce monde moderne et nous sommes là pour aider les nouveaux développeurs et responsables de l’infrastructure à l’utiliser aussi efficacement que possible.

MF : Pouvez-vous décrire comment les développeurs peuvent exploiter les outils d’infrastructure en tant que code pour améliorer leur workflow ?

MK : Oui. Un bon exemple serait la façon dont un développeur peut créer un workflow adapté pour que son propre code soit automatiquement testé, puis compilé et empaqueté chaque fois qu’il crée un élément de code et le dépose dans un référentiel. Les développeurs ne devraient pas avoir besoin qu’un responsable de l’infrastructure fasse cela à leur place. Créer un script YAML de qualité sur GitHub est une tâche d’infrastructure en tant que code que chaque développeur peut optimiser pour rendre ce processus aussi efficace que possible.

Par exemple, un développeur n’a pas besoin d’un packaging, d’une validation et de tests complets s’il évolue uniquement du côté du développement. Ce développeur se dira : « Je suis du côté du développement, je peux ignorer ces 20 tâches qui ne sont destinées qu’à la production. »

Mais si vous êtes du côté de la production, vous devez procéder à toute une série d’automatisations, mettre en route la machine qui va effectuer le contrôle de sécurité et la validation du code, etc. Toutes ces petites décisions qui vont avoir un impact sur la rapidité de la compilation et sur la rapidité avec laquelle vous voyez les résultats après avoir validé le code… Chaque développeur devrait être en mesure de modifier l’infrastructure au fur et à mesure des scripts de code et de l’adapter à son propre workflow.

C’est comme si ces mêmes développeurs aimaient affiner leur propre environnement de développement intégré. Ils préfèrent leurs propres polices, couleurs et raccourcis clavier. Ils devraient également pouvoir configurer leurs propres workflows, c’est-à-dire ce qui se passe après la validation du code. C’est là tout le savoir issu de l’IaC, l’infrastructure en tant que code.

MF : Qu’est-ce que les professionnels de l’infrastructure doivent comprendre du développement d’applications aujourd’hui ?

MK : L’infrastructure en tant que code (IaC) signifie littéralement que les spécialistes de l’infrastructure deviennent des codeurs. L’infrastructure est définie par des scripts, des données et du code, ce qui signifie que le script ou le code de l’infrastructure doit passer par le même cycle de développement logiciel que n’importe quel code écrit par les développeurs :

• Il doit être correctement documenté.
• Il doit être correctement stocké dans un référentiel.
• Il doit être correctement versionné.

Il doit être traité exactement de la même manière. Les responsables l’infrastructure traditionnelle ne comprenaient pas cela ou n’étaient pas en mesure de le faire. Ces personnes peuvent effectuer des configurations, cliquer sur leur souris, et peut-être écrire quelques scripts Bash.

Mais aujourd’hui, on attend des responsables de l’infrastructure qu’ils soient de véritables codeurs. Ils doivent comprendre Git. Ils doivent comprendre comment analyser la sécurité de leur actifs d’infrastructure en tant que code. Ceux-ci doivent être correctement versionnés et faire l’objet d’un examen par les pairs, et ils doivent comprendre ce qu’est une demande d’extraction. Il s’agit là de termes et d’activités standard que tout développeur de logiciel connaît par défaut.

Les responsables de l’infrastructure doivent devenir des ingénieurs de la pile complète. Et ces ingénieurs sont difficiles à former et à trouver. Il y a une pénurie de personnes qui comprennent tout, de la base (comment les paquets circulent, comment le réseau fonctionne et comment le noyau du système d’exploitation fonctionne) jusqu’au sommet. Par exemple, comment rédiger des dépendances logicielles multiples ? Comment utiliser des paquets qui sont soit open source, soit internes ? Comment écrire du code asynchrone ? Autant de questions qui relèvent du développement logiciel pur. Deux énormes domaines se sont réunis en un seul. La gestion du changement, la reconversion et l’amélioration des compétences ne sont pas là.

MF : Si la reconversion et l’amélioration des compétences constituent un tel défi, comment les professionnels de l’infrastructure devraient-ils se tenir au courant des tendances et des technologies en matière de développement ?

MK : Il n’y a plus de personnes dédiées à l’infrastructure et d’autres dédiées au développement, toutes étant regroupées au sein d’un seul domaine. Elles apprennent toutes ces nouvelles tendances ; les changements dans le cycle de vie du développement logiciel et, surtout, les changements en matière d’IA.

Alors que nous nous dirigeons vers un type de développement natif de l’IA, les responsables de l’infrastructure et les développeurs d’applications doivent l’apprendre. Tout le monde souffre du sentiment d’urgence et pense qu’il est déjà en retard. Ils viennent d’apprendre le prompt engineering et on leur dit maintenant qu’ils doivent apprendre à écrire des agents sur Semantic Kernel ou autre.

Les gens doivent s’entraider, ils doivent trouver le bon équilibre. Combien de temps faut-il consacrer à rester à jour tout en sachant que l’on est toujours à la pointe du progrès ? Auparavant, c’était 5 %, maintenant c’est 10 %. L’IA générative aide. Mais le rapport entre le temps nécessaire à l’apprentissage et le temps nécessaire à l’application et à la création de quelque chose qui apporte une valeur commerciale ou informatique penche de plus en plus en faveur de l’apprentissage.

MF : Avant de conclure, quelles sont les principaux éléments que les développeurs et les professionnels de l’infrastructure devraient garder à l’esprit au sujet des applications modernes ?

MK : Il n’y a plus de tâches indépendantes. L’infrastructure des applications modernes est presque intégrée. Ainsi, un développeur moderne va écrire un code et demander à créer un conteneur. Il n’y a pas de responsable de l’infrastructure qui crée un conteneur pour lui. Certains emplois requièrent un travail plus axé sur l’infrastructure, mais aussi sur le développement. D’autres requièrent davantage de développement de logiciels, mais aussi des connaissances et un accès à l’infrastructure.

Les professionnels de l’infrastructure doivent donc envisager de devenir des développeurs de logiciels. Les développeurs de logiciels, quant à eux, doivent devenir des professionnels de l’infrastructure.

Ces rôles ne sont pas séparés, ils se fusionnent. C’est comme il y a une dizaine d’années, lorsque tous les ateliers de développement de logiciels professionnels avaient des développeurs et des testeurs. Plus personne ne parle de testeurs car ces deux rôles ont fusionné. Le même type d’effondrement et de fusion des rôles, cette fois entre les développeurs et les spécialistes de l’infrastructure, se produit actuellement.