Ne vous précipitez pas sur les outils. Pour faire naître une approche DevOps, l’acculturation des équipes est bien plus importante. Fédérez vos collaborateurs autour d’objectifs partagés.
Le DevOps a ceci de commun avec les méthodes agiles qu’il s’articule autour de l’utilisateur final. Le postulat est le même : on fournira un meilleur produit car il aura été confronté plus rapidement et plus souvent aux utilisateurs.
Pour redonner de la place à l’utilisateur, pour le faire remonter dans la chaîne de production, il est important de rapprocher les « Devs » et les « Ops ».
Historiquement, les Devs (les Développeurs) et les Ops (les Exploitants) se partageaient la tâche : les Devs poussaient de nouvelles fonctionnalités, le plus fréquemment possible, et les Ops se chargeaient de garantir la stabilité de la production.
Deux objectifs (changement contre stabilité) qui pouvaient entrer en contradiction. Les Devs et les Ops n’ayant pas les mêmes intérêts, cela créait de la confusion et de l’incompréhension entre les équipes : manque de communication, allers-retours et remaniements permanents.
Construire des objectifs communs
L’approche DevOps, comme son nom l’indique, invite ces deux fonctions à travailler main dans la main. Pour y parvenir, pas de secret : il faut être capable de se donner des objectifs communs. La réorganisation des équipes passe par la définition de ces objectifs : il faut que chacun les reconnaisse comme pertinents et se les approprie.
Or, force est de constater que la tendance actuelle est plutôt de ramener la démarche DevOps à de l’outillage : qu’ils s’agissent d’Ansible, Docker ou encore Kubernetes, on trouve beaucoup d’offres d’emploi adressées à des ingénieurs DevOps qu’en réalité on destine à des rôles d’administrateurs systèmes, chargés de la mise en place de ces outils.
Ces aspects purement techniques ne devraient arriver qu’en deuxième intention, après la réorganisation.
On ne se passera ni des Devs, ni des Ops
Parmi les points de départ incontournables figure le sponsoring de la DSI, seule capable de fédérer les équipes Devs et Ops. Il faut définir avec elle des objectifs de transformation réalistes : dans une perspective agile, on ne veut pas de plannings qui dérapent, on préfère découper un grand projet en une succession de chantiers plus modestes et vraiment soutenables, qui apportent à chaque itération de la valeur.
L’approche DevOps se cultive par petites touches, pour changer progressivement les comportements, les habitudes et pour que les équipes s’approprient progressivement la démarche.
Attention : l’objectif est bien de construire une équipe mixte, et non d’effacer les uns ou les autres. On entend parfois que les Devs pourraient s’en sortir sans les Ops, qu’il suffirait (là encore) de les équiper de nouveaux outils.
Je suis certain du contraire. Nous avons besoin de garder ces deux compétences. Les Ops, qui ont des méthodes de travail différentes, savent ce qu’est la stabilité et la supervision d’un système. Tant qu’il y aura des serveurs où déployer des applications, on aura besoin des Ops !
Je trouve très important que ces deux profils cohabitent et que les équipes se « pollinisent ». Plus on développe la communication, mieux c’est. Il faut que chaque personne soit consciente du travail de l’autre. Quand un Dev ajoute une fonctionnalité, il doit avoir en tête les contraintes qu’il est en train d’ajouter à son déploiement et à son exploitation.
Bâtir une communauté
En début d’intervention, nous créons une core team avec des experts – consultants extérieurs, mais aussi des internes après formation – et le sponsor de la démarche. Cette équipe aura vocation à disparaître à terme, une fois la maturité acquise par les équipes.
Dans un second temps, une communauté de pratiques doit se mettre en place au sein de l’entreprise, pour partager leur expérience de la transformation DevOps en cours.
On va développer un état d’esprit orienté « métriques ». Avec peu de métriques, mais de bonnes métriques ! Par exemple, on va mesurer combien de temps il faut pour lancer une fonctionnalité, de bout en bout : entre l’idée et la mise en service (le « lead time »).
Le temps de réparation est important aussi : le MTTR (mean time to recover/repair), temps moyen pour se remettre d’une anomalie en production. Il indique le niveau de collaboration, plutôt dans le sens des Ops vers les Devs. Mais tout le monde a intérêt à ce qu’il se réduise !
Nous mesurons aussi le taux d’échec des déploiements, qui doit considérablement baisser puisqu’une meilleure collaboration entre Devs et Ops évite d’avoir de mauvaises surprises qui surgissent en fin de cycle.
Dernier point et non des moindres, surtout dans un contexte de guerre des talents dans la Tech : quand on entre dans une démarche DevOps, on améliore sensiblement la qualité de vie au travail. On réduit les tensions. Il est plus épanouissant de travailler en harmonie avec ses collègues, que de se renvoyer la balle dans une organisation silotée. Devs ou Ops, nous restons des animaux sociaux ! Et l’attractivité employeur ne peut qu’en tirer avantage.
