Ingénieur plateforme (Kubernetes)

Ce profil illustre le type d’ingénieur plateforme que recherchent les équipes en croissance : un ingénieur qui traite l’infrastructure comme un produit dont les clients sont les développeurs de l’entreprise elle-même.

Parcours

Huit ans dans des rôles d’infrastructure et de plateforme pour des entreprises SaaS et fintech. A commencé en DevOps classique, puis a évolué vers l’ingénierie de plateforme : bâtir le chemin balisé d’intégration continue, de déploiement, de secrets et d’observabilité qui permet aux ingénieurs produit de livrer sans déposer de billets. Opère Kubernetes sur AWS avec tout défini dans Terraform, et écrit du Go quand la plateforme a besoin d’outillage sur mesure ou d’un petit opérateur. Le passage du DevOps au travail de plateforme survient généralement quand une entreprise dépasse le point où une seule équipe peut accompagner chaque déploiement à la main, et cet archétype a vécu cette transition.

Ce que couvre réellement le travail

Exploitation de grappes. Opérer EKS ou du Kubernetes autogéré comme un système de production : des mises à niveau de version planifiées plutôt que sous pression, des groupes de nœuds dimensionnés et mis à l’échelle selon la forme réelle de la charge, des demandes et limites de ressources réellement définies, et des budgets de perturbation de pods pour qu’une rotation de nœuds de routine ne devienne jamais une panne. Des agencements multienvironnements, habituellement des grappes distinctes pour la production et pour le reste, gardés identiques par le code plutôt que par la mémoire.

GitOps. Des déploiements pilotés par Argo CD ou Flux, où le dépôt Git est la source de vérité et où la grappe converge vers lui. Le retour en arrière devient un simple revert, la dérive devient visible et les pistes d’audit viennent gratuitement, ce que les équipes de conformité fintech remarquent. La version senior inclut la livraison progressive : des déploiements canari ou bleu vert branchés aux métriques pour qu’une mauvaise version se retire d’elle-même.

Plateforme pour développeurs. Le cœur du métier. Des gabarits de chemin balisé pour qu’un nouveau service obtienne CI, manifestes de déploiement, secrets, DNS et tableaux de bord dès le premier jour au lieu d’une chasse au trésor de deux semaines. Des environnements de prévisualisation en libre-service par demande de tirage. Des garde-fous sensés intégrés au chemin, pour que les politiques de sécurité et de coûts soient des valeurs par défaut plutôt que des débats en révision. Le succès se mesure à la rareté des billets d’infrastructure ouverts par les ingénieurs produit.

Terraform en dessous. La couche AWS sous les grappes, les VPC, IAM, les bases de données et le DNS, tenue dans des modules Terraform révisables avec état distant, planifiés en CI à chaque changement. Les ingénieurs plateforme qui sautent cette couche se retrouvent avec des grappes reproductibles sur des fondations bâties à la main, et cet archétype ne le fait pas.

Go pour l’outillage. Kubernetes et son écosystème sont écrits en Go, alors les manques se comblent en Go : un petit opérateur pour automatiser un flux propre à la maison, un CLI qui enveloppe le chemin balisé, un contrôleur qui réconcilie une ressource interne. À l’aise avec client-go et le patron de contrôleur, et assez discipliné pour épuiser d’abord les options du commerce, puisque chaque opérateur sur mesure est un engagement d’entretien.

Signes de séniorité

Huit ans en travail de plateforme se manifestent par un jugement produit, pas seulement par des connaissances Kubernetes. Des signaux à sonder : la personne peut nommer une fonctionnalité de plateforme qu’elle a bâtie et que personne n’a utilisée, et ce qu’elle a appris sur l’importance de consulter les développeurs avant de bâtir. Elle a mené des mises à niveau de grappes dans plusieurs environnements de production et peut en décrire le séquencement. Elle peut plaider contre Kubernetes pour une charge de travail qui n’en a pas besoin. Elle parle d’adoption et d’expérience développeur aussi facilement que de contrôleurs. Les juniors ajoutent des outils à la plateforme; les seniors retirent des étapes du flux de travail.

Quoi vérifier si vous embauchez cet archétype

En entrevue, demandez comment un nouveau service passe du dépôt vide au trafic de production sur sa plateforme, étape par étape; la qualité de la réponse est la qualité de la plateforme. Demandez ce qui arrive quand un déploiement tourne mal à 2 h du matin et si un ingénieur produit peut le renverser seul. Demandez comment la personne introduirait GitOps dans une équipe qui déploie actuellement avec kubectl depuis des portables. Les bonnes candidatures s’informent de votre nombre de services et d’équipes avant de proposer quoi que ce soit, puisqu’une plateforme pour 6 services et une pour 60 ne se ressemblent pas. Signaux d’alarme : un maillage de services ou un portail développeur interne proposé avant que la base fonctionne, aucune réponse sur la façon dont les développeurs obtiennent de l’aide, et des décisions de plateforme justifiées par la valeur sur un CV plutôt que par le besoin de l’équipe.

Adéquation du mandat

Le meilleur contexte est une entreprise d’environ 20 à 150 ingénieurs qui a dépassé l’infrastructure improvisée : plusieurs équipes produit qui partagent des grappes que personne ne possède vraiment, des déploiements qui dépendent de personnes précises, ou une poussée de conformité qui exige des pistes d’audit. Formes courantes : une évaluation de plateforme à portée fixe, une migration GitOps avec un état final défini, ou un rôle intégré de longue durée comme premier ingénieur plateforme dédié. Les équipes plus petites avec un seul produit sont souvent mieux servies par l’archétype DevOps et SRE AWS de ce bassin, puisqu’une pleine plateforme interne est démesurée sous une certaine taille d’équipe. 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 évaluer et consolider l’infrastructure existante, puis reste comme responsable de la plateforme pendant que l’équipe produit prend de l’ampleur. Heures du Royaume-Uni, avec une matinée complète partagée avec l’Europe et des après-midis qui chevauchent l’est des États-Unis. Disponible maintenant.

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.