Editions ENI Livres | Vidéos | e-Formations
Le modèle organisationnel du DevOps
Quels enjeux liés à l’organisation ?
1. La compréhension de l’organisation IT par les métiers
Le modèle organisationnel traditionnel d’un service informatique est structuré autour de silos renfermant les compétences techniques. D’un point de vue extérieur, cette vision est relativement hermétique. Pour qu’un représentant du métier puisse comprendre à qui il doit parler afin de résoudre ses problèmes et/ou lui apporter des solutions, il doit comprendre ce que sont les rôles techniques qui régissent un service informatique.
Comme le montre le schéma ci-dessous, représentant l’organisation de notre exemple Cotradis, un projet réalisé pour le compte d’un métier est géré par des équipes dans chacun des silos techniques de la DSI. Cela impose de mettre en place des rôles transversaux chargés d’actionner les équipes dans les silos et d’assurer la coordination entre eux. Ce rôle de coordination est généralement dévolu à un chef de projet piloté par le métier ou la maîtrise d’ouvrage. Ce chef de projet est en lien avec d’autres chefs de projet nommés dans chacun des silos afin de prendre en charge le projet dans sa globalité. Cette couche de coordination décuple les coûts et nécessite de nombreuses instances de synchronisation.
Cette organisation amène à une certaine complexité et concourt en partie à donner une image brouillonne, voire inefficace, du service informatique. Le responsable métier se pose alors des questions sur la façon d’utiliser le service informatique :
-
En cas d’incident, quel chef de projet prend en charge la résolution...
L’organisation DevOps
L’organisation DevOps, tout comme l’organisation Lean, n’est pas une recette toute faite. Elle ne s’assimile ni à un framework ni à une méthodologie. Le DevOps, c’est d’abord une culture intégrant des principes et des pratiques qui guident les équipes IT dans la façon dont elles font les choses. Il y a plusieurs façons d’aborder le DevOps dans sa composante organisationnelle.
1. Un problème d’échelle
a. La petite échelle
Le passage au DevOps à l’échelle de l’équipe est relativement naturel. D’abord parce que dans une entreprise de petite taille ou de taille intermédiaire, que ce soit au sein d’un éditeur de logiciel ou d’un département informatique, les rôles ne sont pas toujours très découpés et l’on favorise la polyvalence des compétences. Une même personne pourra être le développeur principal d’une application et celui qui s’occupe de son déploiement et de sa maintenance. Ainsi, les personnes trouveront naturel d’automatiser le maximum de tâches afin de faciliter leur quotidien.
Ensuite, parce que les silos sont en général moins marqués que dans une grande entreprise, les réseaux relationnels couvrent rapidement l’ensemble de la structure et la hiérarchie est moins étendue. En général, les décideurs sont accessibles rapidement. L’autonomisation des équipes et la confiance qu’elle suppose sont donc avant tout liées à l’état d’esprit et à la qualité des relations interpersonnelles entre les dirigeants et les équipes opérationnelles.
Mais il y a malgré tout quelques écueils dans ce type de structure :...
Les limites du système
Jill E. Perry-Smith a publié une étude dans la MIT Sloan management review (https://sloanreview.mit.edu/article/how-collaboration-needs-change-from-mind-to-marketplace/) qui met en exergue que les besoins relationnels ne sont pas les mêmes tout au long du parcours d’émergence d’un nouveau produit, de l’idéation, jusqu’à la réalisation.
Elle met notamment en avant les phases suivantes :
Comme le montre Jill E. Perry-Smith, le processus d’innovation nécessite un réseau de liens personnels relativement superficiels le plus large possible. Maintenir des liens lointains aide à nous confronter à des idées différentes, alors qu’à l’inverse, notre réseau le plus proche et le plus fort a tendance à renforcer nos idées et nos points de vue acquis. Recevoir des perspectives qui sortent de notre cadre habituel nous donne plus de chances d’aboutir à une idée innovante.
À l’inverse, lorsqu’arrive la phase de réalisation, il est important de trouver des équipes qui se connaissent bien, et qui vont pouvoir très rapidement converger vers une solution et la soumettre à l’épreuve du client. Cette proximité et la confiance qui en résulte aidera l’équipe à adapter le produit en prenant en compte la façon dont le client se l’approprie. La fiabilité des liens sociaux aide alors à renforcer la pertinence du produit et son adaptation aux besoins du client.
Le DevOps n’organise que la dernière étape ! La proximité importante qu’il contribue à entretenir dans les équipes, ainsi que la construction d’un réseau relationnel fort dans un périmètre relativement proche et cohérent...
