Ingénierie
Développeur
Cinq niveaux, de junior à Principal, sur six compétences : de la livraison du code au développement de l’équipe.
- 5 niveaux
- 6 compétences
Modèle d’échelle de carrière
Modèle d’échelle de carrière pour ingénieurs DevOps
Quatre niveaux, d’ingénieur DevOps junior à Staff, sur six compétences, de l’infrastructure au support aux développeurs.
Offre gratuite · Sans carte bancaire
Cette échelle de carrière s’adresse aux ingénieurs DevOps, plateforme et infrastructure des entreprises d’environ 20 à 200 personnes. À cette taille, l’équipe infrastructure compte généralement une à six personnes qui gèrent les comptes cloud, les pipelines de livraison, le monitoring et l’astreinte, et qui passent autant de temps à aider les développeurs qu’à toucher aux serveurs. Elle décrit quatre niveaux, de la personne qui apporte des changements d’infrastructure bien cadrés à celle qui porte l’orientation de la plateforme de l’entreprise. Son niveau le plus élevé, Staff DevOps Engineer, est un niveau expert ; manager l’équipe infrastructure est un autre métier.
Chaque niveau se définit par ce que la personne fait et par la part du système qu’on lui confie, pas par ses années d’expérience ni par le nombre d’outils sur son CV. Lisez une ligne de la matrice de compétences de gauche à droite pour voir comment une attente évolue ; lisez la section d’un niveau pour voir tout ce qui y est attendu. Servez-vous-en pour expliquer ce que signifie le niveau suivant, pour structurer les points de suivi et pour prendre des décisions de promotion que vous pouvez justifier.
Adaptez-la avant de la publier. Remplacez les formulations génériques par votre propre stack et vos pratiques, et retirez ce qui relève d’une autre équipe — par exemple si la sécurité ou les bases de données sont gérées ailleurs.
Les niveaux en un coup d’œil
Ingénieur DevOps junior
Apporte des changements bien cadrés à l’infrastructure et aux pipelines, avec relecture, et apprend comment tourne la production.
- Périmètre
- Des changements ponctuels dans le code d’infrastructure et les pipelines existants, planifiés et relus par quelqu’un de plus expérimenté.
Ingénieur DevOps confirmé
Porte des parties de l’infrastructure de bout en bout et assure pleinement sa part d’astreinte.
- Périmètre
- Les services, environnements ou pipelines d’une ou deux équipes produit, de la conception à l’exploitation au quotidien.
Ingénieur DevOps senior
Conçoit et pilote des projets d’infrastructure dont dépendent plusieurs équipes, et élève le niveau d’exigence en fiabilité.
- Périmètre
- L’infrastructure partagée qu’utilise la majeure partie de l’ingénierie, et des projets comme des migrations qui touchent toutes les équipes.
Staff DevOps Engineer
Fixe l’orientation de la plateforme de l’entreprise et répond de sa fiabilité, de sa sécurité et de son coût.
- Périmètre
- Toute la plateforme de production, son orientation pluriannuelle et son budget, pour toutes les équipes techniques.
Matrice de compétences
Chaque ligne est une compétence et chaque colonne un niveau. Lisez une ligne de gauche à droite pour voir comment les attentes évoluent.
Ce que recouvre chaque compétence
- Infrastructure as code
- Construire et modifier l’infrastructure par du code relu et reproductible plutôt qu’à la main.
- Pipelines de build et de livraison
- Faire passer le code d’une pull request mergée à la production rapidement et en toute sécurité.
- Fiabilité et réponse aux incidents
- Garder la production disponible et la rétablir rapidement quand elle ne l’est pas.
- Monitoring et observabilité
- Permettre de voir ce que fait la production et de savoir quand quelque chose tourne mal.
- Sécurité et accès
- Protéger les systèmes et les données par des réglages sûrs par défaut, le moindre privilège et des correctifs rapides.
- Support aux développeurs et collaboration
- Aider les développeurs à exploiter leurs propres services et partager les connaissances pour que la plateforme ne dépende pas d’une seule personne.
| Compétence | Ingénieur DevOps junior | Ingénieur DevOps confirmé | Ingénieur DevOps senior | Staff DevOps Engineer |
|---|---|---|---|---|
| Infrastructure as code | Modifie le code d’infrastructure existant en suivant les patterns déjà en place, vérifie le diff prévu avant de l’appliquer, et ne modifie jamais la production à la main sans demander d’abord. | Écrit des modules d’infrastructure réutilisables pour les nouveaux services et environnements, gère l’état et les secrets en toute sécurité, et supprime les ressources qui ne servent plus. | Conçoit l’organisation du code d’infrastructure et des environnements de l’entreprise, pilote des changements comme des mises à niveau de réseau ou de cluster avec un plan de retour arrière testé, et rend les dépenses cloud visibles par équipe. | Choisit les briques de base et les fournisseurs de la plateforme pour les prochaines années, fixe les standards que suit l’infrastructure de chaque équipe, et porte le budget d’infrastructure avec la direction. |
| Pipelines de build et de livraison | Répare les étapes de pipeline cassées, ajoute des jobs simples aux pipelines existants, et explique à un développeur pourquoi son build a échoué. | Construit et maintient le pipeline complet d’un service — build, tests, artefacts, déploiements dans chaque environnement — et raccourcit les étapes lentes dont se plaignent les développeurs. | Conçoit des modèles de pipeline partagés qu’utilisent toutes les équipes, introduit des méthodes de mise en production plus sûres comme les déploiements canary ou blue-green, et suit la fréquence de déploiement et le taux d’échec. | Définit la façon dont toute l’entreprise livre son logiciel, des branches au retour arrière, et supprime les goulots d’étranglement qui ralentissent la livraison de toutes les équipes. |
| Fiabilité et réponse aux incidents | Suit l’astreinte en binôme, applique les runbooks pour les alertes connues, et escalade rapidement avec les informations dont la personne suivante a besoin. | Assure pleinement sa part d’astreinte, résout seul la plupart des incidents de son périmètre, rédige des runbooks pour ce qu’il a corrigé, et teste les sauvegardes en les restaurant réellement. | Pilote la réponse aux incidents majeurs, anime des post-mortems sans recherche de coupable et mène les actions de suivi jusqu’au bout, et planifie la capacité et la bascule des systèmes critiques. | Fixe les objectifs de fiabilité avec le produit et la direction, conçoit le processus d’astreinte et d’incident pour toute l’ingénierie, et prépare les scénarios de sinistre comme la perte d’une région ou d’un fournisseur. |
| Monitoring et observabilité | Ajoute des tableaux de bord et des alertes en suivant les exemples existants, et consulte d’abord les logs et les métriques quand quelque chose semble anormal. | Met en place logs, métriques et alertes pour les nouveaux services, ajuste les alertes pour que chaque page appelle une action, et aide les développeurs à trouver ce dont ils ont besoin dans les données. | Conçoit l’approche d’observabilité des principaux systèmes de l’entreprise, définit les signaux de santé des services sur lesquels les équipes sont mesurées, et réduit le bruit des alertes dans toutes les équipes. | Choisit les outils d’observabilité de l’entreprise et leur modèle de coût, et s’assure que la direction peut voir la santé de la plateforme sans avoir à demander à un ingénieur. |
| Sécurité et accès | Respecte les règles de l’équipe sur les secrets et les accès, applique les correctifs courants, et signale immédiatement tout ce qui ressemble à un problème de sécurité. | Gère les accès et les secrets de ses services selon le moindre privilège, corrige les vulnérabilités selon leur gravité, et traite les constats des scans de sécurité. | Conçoit les frontières réseau, la gestion des identités et des secrets pour toute la plateforme, prépare les éléments de preuve pour les audits de sécurité des clients, et pilote la réponse aux incidents de sécurité. | Porte la posture de sécurité de la plateforme avec la direction, met en place les contrôles qu’exige la conformité (par exemple SOC 2 ou ISO 27001), et fait du chemin sécurisé le plus simple pour chaque équipe. |
| Support aux développeurs et collaboration | Répond aux questions des développeurs sur les environnements et les pipelines, documente les corrections qu’il apporte, et demande une relecture tôt. | Rédige des guides clairs pour les tâches courantes, travaille en binôme avec les développeurs pour déployer et déboguer leurs services, et intègre les nouveaux membres de l’équipe à l’infrastructure. | Construit des outils en libre-service qui permettent aux équipes de créer services et environnements sans ouvrir de ticket, accompagne d’autres ingénieurs DevOps en mentorat, et participe au recrutement. | Façonne la plateforme comme un produit interne dont les développeurs sont les utilisateurs, décide de ce qui revient aux équipes et de ce qui revient à l’équipe plateforme, et fait émerger les prochains ingénieurs seniors. |
Faites défiler le tableau horizontalement pour voir tous les niveaux.
Télécharger en CSV S’ouvre dans Excel, Google Sheets ou Numbers.
Ingénieur DevOps junior : ce qui est attendu
Apporte des changements bien cadrés à l’infrastructure et aux pipelines, avec relecture, et apprend comment tourne la production. Des changements ponctuels dans le code d’infrastructure et les pipelines existants, planifiés et relus par quelqu’un de plus expérimenté.
- Infrastructure as code
- Modifie le code d’infrastructure existant en suivant les patterns déjà en place, vérifie le diff prévu avant de l’appliquer, et ne modifie jamais la production à la main sans demander d’abord.
- Pipelines de build et de livraison
- Répare les étapes de pipeline cassées, ajoute des jobs simples aux pipelines existants, et explique à un développeur pourquoi son build a échoué.
- Fiabilité et réponse aux incidents
- Suit l’astreinte en binôme, applique les runbooks pour les alertes connues, et escalade rapidement avec les informations dont la personne suivante a besoin.
- Monitoring et observabilité
- Ajoute des tableaux de bord et des alertes en suivant les exemples existants, et consulte d’abord les logs et les métriques quand quelque chose semble anormal.
- Sécurité et accès
- Respecte les règles de l’équipe sur les secrets et les accès, applique les correctifs courants, et signale immédiatement tout ce qui ressemble à un problème de sécurité.
- Support aux développeurs et collaboration
- Répond aux questions des développeurs sur les environnements et les pipelines, documente les corrections qu’il apporte, et demande une relecture tôt.
Ingénieur DevOps confirmé : ce qui est attendu
Porte des parties de l’infrastructure de bout en bout et assure pleinement sa part d’astreinte. Les services, environnements ou pipelines d’une ou deux équipes produit, de la conception à l’exploitation au quotidien.
- Infrastructure as code
- Écrit des modules d’infrastructure réutilisables pour les nouveaux services et environnements, gère l’état et les secrets en toute sécurité, et supprime les ressources qui ne servent plus.
- Pipelines de build et de livraison
- Construit et maintient le pipeline complet d’un service — build, tests, artefacts, déploiements dans chaque environnement — et raccourcit les étapes lentes dont se plaignent les développeurs.
- Fiabilité et réponse aux incidents
- Assure pleinement sa part d’astreinte, résout seul la plupart des incidents de son périmètre, rédige des runbooks pour ce qu’il a corrigé, et teste les sauvegardes en les restaurant réellement.
- Monitoring et observabilité
- Met en place logs, métriques et alertes pour les nouveaux services, ajuste les alertes pour que chaque page appelle une action, et aide les développeurs à trouver ce dont ils ont besoin dans les données.
- Sécurité et accès
- Gère les accès et les secrets de ses services selon le moindre privilège, corrige les vulnérabilités selon leur gravité, et traite les constats des scans de sécurité.
- Support aux développeurs et collaboration
- Rédige des guides clairs pour les tâches courantes, travaille en binôme avec les développeurs pour déployer et déboguer leurs services, et intègre les nouveaux membres de l’équipe à l’infrastructure.
Ingénieur DevOps senior : ce qui est attendu
Conçoit et pilote des projets d’infrastructure dont dépendent plusieurs équipes, et élève le niveau d’exigence en fiabilité. L’infrastructure partagée qu’utilise la majeure partie de l’ingénierie, et des projets comme des migrations qui touchent toutes les équipes.
- Infrastructure as code
- Conçoit l’organisation du code d’infrastructure et des environnements de l’entreprise, pilote des changements comme des mises à niveau de réseau ou de cluster avec un plan de retour arrière testé, et rend les dépenses cloud visibles par équipe.
- Pipelines de build et de livraison
- Conçoit des modèles de pipeline partagés qu’utilisent toutes les équipes, introduit des méthodes de mise en production plus sûres comme les déploiements canary ou blue-green, et suit la fréquence de déploiement et le taux d’échec.
- Fiabilité et réponse aux incidents
- Pilote la réponse aux incidents majeurs, anime des post-mortems sans recherche de coupable et mène les actions de suivi jusqu’au bout, et planifie la capacité et la bascule des systèmes critiques.
- Monitoring et observabilité
- Conçoit l’approche d’observabilité des principaux systèmes de l’entreprise, définit les signaux de santé des services sur lesquels les équipes sont mesurées, et réduit le bruit des alertes dans toutes les équipes.
- Sécurité et accès
- Conçoit les frontières réseau, la gestion des identités et des secrets pour toute la plateforme, prépare les éléments de preuve pour les audits de sécurité des clients, et pilote la réponse aux incidents de sécurité.
- Support aux développeurs et collaboration
- Construit des outils en libre-service qui permettent aux équipes de créer services et environnements sans ouvrir de ticket, accompagne d’autres ingénieurs DevOps en mentorat, et participe au recrutement.
Staff DevOps Engineer : ce qui est attendu
Fixe l’orientation de la plateforme de l’entreprise et répond de sa fiabilité, de sa sécurité et de son coût. Toute la plateforme de production, son orientation pluriannuelle et son budget, pour toutes les équipes techniques.
- Infrastructure as code
- Choisit les briques de base et les fournisseurs de la plateforme pour les prochaines années, fixe les standards que suit l’infrastructure de chaque équipe, et porte le budget d’infrastructure avec la direction.
- Pipelines de build et de livraison
- Définit la façon dont toute l’entreprise livre son logiciel, des branches au retour arrière, et supprime les goulots d’étranglement qui ralentissent la livraison de toutes les équipes.
- Fiabilité et réponse aux incidents
- Fixe les objectifs de fiabilité avec le produit et la direction, conçoit le processus d’astreinte et d’incident pour toute l’ingénierie, et prépare les scénarios de sinistre comme la perte d’une région ou d’un fournisseur.
- Monitoring et observabilité
- Choisit les outils d’observabilité de l’entreprise et leur modèle de coût, et s’assure que la direction peut voir la santé de la plateforme sans avoir à demander à un ingénieur.
- Sécurité et accès
- Porte la posture de sécurité de la plateforme avec la direction, met en place les contrôles qu’exige la conformité (par exemple SOC 2 ou ISO 27001), et fait du chemin sécurisé le plus simple pour chaque équipe.
- Support aux développeurs et collaboration
- Façonne la plateforme comme un produit interne dont les développeurs sont les utilisateurs, décide de ce qui revient aux équipes et de ce qui revient à l’équipe plateforme, et fait émerger les prochains ingénieurs seniors.
Comment adapter cette échelle
Nommez votre stack dans les attentes
Des formulations génériques comme « code d’infrastructure » ou « pipelines » sont faciles à approuver et difficiles à évaluer. Remplacez-les par vos vrais outils et pratiques, pour qu’un ingénieur junior sache exactement ce qu’il doit apprendre en premier.
Attendez avant d’introduire le niveau Staff
Avec un à trois ingénieurs DevOps, les niveaux junior, confirmé et senior suffisent généralement. Ajoutez Staff quand quelqu’un fixe réellement l’orientation de la plateforme et porte son budget pour toute l’ingénierie, et non comme titre pour la personne la plus expérimentée d’une petite équipe.
Inscrivez vos règles d’astreinte dans l’échelle
Précisez à quel niveau on rejoint la rotation, quand on pilote les incidents et comment le temps d’astreinte est compensé. Des attentes d’astreinte non écrites sont l’une des raisons les plus fréquentes pour lesquelles les ingénieurs infrastructure s’épuisent et partent.
Alignez les niveaux sur votre échelle des développeurs
Faites correspondre chaque niveau DevOps au niveau de développeur de même périmètre et de même rémunération. Le travail de plateforme est du travail d’ingénierie, et garder les deux échelles alignées facilite les passages entre équipes produit et équipes plateforme.
FAQ
Questions sur cette échelle
Quelle est la différence entre un ingénieur DevOps, un SRE et un platform engineer ?
À strictement parler, DevOps est une façon de travailler plutôt qu’un intitulé de poste ; en pratique, dans les entreprises de 20 à 200 personnes, ces intitulés décrivent pour l’essentiel le même métier avec un accent différent : les SRE se concentrent sur les objectifs de fiabilité — typiquement les SLO et les budgets d’erreur — et sur les incidents, les platform engineers sur les outils en libre-service pour les développeurs, et les ingénieurs DevOps sur les pipelines et l’infrastructure. Une seule échelle couvre généralement les trois ; ajustez la formulation des compétences plutôt que de créer des échelles distinctes.
Quand une start-up a-t-elle besoin de son premier ingénieur DevOps ?
Généralement quand les développeurs passent une part notable de leur semaine sur les déploiements, les environnements et les problèmes de production au lieu des fonctionnalités, ou quand les clients commencent à demander des engagements de disponibilité et des audits de sécurité. Dans beaucoup d’entreprises, cela arrive vers 15 à 30 développeurs.
L’astreinte doit-elle compter pour la promotion d’un ingénieur DevOps ?
Oui, mais comptez ce que la personne apprend et améliore, pas le nombre d’alertes auxquelles elle a répondu. Bien piloter un incident majeur, rédiger des post-mortems dont les actions sont menées à bien et réduire le bruit des alertes sont des preuves claires du niveau suivant. Être souvent d’astreinte n’en est pas une.
Les certifications cloud comptent-elles pour le niveau d’un ingénieur DevOps ?
Elles peuvent aider quelqu’un à apprendre une plateforme, mais elles ne doivent pas décider d’un niveau. Évaluez ce que la personne a construit et fait tourner dans votre environnement au regard de la matrice de compétences. Un certificat sans ces preuves ne démontre pas le niveau suivant ; ces preuves sans certificat, si.
Combien de niveaux faut-il dans une échelle de carrière d’ingénieur DevOps ?
Trois ou quatre, car les équipes infrastructure des entreprises de cette taille sont petites. Ce modèle en utilise quatre — junior, confirmé, senior et Staff — et s’articule bien avec une échelle des développeurs à cinq niveaux, les niveaux Staff étant alignés.
Construisez cette échelle de carrière dans LadderKit — gratuitement
Configurez ses niveaux et ses compétences pour votre équipe, évaluez chacun par rapport à eux lors des points de suivi et gardez des décisions de promotion cohérentes.
Offre gratuite · Sans carte bancaire
Modèles associés
Ingénierie
Ingénieur QA
Quatre niveaux, d’ingénieur QA junior à Lead QA, sur six compétences, de la conception de tests aux pratiques qualité.
- 4 niveaux
- 6 compétences
Ingénierie
Engineering Manager
Quatre niveaux, d’Engineering Manager à VP of Engineering, sur six compétences managériales.
- 4 niveaux
- 6 compétences