Le platform engineer Kubernetes / GitOps construit ce que les équipes de développement consomment sans ouvrir de ticket : un namespace prêt, une base de données, un topic Kafka, un déploiement qui part d'un commit. Les offres françaises citent Argo CD, plus rarement Flux, Crossplane, Kyverno, CloudNativePG et Strimzi. Pour un entretien de platform engineer, les questions portent sur la synchronisation, la promotion entre environnements, les API de self-service et les politiques.
Ces outils figurent sur beaucoup de CV après une simple installation de démonstration. La différence se voit sur la gestion de l'écart entre Git et le cluster, sur l'ordre d'application des CRD, sur ce que devient une base quand on supprime l'objet qui la décrit. Le nombre de clusters et d'équipes que la plateforme servait compte.
Le dépôt Git du candidat reste le meilleur support. Le candidat décrit l'arborescence qu'il a mise en place : où vivent les valeurs par environnement, qui fusionne en production, comment un nouveau cluster reçoit son socle. Le PDF propose 30 questions sur six axes, un cas de 20 minutes et une grille de notation.
De Git au cluster : l'outillage d'une plateforme GitOps
Argo CD
Le contrôleur GitOps le plus cité dans les offres. Il compare en permanence ce que décrit Git et ce qui tourne dans le cluster, signale l'écart et peut le corriger. La branche 3.x a changé plusieurs comportements par défaut, et la version 3.6 est sortie début novembre 2026. Reste à savoir sur quelle version la personne a travaillé.
ApplicationSets
Le générateur d'applications d'Argo CD. Un seul objet produit une application par cluster, par répertoire ou par équipe, à partir de labels ou de l'arborescence Git. C'est ce qui permet d'installer le même socle sur trente clusters sans trente déclarations.
Flux
L'autre grand outil GitOps, installé dans chaque cluster sous forme de contrôleurs. Il s'appuie sur des objets Kustomization et HelmRelease et déchiffre nativement les secrets SOPS. Weaveworks, son créateur, a fermé en 2024 ; le projet continue à la CNCF.
Crossplane
Il étend Kubernetes pour créer des ressources chez le fournisseur cloud : bases, buckets, réseaux. L'équipe plateforme définit ses propres API (XRD) et ce qu'elles créent (Compositions). La version 2 a rendu les ressources namespaced, supprimé les claims pour les nouvelles API et retiré les patches natifs au profit des fonctions. La version courante est la 2.4.
Kyverno et Gatekeeper
Les moteurs de politiques qui refusent ou corrigent un objet à son entrée dans le cluster : registre d'images autorisé, conteneur non privilégié, labels obligatoires. Kyverno 1.19 a déprécié ClusterPolicy au profit de politiques en CEL, avec un retrait prévu en 1.20. Gatekeeper utilise le langage Rego.
Cluster API et Gardener
Des outils qui décrivent les clusters eux-mêmes comme des objets Kubernetes : nombre de nœuds, version, fournisseur. Ils servent quand la plateforme crée et met à jour beaucoup de clusters. Les offres citent aussi Rancher pour le même usage.
CloudNativePG et Strimzi
Deux opérateurs qui font tourner PostgreSQL et Kafka dans Kubernetes. Ils gèrent la réplication, les sauvegardes, les bascules et les montées de version à partir d'objets déclarés dans Git. Plusieurs offres françaises de platform engineer les citent en toutes lettres.
External Secrets Operator, SOPS
Deux façons de garder les secrets hors de Git en clair. External Secrets Operator recopie dans le cluster des valeurs lues dans Vault ou dans le coffre du fournisseur cloud. SOPS chiffre les fichiers dans le dépôt.
Le poste se trouve dans les équipes plateforme qui servent plusieurs équipes de développement sur un parc de clusters. Le profil vient le plus souvent du DevOps ou de l'administration Kubernetes et a pris en charge la conception des API internes. Il écrit beaucoup de YAML, du Helm et du Kustomize, parfois du Go pour une fonction Crossplane ou un petit contrôleur. Les offres françaises associent Argo CD à Crossplane, Kyverno, CloudNativePG, Strimzi et Vault, sur un cloud public ou sur Kubernetes hébergé en interne. La CKA atteste les bases de Kubernetes. Pour le GitOps et Crossplane, le niveau se vérifie sur une plateforme réellement exploitée.
Grille de compétences d'un platform engineer GitOps
- Argo CD, ApplicationSets et synchronisation
- Organisation des dépôts et promotion
- Crossplane : XRD, Compositions, fonctions
- Gestion d'un parc de clusters
- Multi-tenance, politiques et secrets
- Opérateurs de données et run
Cinq questions GitOps, de la synchronisation à Crossplane
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é
Quelqu'un a modifié un Deployment de production à la main avec kubectl. Que fait Argo CD, et que doit-il faire selon vous ?
Une bonne réponseL'application passe en OutOfSync. Avec la synchronisation automatique et selfHeal, Argo CD remet l'état décrit dans Git ; sans selfHeal, il signale l'écart et attend. Le candidat règle ensuite la cause : droits d'écriture retirés aux humains en production, procédure d'urgence qui passe aussi par un commit, ignoreDifferences pour les champs qu'un autre contrôleur gère légitimement.
Signal d'alerte« Argo CD empêche kubectl », ce qu'il ne fait pas. Ou désactiver selfHeal partout parce que les écarts font du bruit.
Question 2 · confirmé
Le même socle (ingress, cert-manager, supervision) doit tourner sur trente clusters, avec des valeurs propres à chacun. Comment l'organisez-vous avec Argo CD ?
Une bonne réponseUn ApplicationSet avec un générateur de clusters qui sélectionne les clusters par labels, ou un générateur Git, souvent combinés en matrice. Les valeurs propres à chaque cluster viennent d'un fichier par cluster ou des labels de son secret. Les sync waves ordonnent CRD puis ressources. Pour déployer par vagues, la synchronisation progressive des ApplicationSets (RollingSync) sur des groupes de labels.
Signal d'alerteTrente fois chaque application écrite à la main, ou un app-of-apps recopié par cluster.
Question 3 · confirmé
Comment une nouvelle version d'image passe-t-elle de la recette à la production dans votre modèle GitOps ?
Une bonne réponseUn répertoire par environnement (overlays Kustomize ou fichiers de valeurs Helm) dans la même branche. La promotion est un commit qui change le tag ou, mieux, le digest dans le chemin de production, ouvert par la CI ou par un outil comme Kargo ou Argo CD Image Updater, et relu. Le retour arrière est un git revert.
Signal d'alerteUne branche par environnement avec des merges entre branches, le tag latest, ou un kubectl set image lancé par la CI.
Question 4 · senior
Une équipe veut une base PostgreSQL managée chez le fournisseur cloud, en self-service. Comment la lui proposez-vous avec Crossplane ?
Une bonne réponseUne API maison définie par une XRD (taille, version, sauvegarde) et une Composition en pipeline de fonctions (function-patch-and-transform, go-templating, KCL) qui crée l'instance, le réseau et le secret de connexion. Avec Crossplane v2, l'équipe crée directement la ressource composite dans son namespace : les claims ne restent que pour les XR hérités de la v1. Le provider s'authentifie par identité de workload. Le schéma fixe les valeurs par défaut et les bornes, le RBAC limite qui crée ce type d'objet.
Signal d'alerteDonner aux équipes l'accès direct aux ressources managées du fournisseur avec tous leurs champs. Ou parler de patches natifs dans la Composition, supprimés en v2.
Question 5 · confirmé
Comment empêchez-vous qu'une équipe déploie un conteneur privilégié ou une image tirée d'un registre public ?
Une bonne réponsePod Security Admission au niveau restricted sur les namespaces applicatifs. Des politiques Kyverno ou Gatekeeper pour la liste des registres autorisés et la vérification des signatures d'images, déployées par GitOps, d'abord en audit puis en blocage, avec des exceptions déclarées. Un profil à jour sait que Kyverno 1.19 a déprécié ClusterPolicy au profit des politiques CEL (ValidatingPolicy, ImageValidatingPolicy), avec un retrait annoncé en 1.20.
Signal d'alerteLa revue de code comme seule protection, ou PodSecurityPolicy, retirée de Kubernetes depuis la 1.25.
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
Platform engineering GitOps : questions courantes
Un profil Flux convient-il si l'équipe utilise Argo CD ?
En général oui. Les principes sont les mêmes : réconciliation depuis Git, gestion de l'écart, ordre d'application, promotion par commit. Un profil solide sur Flux apprend vite l'interface, les AppProjects et les ApplicationSets d'Argo CD, et l'inverse vaut aussi. L'échelle compte davantage : nombre de clusters et d'équipes servies, montées de version menées. L'outil en place reste un plus.
Crossplane remplace-t-il Terraform dans ce poste ?
Rarement en entier. Terraform reste souvent pour le socle : comptes, réseau de base, cluster qui héberge Crossplane. Crossplane prend la suite pour ce que les équipes demandent en self-service. Un candidat qui ne connaît que Terraform peut convenir si le poste prévoit de démarrer Crossplane. Il doit comprendre la réconciliation continue et ce qu'elle change face à un plan Terraform relu puis appliqué.
Comment reconnaître sur un CV une plateforme multi-clusters réellement exploitée ?
Des nombres et des opérations le montrent : combien de clusters, combien d'équipes, quelle méthode pour monter de version le parc, comment un nouveau cluster reçoit son socle. Un CV qui cite Argo CD, Crossplane et Cluster API sans aucune de ces informations décrit souvent un laboratoire. En entretien, le candidat dessine l'arborescence du dépôt GitOps et dit qui pouvait fusionner en production.
Une CKA sur le CV dit-elle quelque chose du niveau GitOps ?
Peu. La CKA vérifie l'administration de Kubernetes en ligne de commande. Les certifications de la Linux Foundation sur Argo et le GitOps (CAPA, CGOA) sont des QCM de 90 minutes. Aucune ne mesure la conception d'API Crossplane ni l'exploitation d'un parc. Un test technique court règle la question : un dépôt GitOps à corriger, ou une Composition à commenter.
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.
