Recruter un DevOps ou un SRE, c'est d'abord lever une confusion : DevOps désigne une culture et des pratiques partagées par les équipes, alors que SRE est un rôle d'ingénierie centré sur la fiabilité. Confondre les deux, ou les assimiler à un sysadmin, mène droit à un mauvais recrutement.
DevOps : une culture, pas un poste
DevOps n'est pas un métier à proprement parler, mais un ensemble de pratiques visant à rapprocher le développement et l'exploitation. L'objectif : livrer plus souvent, avec moins de friction et plus de stabilité. Quand une offre cherche un ingénieur DevOps, elle décrit en réalité un profil capable d'industrialiser ces pratiques.
Concrètement, ce profil intervient sur la chaîne qui mène du code au déploiement en production. Il automatise ce qui était manuel, fluidifie les boucles de feedback et rend les déploiements répétables. Il pense systèmes, pas serveurs isolés.
- Automatisation des builds, tests et déploiements via des pipelines.
- Standardisation des environnements pour réduire les écarts entre dev, recette et production.
- Collaboration étroite avec les développeurs plutôt qu'un fonctionnement en silo.
SRE : l'ingénierie au service de la fiabilité
Le Site Reliability Engineering applique des méthodes d'ingénierie logicielle aux problématiques d'exploitation. Là où le DevOps cherche la vélocité, le SRE arbitre en permanence entre vitesse de livraison et stabilité du service, à l'aide d'objectifs mesurables.
Un bon SRE raisonne en SLO (objectifs de niveau de service) et en error budget : tant que le budget d'erreur n'est pas épuisé, on continue de livrer ; quand il l'est, on ralentit pour consolider. Cette logique change radicalement la manière de prioriser. Le SRE écrit aussi du code pour supprimer le travail répétitif et automatiser la réponse aux incidents.
En clair : tout SRE pratique le DevOps, mais tout DevOps n'est pas SRE. Le SRE pousse la démarche jusqu'à une discipline outillée et chiffrée de la fiabilité.
Les compétences réelles à rechercher
Au-delà des intitulés, ce sont les compétences concrètes qui comptent. Voici le socle technique attendu d'un profil DevOps ou SRE solide, quel que soit le titre affiché sur le CV.
- CI/CD : conception et maintenance de pipelines d'intégration et de déploiement continus, avec tests automatisés et stratégies de release maîtrisées.
- Infrastructure as Code : description de l'infrastructure sous forme de code versionné, reproductible et auditable, plutôt que de configurations manuelles.
- Cloud : maîtrise d'au moins un fournisseur majeur, des services managés, du réseau et des modèles de coûts associés.
- Observabilité : mise en place de métriques, logs et traces, avec des tableaux de bord et des alertes utiles plutôt que bruyantes.
- Gestion d'incident : capacité à diagnostiquer sous pression, à communiquer pendant la crise et à conduire un post-mortem sans chercher de coupable.
- Scripting et automatisation : aisance dans au moins un langage pour supprimer les tâches manuelles récurrentes.
La compétence la plus différenciante reste la gestion d'incident. Un candidat capable de raconter précisément un incident, son diagnostic et les correctifs durables mis en place vaut bien plus qu'un autre récitant une liste d'outils.
Ne pas confondre avec un sysadmin ou un dev classique
L'erreur la plus fréquente consiste à requalifier un administrateur système ou un développeur en DevOps sans en mesurer les écarts. Ces profils ont de la valeur, mais répondent à des besoins différents.
Un sysadmin excelle dans l'exploitation et la maintenance, souvent de façon manuelle et réactive. Un DevOps ou SRE pousse vers l'automatisation systématique et la pensée logicielle appliquée à l'infrastructure. À l'inverse, un développeur applicatif maîtrise le code mais ignore parfois les contraintes de production, de réseau et de coût d'exploitation.
Le bon profil se situe à l'intersection : il code comme un développeur et raisonne comme un exploitant. Pour cadrer ces attentes dès l'offre, une scorecard de poste aide à distinguer le socle indispensable du simple confort.
Où sourcer : les signaux qui ne trompent pas
Les meilleurs profils DevOps et SRE sont rarement en recherche active. Le sourcing repose donc sur l'identification de signaux concrets d'expertise, plutôt que sur la seule lecture des intitulés de poste.
- Contributions open source : modules d'infrastructure, outils internes publiés, correctifs sur des projets liés au cloud ou à l'observabilité.
- Post-mortems publics : articles détaillant un incident, sa cause racine et les actions correctives, signe d'une vraie culture de la fiabilité.
- Conférences et meetups : interventions techniques sur des sujets de production, qui révèlent à la fois l'expertise et la capacité à transmettre.
Pour atteindre ces profils, un sourcing booléen précis fait la différence. Construire des requêtes ciblées avec un générateur de requêtes Boolean permet de croiser compétences, outils et signaux d'engagement, au lieu de ratisser large sur un seul mot-clé.
Comment évaluer : system design et mise en situation
L'évaluation d'un DevOps ou d'un SRE ne se résume pas à un quiz d'outils. Elle doit mesurer la capacité à raisonner sur la fiabilité d'un système et à agir sous pression. Deux exercices sont particulièrement révélateurs.
Le premier est un system design orienté fiabilité : demandez au candidat de concevoir une architecture résiliente pour un service donné. Observez comment il anticipe les pannes, gère la redondance, définit des SLO et arbitre entre coût, complexité et disponibilité.
Le second est une mise en situation d'incident : présentez une panne en production et observez sa méthode. Pose-t-il les bonnes hypothèses ? Cherche-t-il les métriques pertinentes ? Communique-t-il clairement ? Propose-t-il un correctif durable et un post-mortem ?
Pour rendre ces entretiens comparables d'un candidat à l'autre, structurez-les avec une grille d'évaluation partagée :
- Conception fiable : prise en compte des pannes, redondance, dimensionnement et SLO explicites.
- Méthode de diagnostic : hypothèses ordonnées, usage des métriques, logs et traces.
- Automatisation : réflexe de supprimer le manuel et de rendre les actions reproductibles.
- Communication d'incident : clarté, gestion des parties prenantes, posture sans recherche de coupable.
- Culture post-mortem : capacité à transformer un incident en améliorations durables.
Chaque critère noté sur une même échelle limite le biais d'affinité et rend la décision défendable en comité de recrutement.
DevOps et SRE, est-ce le même métier ?
Non. DevOps est une culture et un ensemble de pratiques partagées par les équipes, tandis que SRE est un rôle d'ingénierie qui applique des méthodes logicielles à la fiabilité, avec des SLO et des budgets d'erreur. Un SRE pratique le DevOps, mais l'inverse n'est pas toujours vrai.
Un bon sysadmin peut-il devenir DevOps ou SRE ?
Oui, à condition d'évaluer la marche à franchir. Le passage exige une vraie montée en compétence sur le code, l'automatisation et l'infrastructure as code. Un sysadmin curieux, déjà engagé dans l'automatisation et le scripting, est un excellent candidat à la reconversion.
Faut-il privilégier le cloud ou les compétences fondamentales ?
Les deux comptent, mais les fondamentaux priment. Un candidat solide sur le réseau, les systèmes, l'observabilité et le raisonnement fiabilité s'adapte vite à un nouveau cloud. L'inverse est plus rare : une certification cloud sans bases solides ne tient pas en production.
Recruter un DevOps ou un SRE demande de clarifier le besoin, de viser les bons signaux et d'évaluer avec méthode. Si vous souhaitez structurer cette démarche sur vos prochains postes, échangeons lors d'un rendez-vous pour cadrer ensemble votre stratégie de recrutement Tech.