DevOps met de la transversalité dans la DSI
Pourquoi l'outil n'est que le début — et comment le choc culturel entre développeurs et exploitants est le vrai sujet à résoudre.
Dans toutes les DSI, on ne compte plus les outils censés faciliter le travail qui restent sur étagères sans être utilisés. DevOps ne fait pas exception à cette règle — sauf si on comprend dès le départ que le vrai sujet n'est pas technique. C'est un projet de management.
J'ai lancé la démarche DevOps à la DSI de l'Académie de Versailles en 2015. Non pas parce que c'était le mot à la mode — quoique, il l'était déjà — mais parce que nous avions un problème concret : nos portails et services intranet ne pouvaient plus évoluer au rythme qu'attendaient les métiers. Chaque mise en production mobilisait une demi-journée pour quatre personnes, provoquait un arrêt de service d'une demi-journée, et nous avait conduits à accumuler les évolutions pendant trois à six mois avant une livraison majeure.
Le choc culturel qu'on ne dit pas assez
Il y a dans toute DSI une tension structurelle que tout le monde ressent mais que peu nomment clairement. D'un côté, les développeurs, dont la mission est de garantir l'évolution du système et de livrer rapidement. De l'autre, les équipes de production, dont la mission est de garantir la stabilité.
DEV — Les chargés de l'évolution
Objectif : livrer vite, livrer souvent, répondre aux demandes métier. Horizon : la prochaine version. Risque accepté : la régression.
OPS — Les gardiens de la disponibilité
Objectif : maintenir la stabilité, protéger la production. Horizon : le temps de service. Risque refusé : toute perturbation non maîtrisée.
Ce choc culturel ne se résout pas avec un outil. Il peut même être aggravé si on déploie l'outil sans travailler sur la culture : les développeurs adoptent la partie intégration continue, les ops adoptent la partie déploiement automatisé, et chacun reste dans son silo amélioré. On a modernisé les tranchées sans supprimer le no man's land.
Choisir un outil, c'est le début, ce n'est qu'une petite partie du problème, car il faut accompagner les équipes pour éviter que le développement et la production se regardent en chiens de faïence.
— Jacky Galicher, CIO-Online, juillet 2016Il y a toujours une bonne raison pour ne pas faire. Une bonne raison technique, organisationnelle, de calendrier. La résistance au changement dans une DSI ne se manifeste presque jamais par un refus frontal — elle se manifeste par une accumulation de bonnes raisons.
Ce que DevOps change vraiment : la perception des finalités
La phrase que j'ai prononcée en juillet 2016 dans CIO-Online — « DevOps met de la transversalité dans la DSI en changeant la perception des finalités » — est celle qui me semble la plus juste pour résumer ce que nous avons vécu.
Avant DevOps, chaque équipe avait sa finalité propre. Les développeurs livraient du code. Les exploitants maintenaient la production. DevOps ne change pas les rôles — il change la question que chaque rôle se pose : non plus « est-ce que j'ai fait ma part ? » mais « est-ce que le service rendu à l'utilisateur final s'est amélioré ? »
Ce que DevOps change : il donne à Dev et Ops une finalité commune mesurable — la satisfaction et la continuité du service — et les contraint à construire ensemble les indicateurs qui permettent de la piloter.
Notre choix de périmètre : les portails, et pourquoi
Quand nous avons lancé le POC DevOps en mai 2015, nous avons choisi le déploiement des portails et services intranet. Ce n'était pas arbitraire. L'audience de notre portail grand public dépassait souvent celle de grands médias — 3,5 millions de pages vues mensuelles pour le site institutionnel, 9 000 pages vues quotidiennes pour l'intranet @riane. L'enjeu de service public était immédiatement compréhensible par tous.
Et le problème était tangible : les directions métier ne pouvaient pas mettre à jour leurs portails de façon réactive. Chaque évolution attendait la prochaine livraison majeure, dans un délai de trois à six mois. Pour un service de communication institutionnelle, c'est insupportable. Fluidifier le déploiement était une opportunité d'innover.
La stack technique : un choix de maîtrise, pas de mode
La chaîne d'automatisation du POC DevOps — Académie de Versailles (2015)
Développement
- Eclipse, Git, Subversion
- Java, PHP
- JCMS / Jalios
- Méthodes agiles
Qualité & Livraison
- Jalios JADE — CI/CD
- Jenkins, JUnit, PHPUnit
- Docker, Vagrant
- CFEngine, Rudder
Production & Mesure
- Tomcat, Apache, Nginx
- Dollar Universe (Automic)
- Nudge APM
- Nagios, CheckMK
Jalios JADE est l'environnement d'intégration continue associé au CMS JCMS : production des livrables, mesure automatique et continue de la qualité des développements, supervision, détection des incidents. Il ne fait pas que compiler — il mesure en continu.
Nudge APM a peut-être eu le plus d'impact sur la culture de nos équipes. Ses sondes permettent de valider les temps de réponse et de diagnostiquer un problème avant une plainte d'utilisateurs — voire avant la mise en production effective. Ce déplacement de la réactivité vers l'anticipation est un changement de posture fondamental.
⚠ Le piège de l'approche purement technique
Déployer la chaîne d'automatisation sans travailler sur les indicateurs communs, c'est reproduire à l'échelle DevOps les erreurs du reporting ITIL classique : des processus bien définis, des outils déployés, et une opacité persistante sur ce qui fonctionne ou non. La question à poser avant tout outil : comment saurons-nous que ça marche mieux ?
Le TRS comme langage commun Dev et Ops
C'est ici que la démarche DevOps de Versailles se distingue. Nous n'avons pas lancé DevOps sur une page blanche. Depuis 2013, une culture de la mesure par le TRS existait — et cette culture a été l'une des conditions de réussite du projet.
Une étude IDC le confirme chiffres en main : parmi les organisations ayant réellement adopté DevOps, le critère de succès qui progresse le plus est la définition d'indicateurs communs Dev et Ops — +19 points. Plus que la conduite du changement. Plus que le support du management.
Les deux équipes doivent prendre conscience des défis des autres et parler un même langage pour mieux collaborer. S'accorder sur la définition de chaque indicateur et sur la façon dont il est mesuré.
— François Gilles & Charlotte Gondre, Think Tank Automic, septembre 2015Bilan à mi-parcours — et ce qui restait ouvert
Ce que j'aurais dit à mon équipe en 2015
Première chose : commencez par « comment saurons-nous que ça marche mieux ? » avant toute décision d'outillage.
Deuxième chose : le choc culturel entre développeurs et exploitants n'est pas un problème à résoudre avant de lancer DevOps — c'est une tension productive à canaliser grâce à DevOps, via une finalité partagée et des indicateurs communs.
Troisième chose : choisissez un périmètre dont tout le monde comprend l'importance. Pas le plus simple techniquement — le plus visible pour les métiers.
Quatrième chose : ancrez la démarche institutionnellement dès le départ. Un outil que vous seul défendez est un outil fragile.
DevOps n'est pas une destination — c'est une façon de voyager
Ce qui m'a le plus marqué dans notre démarche DevOps à Versailles, c'est qu'elle a changé la façon dont mes équipes se parlaient — avant même de changer la façon dont elles travaillaient. Quand des développeurs et des exploitants débattent ensemble de la définition du « taux de disponibilité de la plateforme de livraison », quelque chose d'important se passe : ils cessent d'être des représentants de leurs silos pour devenir membres d'une même équipe de service.
C'est ça, la transversalité. Pas une structure organisationnelle. Pas un outil. Une façon commune de regarder le même problème depuis des positions différentes, avec des indicateurs qui forcent à se parler.
Pour tout DSI qui engage une démarche DevOps : le premier investissement n'est pas dans la CI/CD. C'est dans le temps passé à faire asseoir ensemble les personnes qui ne se parlaient pas — et à leur poser la question : « Qu'est-ce qui devrait mesurer que nous faisons bien notre travail commun ? »
La démarche DevOps et le TRS mesuré via EasyVista ont été abandonnés après mon départ de l'Académie de Versailles fin 2019. Un mécanisme que j'analyse en détail dans un article dédié.
Pourquoi les outils de gouvernance dépendent trop des individus qui les portent, et ce que DSI et éditeurs peuvent faire pour l'éviter.
→ jgconsultants.fr