Close

Qu'est-ce que la culture DevOps ?

Comment la culture DevOps aide à aligner les personnes, les processus et les outils sur une orientation client plus unifiée.

Portrait de Tom Hall
Tom Hall

Expert DevOps


Collaboration

DevOps est une approche Agile du changement organisationnel qui cherche à combler les fossés traditionnels entre les équipes, à éliminer les silos et à établir de nouveaux processus qui facilitent une collaboration accrue. Bien que DevOps soit rendu possible par de nouveaux outils et des pratiques d'ingénierie Agile, cela ne suffit pas pour exploiter les avantages de DevOps. Sans un état d'esprit, des rituels et une culture appropriés, il est difficile de tirer pleinement parti de DevOps.

Les personnes et la culture sont les principaux facteurs qui garantissent l'implémentation fructueuse de la méthodologie DevOps.
- Enquête Atlassian sur les tendances DevOps de 2020

Qu'est-ce que la culture DevOps ?


Par essence, une culture DevOps implique une collaboration plus étroite et une responsabilité partagée entre les équipes de développement et opérationnelles pour les produits qu'elles créent et gèrent. Elle permet aux entreprises d'aligner leurs employés, leurs processus et leurs outils sur une orientation client plus unifiée.

Il s'agit de favoriser la formation d'équipes multidisciplinaires qui assument la responsabilité de l'ensemble du cycle de vie d'un produit. Les équipes DevOps travaillent de manière autonome et adoptent une culture d'ingénierie logicielle, des workflows et un ensemble d'outils qui élèvent les exigences opérationnelles au même niveau d'importance que l'architecture, le design et le développement. Comprendre le principe « vous le développez, vous en êtes responsable » rapproche les développeurs de l'utilisateur, puisque cela permet de mieux cerner les exigences et les besoins de ce dernier. Les équipes opérationnelles étant davantage impliquées dans le processus de développement, elles peuvent ajouter des exigences de maintenance et des besoins client pour un meilleur produit.

La culture DevOps est axée sur la transparence, la communication et la collaboration accrues entre les équipes traditionnellement cloisonnées. Mais des virages culturels importants doivent être opérés pour rapprocher ces équipes. DevOps est un changement de culture organisationnel qui met l'accent sur l'apprentissage et l'amélioration continus, notamment grâce à l'autonomisation des équipes, à un feedback rapide, à une empathie et une confiance élevées, ainsi qu'à une collaboration entre équipes.

Logo de la pleine conscience
Matériel connexe

Adoptez une mentalité donnant la priorité au client

Logo de trophée
Matériel connexe

Découvrez les avantages de DevOps

DevOps implique des responsabilités partagées. Les membres des équipes de développement et opérationnelles doivent être responsables de la réussite ou de l'échec d'un produit. Les développeurs ne sont pas censés se limiter à développer un produit et à le transmettre à l'équipe opérationnelle. En effet, ils sont censés partager la supervision d'un produit tout au long de sa durée de vie, en adoptant une mentalité « vous le concevez, vous en êtes responsable ». Ils testent et exploitent des logiciels et collaborent davantage avec les équipes de QA et informatiques opérationnelles. Lorsqu'ils comprennent les défis auxquels sont confrontées les équipes opérationnelles, ils sont mieux à même de simplifier le déploiement et la maintenance. De même, lorsque les équipes opérationnelles comprennent les objectifs métier du système, elles peuvent collaborer avec les développeurs pour en définir les besoins opérationnels et adopter des outils d'automatisation.

Autre aspect important de DevOps, les équipes autonomes. Pour que les équipes de développement et opérationnelles puissent collaborer efficacement, elles doivent prendre des décisions et implémenter des changements sans passer par un processus d'approbation fastidieux et chronophage. Cela implique de faire confiance aux équipes et d'établir un environnement qui bannit la peur de l'échec. Ces équipes doivent disposer des processus et des outils appropriés pour prendre des décisions plus rapidement et plus facilement, pour chaque niveau de risque pour le client.

Par exemple, un workflow de développement classique peut nécessiter l'implication de plusieurs contributeurs de différentes équipes pour déployer les changements de code. Le développeur apporte un changement au code et l'envoie vers un dépôt de contrôle de version. Un ingénieur de développement développe et déploie le code dans un environnement de test. Un Product Owner met à jour l'état d'avancement du travail dans un outil de suivi des tickets, etc. Une équipe autonome tirera parti des outils qui automatisent ces processus, de sorte que l'envoi d'un nouveau code déclenchera le développement et le déploiement d'une nouvelle fonctionnalité dans un environnement de test et que l'outil de suivi des tickets sera mis à jour automatiquement.

Par exemple, une équipe est handicapée par des exigences telles que la nécessité d'ouvrir un ticket auprès d'une équipe opérationnelle distincte pour effectuer un changement d'infrastructure simple, comme une nouvelle entrée DNS. Une tâche qui devrait prendre quelques secondes finit par prendre des jours voire des semaines. Une équipe autonome a la possibilité d'implémenter ces changements elle-même, que ce soit grâce à la présence dans l'équipe d'une personne qui possède les compétences et l'expérience requises ou grâce à l'accès à des outils en libre-service.

Une culture d'équipe DevOps valorise un feedback rapide qui peut contribuer à l'amélioration continue d'une équipe de développement et opérationnelle unifiée. Dans un environnement où les équipes de développement et opérationnelles travaillent dans des silos isolés, les feedbacks sur les performances et la stabilité des logiciels applicatifs en production sont souvent lents à être renvoyés à l'équipe de développement, le cas échéant. DevOps veille à ce que les développeurs obtiennent le feedback rapide dont ils ont besoin pour itérer et améliorer rapidement le code applicatif en exigeant une collaboration entre les membres de l'équipe opérationnelle pour concevoir et implémenter des stratégies de surveillance des applications et de reporting. Par exemple, tout outil d'intégration continue suffisamment performant permettra de développer et de tester automatiquement les nouveaux pushs de code et fournira au développeur un feedback immédiat sur la qualité de son code.

L'automatisation est essentielle à la culture DevOps, car elle permet une grande collaboration et libère des ressources. En automatisant et en intégrant leurs processus, les équipes de développement et informatiques peuvent développer, tester et livrer des logiciels plus rapidement et de manière plus fiable.

Quels sont les avantages de la culture DevOps ?


Commençons par le plus évident (et le plus important) : des livraisons de logiciels simplifiées, fréquentes et de haute qualité. Cela augmente non seulement les performances de l'entreprise, mais également la satisfaction des employés.

Une culture DevOps favorise des niveaux élevés de confiance et de collaboration, se traduit par de meilleures prises de décision et des niveaux de satisfaction professionnelle encore plus élevés, selon le livre « Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations ».

L'adoption d'une culture DevOps est essentielle pour créer une organisation d'ingénierie ultra performante sans nuire à la satisfaction des employés. C'est gagnant-gagnant. Pour un ingénieur, rien ne vaut le sentiment de déployer et d'exécuter fréquemment et facilement des logiciels stables et ultra performants, qui font le bonheur de ses utilisateurs. Pour les dirigeants, rien de tel que l'amélioration des résultats métier.

Quels sont les défis ?


Pour adopter pleinement une culture DevOps, il faut généralement que les personnes et les équipes changent considérablement leurs méthodes de travail, ce qui nécessite un engagement aux plus hauts niveaux de l'organisation.

Une adoption par la base peut être, et est souvent, un point de départ important pour rallier les responsables et les cadres à une transformation DevOps. Souvent, l'adoption d'une approche DevOps par quelques personnes ou petites équipes, qui vont ensuite faire état du succès remporté, constitue l'argument le plus propice à une adoption plus large de DevOps.

Les niveaux élevés d'autonomie et de confiance typiques d'une culture DevOps peuvent être difficiles à favoriser en cas de conflits passés entre les personnes ou les équipes concernées. Plus les équipes étaient cloisonnées avant de tenter d'adopter une approche DevOps, plus il sera difficile de tisser des liens.

Le changement est difficile. Même dans les environnements où le niveau d'harmonie entre les personnes et les équipes en place est élevé, si les avantages du changement ne sont pas clairement énoncés et compris, il peut être difficile de le faire accepter et d'inciter les gens à s'investir.

Il est compréhensible que les organisations qui adoptent une solide approche orientée ingénierie se tournent immédiatement vers les outils et les technologies pour relever les défis métier. Car, oui, des outils et des technologies peuvent aider votre organisation dans sa transition vers une approche DevOps. Mais changer d'outils et de technologies sans repenser la culture est souvent qualifié de « culte du cargo DevOps », car seule la façade est refaite. Les faiblesses des fondations ne sont, elles, pas corrigées.

Considérations relatives à la transition vers une culture DevOps


Communication ouverte

Le cloisonnement des connaissances, de l'expérience et du travail dans différentes unités organisationnelles constitue l'un des défis essentiels que DevOps cherche à relever. Lorsque les programmeurs qui écrivent du code et les administrateurs système qui le déploient et le gèrent ne communiquent pas, des problèmes d'efficacité sont possibles.

La possibilité de commettre des erreurs

De nombreuses organisations, équipes et personnes se mettent une pression énorme, sur elles-mêmes et les unes sur les autres, pour ne jamais commettre d'erreurs. Si l'échec n'est pas envisageable, une personne ou une équipe sera moins encline à tenter une nouvelle approche pour résoudre un problème ou développer des fonctionnalités innovantes.

Cette mentalité transparaît dans l'obsession passée à mesurer l'« intervalle moyen entre les défaillances » (MTBF) par rapport au « temps moyen jusqu'à la remise en route » (MTTR). Le MTBF utilise des outils tels que « l'analyse des causes profondes » pour identifier la source des défaillances et tenter de les empêcher de se reproduire. Le MTTR reflète une vision des apps logicielles en tant que systèmes complexes susceptibles de tomber en panne de manière imprévisible et se concentre sur une récupération rapide en cas de panne.

La « rétrospective sans reproches » est une caractéristique courante de la culture DevOps. Les résultats peuvent être améliorés lorsqu'une équipe se réunit à la fin d'un sprint ou d'un projet pour discuter de ce qui s'est bien passé et de ce qui pourrait être amélioré, dans un environnement ouvert et sûr.

La réussite d'une vision sans reproches est liée à l'adoption d'une mentalité axée sur la croissance, qui reconnaît que l'on ne peut échapper aux erreurs, mais part du principe que les personnes et les organisations sont capables d'apprendre, de se développer et de s'améliorer.
- « Effective DevOps », Jennifer Davis et Katherine Daniels

Un nouvel ensemble de processus

Pour instaurer une culture DevOps, il faut développer de nouvelles approches pour résoudre d'anciens problèmes. L'approche DevOps implique de revoir le processus cloisonné des programmeurs qui écrivent le code applicatif et le « livrent aveuglement » à une équipe opérationnelle qui déploie et exploite l'app. Elle présuppose la collaboration des équipes de développement et opérationnelles tout au long du cycle de vie d'un projet.

L'intégration et la livraison continues (CI/CD) sont communément considérées comme nécessaires à une culture DevOps. Un troisième processus, le déploiement continu, est adopté et promu par de grandes organisations telles que Netflix, mais il n'est pas couramment adopté (ou nécessaire) dans la plupart des petites entreprises. En effet, le déploiement continu de nouvelles fonctionnalités dans un environnement de production exige un degré élevé de confiance dans le fait que le nouveau code a été minutieusement testé et peut être déployé en toute sécurité (p. ex., derrière un feature flag). Ainsi, à moins que votre organisation ne procède à des déploiements plusieurs fois par jour, il ne vaut peut-être pas la peine d'investir dans les processus qui soutiennent cette approche.

Dans la plupart des cas, appliquer une variante du « SLA de disponibilité » simplifiera considérablement vos efforts de CI/CD. Dans ce modèle, l'équipe élimine les branches de fonctionnalités au long cours et effectue des commits fréquents vers la branche « trunk » du code.

Les tests automatisés complets, qui incluent les tests unitaires, d'intégration et de régression, constituent une composante importante du SLA de disponibilité. Ils permettent de s'assurer que tous les nouveaux commits dans la branche « trunk » ont été soigneusement vérifiés lorsqu'ils sont pushés vers le dépôt.

L'intégration continue désigne le processus qui consiste à automatiser l'intégration des changements de code réalisés par plusieurs contributeurs dans un projet de développement. Elle s'étend au-delà des équipes de développement et touche le reste de l'organisation. Par exemple, les équipes produit coordonnent les lancements successifs de fonctionnalités et de correctifs, ainsi que les membres de l'équipe qui en seront responsables.

La livraison continue est une méthodologie organisationnelle qui fait appel à des équipes d'ingénierie ainsi qu'à des équipes non techniques telles que les équipes de design, produit et marketing afin de livrer un produit. Les environnements sans livraison continue encouragent des comportements de livraison à l'aveugle où les développeurs considèrent l'équipe de QA comme principal interlocuteur pour l'évaluation de l'expérience utilisateur. Cela signifie que la branche « trunk » de votre dépôt est à un état « déployable » à tout moment.

Le déploiement continu permet de déployer automatiquement les changements de code en production dès leur création, qu'ils soient masqués derrière un feature flag, déployés auprès d'un petit pourcentage de clients et/ou facilement annulables. Les équipes disposent ainsi d'une plus grande flexibilité pour répondre à l'évolution des marchés et des besoins des clients, puisqu'elles peuvent réagir aux feedbacks client, et déployer et valider rapidement de nouvelles fonctionnalités. Elles peuvent également facilement restaurer des fonctionnalités, ce qui leur permet de ne pas être freinées en cas de problèmes avec le build.

Les feature flags (ou feature toggles) ou le dark launch sont des méthodes courantes pour s'assurer que les nouvelles fonctionnalités applicatives n'apparaissent pas ou ne fonctionnent pas lorsqu'elles sont déployées dans l'environnement de production, mais qu'elles peuvent être activées avec un minimum d'efforts. Cette stratégie permet un déploiement continu, car le risque d'impact négatif sur les utilisateurs est très faible. Il est également courant de restreindre les fonctionnalités à un sous-ensemble de la base d'utilisateurs en les segmentant par région, ou en exécutant des instances de serveur distinctes et en livrant les fonctionnalités sur un seul serveur accessible aux utilisateurs.

Une chaîne d'outils mise à jour

La plupart des équipes de développement utilisent au moins un certain type d'outils de contrôle de version, de suivi des tickets et de surveillance des apps. Tous ces outils sont importants pour soutenir une culture DevOps, mais un logiciel compatible avec la CI/CD constitue le complément le plus important à la boîte à outils traditionnelle. Disposer d'un workflow automatisé qui prend un commit, le teste et le déploie est réellement le seul moyen d'obtenir rapidement le feedback nécessaire à une culture DevOps.

DevOps : un virage culturel éprouvé


Depuis des décennies, les développeurs poursuivent le rêve de livrer des logiciels plus fréquemment, avec moins d'efforts et moins de bugs. Désormais, les outils nécessaires à la concrétisation de ce rêve existent.

Atlassian a constaté que les organisations qui ont adopté DevOps déclarent livrer de façon plus qualitative (61 %), avec une fréquence de déploiement accrue et un délai de commercialisation plus rapide (49 %). Et les organisations ne sont pas les seules à en récolter les fruits : les experts affirment avoir acquis de nouvelles compétences (78 %) et reçu une augmentation (48 %).

Instaurer une culture DevOps peut s'avérer difficile, mais cela vaut la peine : la satisfaction des développeurs, des responsables et des clients augmente.

Vous souhaitez améliorer votre culture DevOps ? Commencez par le contrôle de santé des équipes de service. Exercez-vous à communiquer, à collaborer et à échanger des idées avec des collègues grâce aux 4 meilleurs scénarios pour instaurer une culture DevOps.

Tom Hall
Tom Hall

Tom Hall est un expert DevOps, un lecteur avide et un pianiste amateur.
Au cours des 20 dernières années, il a notamment obtenu les certifications Novell, EMC, VMware et AWS. Il a participé à l'organisation des DevOpsDays à Atlanta en 2016 et à Austin, au Texas, dans les années qui ont suivi.


Partager cet article

Lectures recommandées

Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.

Illustration Devops

Communauté DevOps

Illustration Devops

Atelier de simulation

Illustration d'une carte

Essayez la solution gratuitement

Inscrivez-vous à notre newsletter Devops

Thank you for signing up