Les bénéfices d’une organisation agile dans le domaine des infras IT en Datacenter

En 2019, la Direction des Infrastructures (actuelle Direction Plateformes Cloud) d’Orange France, anticipant les limites de son organisation industrielle pour déployer des solutions technologiques « en rupture », se lance dans l’expérimentation de l’agilité. Une approche apprenante et adaptée au domaine des infrastructures IT en datacenter, un accompagnement attentif des équipes, la forte mobilisation des managers et le soin porté à l’interfonctionnement entre périmètre ciblé et équipes de l’organisation « historique » ont conditionné le succès de cette transformation.

Quel est le contexte de l’activité et ses enjeux ? Comment était-elle organisée ?

A l'origine, nous étions organisés en usine à production de façon à adresser de gros volumes de demandes clients.

Que ce soit pour les métiers du stockage, des serveurs ou du réseau, les équipes d'ingénierie étaient séparées des équipes de déploiement, elles-mêmes distinctes des équipes d'exploitation, une même équipe adressant un unique domaine métier (exemple : l'équipe déploiement pour le stockage/sauvegarde). L'organisation était donc très silotée avec un RACI précis entre les différentes équipes. Ce mode de fonctionnement processé et industrialisé était très efficace pour répondre à des demandes « standard » mais moins adapté à du "sur mesure" ou encore aux nouvelles solutions technologiques nécessitant de mixer les expertises métiers (exemple : stockage/sauvegarde et serveur). De plus, les demandes "standard" étaient de plus en plus adressées au travers de la solution Cloud Privé d’Orange France, les équipes en place traitant des demandes de plus en plus complexes.

Par ailleurs, les équipes se sentaient cantonnées au périmètre de leur mission sans possibilité d'intervenir sur des actions connexes qui auraient eu du sens en termes d'optimisation et qui étaient à leur portée en termes de compétences.

Comment en êtes-vous venus à l’agilité ?

Nous avions l'intuition que les approches agiles, par ailleurs largement déployées chez nos clients côté plateformes de services et applications, pouvaient apporter des bénéfices à notre domaine des infrastructures IT en datacenter, notamment en termes d’efficacité opérationnelle. Des retours d'expérience externes au Groupe Orange (Ubisoft notamment) ayant mis en œuvre l'agilité sur un domaine similaire sont venus renforcer notre conviction.

Le choix a été fait de s'inspirer de l'agilité pour rassembler les expertises métiers et pour rapprocher ingénierie (think), déploiement et exploitation dans des « teams ». Ce, avec une « raison d'être » commune de mieux servir le client à partir d'une compréhension partagée de ses besoins et enjeux.

Cette mise en œuvre s'est opérée en premier lieu sur le périmètre de nouvelles solutions technologiques en construction dans le domaine du stockage/sauvegarde (exemples : la team Back-up as a Service (BaaS) et la team File Service Stockage (FSS)).

Quels sont les premiers chantiers entrepris pour initier la transformation agile ?

Le principe retenu était que les nouvelles équipes agiles (teams) étaient constituées en mixant les métiers think, build et run sur le périmètre de solutions d’infrastructures émergeantes.

La participation des collaborateurs des équipes de l’organisation « historique » s'est réalisée sur une base de volontariat. Ce principe nous a paru important pour nous assurer de leur adhésion sur le fait de travailler autrement et également parce que l'intégration aux « teams » supposait un « one roof » de deux jours par semaine en physique pour bâtir le collectif (et donc des déplacements lorsque le one roof n'était pas sur son site).

Beaucoup de sens a été donné auprès des équipes sur l'intérêt d'aller sur ce type de fonctionnement en équipe intégrée pour aborder les nouvelles technologies virtualisées et l’évolution des métiers associée avec l’introduction du devops, des chaines CI/CD et de l’automatisation.

Des communications ont été organisées pour sensibiliser le management à l'agilité et au mode de fonctionnement de la « team » pour qu'ils puissent accompagner au mieux les collaborateurs embarqués.

Nous avons démarré par une acculturation à l'agilité sur 2 jours pour tous les candidats puis les teams rattachées à des trains agiles ont suivi des formations Safe. Un coach a également accompagné le lancement des teams sur la première année (notamment sur les aspects staffing et mise en place des rituels). 

Comment êtes-vous passés en vitesse de croisière ?

Les collaborateurs embarqués avaient un temps sanctuarisé pour la « team » (à hauteur de 70%).

Une attention particulière a été portée sur la conservation du lien et sur la communication avec leur équipe de rattachement initiale (exemple : partage en réunion d'équipe des actualités de la « team » par le contributeur concerné).

Les managers se sont mobilisés pour donner l’exemple en se formant à l’agilité et également en introduisant des pratiques agiles dans leur animation (exemple : rétrospective sur la réunion d'équipe pour coconstruire un format et un contenu correspondant aux attentes de tous).

Côté production, une synchronisation a été organisée entre les products managers des "teams" et les managers du périmètre historique. En effet, une mise en production d’une nouvelle solution technologique par une « team » pouvait avoir un impact à la baisse des demandes clients vers les anciennes technos.

Les premières « teams » ont mis environ 6 mois à atteindre un rythme de croisière, en fonction notamment du délai de staffing.

Peux-tu nous décrire les difficultés rencontrées ? Et comment elles ont été surmontées ?

Des difficultés se sont présentées pour participer aux formations et à l'acculturation. Il a fallu prioriser et dédier du temps pour ce faire. Les deux jours par semaine de déplacement pour participer au "one roof" ont pu être également un frein pour certains.

La distribution initiale des rôles au sein de la « team » (notamment la préemption de postes techlead et PO par des profils chefs de projets ou architectes côté build) a posé des problèmes en passant un message antagoniste. D'un côté, chaque participant était invité à mettre son expertise au service de la « team » sur tous types de contributions. D'un autre côté, certains rôles étaient fléchés vers un certain type de profil. Ce problème a été adressé en permettant un casting plus large au démarrage des « teams ». Certains profils côté run ou déploiement se sont ainsi révélés dans leur nouveau rôle de scrum master ou de PO. Cela a même permis à certains de redynamiser leur parcours professionnel.

D’autre part, il est apparu rapidement que les PO et les scrum master jouaient un rôle clé pour assurer la cohésion de la « team » et que leur casting était donc critique.

Côté management, une difficulté s'est présentée pour les exercices d'évaluation de fin d'année. Comment évaluer la participation à la « team », quels objectifs individuels fixer ? Comment s'assurer que cette évaluation soit juste en regard de celle des autres collaborateurs ne participant pas aux « teams » ? Ces questions ont été résolues en mettant en place une synchronisation entre le manager et le PO de la « team ».

Quels ont été les apports, les enseignements ?

L'organisation en « teams » a fait ses preuves pour construire des solutions technologiques en rupture en développant la performance opérationnelle et l'épanouissement des collaborateurs embarqués.

La démarche a également démontré qu'il était important de sélectionner les projets positionnés sur l'agilité. Certains projets comme la gestion de l'obsolescence ne sont pas adaptés car l'agilité ne leur apporte aucune valeur ajoutée. Il a été également constaté que lorsque la solution passait dans la phase "cycle de vie", il était plus efficace et économique de confier celui-ci aux équipes d’exploitation (contrairement à l'intention première de confier l’ensemble du cycle de vie à la « team »).

Au-delà des gains cités pour la création de nouvelles solutions en termes d'efficacité et de bénéfices pour les contributeurs, l'évolution des mindsets par capillarité sur les périmètres « historiques » a constitué un apport majeur de la démarche. La mise en place de l'agilité a amené une évolution globale et notamment une meilleure flexibilité et une optimisation de l’ensemble de l'organisation « historique » au service de ses enjeux clients.

En 2021, la réorganisation de l’ensemble de la Direction en lignes de produits think-build-run s’est largement appuyée sur les enseignements de cette expérimentation de l’agilité.

Ecrit par Anne Boutroux, Responsable du Département Architecture Réseau et Sécurité, Sofrecom