NoOps est-il le futur de DevOps ?

Tribune : Les processus de production hérités des équipes de développement infusent désormais partout dans la DSI. Au point de tuer certains cadres méthodologiques ? Yann Guernion, de l’entreprise Automatic, fait le point dans cette tribune sur les conséquences du DevOps.

Par Yann Guernion, Automic |

Le DevOps a pour principal objectif de décloisonner les équipes Développement (Dev) et Opérations (Ops) afin qu’elles puissent travailler de manière plus fluide et agile. Une agilité indispensable pour accélérer la livraison de nouveaux services digitaux et améliorer la compétitivité des entreprises sur des marchés en mutation rapide. Néanmoins cela n’a pas empêché que le DevOps a fait couler beaucoup d’encre dans l’IT ces derniers mois.

Aussi DevOps est-il souvent interprété comme une extension de la sphère d’influence du Développement au détriment des équipes de Production. Il est vrai que le concept d’agilité est essentiellement porté par les développeurs depuis le début des années 2000 avec le fameux Manifeste pour le Développement Agile. Du côté des Opérations, les bonnes pratiques ont été formalisées dans des cadres méthodologiques tels qu’ITIL et mises en œuvre par la plupart des grandes entreprises depuis le milieu des années 1990. Les deux approches semblent s’opposer puisque DevOps prône l’accélération et la multiplication des changements alors qu’ITIL tend à les contrôler et les maîtriser. Est-on en train d’assister à l’une de ces mutations spectaculaires qui va voir disparaitre les équipes Opérations ?

 Le futur de DevOps est-il NoOps ?

Probablement pas, et surement pas de façon aussi caricaturale. Pour la simple raison que le Développement ne veut pas avoir à faire avec les infrastructures, et que bien peu d’organisations sont prêtes à faire confiance aux développeurs pour gérer leurs datacenters, qu’ils soient physiques ou virtuels. Ainsi DevOps ne signifie pas la fin des Opérations, bien au contraire, les Opérations restent essentielles dans toute démarche DevOps.

Les infrastructures de production constituent en effet un empilement de technologies complexe et délicat, discret mélange d’architectures modernes et d’applications historiques. Il est ainsi très souvent impossible pour le Développement de recréer ces environnements particuliers, et c’est pour cette raison que bien souvent une application pourtant testée avec succès dans un environnement de qualification ne fonctionnera pas correctement en production. Il est pourtant crucial de pouvoir valider un nouveau développement dans un réplica représentatif de l’environnement de production. Alors DevOps est-il voué à un échec permanent faute de continuité entre les plateformes de qualification et les systèmes de production ?

DevOps induit OpsDev

C’est surement le cas si l’on se borne à considérer DevOps comme une simple démarche descendante du Développement vers les Opérations. Se contenter de produire des changements à une cadence plus élevée ne fait que déplacer et faire prospérer un goulet d’étranglement qui s’installe durablement au niveau de la production, sans produire la valeur ajoutée tant attendue par l’entreprise. DevOps doit donc également être envisagé comme une démarche remontante. Pour schématiser, si l’on considère DevOps, on doit également prendre très sérieusement OpsDev en considération.

En pratique, pour une approche DevOps réussie, le Développement doit se positionner en tant que consommateur d’infrastructures clé en main. Les Opérations s’installent alors dans une démarche OpsDev, et fournissent des infrastructures à la demande pour toutes les phases d’intégration continue depuis la compilation jusqu’à la qualification, en passant par les tests unitaires. Si DevOps constitue un changement radical dans la manière dont le Développement travaille, OpsDev révolutionne également les pratiques des Opérations. Cela passe par des infrastructures « déclaratives » plus agiles, décrites et construites à partir d’un code source, une automatisation encore plus sophistiquée et la possibilité de fournir des services d’infrastructure en accès-libre pour les développeurs.

Ainsi l’adoption de DevOps ne présage-t-il pas de la disparition des Opérations au profit du Développement, mais plutôt de l’instauration d’une agilité bidirectionnelle. DevOps appelle OpsDev plutôt que NoOps. Finalement, que l’on se plaise à regarder son processus de mise en production sous l’angle DevOps ou ITIL, l’objectif final affiché n’est–il pas exactement le même : livrer un service aux clients en tendant vers le zéro-défaut ?