Ingénieur DevOps / plateforme / SRE

Infrastructure décrite en code, définitions de chaînes, manifestes — le grand volume de texte structuré qui décrit ce qui doit exister.

Décider à trois heures du matin, sous la pression du temps et avec une information partielle, quoi revenir en arrière, quoi dégrader et quoi dire aux gens pendant que c'est encore cassé.

Expliquer une facture d'infonuagique, trouver la chose qui l'a triplée, et décider quelle inefficacité vaut la semaine d'un ingénieur.

Choisir l'architecture, les modes de défaillance que vous acceptez d'avoir, et ce que l'équipe saura encore exploiter dans deux ans.

Une enquête auprès de praticiens : les 90 % sont donc un usage déclaré plutôt que mesuré, et le « 80 % pensent que cela a augmenté leur productivité » qui l'accompagne est une croyance et doit être lu comme telle — ce site détient un essai randomisé dans lequel des développeurs expérimentés étaient 19 % plus lents en se croyant 20 % plus rapides, donc une croyance sur sa propre vitesse n'est pas une preuve sur la vitesse. Ce qui n'est pas de l'auto-déclaration sur sa propre performance, c'est la corrélation que les chercheurs calculent entre répondants, et c'est la partie utile : l'adoption est positivement liée au débit et à la performance produit, et négativement à la stabilité des livraisons. Le mécanisme que donnent les auteurs est précis — sans tests automatisés solides, gestion de versions mature et boucles de retour rapides, un volume de changements plus élevé produit de l'instabilité, et les équipes en architecture faiblement couplée voient des gains là où les fortement couplées n'en voient guère. Google Cloud publie cette enquête et vend les outils sur lesquels elle interroge.

Usage mesuré et à grande échelle d'un outil pour du travail réel, où la décision de l'utiliser vient de la personne qui travaille et non de l'employeur. C'est plus qu'un enregistrement de capacité — le travail est réel, pas une démonstration — et moins qu'un enregistrement de déploiement, car aucun employeur ne l'a mis en production, ne l'a exigé, ni n'a construit un processus autour. Pondéré `cautious` : `automating` signifie que la machine sait faire la tâche ET qu'il y a des signes d'adoption, et ceci est un signe d'adoption ; mais l'usage peut être expérimental, et une bonne part de la mesure vient d'une partie intéressée, donc un enregistrement ne suffit jamais et deux indépendants suffisent. Regardez qui compte. La télémétrie d'un fournisseur voit cela directement et vend l'outil, donc un tel enregistrement déclare cet intérêt dans son périmètre ; une agence statistique qui demande aux entreprises si leurs salariés utilisent l'IA dans leurs tâches voit le même canal sans aucun intérêt propre, et là où elle existe, c'est la meilleure source.

Une étude sectorielle commandée, non une mesure, et elle est enregistrée ici parce qu'elle pointe dans l'autre sens que l'essentiel de cette base. Le même document qui attend une contraction du support autonome attend que le travail atterrisse sur ce poste : il dit que la fonction DevOps prendra en charge la supervision des engagements de service et le développement de nouveaux systèmes, que développement et exploitation se rejoignent pour offrir un soutien plus global, et il liste les ingénieurs en automatisation et orchestration parmi les postes dont la demande croît. Il nomme aussi l'ingénieur DevOps comme la destination qu'il considère facile ou modérée pour les ingénieurs de support dont il attend le remplacement. Rien de tout cela n'est la preuve que quelqu'un ait été recruté, que les effectifs aient monté ou que la transition ait eu lieu — c'est l'attente d'une agence, publiée avant que l'IA générative n'atteigne le public, couvrant Singapour seulement et bâtie sur des entretiens avec des parties prenantes plutôt que sur des données d'emploi. Ce que cela établit, c'est que le constat de remplacement ailleurs dans le même rapport n'affirme pas que le travail disparaît.

Une personne nommée, ayant une position reconnue, a publiquement prédit quelque chose, à une date, dans une déclaration attribuable. On l'enregistre pour que qui a dit quoi, et quand, reste vérifiable — et cela ne déplace jamais l'appréciation d'une tâche, car une prévision n'est pas une observation. Sa valeur arrive plus tard : l'enregistrement se trouve sur la même page que les preuves concernant ce métier, donc qui lit la prévision lit à côté le relevé de ce qui s'est passé ensuite. C'est là que les comptes se font ; ce site ne publie aucun verdict sur la réalisation d'une prévision.

Le barreau qui embauchait les débutants — écrire et brancher la configuration — est celui vers lequel le mécanisme le plus net est pointé, parce que c'est du code au résultat vérifiable par machine. Ce qu'il reste alors à un débutant est l'astreinte, c'est-à-dire la partie la plus dure et celle que vous étiez censé mériter. Poussez pour assister aux revues d'incident bien avant d'entrer dans le tour de garde.

Votre levier est la décision de conception et l'appel pendant l'incident, et les deux sont de minces tranches de la semaine. Le risque n'est pas qu'elles soient automatisées, c'est que les heures autour d'elles soient amincies jusqu'à ce qu'un ingénieur couvre plus de services qu'une seule tête ne peut en tenir. Surveillez le nombre de services par ingénieur comme un serveur surveille le nombre de tables qu'on lui confie.

Rester et se renforcer

Allez vers la conception et éloignez-vous du branchement

La décision de conception n'a aucun arbitre automatique, et c'est exactement pour cela qu'aucun outil ne peut y boucler la boucle — et c'est la partie du métier qui capitalise.

Refaçonner le poste

Détenez l'exploitabilité de ce que les autres construisent

Plus de configuration générée veut dire plus de systèmes dont personne n'est responsable, et quelqu'un doit tenir la norme de ce qui a le droit de tourner en production.

La moitié configuration bouge, et bouge vite, parce que le code d'infrastructure s'applique proprement ou échoue — un résultat vérifiable par machine est ce qui permet à un modèle de réessayer sans surveillance. L'astreinte, non, parce qu'un incident est par définition la panne que personne n'avait anticipée et que l'appel porte sur des dégâts acceptables plutôt que sur une réponse correcte. La forme probable n'est pas la suppression mais l'amincissement : moins d'ingénieurs couvrant plus de services, ce qui garde chaque tâche et rend le tour de garde pire.

Pas de date. Deux chiffres que vous pouvez produire vous-même en disent plus que n'importe quelle prévision : quelle part de votre semaine va à du travail dont l'application réussit ou échoue, et de combien de services chaque ingénieur de votre tour de garde est désormais responsable. Le premier est votre exposition par tâche ; le second est le changement qui atteint réellement les gens de ce métier, et il bouge discrètement un ou deux trimestres après l'arrivée de n'importe quel outil.

Pas d'ordinaire, et c'est le cas le plus net de ce site d'un outil qui ressemble à une économie et se comporte comme une dette. Chaque ressource créée est une ressource que quelqu'un doit garder, sécuriser et un jour supprimer : une configuration plus rapide produit donc plus de configuration plutôt que moins de travail — les heures passent de l'écriture au démêlage. Le démêlage est invisible sur une feuille de route, et c'est exactement pourquoi il est budgété comme une économie.

C'est la tâche la plus sûre du métier et aussi la plus petite. Savoir si une conception était juste se découvre dix-huit mois plus tard, ce qui veut dire qu'il n'y a pas d'arbitre automatique et donc aucune boucle qu'un outil puisse fermer — mais dans la plupart des équipes les décisions de conception représentent quelques jours par trimestre. Un poste peut être solide sur sa tâche la plus experte et perdre quand même l'essentiel de ses heures, et c'est cet écart qu'il faut anticiper.