Comment s’approprier ce nouvel espace qu’est le Cloud, et comment l’exploiter pour répondre aux attentes de la transformation digitale ? Si parmi les facteurs clé de la réussite on trouvera évidemment le savoir-faire et la compétence technique, ce qui fait le succès de la transformation, c’est l’humain. Faire évoluer le savoir-être est parfois long, et les challenges ne sont pas toujours là où ils sont attendus. Cet article propose un retour d’expérience concret après une année au sein d’une équipe Ops.

Une entité pour porter la transformation digitale

Renault a fait le choix d’une entité digitale transverse, Renault Digital, pour incuber de nouveaux projets et porter la transformation digitale sur 4 axes :

• L’agilité
• Le design thinking
• Les nouvelles stacks techniques
• La Data

Parmi les projets incubés par Renault Digital, on trouve par exemple une application destinée aux usines, qui remonte en temps réel des informations liées à la chaîne de production ; ou encore une application de communication pour les concessionnaires. Pour concevoir ces nouvelles applications, la collaboration entre Renault Digital et le métier se déroule en trois phases : une phase de définition du produit (et de la valeur attendue), une phase de développement, en mode agile avec sprints de 2 semaines, durant lesquelles les informations sont remontées au product owner, et enfin une phase de transfert du projet à une nouvelle équipe.

Le Cloud AWS comme terrain de jeu

Dans ce cadre, le Cloud AWS a été choisi pour son offre de services sécurisés, résilients et scalables, et pour accélérer le rythme de l’innovation en facilitant les POC et la mise à disposition d’environnements pour l’ensemble des applications. Si l’appropriation technologique par les équipes a été rapide, mon véritable challenge a été d‘accompagner la transformation humaine et organisationnelle permettant de bénéficier vraiment des avantages du Cloud.

Pour cette entité nouvellement créée, le Cloud est un nouvel espace, et il faut trouver comment se l’approprier et l’exploiter pour répondre aux attentes de transformation. Quels sont les facteurs clé de la réussite de la transformation digitale ? La compétence technique est évidemment un atout, le savoir-faire se transfère facilement, mais faire évoluer le savoir-être est plus long. Or, ce qui fait la réussite d’une transformation, c’est surtout l’humain, pas seulement la technologie !

Le DevOps à l’épreuve du quotidien

A mon arrivée chez Renault Digital, j’ai constaté que chacun était concentré sur son périmètre. Les développeurs pensaient à leur langage, les architectes à leurs technologies, et les Ops à leurs outils. Et même dans l’équipe Ops, chacun s’était approprié une activité en fonction de ses compétences : il fallait livrer au plus vite les premiers environnements applicatifs sur le cloud, avec un pipeline d’intégration et déploiement continu (CI/CD), ce qui laissait peu de temps au transfert de connaissances et l’émergence de nouvelles idées.

Pourtant, une personne dans l’équipe avait une vision plus transverse, de par ses multiples interactions avec les développeurs et les architectes : c’était la personne en charge du support des environnements applicatifs. En effet, aussi mal aimée que soit la fonction du support, c’est celle qui permet d’avoir la vision la plus large, et de faire un état des lieux des besoins actuels et futurs.

Après quelques jours passés au support, j’en suis venue au constat que les équipes projet ne savaient pas comment nos process fonctionnent, ou comment utiliser les outils au mieux. En effet, nos process et nos services n’étaient pas formalisés – l’une des équipes projet a même passé ses deux premiers sprints de développement a essayer de comprendre ce qui avait été livré ! Nous avons alors eu l’idée de présenter les environnements AWS, le pipeline de CI/CD et les outils fournis avant même le début des développements, avant même la livraison des outils. C’était la première fois qu’un on-boarding des développeurs était proposé.

Pour continuer dans cette logique, nous avons aussi mis en place un workshop pour les équipes projet désirant customiser leur pipeline : l’idée est de proposer une revue des environnements, des pipelines, de voir ensemble ce qu’ils veulent personnaliser, et de les accompagner pour aller plus loin que le service basique fourni par l’équipe Ops. Et toujours dans l’idée de rendre les équipes projets plus autonomes, nous avons aussi impliqué les coach agiles et les scrum master dans la démarche. Je me suis rendue compte que certains développeurs n’avaient pas l’habitude de communiquer avec une équipe ops, et se faisaient accompagner par les coach agiles pour poser leurs questions ! C’est ainsi que l’équipe Ops a pu faire la connaissance d’équipes projets qui travaillaient pourtant dans le même couloir.

A partir de ce moment-là, les développeurs sont devenus plus autonomes – ils se sentaient plus à l’aise avec leur pipeline et les outils fournis par l’équipe Ops, que tous voyaient désormais comme l’équipe DevOps.

Une nouvelle organisation pour passer à l’échelle

La multiplication du nombre de projets nous a obligés à revoir notre organisation pour gérer la résilience des compétences. Notre idée était de faire en sorte que n’importe qui dans l’équipe puisse fournir le même service, et pour parvenir à ce résultat nous avons commencé par mettre en place des méthodes de collaboration au niveau du code : revues de code, pair programming…

Comme nous faisions de l’infrastructure as code, nous avions un outil de gestion du code : le même que celui que nous fournissons aux développeurs. Mais utiliser cet outil a demandé à l’équipe Ops de s’adapter : faire du code commun pour des ops, c’est assez nouveau. Les ops sont étrangers aux concepts de revue de code, de merge request. Dans notre équipe par exemple, un ops n’a pas compris que son code ne soit pas accepté parce qu’il ne respectait pas les bonnes pratiques. D’où l’importance de se mettre d’accord sur ces règles, sur la manière de travailler ensemble. C’est ce qui a ensuite permis de créer de la confiance, et de libérer la prise de décision, ce qui est essentiel quand l’équipe grandit.

Outre le code en commun, nous avons aussi mis en place des daily meeting et des rétrospectives. Au départ, il y a eu des réticences face au daily meeting, puis chacun se rend compte que grâce au daily meeting, on ne reste plus bloqué sur un sujet, on peut se faire aider. C’est à ce moment que l’équipe ops a pu commencer à travailler ensemble en tant qu’équipe soudée. C’était un pré-requis pour l’étape suivante, devenir user centric.

Le support, cette fonction mal aimée

Nous avions un service qui était fonctionnel, automatisé, industrialisé, mais les demandes de support étaient toujours nombreuses. D’où l’idée de partager le rôle du support sur toute l’équipe, pour alléger la charge, mais aussi pour donner à chacun une vision de ce qui se passe sur le terrain, et d’avoir une visibilité complète sur notre service. Nous avons donc mis en place un support tournant, avec deux personnes en charge chaque semaine. Le problème, c’est que le support, ça ne fait pas rêver les ops. Pourtant, le support fait partie du métier. La qualité du support influe directement sur la perception qu’ont les équipes projets du travail fait par les ops.

Nous avons commencé à recevoir du feedback concret à la machine à café. Bien que les voyants du monitoring étaient au vert, ce feedback remontait tout de même des éléments que nous n’avions pas identifiés – évolutions des besoins, des pratiques…

Mais comment intégrer ce feedback au quotidien ? Nous avons mis en place un formulaire de feedback pour faire évaluer la qualité de nos différents services, complété collectivement lors d’une session d’échange. Si nous avons reçu beaucoup de suggestions d’amélioration, nous avons aussi pu nous rendre compte que notre service de pipeline était très bien perçu. Cela a donné de la confiance à l’équipe, et a facilité la transition vers une activité de support mieux définie au sein de l’équipe.

Les conditions d’une bonne collaboration Dev et Ops

Les ops ont adopté les codes des développeurs, utilisé les mêmes services qu’eux, et Dev et Ops ont mis en commun leurs objectifs : toutes les conditions de la collaboration étaient réunies. Nous pouvions alors proposer une offre de services construite ensemble par des équipes qui n’avaient pas toujours les mêmes objectifs, mais qui travaillaient ensemble pour répondre au besoin des projets.

Ce que j’ai retenu de cette année d’expérience, c’est que si la technique peut s’acquérir facilement, créer une équipe devops qui fonctionne demande du savoir-être, pour mieux travailler ensemble. Et quand on a un collectif qui fonctionne, il faut parvenir à le maintenir, et s’assurer que tout ce qui est mis en place pour faciliter la vie des équipes favorise le collectif.