Les deux facettes du DevOps : gourou de la technologie versus une nouvelle culture

De quoi s’agit-il?

Au cours des derniers mois, en examinant le marché de l’emploi DevOps , une tendance claire s’est manifestée: de nombreuses organisations considèrent encore DevOps comme deux intérêts distincts. Ci-dessous, je vais essayer de les démonter et de vous faire voir ce qui les fait fonctionner. Gardez à l’esprit que DevOps ici, c’est aussi très bien SecDevOps.

Bien que pour SevDevOps, il y ait très peu de sensibilisation (pour ne pas dire d'intérêt) de ses avantages, les raisons en sont exactement les mêmes et c'est ce dont nous parlons ici: tout est balancé dans le même tas. Et donc perdus dans la chaîne de valeur.

Posture 1: DevOps en tant que rôle spécialisé

Tout d’abord, et le plus souvent, je vois DevOps être promu comme un rôle de génie distinct, quelqu’un pour « combler le fossé » entre les développeurs qui créent des fonctionnalités et les administrateurs système qui s’immiscent dans l’infrastructure. DevOps arrive a maintenir son titre ici parce que le rôle se situe bien entre les deux: Dev et Ops.

• Forte demande, salaire élevé : Les rôles étiquetés « DevOps Engineer » restent courants. Les données de l’enquête montrent que 29% des équipes informatiques ont récemment embauché des ingénieurs DevOps, avec des salaires allant de ≈ 84 k$ US à 126 k$ US (pour 1 à 5 ans d’expérience) (Spacelift, Brokee).
• Rareté des compétences : 37% des leaders technologiques mentionnent DevOps/DevSecOps comme leur principal déficit de compétences (Spacelift).
• Chaînes d’outils spécialisées : La boîte à outils typique, Docker, Kubernetes, pipelines CI/CD, est solidement perchée sur les épaules de ces « spécialistes des lacunes » (Spacelift). 

Ce modèle est vite à démarrer: embauchez quelqu’un qui possède des "pipelines", de l’automatisation, de la conteneurisation et des déploiements infonuagiques. Les objectifs sont clairs. Mais il y a un danger: la concentration des responsabilités.

• La personne (ou l’équipe) DevOps devient un nouveau point de défaillance ou de goulot d’étranglement .
• Les transferts sont fréquents : développement de fonctionnalités à DevOps à infra. Cela peut ralentir la livraison et créer des frictions de communication.
• Du point de vue de la pérennité, il risque d’entraîner l’épuisement professionnel, la surspécialisation et la dépendance malsaine à l’égard de quelques personnes clés.
• Surtout, cela crée également un nouveau silo. Une chose que la plupart des amateurs de DevOps confirmeraient est indésirable.

Pour moi, il s'agit d'une appropriation.  DevOps a certainement prouvé qu'il était sexy là où il a été correctement mis en œuvre. Donc, parsemer le marché du travail avec le terme tout en trouvant une excuse pour lancer cette responsabilité sur une nouvelle "faction", semble un peu fourbe. Mais à proprement parler, c'est un de mes agacements très personnels.

Posture 2: DevOps comme paradigme culturel

L'alternative n'est pas mythique: mais c'est le changement holistique et culturel où DevOps est adopté par toute l'équipe.

• Propriété par les équipes : Les développeurs créent, déploient et exploitent leurs services avec intention.
• La responsabilité partagée élimine les goulots d’étranglement et les points de défaillance uniques.
• L’ingénierie de la plateforme et les plateformes de développement internes (IDP) permettent le libre-service: les développeurs obtiennent ou construisent des chaînes d’outils, des pipelines et des environnements à la demande, et non par l’intermédiaire d’un intermédiaire (Baytech Consulting, Wikipédia).
• Ce modèle s’aligne sur les valeurs de DORA : les équipes deviennent une élite, avec une livraison continue en moins d’une journée, une culture irréprochable et des équipes autonomes (Cortex), la sécurité et les opérations sont intégrées à leur travail, donc la coopération dès le départ.

De plus, en 2025, nous voyons le DevOps évoluer :

• AI/ML/LLM s’intègrent dans les pipelines pour la gestion prédictive des incidents, la génération d’autotests et les systèmes d’auto-réparation (DevOps.com, Baytech Consulting).
• DevSecOps intègre la sécurité dans CI/CD, réduisant les frictions et atténuant les risques tôt (DevOps.com, H2K Infosys).
• Les équipes de la plateforme se concentrent sur l’expérience des développeurs, pas seulement sur l’outillage, en mesurant le succès en fonction du débit, de la stabilité et de la satisfaction (Baytech Consulting, Wikipédia).
• La pérennité gagne du terrain: l’accent est mis sur la culture, le cadre CAMS et les cadres décisionnels pour intégrer la maintenabilité et la viabilité à long terme (arXiv).

Comme je l'ai déjà dit, si ce n'est pas simplement pour l'aspect de la pérennité, cela s'aligne beaucoup mieux avec ce que DevOps a à offrir. Pour faire simple*, il ne s'agit pas de travailler plus fort, mais de travailler mieux. Si vous ne pouvez pas amener vos développeurs à s'engager dans ce changement, c'est probablement le point que vous n'avez pas assez poussé.

Ce n’est pas tant un effet secondaire, cela leur rend la vie plus facile, meilleure.

*Simple ne remplace pas facile, gardez ça en tête.

Ma propre évaluation des deux approches

Aspect	Rôle de spécialiste DevOps	DevOps comme culture et ingénierie de plateforme
Il est temps de commencer	Rapide – embauchez quelqu’un qui « est propriétaire »	Plus lent, nécessite un changement culturel et des outils
Modèle de dépendance	Point de défaillance centralisé et unique	Responsabilité décentralisée et partagée
Goulots d’étranglement	Élevée – un spécialiste devient un goulot d’étranglement	Faible – les pipelines libre-service réduisent la friction
Évolutivité	Limité – nécessite plus de spécialistes au fur et à mesure que les équipes grandissent	Plus élevé – les plateformes partagées évoluent horizontalement
Résilience pérenne	Fragile – risque d’épuisement professionnel et de silos	Robuste – l’appropriation et la collaboration favorisent la santé
Intégration de la sécurité	Géré par un ou plusieurs rôles spécialisés	Intégré par défaut dans toutes les équipes
Innovation et autonomie	Contraintes, les dépendances ralentissent les progrès	Les équipes habilitées itèrent rapidement

Mon point de vue: La pérennité d’abord

Si vous avez lu mes autres articles dans le passé, vous devez commencer à me connaître: si ce n'est pas pérenne, j'aurai du mal à le défendre. Donc, comme dans les articles précédents, j’ai mis l’accent sur la pérennité, les développements que nous pouvons maintenir, évoluer et dont nous dépendons à long terme. Le modèle DevOps centré sur les spécialistes est opportun, mais il comporte des risques périlleux pour la pérennité: dépendance humaine excessive, connaissances cloisonnées et fragilité des processus.

Le modèle DevOps culturel, alimenté par la propriété de l’équipe et l’ingénierie de la plateforme, est plus difficile à atteindre, mais il correspond directement à cette pérennité que je vous souhaite. Les services deviennent auto-renforcés :

• Moins d’épuisement professionnel: La responsabilité partagée dilue la charge.
• Moins de goulots d’étranglement: Les outils en libre-service responsabilisent les équipes.
• Résilience culturelle: Les pratiques et les normes survivent aux changements de personnel.

Maintenant répondez-moi ceci: Lequel offre le meilleur rapport qualité-prix?

• Est-ce que l’embauche d’un autre expert est une victoire rapide, mais un passif à long terme?
• Investir dans la transformation culturelle et l’ingénierie des plateformes est-il plus gourmand en ressources au départ, mais beaucoup plus résilient et pérenne?

En d’autres termes : valorisons-nous les solutions rapides ou les systèmes de construction (humains et techniques) qui perdurent?

Quelle a été votre expérience? Vos efforts DevOps sont-ils centrés sur un modèle de transition ou intégrés à vos équipes? Quel chemin a le plus contribué aux opérations pérennes à grande échelle?

Poursuivons la conversation et construisons des systèmes DevOps qui responsabilisent d’abord les gens, puis les outils.
 

À venir :

Agentic SecDevOps, est-ce pour vous?