Les missions d'ingénieur FinOps ou de DevOps FinOps publiées en France demandent de repérer les ressources inactives ou surdimensionnées, d'automatiser les contrôles et les actions d'optimisation, de travailler dans l'infrastructure as code et de faire du rightsizing, des réservations de capacité et l'optimisation d'AKS ou d'EKS. Terraform, Kubernetes, Python ou PowerShell et un cloud maîtrisé reviennent dans presque toutes, avec Azure Cost Management, Kubecost ou Infracost en complément.
Le profil vient le plus souvent du DevOps ou du SRE. Il connaît l'infrastructure, mais n'a pas toujours raisonné en euros. Un ingénieur peut réduire un cluster de moitié et faire tomber la production au premier pic, ou acheter trois ans de Savings Plans juste avant une migration. À l'inverse, un analyste FinOps qui postule repère les économies sans savoir les appliquer.
Le candidat raconte une économie réellement obtenue : la ressource, la mesure de départ, le changement, le contrôle après coup, le montant constaté sur la facture suivante. Un bon profil parle de requests Kubernetes, d'interruptions spot et de l'ordre entre rightsizing et engagements. Le PDF contient la grille de 1 à 4 et un cas de 20 minutes sur une plateforme AWS à alléger.
Ce que l'ingénieur FinOps règle et automatise
Recommandations natives
AWS Compute Optimizer, Azure Advisor et Recommender chez Google Cloud proposent des tailles à partir des métriques CPU, mémoire et réseau. Elles servent de point de départ. Un ingénieur FinOps sait qu'elles ignorent la mémoire quand aucun agent ne la mesure et qu'elles lissent les pics rares, et il les vérifie avant de toucher à la production.
Autoscaling et Karpenter
Groupes d'autoscaling, autoscaler de cluster ou Karpenter pour EKS, autoscaling horizontal et vertical des pods : ils ajustent la capacité à la charge. Mal réglés, ils gardent des nœuds à moitié vides ou réagissent trop tard à un pic.
Instances spot
De la capacité excédentaire vendue avec une forte remise, reprise par le fournisseur après un préavis de deux minutes chez AWS et d'environ trente secondes chez Azure et Google Cloud. Elle convient aux traitements par lots, à la CI et aux nœuds Kubernetes sans état, à condition de varier les types d'instances.
OpenCost et Kubecost
OpenCost, projet de la CNCF créé par Kubecost, calcule le coût de chaque conteneur à partir du plus grand de ses requests et de sa consommation, et isole le coût inutilisé du cluster. Kubecost, aujourd'hui chez IBM, ajoute recommandations et alertes. Pour EKS, AWS fournit aussi les données d'allocation fractionnée dans le CUR.
Infracost
Infracost chiffre un changement Terraform, CloudFormation ou CDK et le commente dans la merge request, avec des politiques FinOps et de tags. Intégré à la CI, il fait discuter du coût avant le déploiement plutôt qu'après la facture.
Politiques et arrêts automatiques
Azure Policy, les SCP et tag policies d'AWS Organizations, les contraintes d'organisation Google Cloud et Cloud Custodian en open source bloquent ou corrigent les ressources hors règles. AWS Instance Scheduler, l'arrêt planifié des VM Azure et la planification d'instances Compute Engine éteignent le hors production la nuit et le week-end.
Savings Plans, réservations et CUD
Les remises contre un engagement d'un ou trois ans : Savings Plans (Compute, EC2 Instance, SageMaker AI, Database) et instances réservées chez AWS, réservations et savings plan for compute chez Azure, committed use discounts chez Google Cloud. L'ingénieur FinOps calcule le volume à engager sur l'usage qui reste après optimisation.
Stockage et transfert
Classes de stockage objet et règles de cycle de vie, volumes gp3 plutôt que gp2, snapshots orphelins, adresses IPv4 publiques facturées chez AWS, transferts entre zones et passerelles NAT. Ces postes grossissent sans bruit et demandent un œil technique.
L'ingénieur FinOps travaille avec l'équipe plateforme, les équipes DevOps et l'équipe FinOps centrale. Il reprend les recommandations et les anomalies, les vérifie sur les métriques, applique le changement dans le code d'infrastructure et mesure le résultat. Dans le framework de la FinOps Foundation, son travail relève de l'optimisation de l'usage et des coûts (usage, tarifs, architecture et placement des charges) et de l'automatisation. Les offres demandent un cloud principal à un niveau expert, Kubernetes, Terraform, un langage de script et la pratique d'un outil de coûts. La FinOps Foundation propose une certification FinOps Certified Engineer. La capacité à réduire sans casser se vérifie en entretien.
Six compétences d'ingénierie à vérifier
- Rightsizing et autoscaling
- Spot et capacité interruptible
- Coûts et dimensionnement Kubernetes
- Automatisation, politiques et coût dans la CI
- Stockage et transfert réseau
- Stratégie d'engagements
Questions d'entretien pour un ingénieur FinOps
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Compute Optimizer recommande de diviser par deux la taille d'une centaine d'instances EC2. Comment procédez-vous ?
Une bonne réponseIl vérifie d'abord les données : période observée, pics de fin de mois, mémoire mesurée ou non (sans l'agent CloudWatch, la mémoire est inconnue). Il classe par économie et par risque, commence par le hors production, puis passe la production par lots, dans le Terraform et avec un retour arrière prêt. Il compare latence et erreurs avant et après, et mesure l'économie sur la facture suivante. Il en profite pour passer sur une génération récente ou sur ARM quand l'application le permet.
Signal d'alerteTout appliquer d'un coup depuis la console, ou refuser par principe parce que « la prod ne se touche pas ».
Question 2 · confirmé
Sur quelles charges mettez-vous des instances spot, et comment gérez-vous les interruptions ?
Une bonne réponseSur les charges sans état ou reprenables : CI, traitements par lots avec points de reprise, nœuds Kubernetes de services répliqués, entraînements avec checkpoints. Il diversifie les types d'instances et les zones, choisit une stratégie d'allocation orientée capacité, écoute le préavis (deux minutes chez AWS, environ trente secondes chez Azure et Google Cloud) pour drainer le nœud, et garde un repli sur la capacité à la demande. Jamais de spot pour une base unique ou un service avec état sans réplique.
Signal d'alerte« Le spot, c'est trop risqué » sans nuance, ou une base de production sur du spot.
Question 3 · confirmé
Le cluster est rempli à 80 % en requests, mais les nœuds tournent à 25 % de CPU. Que faites-vous ?
Une bonne réponseLes requests sont surestimées : le scheduler réserve de la place jamais utilisée, et les nœuds se paient quand même. Il mesure la consommation réelle par conteneur sur plusieurs semaines (Prometheus, VPA en mode recommandation, OpenCost ou Kubecost), propose de nouvelles requests par équipe avec une marge, puis laisse l'autoscaler de nœuds ou Karpenter consolider. Il surveille ensuite les OOMKilled et le throttling.
Signal d'alerteSupprimer les requests, ou retirer des nœuds sans toucher aux requests, ce qui laisse des pods en attente.
Question 4 · confirmé
Comment rendez-vous visible le coût d'un changement d'infrastructure avant son déploiement ?
Une bonne réponseInfracost dans la CI : il calcule l'écart de coût du plan Terraform et le commente dans la merge request, avec des politiques (types d'instances autorisés, tags obligatoires, régions) qui avertissent ou bloquent. Au-delà d'un montant, une revue de l'équipe FinOps est demandée. Il précise que l'estimation repose sur les prix publics et que l'usage (trafic, volume stocké) doit être déclaré à part.
Signal d'alerteUn tableur de coûts rempli à la main après la mise en production.
Question 5 · confirmé
Un bucket S3 de 400 To grossit chaque mois. Comment réduisez-vous son coût ?
Une bonne réponseIl analyse d'abord les accès (Storage Lens, analyse des classes de stockage) et la taille des objets. Puis des règles de cycle de vie vers Standard-IA, Glacier Instant Retrieval ou Deep Archive selon la fréquence de lecture, l'expiration des anciennes versions et des envois multipart incomplets, Intelligent-Tiering si les accès sont imprévisibles. Il tient compte des durées minimales de stockage, des frais de récupération et du coût des transitions, élevé sur des millions de petits objets.
Signal d'alerteTout passer en Glacier sans savoir qui lit les données.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Questions fréquentes sur le poste d'ingénieur FinOps
D'où viennent les bons ingénieurs FinOps ?
Le plus souvent du DevOps, du SRE ou de l'ingénierie cloud, avec un cloud bien connu, Terraform et Kubernetes. Le candidat a ajouté la lecture des coûts : exports de facturation, recommandations, engagements. Un analyste FinOps peut évoluer vers ce poste s'il a déjà modifié lui-même de l'infrastructure. L'entretien vérifie que le candidat a appliqué des optimisations en production, et pas seulement rédigé des recommandations.
Faut-il exiger la certification FinOps Certified Engineer ?
Elle montre que le candidat connaît l'approche de la FinOps Foundation appliquée à l'ingénierie. Elle ne remplace ni une certification cloud de niveau professionnel ni l'expérience de production, et mieux vaut la traiter comme un plus. En entretien, compte une économie réalisée, son montant constaté et la façon dont le risque a été géré. Un profil expérimenté répond avec des chiffres et une méthode.
Comment évaluer un ingénieur FinOps en une heure ?
Un tiers du temps va à un exercice sur des données réelles anonymisées : un extrait de recommandations de dimensionnement, la liste des nœuds d'un cluster avec leurs requests, ou un historique d'usage à couvrir par des engagements. Il dit ce qu'il appliquerait, dans quel ordre et avec quel contrôle. Ce format montre mieux sa méthode qu'un test technique à rendre plusieurs jours plus tard.
Un DevOps attentif aux coûts peut-il suffire ?
Oui, tant que la facture reste modeste et portée par une seule équipe. Le poste dédié se justifie quand plusieurs équipes partagent des clusters, que les recommandations s'accumulent sans être appliquées et que les achats d'engagements prennent de l'ampleur. L'ingénieur FinOps travaille alors pour toutes les équipes, avec des politiques, de l'automatisation et un suivi des économies réellement constatées sur la facture.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
