Publié par

Il y a 5 mois -

Temps de lecture 8 minutes

Une décennie DevOps, quels enseignements tirer ?

DevOps, bientôt 10 ans que ce terme existe. Il apparaît dans toutes les discussions IT mais on ne peut pas cacher que sa définition est floue pour beaucoup. Cet article de blog est l’occasion de partager quelques réflexions sur le mouvement DevOps et sur son acceptation dans les entreprises.

Un mur qui peine à tomber

Le mur de la confusion est la plus célèbre métaphore du mouvement DevOps. Il faut déconstruire le mur qui sépare les devs (qui veulent du changement) et les ops qui sont garants de la stabilité). Après des années à vivre en silo avec des objectifs non alignés, nous sommes forcés de constater que la déconstruction du mur prend du temps même si tout le monde en est conscient. L’arrivée des solutions de cloud public a fait bouger les lignes : les dev pensent pouvoir se passer des ops, ce qui est faux dans la plupart des cas car ils sont souvent loin des réalités de la production. Les ops doivent réagir à cette offre publique en proposant une alternative interne : pour faire simple, supprimer les tickets et proposer des services à la demande par API ou portail. La peur des start-ups qui uberisent de nombreux marchés a poussé les entreprises historiques à se challenger. Malgré une résistance forte, la culture des entreprises évolue et les organisations entreprennent de déconstruire le mur. D’un coté en alignant les dev sur les réalités de la production avec la fusion du support et de l’intégration dans les feature teams. De l’autre en alignant les ops sur les enjeux métiers : ce qui passe par l’arrivée d’un product owner infra qui se rapproche des dev. Cet alignement devient nécessaire avec l’évolution des métier des ops qui sont de plus en plus développeurs.

a crack in the wall by Tai, flickr

DevOps n’est pas un concept IT

C’est sans doute son problème le plus important, le mouvement DevOps n’est pas aidé par son nom. L’agilité est un terme général adapté à des méthodes de développement logiciel technique. Dans le cas de DevOps, le choix fut inverse : un terme empreint de jargon pour désigner un modèle d’organisation de l’entreprise… 10 ans plus tard, nous sommes forcés de reconnaître que le terme n’aide pas. L’entreprise ne l’assume pas et le business y voit une solution quand les initiateurs du mouvement y voyaient une nouvelle culture avec une façon de s’organiser et un nouveau management.

Une obédience technique qui complique l’appropriation

Le terme DevOps fait peur, les métiers et les managers réagissent de deux manières quand ils l’emploient : soit ils le minimisent, soit ils le considèrent comme un mouvement pour les dev et les ops. Certes le mouvement DevOps est à l’origine initié par des personnes comme Patrick Debois qui sont issues des infrastructures mais ils avaient conscience de l’importance de l’agilité et de l’alignement de l’entreprise. Le mouvement DevOps propose une façon d’organiser et de manager l’entreprise dans son ensemble. Nombre d’entreprises ont du mal aujourd’hui à se retrouver derrière cet étendard par méconnaissance. Des méthodes comme le lean startup qui partagent des valeurs communes (à commencer par la culture de la mesure) ont aujourd’hui un écho plus important coté métier et il semble que le nom et l’origine en soient en partie la cause.

Des raccourcis pris par les technophiles

Automatiser n’est pas DevOps. On ne peut que constater dans les DSI que l’amalgame persiste. Certes il existe deux types d’automatisation indissociables de DevOps : le pipeline CI/CD qui va permettre de mettre en production rapidement de manière sécurisée. Et le provisionning des infras qui permet de construire rapidement des environnements reproductibles et maîtrisés. Sans ces deux automatisations, il n’y a pas de développements agiles mais un bon niveau d’automatisation n’implique absolument pas d’être DevOps. L’obnubilation pour l’automatisation peut vite faire oublier les principes de DevOps : la collaboration, l’importance de mesurer les actions, le lean et bien sûr l’amélioration continue. On parle souvent du modèle CALMS qui se veut une alternative a ITSM dans le monde ITIL.

Le marketing des éditeurs est un miroir aux alouettes

DevOps est un buzzword et l’homme aime ce qui est magique. Il est tentant de croire qu’un logiciel va nous rendre DevOps. C’est globalement le travers des organisations quant à l’outillage. Acheter un outil semble souvent la solution. Quand bien même l’outil est de qualité, on oublie de s’assurer que les collaborateurs l’utilisent correctement, formation et accompagnement sont souvent bâclés. Derrière chaque outil étiqueté DevOps il y a des concepts implémentés mais on ne peut décemment croire qu’un outil pourra tous les abstraire. Le développement est un métier complexe, le mouvement DevOps fait travailler avant tout l’état d’esprit des équipes. On n’installe pas un état d’esprit.

DevOps est l’organisation moderne pour une entreprise

Si vous n’en êtes pas convaincus, il reste un argument massue : même SAFe en parle ! On peut être DevOps sans être SAFe mais l’inverse n’est pas envisageable. A l’instar des frameworks d’agilité à l’échelle, DevOps propose une organisation et une culture adaptées aux enjeux de l’entreprise d’aujourd’hui : centrées sur l’utilisateur du produit, permettant d’expérimenter rapidement et de pivoter si besoin. Le monde dans lequel nous vivons est complexe, il est impossible de créer le produit parfait au bon prix et dans les temps pour de nombreuses raisons. Il faut donc repenser l’entreprise pour qu’elle devienne anti-fragile, par opposition à fragile. Comme le dit Nassim Nicholas Taleb dans son livre : « L’anti-fragilité est une propriété des systèmes qui se renforcent lorsqu’ils sont exposés à des facteurs de stress, des chocs, de la volatilité, du bruit, des erreurs, des fautes, des attaques ou des échecs. » Les entreprises doivent s’organiser pour tendre vers cet idéal.

Faire le deuil de la cohérence logique.

La cohérence logique est ce qui nous pousse à ranger les choses dans des boites. Il y a une indéniable logique à mettre tous les développeurs front ensemble, tous les DBA ensemble, etc. Ce modèle a certains avantages : économie d’échelle, contrat de type centre de service, gestion de la compétence. C’est inévitable, ce mode d’organisation en silo oblige à dépenser une énergie folle en coordination et en stratégie pour satisfaire des objectifs orthogonaux. Localement, on a l’impression de faire des économies mais dans la réalité, la gestion d’un SI est trop complexe pour que ce fonctionnement en silo soit efficient et surtout rapide. L’organisation en feature team, mais plus généralement en équipe pluridisciplinaire, est aujourd’hui la seule qui semble permettre un time to market concurrentiel pour beaucoup de produits.

Transformation DevOps en cours…

Alors où en est on dix ans après ? Bonne nouvelle, la transformation sera longue mais il est indéniable que du chemin a été parcouru ! Les organisations en feature teams sont à la mode et le recul du cycle en V est visible. Il est aujourd’hui aisé pour un développeur de travailler de manière agile. Si ça n’est pas votre cas, sachez que le marché est de plus en plus mature et qu’il est possible de travailler autrement et ce partout en France. Dans les grandes entreprises leaders, les silos les plus proches fusionnent : testeurs, intégrateurs, supports rejoignent de plus en plus les équipes de développement. De même pour les MOA qui, il y a 10 ans, étaient dans le bâtiment d’à coté et qui maintenant sont membres de l’équipe. Côté ops, les métiers les plus bas niveaux comme l’infrastructure en entier ou le réseau ne sont pas dans les feature teams et n’ont pas obligatoirement vocation a y être (cf où s’arrête la responsabilité d’une feature team ?) mais le changement a commencé et ce retard sera vite comblé pour deux raisons : les solutions infrastructure-as-code arrivent à maturité grâce à des leaders comme les GAFA et autres Netflix et grâce à la maturité de l’accompagnement agile. En effet, les méthodes se précisent, s’adaptent et les profils agiles (coachs, scrum masters, product owners) sont de plus en plus nombreux. Nous sommes de plus en plus nombreux à avoir 10 ou 15 ans d’expérience dans le développement agile. Les ops utilisent ce savoir et ces compétences pour rattraper le retard à grand pas !

Publié par

Publié par Clément Rochas

Coach agile, formateur DevOps, speaker. Clément est passionné par le développement et la création logicielle en général. Retrouvez Clément sur twitter sur @crochas

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.