Infra vient du latin — en dessous. Structure — le socle, ce qui soutient tout le reste. L'infrastructure est ce qui est en dessous et qui porte. Cette étymologie n'est pas un détail grammatical — c'est une définition fonctionnelle. L'infrastructure est la couche basse, physique, tangible, qui conditionne l'existence de toutes les couches au-dessus. Elle ne peut pas être du code. Elle peut être gérée par du code, décrite par du code, documentée par du code. Mais elle reste du métal, du câble, de l'électricité, de la chaleur et des disques qui tombent en panne.

Ce n'est pas un débat sémantique. Quand le mot "infrastructure" perd sa dimension physique dans le langage courant des équipes techniques, les ingénieurs formés dans cet environnement linguistique n'apprennent pas à penser en couches physiques. Ils apprennent à penser en ressources cloud. Quand la panne arrive — la vraie, celle qui est dans le câble, dans la carte réseau, dans l'alimentation redondante qui ne l'est plus — personne ne sait chercher là où le problème est. Parce que personne n'a appris que c'est là qu'on cherche.

"Configuration as Code" — précis, exact, sans ambiguïté. La configuration des ressources cloud décrite de manière déclarative et versionnée. Ce mot aurait décrit la même pratique sans prétendre que du code peut être de l'infrastructure physique. Il n'a pas été choisi. "Infrastructure as Code" a été préféré — parce qu'il donne l'illusion que maîtriser Terraform, c'est maîtriser l'infrastructure. Et cette illusion sert les intérêts de ceux qui vendent l'accès à l'infrastructure réelle.

Un développeur et un ingénieur système ont des compétences fondamentalement différentes, acquises par des parcours différents, exercées dans des contextes différents. Leur collaboration est précieuse. Leur fusion sous un seul titre ne crée pas un profil plus complet — elle crée un profil plus flou. Un "ingénieur DevOps" qui excelle en CI/CD peut ne rien savoir de la gestion d'un incident réseau à 3h du matin. Un "ingénieur DevOps" qui maîtrise le diagnostic système peut écrire du code de qualité médiocre. La fusion des noms n'a pas fusionné les compétences. Elle a dilué les critères d'évaluation des deux.

DevOps a été suivi de FinOps, SecOps, MLOps, DataOps, GitOps, CloudOps, PlatformOps. Chaque nouveau suffixe "Ops" promet la même chose : la fusion de deux mondes qui travaillaient en silos. Chaque nouveau suffixe dilue un peu plus le sens du mot "opérations". À force de tout appeler "Ops", le mot ne désigne plus rien de précis. Et quand le mot "opérations" ne désigne plus rien de précis, les compétences opérationnelles réelles — celles qui maintiennent les systèmes en production la nuit — deviennent invisibles dans les référentiels, les fiches de poste et les plans de formation.

Des milliers d'ingénieurs formés depuis 2015 ont appris à "provisionner de l'infrastructure" sans jamais toucher un serveur physique, sans jamais câbler un switch, sans jamais diagnostiquer une panne réseau sur du métal nu. Ils ont appris à manipuler des abstractions — des ressources cloud, des fichiers Terraform, des pipelines CI/CD. Ces compétences sont réelles et utiles. Mais elles s'arrêtent à la couche API. En dessous de la couche API, il y a une infrastructure physique dont personne ne leur a appris l'existence — parce que le vocabulaire leur a donné l'illusion qu'elle n'existait pas, ou qu'elle n'avait pas besoin d'être connue.

Les organisations qui ont migré "vers le cloud pour réaliser des économies d'échelle" découvrent en général, 18 à 36 mois après la migration, que leurs coûts d'infrastructure ont augmenté plutôt que diminué. Une partie de cette augmentation est structurelle — les modèles de pricing cloud sont conçus pour croître avec l'usage. Mais une autre partie est évitable et provient directement de l'ignorance de la couche physique : surprovisionnement de ressources parce que personne ne sait dimensionner, egress fees ignorés parce que personne n'avait compris qu'il y avait des frais de sortie, architectures cloud-native qui répliquent des patterns on-premises sans les optimiser.

Le marché manque cruellement d'ingénieurs capables de maîtriser l'infrastructure de la couche physique jusqu'à la couche applicative — de l'électricité au service. Ce profil existait. Il s'appelait administrateur système, ingénieur infrastructure, SRE. Il a été progressivement remplacé dans les fiches de poste par des "ingénieurs DevOps" et des "ingénieurs cloud" dont les compétences s'arrêtent à la couche API. Le profil complet n'a pas disparu parce que la compétence est devenue impossible à acquérir. Il a disparu parce que le vocabulaire a cessé de le valoriser — et que le marché suit le vocabulaire.

AWS, Azure et GCP bénéficient directement de la conviction que maîtriser Terraform ou CloudFormation équivaut à maîtriser l'infrastructure. Si les ingénieurs croient que l'infrastructure, c'est du code, ils n'ont pas besoin de comprendre ce qu'il y a sous le code. Et s'ils n'ont pas besoin de comprendre ce qu'il y a sous le code, ils n'ont jamais de raison de se demander si ce qu'il y a sous le code pourrait appartenir à quelqu'un d'autre qu'un hyperscaler. La console AWS qui "provisionne de l'infra" est un interface de location, pas un outil de maîtrise. Le vocabulaire efface la distinction.

Deux acteurs bénéficient de la dilution des métiers. Les employeurs qui remplacent deux spécialistes par un généraliste moins coûteux — le titre "DevOps" justifie de payer moins deux expertises distinctes sous un seul salaire. Et les éditeurs d'outils qui vendent des plateformes "DevOps" censées résoudre par l'outillage ce que seule la culture et la compétence peuvent résoudre. Le mot "DevOps" est devenu un marché. Comme tous les marchés, il est shapé par les acteurs qui en bénéficient.

Appeler "Configuration as Code" ce qui est de la configuration déclarative de ressources virtuelles. Réserver le mot "Infrastructure" à ce qu'il désigne — la couche physique, tangible, qui porte tout le reste. Cette distinction n'est pas une question de style — elle est une question de précision opérationnelle. Un ingénieur qui sait que Terraform gère de la configuration, pas de l'infrastructure, sait qu'il y a une couche en dessous qu'il ne voit pas et dont il doit tenir compte.

Distinguer dans les fiches de poste, les référentiels de compétences et les plans de formation ce qui relève du développement (écrire du code qui résout des problèmes métier), de l'ingénierie infrastructure (maîtriser la couche physique jusqu'à la couche service) et de la fiabilité (concevoir et maintenir des systèmes disponibles en production). Ces trois compétences peuvent coexister chez un même individu — certains SRE excellent dans les trois. Elles ne peuvent pas être supposées présentes sous l'effet d'un titre générique.

Le Socle du Fer — 26 semaines de l'électricité au réseau — est construit sur ce principe : on ne peut pas maîtriser l'abstraction si on ne comprend pas ce qu'elle abstrait. Un ingénieur qui a appris à câbler un switch avant d'apprendre à configurer un VPC comprend ce qu'est réellement un réseau. Un ingénieur qui n'a connu que le VPC croit que le réseau est un fichier JSON. La formation à la couche physique n'est pas une nostalgie — c'est la condition de la compréhension réelle.