DevOps / SRE AWS

Ce profil représente le type d’infrastructure dont la plupart des équipes produit finissent par avoir besoin : quelqu’un qui rend AWS prévisible, reproductible et abordable pour que le reste de l’équipe puisse livrer.

Parcours

Huit ans dans des rôles DevOps et SRE, entièrement sur AWS, surtout pour des entreprises SaaS et fintech où le temps de disponibilité et les pistes d’audit comptent tous les deux. La trajectoire typique de cet archétype commence par l’automatisation des déploiements dont personne ne voulait, puis évolue vers la pleine responsabilité de l’infrastructure sous un produit qui génère des revenus. Bâtit tout en code avec Terraform, exécute les charges de travail sur Kubernetes et automatise le reste avec Python. A été de garde pour ses propres systèmes, ce qui transparaît dans la manière de les construire.

Ce que couvre réellement le travail

Infrastructure en tant que code. Pas seulement « on utilise Terraform », mais une organisation AWS multicompte avec des comptes séparés pour la production, la préproduction et l’outillage, un état distant avec verrouillage, et des modules assez petits pour qu’un nouvel ingénieur puisse lire la sortie d’un plan et comprendre ce qui va changer. Les plans s’exécutent en CI sur chaque demande de tirage, pour que les changements d’infrastructure soient révisés comme du code applicatif. Les accès IAM sont limités par service au lieu de clés administrateur partagées, ce qui fait la différence entre réussir et échouer un audit fintech.

CI/CD. La conception du pipeline du commit jusqu’à la production : bâtir une seule fois, promouvoir le même artefact d’un environnement à l’autre, et faire du retour en arrière une action testée en une étape plutôt qu’une théorie. Cet archétype a généralement vécu un processus de déploiement qui exigeait un après-midi et une personne, et tient fermement à ne jamais en recréer un.

Observabilité. Métriques, journaux et traces branchés avec CloudWatch, Prometheus et Grafana, ou un outil commercial comme Datadog, selon ce que l’équipe paie déjà. Le réflexe senior consiste à alerter sur les symptômes visibles par l’utilisateur, comme le taux d’erreur et la latence, pas sur chaque pointe de processeur, pour que les appels de garde veuillent dire quelque chose. Quand l’équipe est prête, cela s’étend aux SLO et aux budgets d’erreur.

Réponse aux incidents. Des guides d’intervention écrits avant l’incident, une rotation de garde qui n’épuise pas les gens, et des rétrospectives qui se terminent par une classe de problème corrigée plutôt que par un ingénieur blâmé. Quelqu’un qui a porté le téléavertisseur pour sa propre architecture conçoit différemment de quelqu’un qui ne l’a jamais fait.

Coûts. Lit la facture AWS ligne par ligne : un étiquetage qui relie les dépenses aux équipes et aux fonctionnalités, un dimensionnement des instances selon l’utilisation réelle, des plans d’épargne pour la charge stable, des instances ponctuelles pour les charges sans état, des règles de cycle de vie du stockage, et les frais de passerelle NAT et de trafic entre zones qui grossissent en silence. Le travail sur les coûts est traité comme de l’ingénierie, pas comme de l’approvisionnement.

Signes de séniorité

L’écart entre huit ans et trois ans dans ce rôle tient surtout aux cicatrices. Des signaux à sonder : la personne peut vous dire quand Kubernetes est la mauvaise réponse, pas seulement comment l’exploiter. Elle a mené au moins une migration avec du trafic de production en jeu et peut vous expliquer comment elle l’a séquencée. Elle parle du coût par environnement sans qu’on le lui demande. Elle peut décrire une vraie panne avec franchise, y compris ses propres erreurs et ce qui a changé ensuite. Les juniors décrivent des outils; les seniors décrivent des décisions et des compromis.

Quoi vérifier si vous embauchez cet archétype

En entrevue, demandez à la personne candidate de raconter un incident dont elle a été responsable du début à la fin, de l’alerte à la rétrospective. Demandez comment elle découperait une configuration Terraform unique de 5000 lignes que trois équipes modifient. Demandez sur quoi elle déclenche des alertes et pourquoi. Une bonne candidature vous posera aussi des questions en retour : fréquence de déploiement, taille de l’équipe et ce qui existe déjà, avant de proposer le moindre outil. Parmi les signaux d’alarme : sortir un maillage de services ou une architecture multirégion avant de comprendre le produit, être incapable d’expliquer la facture actuelle, et considérer les environnements de préproduction comme optionnels.

Adéquation du mandat

Le meilleur contexte est une équipe produit d’environ 5 à 50 ingénieurs où l’infrastructure appartient actuellement au dernier qui y a touché. Formes de mandat courantes : un audit d’infrastructure à portée fixe, un projet de migration avec un état final défini, ou un rôle de plateforme intégré à l’équipe produit, à temps plein ou à temps partiel. Moins pertinent si votre vrai besoin est du développement de fonctionnalités applicatives, ou si vous avez déjà une équipe plateforme en place, auquel cas l’archétype plateforme Kubernetes de ce bassin correspond mieux. Les tarifs de cet archétype se situent généralement dans la fourchette affichée sur cette fiche et varient selon la séniorité et la région.

Mandat typique

Commence souvent par un audit d’infrastructure ou une migration, puis se poursuit comme ingénieur de plateforme intégré à une équipe produit. Heures européennes avec un chevauchement d’après-midi sur l’Est américain. Disponible dans environ deux semaines.

Ceci est un échantillon représentatif du bassin vérifié. Faites-en la demande et nous confirmons la disponibilité réelle et actuelle d’un développeur avec ce parcours.