« DevOps » ! Le mot est à la mode et sur toutes les langues. Pourtant, pour le profane qui effectuera ses premières recherches sur le sujet, le concept peut sembler flou et difficile à cerner. En fait, c’est même pire que ça ! On a l’impression que DevOps est un mot caméléon qui s’adapte à celui qui l’emploie et derrière lequel on peut placer toutes sortes d’idées, de méthodes et d’outils. Ainsi, un « Dev » abordant le sujet parlera facilement d’intégration continue, d’automatisation des tests fonctionnels voire même d’agilité. Un « Ops » de l’autre côté aura tendance à mettre sur la table l’automatisation des déploiements, l’Infrastructure as Code ou encore une gestion des environnements optimisée.

Pourtant DevOps ne se limite pas à ce type de sujets : il les englobe. Osons une phrase toute faite : « Le tout est plus que la somme des parties ». Le piège c’est de ne pas voir le « tout » et de se concentrer sur les « parties ».

DevOps ce n’est pas faire parfaitement du développement d’un côté et gérer parfaitement les opérations de l’autre mais c’est justement créer un « Tout » qui permettra à la DSI d’apporter plus de valeur au client notamment en améliorant son TTM (Time To Market). Si on parle de « DevOps » en un seul mot, c’est justement pour effacer la frontière entre les 2 mondes.

Car ce sont bien souvent 2 mondes différents qui existent au sein des entreprises :

  • Leurs objectifs diffèrent (faire évoluer pour les Devs, assurer la stabilité pour les Ops)
  • Les processus et les outils ne sont pas partagés
  • La communication est souvent unilatérale (poussée des évolutions des Devs vers les Ops) et peut être conflictuelle  

DevOps

 

Le but de DevOps est de rassembler :

  • Autour d’un objectif commun : la satisfaction client
  • Sur la base de processus et d’outils partagés
  • En s’appuyant sur une organisation qui permet une communication bilatérale et efficace

 

Une réflexion qui suscite au moins deux conséquences directes

Premièrement, si des actions allant dans le sens de « DevOps » peuvent être menées par un responsable d’un bord ou d’un autre, la mise en place d’une véritable culture et organisation « DevOps » passe nécessairement par la Direction des SI.

En effet, ce ne sera qu’à ce niveau que l’on disposera de tous les leviers nécessaires pour entreprendre les actions structurantes fondamentales à un tel changement.
Autrement dit, un sponsoring fort de la part de la direction est un prérequis pour initier un changement de manière global. Et celui-ci devrait s’appuyer autant que possible sur un management transversal afin de faire progresser les équipes de manière homogène, évitant ainsi qu’un côté n’avance plus vite que l’autre ce qui pourrait générer des conflits supplémentaires.

Deuxièmement, « DevOps » n’est pas en priorité une affaire d’outils et de technique, mais plutôt de relations humaines et d’organisation. Mettez en place tous les outils que vous voulez, si les équipes derrière refusent de travailler ensemble, vous n’obtiendrez jamais un résultat satisfaisant.
Le but est de casser le mur des conflits entre les 2 mondes et d’instaurer une communication saine et efficace entre les équipes.

Poussé à l’extrême (chez Amazon par exemple), le concept de DevOps peut donner naissance à des équipes mixtes travaillant sur des projets ensemble, de l’expression de besoin à l’exploitation.
On ne retrouve plus les Devs d’un côté, les Ops de l’autre, mais des cellules projets contenant chacune des Devs et des Ops. C’est une parfaite illustration des deux points précédents : on comprend qu’une telle organisation ne pourrait venir des « Ops » ou des « Dev » puisqu’il s’agit de les associer, cette décision ne pouvant être prise qu’à un niveau supérieur. Et on comprend l’idée révolutionnaire qu’il y a derrière sans même parler d’outils ou de technique mais bien en se recentrant sur le concept d’équipe et donc de relations humaines.

 

Rétablir le dialogue entre les « Devs » et les « Ops »

Ceci peut passer par des actions simples :

  • Mise en place d’instances de gouvernance et de communication communes
  • Partage des informations et des outils
  • Séminaires de rapprochement des équipes

Mais aussi par des chantiers plus complexes :

  • Changement des méthodes de gestion de projet
  • Refonte des processus
  • Réorganisation

 

Pour résumer, il ne faut pas voir l’automatisation du processus dev / livraison / tests / déploiement comme une finalité de DevOps. C’est une brique importante et l’outillage et les changements de processus pour y parvenir sont des projets d’envergure à ne pas sous-estimer. Mais ces projets doivent s’inscrire dans une vision plus large de rapprochement des équipes et de culture du partage, l’ensemble devant être porté par une stratégie définie sur le long terme et suivie par la DSI dans sa globalité.

Finalement, DevOps, c’est avant tout une ouverture avant d’être un cadre méthodologique et technologique restrictif.

 

Stéphane Defaye, Responsable d’Exploitation des systèmes et des infrastructures chez COFELY INEO
« L’opposition des dev et des ops est originelle et universelle. Résumer une solution à l’acquisition d’un logiciel estampillé devops est réducteur. Si nous devons toujours aller plus vite pour servir le métier, ce ne peut être au détriment d’une certaine sécurité pour les services de production.
Talisker élargit le champ de vision et aide à mettre en évidence et résoudre des difficultés entre les développements et la production qu’aucun outil ne règlera sans changement de méthode ou d’organisation. »

FavoriteLoadingAjouter à mes favoris

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.