[EXCLUSIF] C’est un phénomène social assez classique que de voir de l’engouement pour le changement, sauf lorsqu’il faut en supporter les conséquences… Le DevOps ne fait évidemment pas exception. Cela implique alors une gestion particulièrement soignée de ce projet fortement structurel : Information et collatéralité en force. Si les entreprises même les plus importantes veulent aujourd’hui opérer des mutations pour davantage d’agilité et de réactivité par rapport à leurs métiers, elles doivent y mettre les moyens humains, techniques et financiers sans oublier une bonne dose d’audace, au risque – à terme – de perdre complètement la maîtrise de leur IT.
Omer Shala, fondateur et PDG du groupe Newlode
Le DevOps, où en est-on ?
Le devOps, c’est la réunion à priori de deux inconciliables : les exploitants (« ops ») chargés de la stabilité et de la qualité du système d’Information, au détriment il est vrai des coûts et des délais ; et, les développeurs (« dev ») pris dans la course au développement d’applications attendus par les métiers, toujours plus vite et à moindre coûts. Les exploitants jugent donc sévèrement les changements non contrôlés et imposés par les développeurs qui passent outre les bonnes pratiques de gestion des SI. Et c’est bien ce que la nouvelle méthode de travail DevOps souhaite enrayer.
La solution ? Mettre tous ces acteurs au diapason sur l’équation « Qualité / Délais / Coûts » et la généralisation de méthodes agiles, reposant essentiellement sur la réactivité, des cycles de décisions très courts, et en « marquant à la culotte » les besoins des métiers, en somme d’avancer très conjointement avec eux.
La transversalité n’est pas la tasse de thé de l’entreprise en France et pourtant selon une étude récente de IDC, l’adoption du DevOps a progressé dans le pays des entreprises silotées. Près d’une entreprise de plus de 1000 salariés sur 2 s’intéresse au DevOps ; 17% sont en phase de réflexion pour lancer une initiative DevOps, 29% des entreprises sondées l’ont déjà adoptée, mais seules 19% pour toutes leurs applications.
Si l’adoption du DevOps innervée à l’organisation n’est pas plus franche que ça, c’est que le modèle traditionnel des grandes entreprises a du mal à évoluer. Il semble que ce soit insurmontable de rompre avec une vision en silos, de demander aux cadres et employés de collaborer sur des projets entre divisions différentes. Plus récentes, plus souples, les startup l’ont intégré pour beaucoup dès le début de leur aventure. Ce que personne n’a vraiment anticipé c’est que le numérique allait mettre à mal toutes les règles de ces organisations très compartimentées, très hiérarchisées.
De la même façon que le Taylorisme et le Fordisme ont révolutionné l’industrie au début du XXème siècle, le DevOps est un nouveau modèle d’organisation de l’entreprise, reposant sur la collaboration technique comme organisationnelle. Mais c’est d’abord et avant tout une philosophie que doit inspirer la Direction.
Comment prend t-elle forme ? Comme vu plus haut, une initiative Devops peut débuter par la création d’un groupe de travail composé de différentes entités (équipe développement, équipe réseau, équipe projet, équipe sécurité, etc.) pour collaborer sur un projet de développement « one shot ». De façon plus aboutie et donc systématique, le DevOps a pour vocation de favoriser la collaboration et le partage d’informations dans l’entreprise dans toutes ces constituantes, mais aussi entre entreprises y compris concurrentes, dans un esprit de coopétition. Ainsi, en partageant davantage et mieux leurs données, les entreprises enrichissent mutuellement leurs solutions (applications, logiciels, etc.) et accélèrent ainsi leur développement et leur business.
Le DevOps c’est un moyen de rendre les entreprises plus agiles et de reprendre la main sur leur IT en le ré-internalisant. En effet, les métiers ne prennent plus le temps d’attendre et ont un recours de plus en plus effronté au Cloud. Quand en interne il faut 6 mois pour héberger des applications, dans les nuages c’est 15 minutes…
Concrètement, il faut maintenant constituer de petites équipes, pouvant être montées rapidement pour un projet, puis dissoutes, puis remontées différemment quelques semaines ou quelques mois plus tard. Les entreprises ont besoin de visualiser le résultat vite, et plus sur des plans d’actions de 18 mois de réunionnite aigue.
Les différents corps de métier IT doivent désormais travailler ensemble. Les métiers ont besoin d’une approche de bout en bout, et plus des projets où le réseau passe le relais à la sécurité, qui passe le relais au système, qui passe le relais aux développeurs, etc. Désormais, tout le monde doit échanger.
Mais la stratégie DevOps c’est aussi un déploiement d’applications plus rapide, et parfois au détriment de la sauvegarde, de l’automatisation, de la sécurité. Il va falloir industrialiser pas mal de choses avec DevOps et capitaliser bien plus qu’aujourd’hui sur des retours d’expérience pour la DSI (qu’est ce qui a été fait ? Qu’est-ce qui doit être réutilisé ? Quelles erreurs sont à ne pas commettre à nouveau ? Qui a besoin de formations ? etc.). Les entreprises ne peuvent faire l’impasse d’investissements sur des outils communs collaboratifs.
Mais, agir ainsi, c’est s’exposer aux foudres du management en place. Comment détricoter les organisations en place, dire aux managers que leurs équipes pourront être utilisées par d’autres équipes, que ce qu’ils avaient passé du temps à protéger va finalement leur échapper ? Il s’agit maintenant de revoir de fond en comble la notion de rapport hiérarchique pour le faire coller au devops, de redéfinir la place de l’IT dans l’entreprise et surtout d’impliquer dans cette démarche les Ressources Humaines, qui pourraient devenir les chefs d’orchestre inattendus du Devops.
Les Ressources Humaines à impliquer
Il ne s’agit en effet pas de rater le virage… comme avec le Cloud. Lorsqu’il a commencé à percer, l’IT ne voulait pas y aller, par peur du changement, de perdre leur place. Certains DSI y étaient publiquement réfractaires… On connaît le résultat : l’installation de l’anarchie numérique dans les entreprises où chacun fait ce qu’il veut.
C’est un peu la même chose avec les Ressources Humaines aujourd’hui. Les RH telles qu’organisées aujourd’hui ont beaucoup de mal à suivre les tendances, ne sont pas en position de comprendre les bénéfices du DevOps, les interactions possibles, et surtout quand ça dépasse leur champ « territorial » d’intervention dans l’entreprise.
Victimes elles aussi de l’effet silo, elles ne sont donc pas en mesure d’adapter les recrutements et les ressources humaines en interne (formations, etc.) Mais in fine, le business a toujours le dernier mot. Si les RH ne s’approprient pas très vite le sujet, leur isolement dans l’entreprise comme celui de l’IT n’est pas exclure.
Mais d’égale distance entre l’IT et les métiers, les RH pourraient être de bons chefs d’orchestre à condition qu’il y ait une impulsion pour qu’elles comprennent mieux les métiers de l’IT. Et là est le challenge. On parle d’équipes ultra sophistiquées, avec une somme de talents à aligner, et pour lesquels il faut un objectif de réussite basé sur le succès technique… Les RH ont donc tout intérêt à travailler et mieux s’intégrer au niveau du middle management, et ce de façon plus régulière pour avoir un rôle à jouer.
Les équipes RH vont probablement avoir besoin d’aide sur le sujet, soit en recrutant, soit en s’appuyant sur des ressources externes. Mais cette transformation est en tout cas demandée par de nombreuses sociétés, même certains grands groupes difficiles à transformer, qui savent que la survie de leur IT interne passe par là.
Si l’on se réfère à l’enquête IDC, La grande majorité – 65% – des organisations convaincues se félicitent de l’amélioration du time to market, tandis que 58% constatent une amélioration de la qualité des applications ainsi développées. Enfin, 41% de ces entreprises vantent l’augmentation de la fréquence de déploiement.
Cela prête à réfléchir, non ?
A lire aussi sur Alliancy :