À l’évocation du mot "DevOps", vous pensez probablement Kubernetes, Terraform, Azure DevOps ou Pipelines CI/CD. Pourtant, réduire l’approche DevOps à une suite d'outils est une erreur courante des organisations en transformation.

Il existe aujourd'hui une multitude d'outils pour répondre aux besoins techniques de l'IT. Mais installer Jenkins ou passer sur le Cloud ne suffit pas à devenir "DevOps". C'est même souvent le contraire. Vouloir mettre en œuvre un catalogue d'outils à la mode sans changer les mentalités revient à faire du "Cargo Cult", c'est-à-dire imiter la forme sans en comprendre le fond.

Dans cet article, nous présentons les anti-patterns que nous retrouvons le plus souvent ainsi que les défis à relever pour réduire le Time to Market (TTM) et à améliorer la qualité de vos produits logiciels (objectif initiaux de la culture Devops). Spoiler: les défis sont avant tout organisationnels!

Les 3 anti-patterns qui sapent votre transformation

Vouloir adopter une approche DevOps sans changement organisationnel conduit souvent à reproduire les mêmes erreurs sous de nouveaux noms. Dans ce contexte, nous rencontrons trois anti-patterns récurrents qui transforment l'ambition initiale, la réduisant au mieux à un statu quo, au pire à un échec coûteux.

Des nouveaux outils sans changer les pratiques

Le réflexe que nous observons fréquemment est de commencer par changer l’outillage des équipes. Les initiatives courantes sont la mise en place d’une CI/CD et un début d’automatisation de l’infrastructure. Le piège est de se cantonner à utiliser de nouveaux outils sans changer les pratiques. Si vos mises en production sont toujours des événements mensuels ou trimestriels avec un stock de fonctionnalités important, vos déploiements seront toujours risqués quand bien même ils sont automatisés dans un outil de CI/CD. La complexité d’intégrer un grand nombre de changements d’un coup sera toujours présente. La probabilité d’intégrer une régression majeure également. De plus, récolter du feedback auprès de vos utilisateurs se fera toujours tardivement augmentant le risque de développer des fonctionnalités coûteuses ne répondant pas à leur besoin.

Le rôle “DevOps”

Nous apercevons régulièrement des fiches de poste pour un “Ingénieur DevOps”. Ces dernières se résument généralement à une liste d’outils et ont pour but de compléter chaque équipe de développement. Les responsabilités qui leur incombent sont la gestion de la CI/CD et parfois faire le lien avec les équipes Ops. Les équipes résultantes sont autonomes pour livrer de nouvelles fonctionnalités mais ne gèrent toujours pas le run. Il subsiste donc toujours un mur de la confusion entre les Dév et les Ops péjorant la collaboration entre équipe. Cette approche génère également une forte dépendance à l’ingénieur DevOps, seule personne en charge de la CI/CD.

Il est important de rappeler que DevOps n'est pas un rôle. C'est une culture où la collaboration est au centre. Recruter un “DevOps” ou ajouter une équipe de médiation ne résout pas le problème de responsabilité partagée, cela ne fait que diluer la responsabilité.

L'équipe "DevOps"

À plus grande échelle, nous apercevons souvent la mise en place d’une équipe "DevOps". Dans ce schéma, l'équipe DevOps devient un proxy entre les équipes de Dév et les Ops. Elle est chargée de l'intégration et des environnements. Vous souhaitez accéder à une nouvelle base de données? Il faut demander à l’équipe DevOps. Créer un bucket S3? Il faut demander à l’équipe DevOps. Ajouter une variable d’environnement? … Vous comprenez l’idée. Le problème de cette approche est que les équipes de Dév ne sont toujours pas autonomes. Même si l’équipe DevOps est outillée avec de l’Infrastructure as Code, elle centralise toutes les demandes et finit par devenir un goulot d'étranglement. Se pose également la question d’être en capacité de valider les demandes comme détaillé dans notre article Le Cloud, ça coûte vraiment cher ! (part. 2).

Le défi de l'autonomie réelle (Team Topologies)

Éviter ces pièges demande de passer d'équipes ségrégées (Dev d'un côté, Ops de l'autre) à de véritables équipes autonomes et pluridisciplinaires. Comme détaillé dans notre article Le Cloud, ça coûte vraiment cher ! (part. 2), ce changement est le plus difficile à opérer car il nécessite de faire évoluer les comportements et d’instaurer de nouvelles habitudes à l’échelle de l’organisation. Il suppose de revoir la structure même de l'organisation. On parle ici de regrouper les Dév et les Ops dans une même équipe. Chaque profil s'enrichit au contact de l'autre afin de désiloter les savoir-faire et d'assurer une meilleure résilience collective. Les modèles proposés par Team Topologies sont une bonne source d’inspiration.

Le but final est d’obtenir des équipes produits qui livrent en flux continu réduisant ainsi les risques de mise en production et raccourcissant la boucle de feedback avec les utilisateurs. Les équipes sont souveraines sur leur périmètre (You build it, you run it) avec des équipes plateformes en soutien. Le rôle de ces dernières n’est plus de dépiler des tickets mais de mettre à disposition des produits d'infrastructure en libre-service, utilisable de manière autonome par les équipes produits, avec un support en cas de problème. À la manière d’un Software as a Service (SaaS), les équipes plateformes cherchent à répondre aux besoins de leurs clients (ici les équipes produits).

Mesurer le succès autrement

Passer d’une culture IT traditionnelle à une culture DevOps ne se fait pas du jour au lendemain. C’est pourquoi il est important de savoir si cette transformation et les investissements qui vont avec portent leurs fruits. Comment le mesurer?

Oubliez le nombre de conteneurs déployés ou la couverture fonctionnelle de votre usine logicielle. L'utilisateur final se moque de savoir si vous utilisez Kubernetes ou des scripts bash. Ce qui compte, c'est la valeur que vous lui apportez et la vitesse à laquelle vous le faites. Pour s'assurer que les investissements apportent les résultats escomptés, il est crucial de suivre des métriques orientées vers la performance et la satisfaction client, plutôt que des métriques purement techniques.

Les indicateurs clés (golden metrics) à surveiller sont :

• La fréquence de déploiement À quel rythme livrez-vous de la valeur ?
• Le délai de mise en production (Lead Time for changes) Combien de temps faut-il pour qu'une idée ou une correction arrive entre les mains de l'utilisateur ?
• Le Mean Time To Recovery (MTTR) En cas d'incident, à quelle vitesse le service est-il restauré ?
• Le taux d'échec des changements (Change Failure Rate) Quelle est la fiabilité de vos déploiements ?

C’est en mesurant l’ensemble de ces indicateurs que vous pourrez évaluer le succès de votre transformation. L’approche DevOps vise à optimiser et obtenir le bon équilibre entre vélocité et fiabilité.

Ces métriques permettent également d’aligner les objectifs des équipes. C’est un pas pour résoudre les objectifs historiques antagonistes entre les Dév et les Ops, les premiers cherchant à livrer de nouvelles fonctionnalités et les seconds à garantir un service stable à moindre coût.

Pour conclure

Le véritable frein d'une transformation DevOps n'est pas technologique, il est humain.

Les outils sont des accélérateurs, mais ils ne peuvent pas compenser une organisation silotée ou des processus de validation inefficaces. Pour réussir votre transformation, ne commencez pas par choisir votre orchestrateur de conteneurs. Commencez par aligner vos équipes (Métier, Dév, Ops) autour d'objectifs communs et réaliser un état des lieux (reality check) des compétences de vos équipes. Viennent ensuite l’autonomie et de responsabilisation de vos équipes, deux enjeux clés pour réduire votre Time to Market et améliorer la qualité de vos produits … avec ou sans outil dernier cri.