Quelles évolutions pour le DevOps ?

par Marc Dallas

Le concept DevOps s’est largement développé ces dernières années dans de nombreuses organisations souhaitant répondre plus efficacement à leurs enjeux business.
Si DevOps concernait jusque-là principalement les services IT, il se répand aujourd’hui sur l’ensemble de la chaîne de l’entreprise et entraîne de nombreuses évolutions.

DevOps, avant tout une gestion du changement

Les organisations qui ont mis en place tout ou partie de DevOps ont depuis longtemps identifié et validé qu’une telle démarche garantissait un retour sur investissement.
Par contre, beaucoup d’autres ont abordé et étudié DevOps mais ne l’ont pas encore traduit dans les faits.
La raison principale est que DevOps est avant tout une démarche de gestion du changement.
En effet, DevOps ne se résume pas à choisir la bonne solution d’automatisation. Il est surtout important de se faire accompagner dans cette démarche, et c’est de la responsabilité d’un éditeur. Dans un projet DevOps, les niveaux de maturité et de compréhension sont différents suivant les organisations. Un fournisseur de solutions DevOps a donc un devoir de conseil et d’accompagnement dans la gestion du changement et doit apporter de la valeur. Il doit également prendre en compte l’entreprise dans sa particularité, sa diversité. Dans le cas contraire, un projet DevOps n’a aucune chance d’aboutir.

L’apparition de DevSecOps et BizOps

L’apparition de ces termes est directement liée à la difficulté de la relation entre le développement et l’opérationnel.
A l’époque, le développement s’était organisé avec l’arrivée de méthodes agiles, alors que l’opérationnel représentait un goulot d’étranglement. Pour que le cycle soit fluide, il fallait donc absolument intégrer les opérations.
Une communication s’est alors créée, et une reconnaissance des contraintes entre les différents services a été mise en place. Nous sommes passés dans une posture de dialogue, d’échanges et d’élaboration des processus : reconnaissance du métier de l’autre et intégration des contraintes de chacun pour pouvoir avoir une zone de discussion commune.

L’apparition de nouveaux termes relatifs au DevOps représente simplement une extension de la posture de communication à l’ensemble des services, une progression dans la mutation des entreprises.
Le DevSecOps, par exemple, a pour objectif de renforcer la sécurité en l’intégrant dès le début du processus de développement des applications. D’autres services pourraient d’ailleurs être rajoutés dans la chaîne.
Cela veut surtout dire qu’aujourd’hui les entreprises prennent conscience qu’il y a une nécessité d’avoir une chaîne logistique globale qui, à chaque articulation, intègre la même posture que celle décrite par DevOps.

BizOps est davantage un terme générique. Il s’agit d’une chaîne entre le business et l’opérationnel. C’est une contraction que l’on pourrait finalement appeler « BizDevSecOps ».
Elle implique la direction stratégique à l’opérationnel. Nous devrions d’ailleurs ne plus parler d’Ops aujourd’hui, mais d’utilisateurs (BizUsers).
Nous revenons finalement à de vieilles notions telles que le BtoB ou le BtoC, excepté le fait que l’on intègre aujourd’hui à la connotation de ces termes un changement d’organisation interne, nécessaire à l’entreprise. Cela permet d’obtenir une granularité de travail pour pouvoir se concentrer sur la résolution de problèmes dans un domaine particulier. Il s’agit de définir et d’exécuter toutes les actions requises et les automatiser dans un environnement de livraison continue.
C’est toute la notion de Release Coordination, de la direction stratégique jusqu’à la mise à disposition auprès de l’utilisateur.

Les challenges de l’Enterprise DevOps

La notion d’Enterprise DevOps permet de positionner DevOps comme une stratégie d’entreprise, un processus qui apporte de la plus-value à l’organisation, et pas uniquement dans les services informatiques.
Les enjeux en termes d’identification, de validation de release entre les différents services, d’explication d’un goulot d’étranglement, de temps de décision, de réalisation ou temps de mise à disposition, s’ils sont résolus à l’échelle du DevOps, peuvent être un terrain expérimental. Cette notion d’articulation interservices pourra alors être étendue à l’ensemble de l’entreprise, ce qui permettra de facto d’augmenter le retour sur investissement sur la globalité.
Et c’est là tout le défi de l’Enterprise DevOps : que l’ensemble de l’entreprise prenne conscience de la plus-value apportée par ce changement de collaboration entre services.
Tout ce travail géré à l’échelle microscopique entre Dev et Ops sera alors implémenté à une échelle macroscopique au sein de l’ensemble de la chaîne de l’entreprise (de la décision stratégique à l’utilisateur final).

Les enjeux de DevOps for Database

Même si elle n’est pas nouvelle, la notion de donnée prend aujourd’hui de l’ampleur.
Afin de gagner du temps et d’éviter les développements, la notion de paramétrage de données (quelles qu’elles soient et sans présager de la structure technologique de gestion de données sous-jacentes), a été introduite de façon à modifier le comportement de la solution en fonction des données qui ont été saisies.
Ces données de paramétrage ont donc un impact sur le comportement de la solution. A ce titre-là, ces données appartiennent au domaine du développement et du fonctionnement de l’application.

Généralement, le volume de données restant faible, des processus dégradés sont utilisés pour la mise en production.
Ces processus dégradés ne permettent donc pas d’effectuer des rollbacks, ni par exemple d’identifier le niveau de version du système installé, mais tout cela est considéré comme anecdotique puisque le volume de données reste faible.
Pourtant, la criticité est très importante.
En procédant de cette manière, la chaîne de qualité est rompue, et cela peut mener à un incident de production qui engendrera des pertes financières parfois énormes, mais aussi une perte de confiance dans le processus de déploiement.
Il ne faut donc pas se concentrer uniquement sur la fréquence de déploiement, mais aussi sur la criticité de ce que représentent ces données.
Elles doivent donc suivre la même chaîne de qualité que les applications, ce que promet DevOps for Database.

Conclusion

• DevOps ne se résume pas à l’automatisation des processus, c’est une véritable démarche de gestion du changement
• Les termes DevSecOps et BizOps signifient que les entreprises prennent conscience qu’il y a une nécessité d’avoir une chaîne logistique globale
• L’ensemble de l’entreprise doit prendre conscience de la plus-value apportée par un changement de collaboration entre services
• Les données souvent critiques doivent suivre la même chaîne de qualité que les applications

Marc Dallas

Directeur R&D

Diplômé en Ingénierie Informatique à Integral International Institute, Marc commence sa carrière en 1994 en tant qu’Analyste Programmeur chez Nestle Cereal Partners. Il est ensuite nommé Directeur Produit chez ADSM Software, avant de rejoindre ARCAD Software en 1997.