Platform Engineer / SRE 2026 : interview métier

Camille :

Bonjour Sophie. Mon parcours est assez représentatif de la mutation qu'a connue notre secteur ces dix dernières années. J'ai commencé ma carrière en 2014, après un diplôme d'ingénieur en informatique à l'ENSEEIHT de Toulouse. À l'époque, on ne parlait pas encore de Platform Engineering. J'ai débuté comme administratrice système classique dans une ESN, où je passais mes journées à configurer des serveurs Linux à la main et à gérer des baies de stockage. C'était l'époque héroïque mais épuisante des interventions nocturnes pour des pannes matérielles.

Vers 2018, j'ai pris le virage du Cloud et du DevOps. J'ai rejoint une start-up spécialisée dans l'IoT où j'ai découvert Docker et Kubernetes. C'est là que j'ai compris que l'avenir n'était plus de gérer des machines, mais de coder l'infrastructure. J'ai évolué vers un poste de Cloud Architect, puis de SRE (Site Reliability Engineer). J'ai passé quatre ans à optimiser la résilience de systèmes distribués complexes, à traquer la moindre milliseconde de latence et à automatiser les réponses aux incidents.

Il y a trois ans, j'ai rejoint SkyScale, un éditeur SaaS toulousain en pleine hyper-croissance. Mon rôle a alors basculé vers le Platform Engineering. Pourquoi ? Parce que l'entreprise avait besoin de passer à l'échelle. Nous avions 150 développeurs qui perdaient un temps fou à configurer leurs environnements de test ou à demander des accès base de données. Mon job est devenu de créer une « plateforme interne » (IDP) pour que ces développeurs soient totalement autonomes. Aujourd'hui, en 2026, je ne répare plus des serveurs : je construis un produit logiciel dont les clients sont les autres développeurs de ma boîte.

Camille :

En 2026, le Platform Engineering est l'aboutissement logique de la philosophie DevOps qui a parfois montré ses limites. Il y a quelques années, on disait aux développeurs : « You build it, you run it » (tu le codes, tu l'opères). C'était une belle intention, mais dans la réalité, c'est devenu une charge cognitive insupportable pour eux. Le Platform Engineering est né pour réduire cette charge.

Concrètement, notre mission en 2026 est de construire et de maintenir une Internal Developer Platform (IDP). Imaginez une sorte de portail interne, souvent basé sur des standards comme Backstage, où un développeur peut, en trois clics, provisionner un nouvel environnement de micro-services, configurer un pipeline CI/CD sécurisé et obtenir un dashboard de monitoring pré-configuré. Nous créons ce que nous appelons des « Golden Paths » : des configurations standardisées, sécurisées et optimisées que les développeurs peuvent emprunter sans se soucier de la tuyauterie complexe qui se cache derrière.

L'aspect crucial en 2026, c'est l'intégration de l'intelligence artificielle générative dans ces plateformes. Mon quotidien consiste aussi à entraîner et superviser des agents IA qui aident les développeurs à diagnostiquer leurs erreurs de déploiement en langage naturel. Nous ne sommes plus des « gardiens du temple » qui disent non, mais des « facilitateurs » qui offrent des outils en libre-service.

Camille :

C'est une excellente question, car la frontière est devenue très nette en 2026. Pour faire simple : le Platform Engineer construit la scène, tandis que le SRE s'assure que le spectacle continue sans interruption. Le Platform Engineer a une approche « produit » orientée vers l'efficacité des développeurs (Developer Experience). Le SRE a une approche « opérationnelle » orientée vers la fiabilité et la disponibilité du système pour les clients finaux.

Le métier de DevOps et ses spécificités s'est scindé en ces deux spécialités pour mieux gérer la complexité. Le SRE va passer beaucoup de temps sur les SLO (Service Level Objectives) et les SLI (Service Level Indicators). Le Platform Engineer, lui, va se demander comment automatiser le déploiement de ces outils de monitoring pour que le développeur n'ait même pas à y penser.

Voici un tableau comparatif pour mieux visualiser les nuances en 2026 :

Caractéristique	Platform Engineer	SRE (Site Reliability Engineer)
Objectif principal	Optimiser la vélocité et l'autonomie des devs	Garantir la disponibilité et la performance
Client principal	Le développeur interne	L'utilisateur final du service
Indicateur clé (KPI)	Temps de provisionnement, adoption de l'IDP	Taux de disponibilité (Uptime), Error Budget
Activité majeure	Développement d'outils et de portails	Gestion des incidents, automatisation de la remédiation
Approche	Infrastructure as a Product	Infrastructure as a Service / Reliability

Chez SkyScale, mon équipe de Platform Engineering travaille main dans la main avec les SRE. Si les SRE constatent qu'une configuration de base de données cause régulièrement des latences, ils nous remontent l'information. Nous modifions alors le « Golden Path » dans notre plateforme pour que, par défaut, toutes les futures bases de données créées par les développeurs intègrent le correctif de performance.

Camille :

C'est tout à fait vrai ! Ma journée commence généralement par une analyse des métriques d'utilisation de notre plateforme. Je regarde combien de nouveaux services ont été déployés hier et si certains développeurs ont rencontré des erreurs lors de l'utilisation de nos API internes. En 2026, nous utilisons énormément de ressources et outils logiciels pour administrateurs système qui ont évolué vers des versions cloud-native ultra-intégrées.

Ensuite, j'ai souvent une session de « User Research ». Oui, comme un Product Designer ! Je m'assois avec une équipe de développeurs Front-end ou Mobile pour comprendre leurs points de friction. Le codage représente environ 50 % de mon temps, principalement en Go ou en Python, pour étendre les fonctionnalités de notre IDP ou écrire des contrôleurs Kubernetes personnalisés.

L'après-midi est souvent consacrée à la « Gouvernance automatisée ». Je travaille sur des « Policies as Code » (avec OPA — Open Policy Agent). Par exemple, je code une règle qui interdit automatiquement le déploiement d'un conteneur s'il contient une vulnérabilité critique ou s'il dépasse un certain budget carbone. C'est ce qu'on appelle le GreenOps.

Enfin, il y a une part importante de mentorat et de documentation. Une plateforme n'est utile que si elle est comprise. Nous ne sommes pas dans une tour d'ivoire ; nous sommes au cœur de la machine, à l'écoute constante de ceux qui l'utilisent.

Camille :

Le socle technique reste exigeant, mais il s'est déplacé vers le haut de la pile. Voici les piliers actuels :

• Maîtrise de l'orchestration (Kubernetes) : le système d'exploitation du Cloud en 2026. Il faut savoir l'étendre via des « Operators » et des « Custom Resource Definitions » (CRD).
• Infrastructure as Code (IaC) et GitOps : Terraform et OpenTofu sont des prérequis, avec une tendance forte vers Crossplane pour gérer l'infrastructure via l'API Kubernetes.
• Développement logiciel : un Platform Engineer doit être un bon développeur, souvent en Go, le langage roi de l'infrastructure.
• Sécurité (DevSecOps) : comprendre les concepts de Zero Trust et de gestion des secrets, en lien étroit avec les métiers de la cybersécurité en 2026.
• FinOps et GreenOps : savoir coder de manière rentable et écologique est devenu une compétence technique à part entière.

Côté « soft skills », l'empathie est primordiale. Vous construisez pour les autres. Il faut aussi une vision « Produit » : savoir dire non à une fonctionnalité trop spécifique et savoir prioriser sa roadmap en fonction de la valeur ajoutée pour l'entreprise.

Camille :

Le marché est extrêmement tendu, ce qui tire les salaires vers le haut. Le Platform Engineering fait clairement partie de les métiers du développement web les mieux payés. Les entreprises ont réalisé qu'un bon Platform Engineer peut débloquer la productivité de 50 développeurs.

Voici une estimation des salaires moyens constatés en France en 2026 :

Profil	Expérience	Salaire brut annuel
Junior	2-3 ans (dev ou ops)	55 000 € – 65 000 €
Confirmé	5-8 ans	70 000 € – 90 000 €
Senior / Staff Engineer	10 ans et plus	95 000 € – 130 000 € (+ packages d'actions en scale-up)

Les perspectives de carrière sont excellentes : Staff Engineer, Platform Product Manager, VP Infrastructure, ou consulting indépendant avec des TJM oscillant entre 850 € et 1 200 €.

Camille :

Pas du tout, c'est au contraire un métier de « maturité ». On fait rarement du Platform Engineering en sortant d'école. Se reconvertir dans le développement après 30-40 ans est tout à fait possible et même très fréquent dans nos équipes.

Pour se reconvertir, je conseille une approche en trois étapes : solidifier le socle Cloud avec des certifications reconnues, apprendre à coder si vous venez de l'Ops, et pratiquer sur des projets Open Source portés par la CNCF comme Kubernetes ou Backstage.

Voici une petite checklist pour votre plan de formation :

1. Maîtriser Docker et l'isolation des conteneurs.
2. Apprendre le Go ou le Python à un niveau avancé.
3. Comprendre les principes du « Platform as a Product ».
4. Savoir manipuler des outils de CI/CD modernes (GitHub Actions, GitLab CI).
5. Se former aux bases de la sécurité cloud.

De nombreux bootcamps spécialisés « Cloud & Platform » permettent à des profils expérimentés de faire la transition en 3 à 6 mois.

Camille :

L'erreur numéro un, et de loin, c'est l'over-engineering. On voit souvent des ingénieurs construire une plateforme incroyablement complexe pour répondre à des problèmes que les développeurs n'ont pas. Si votre plateforme est plus compliquée à utiliser que l'infrastructure brute, personne ne l'utilisera.

Voici une liste des erreurs à éviter absolument :

• Ne pas traiter la plateforme comme un produit : imposer des outils sans consulter les développeurs.
• Vouloir tout automatiser tout de suite : automatiser un processus bancal ne fait que générer des erreurs plus rapidement.
• Oublier la « Day 2 operation » : déployer un cluster Kubernetes est facile ; le mettre à jour sans interruption six mois plus tard l'est beaucoup moins.
• Le manque de standardisation : une plateforme qui permet dix manières différentes de tout faire augmente la charge cognitive au lieu de la réduire.

Enfin, il y a le piège de la « plateforme fantôme » : si vous passez 80 % de votre temps en support, vous n'êtes plus un Platform Engineer, vous êtes un Ops déguisé.

Camille :

Mon premier conseil serait de commencer par s'intéresser à ce qui se passe après le « git push ». Allez voir vos collègues de l'infra, demandez-leur d'expliquer comment le trafic arrive jusqu'à votre code, comment les secrets sont gérés, comment la base de données réplique ses données.

Devenez le « référent infra » de votre équipe. Proposez d'améliorer le Dockerfile, d'optimiser le pipeline CI/CD ou de mettre en place de meilleurs tableaux de bord de monitoring. Le Platform Engineering, c'est avant tout une question d'état d'esprit : vouloir rendre le système meilleur pour tout le monde.

N'ayez pas peur de la complexité de Kubernetes ou du Cloud. En 2026, l'important n'est pas de tout savoir, mais de savoir où chercher et comment apprendre vite. C'est un métier d'avenir, au croisement de l'humain et de la technologie de pointe, et la France a besoin de beaucoup de talents dans ce domaine pour rester compétitive.