Convictions et retours d’expérience d’un architecte sur la mise en place de la méthode DevOps

Concaténation de « development » et « operations », le mouvement DevOps prend de plus en plus d’ampleur. On le résume souvent à une réponse miracle au prétendu fossé entre les équipes de développement logiciel qui veulent de l’agilité, et les équipes d’exploitation pour qui la stabilité est un impératif. Quelle est la réalité terrain ?

Olivier Parker, consultant et architecte IT, nous partage ses vécus terrains et ses convictions sur la mise en pratique de l’approche DevOps dans les organisations.

Quelle est ta définition pratique du DevOps ?

J’associerai deux notions pour expliquer le DevOps. Pour moi il s’agit de technologies associées à une nouvelle modalité organisationnelle, dont l’objectif est d’améliorer l’efficacité opérationnelle entre « Dev » et « Ops ». 

Cette définition met en lumière une de mes convictions ! On amalgame très souvent DevOps avec les outils, mais il ne faut pas oublier la facette organisationnelle.

Sans organisation, pas de DevOps. Il faut se demander comment je « co-travaille » en agilité, et ce que cela implique. Les moyens technologiques viennent ensuite !

Qu’est-ce qui est à la source de la méthode DevOps ?

Les liens entre les équipes Dév et Ops existent hors du DevOps, mais plutôt en mode « guichet ». L’équipe de développement logiciel livre l’application à l’équipe d’exploitation, qui la met ensuite en production.

Avec l’utilisation des méthodes agile, les équipes de développement sont en capacité de livrer plus d’applications sous des délais plus courts. De l’autre côté les équipes opérationnelles ont conservé un fonctionnement plus classique et prudentiel. 

Cela a créé un écart organisationnel entre les deux équipes, notamment sur le rythme de livraison des applications d’un côté et sur la capacité à les mettre en production de l’autre. Ce point de contention impacte l’efficacité opérationnelle. Pourtant, la solution ne peut pas être de négliger les contraintes opérationnelles et le bon fonctionnement du SI de production !

Ce goulot d’étranglement n’est pas le seul facteur. Les équipes d’exploitation sont depuis longtemps animées par une volonté d’automatisation de leurs activités. Les architectures virtualisées, puis les architectures Cloud et plus récemment les conteneurs ont ouvert encore plus d’opportunités d’automatisation des actions d’installation et de paramétrage : des serveurs, du stockage, du réseau, du système d’exploitation, des middlewares et des applications. 

Comment simplifier la mise en production des applications ? Comment accroître la scalabilité du SI ? Comment être plus agile pour le provisioning ?

Pour moi, le DevOps est né autant d’un écart organisationnel dû au travail en mode agile , que de retrouvailles des deux équipes autour d’une même volonté : l’automatisation et l’efficacité opérationnelle ! 

Comment se matérialise l’approche DevOps vis-à-vis de cette collaboration ?

L’approche DevOps facilite la coordination entre les deux équipes. Elle vise à aligner le Système d’Information sur les besoins de l’organisation en le rendant plus réactif.

Au-delà du changement de culture, le DevOps repose pour moi sur deux principes. Premièrement, déplacer une partie de la gestion de la mise en production vers l’équipe de développement, mais aussi automatiser l’action de MEP afin qu’elle devienne plus simple et transparente.

C’est en permettant à l’équipe de développement de gagner en autonomie que la gestion de la mise en production ne sera plus le maillon faible du cycle agile.

L’équipe de développement sait à quel moment déployer l’application. Il est donc logique que la tâche de MEP se déplace vers l’acteur initiateur dans le cycle agile. Cependant, si l’action n’est pas automatisée et contrôlée par les équipes Ops, cela ne peut pas fonctionner. 

Les moyens technologiques pour automatiser les gestes de MEP sont ainsi un déclencheur récent pour la démarche DevOps. On pense immédiatement au Cloud, mais ce n’est pas le seul levier. La gestion de conteneurs est en particulier un outil clé pour le DevOps.

Quel rôle jouent les conteneurs pour la démarche DevOps ?

Le conteneur est actuellement un moyen technologique central pour le DevOps. Le DevOps n’est pas mono modèle technologique, je souligne donc le « actuellement » !

Sans conteneur, les équipes d’administration des infrastructures informatiques doivent préparer à chaque fois « l’environnement d’accueil » pour recevoir l’application. Une étape complexe et à risque qui joue en défaveur des délais de MEP.

Toute cette complexité vole en éclat avec le concept de conteneurs. Le développeur va être autonome pour préparer tous les éléments nécessaires. Une fois que ce travail a été fait et vérifié en intégration, il sera transporté en l’état, sans altération de la qualité, en production.

Le conteneur sert donc pleinement l’enjeu d’agilité. L’impact est aussi positif sur l’évolution de l’applicatif en phase RUN pour faire face aux montées en charge et aux défaillances potentielles.

La technologie de conteneurs a deux vertus : fluidifier la relation entre Dev et Ops et rendre l’architecture IT plus scalable, robuste et résiliente.

C’est une partie bien précise du geste de MEP qui est déplacée des équipes Ops à Dev. Les équipes d’exploitation conservent bien sûr la maîtrise de l’architecture IT. Elles définissent aussi le « l’environnement d’accueil » lié aux conteneurs. Le développeur ne maîtrise pas tous les points d’adhérence avec le SI et n’a pas vocation à le faire !

Quelles sont tes convictions autour du DevOps ?

Ma première conviction c’est que le DevOps ne doit pas être uniquement perçu sous l’angle technologique. C’est aussi et avant tout de l’organisation et du change management. C’est d’autant plus important qu’avec une même solution technologique, le DevOps peut être mis en place d’autant de manières différentes qu’il y a d’entreprises ! La technologie n’est que le catalyseur.

Définir une matrice RACI entre Dev et Ops est un impératif. Si on ne soulève pas ces questions, elles vont se poser d’elles-mêmes lorsque les équipes seront au pied du mur.

Ma deuxième conviction, c’est que le DevOps amène en premier lieu de la valeur à l’équipe de développement logiciel. Je suis convaincu qu’il y a encore des pas à franchir sur les enjeux d’automatisation et d’hyper-industrialisation pour aller vers des équipes d’opérations agiles.

Prenons l’exemple de la gestion des compatibilités. Les développeurs sont maintenant dotés d’outils très puissants pour se synchroniser et gérer les dépendances. Du côté des Ops, lors d’une transformation globale en mode agile avec des dizaines de projets en parallèle, le point névralgique c’est la gare du triage et la coordination ! Il est facile de se faire déborder par les pièces du puzzle qu’on fabrique…

DevOps, DevSecOps… comment les enjeux de sécurité rentrent-ils dans l’équation ?

Les politiques de sécurité impliquent une certaine inertie. Au niveau de la démarche DevOps, cela peut créer des complications. Les technologies sont encore récentes et n’ont pas atteint toutes leurs lettres de maturité sur la sécurité. La gestion des « secrets » par ces technologies est considérée comme insuffisante au regard des experts de la sécurité pour certains cas d’usage (données bancaires, personnelles…).

La sécurité ne doit pas rester sur le côté à regarder le train agile passer. Elle doit être embarquée dès la première étape !

Cela soulève de vraies questions : A quelle itération du cycle agile passer du DevOps au DevSecOps ? Est-ce nécessaire ? Quels sont les risques ?

Il faut accepter d’arbitrer négativement la sécurité dans les phases d’expérimentation, mais avoir le courage managérial de la prendre en compte dès que le développement se pérennise. 

L’enjeu est donc de bien identifier lorsque je peux faire du DevOps et lorsque je dois basculer sur du DevSecOps. Le DevOps est une philosophie organisationnelle, elle n’est donc pas remise en compte par les enjeux de sécurité. Cependant, cela impose des arbitrages sur les moyens : lorsqu’il y a des enjeux de sécurité élevés, il faut par exemple laisser de côté la technologie de conteneurs, sans abandonner les principes d’agilité.

Quels sont les prérequis de la démarche DevOps au niveau de l’architecture informatique et des équipes IT ?

Le principal prérequis technique c’est d’être cloud ready ! C’est incontournable.

Au niveau humain, la mise en place de la démarche DevOps implique une montée en compétences des équipes. Les équipes de développement vont devoir prendre en compte de nouveaux éléments liés à la MEP. Les Ops doivent être prêts à gérer toute l’ingénierie, en lien avec le fournisseur Cloud, pour préparer l’environnement d’accueil des conteneurs. Cela implique aussi des deux côtés l’appropriation des technologiques sous-jacentes. 

Il faut anticiper une courbe d’apprentissage pour les deux équipes !

Je préconise de débuter par un exercice d’appropriation en montant un environnement sans risque : un « banc d’essai ». Les équipes de développement logiciel vont réaliser une application blanche représentative, mais bien sûr simple puisque jetable.

Une fois la maîtrise acquise par les deux équipes, on poursuivra avec une application à faible risque pour les métiers et à faible volume d’utilisateurs qui sera mise en production. Les deux équipes vont continuer ainsi progressivement tout en veillant à l’éligibilité des applications.

Dès lors qu’on parle d’ajustement automatique de l’architecture selon la charge, cela appelle aussi une vigilance FinOps. Il ne s’agit pas d’aller vite à n’importe quel prix. Ajuster ses coûts selon ses besoins n’est pas forcément synonyme de gains ! Il faut prêter attention aux dimensions financières, contractuelles et aux modalités de facturation.

Si tu avais quelques mots de conclusion ?

Comme dans tout changement avec une double facette technologique et organisationnelle, il faut bien appréhender les deux axes. La prudence doit aussi vous accompagner ; il faut certes évoluer, mais aussi se poser les bonnes questions et avoir de la rigueur dans sa démarche. La vélocité recherchée par le DevOps, ce sont les hommes et les femmes qui la porte ! 

Le DevOps porte de belles promesses, ne les gâchons pas par une préparation mal conduite ! Ce n’est pas non plus une solution miraculeuse : c’est une corde parmi d’autres pour agiliser son SI.

Olivier Parker

Consultant en architecture d’entreprise 
et management de projets

Projexion est un cabinet de conseil en transformation. Nous mettons à votre disposition un « collectif d’expertises » qui regroupe des consultants avec des parcours variés, et en particulier autour de l’architecture IT et des méthodes agiles.

Envie de découvrir nos offres pour agiliser son Système d’Information et mettre en place DevOps ?