Comment Axa a imité avec succès le modèle Spotify pour aller vers l' « Agile at Scale »

Une première cellule agile montée à Lille en 2011

En 2011, 4 informaticiens de la DSI de Nanterre sont détachés à Lille afin de créer un Webcenter. L’objectif est alors d'internaliser de jeunes développeurs afin de travailler sur de nouvelles technologies, de nouvelles architectures pour créer de nouvelles applications de FrontOffice uniquement. Octo Technology accompagne alors Axa dans la mise en place des méthodes agiles au sein de cette nouvelle structure. Des Product Owners et des chefs de projet, jusqu'ici basés à Nanterre, sont envoyés à Lille pour intégrer les équipes agiles. A l'époque, Axa fait le choix de Scrum et les équipes sont formées avec les Coach Agile d'Octo Technology. Depuis, ce choix de Scrum a évolué et la méthode Kanban est en train de monter en puissance chez Axa. Mais les premiers résultats positifs ont rapidement été enregistrés sur les développements FrontOffice. « Nous avons amélioré le Time to Market des applications et la satisfaction des métiers » souligne Emilie-Anne Guerch. « C'était très positif, mais nous devions aller plus loin. Les cycles de livraison étaient encore longs avec des livraisons chaque mois et - au-delà du front - comment faire avec tous les stacks techniques d'Axa qui vont du Web Service aux mainframes ? » L'objectif est alors d’élargir l’agile à l’ensemble de la DSI et de créer du lien entre les petites équipes agiles, des « Component Teams » pour mettre en place des « Feature Teams ».

La révolution Agile at Scale est lancée en 2015

Fort de quatre années d'expérience de l'agilité sur des petites équipes « front », Axa décide de changer d'échelle en 2015 et aller vers ce que l'on appelle l' « Agile at Scale ». Axa regarde alors ce que Spotify a mis en place afin de déployer l'agilité à l'échelle. « Nous avons pris de la démarche Spotify ce qui nous intéressait. Je ne suis pas une Ayatollah des frameworks Agile : nous n’en retenons des éléments qu’en fonction de notre contexte. Nous avons pioché dans (Scaled Agile) SAFe du côté de l'architecture mais nous n'avons pas tout retenu. »

L'expérimentation est lancée sur 400 personnes afin de créer non plus seulement des équipes Composants, mais des équipes Produits. Sur le modèle Spotify, AXA crée alors des tribus qui fonctionnent comme de grosses startups. Chacune d’elles se compose de 50 à 120 personnes, et travaille sur un produit bien précis. La souscription IARD (assurance habitation / assurance auto) pour les particuliers est un produit auquel sont affectées 120 personnes qui travaillent de manière stable et pérenne sur ce produit dans la durée. Pour qu'une équipe soit efficace, le nombre optimal est de 7 à 9 personnes. Il faut donc découper les 120 personnes en équipes de 7 à 9 personnes, des Squads.

La Coach Agile ajoute : « Tout l'enjeu du passage à l'échelle est de savoir comment découper ces équipes au sein de l'organisation produit. L'équipe souscription IARD regroupe 120 personnes, avec des Product Owners, des architectes, des experts en cybersécurité, des développeurs front, des développeurs back, des développeurs mainframe, etc. des personnes qui vont travailler sur ce produit pendant plusieurs années ». Cette organisation mise en place à partir de 2015, valide l’efficacité de l’approche si bien que le projet se poursuit avec le découpage des 2000 personnes de la DSI par métier. En 2016 et 2017, vague après vague, la DSI d'Axa déploie de nouvelles tribus pour arriver aujourd'hui à un total de 18 tribus qui travaillent sur de multiples produits de l’assureur dont la santé, l’épargne, la retraite, etc.

Des guildes assurent la cohérence de l’action des tribus

En 2018, les Ops ont été intégrés aux tribus afin que celles-ci deviennent autonomes de bout en bout, depuis l'expression du besoin jusqu'à la mise en production de l'application, une intégration de la production informatique, ce qui n’est pas sans conséquence : « Le danger, c'est de se retrouver avec 18 DSI qui travaillent chacune en mode startup, avec chacune ses choix en termes d'architecture, de sécurité » pointe Emilie-Anne Guerch.

Pour maintenir la cohérence de l'ensemble, sur le modèle Spotify, Axa a mis en place des guildes transverses, des communautés d'experts qui sont garantes des choix d'Axa de manière transversale. Il y a des guides de développeurs, des guildes de testeurs, d'Ops, de sécurité. 11 guildes ont été crées afin de promouvoir les meilleures pratiques chacune dans leur domaine, dans chaque tribu.

L’organisation matricielle mise en œuvre par AXA représente de 50 à 120 personnes par tribu.

Ainsi, la guilde des développeurs cherche à être en pointe sur le Software Craftmanship et forme ses 400 développeurs selon ses priorités. Les budgets sont portés par les tribus et l'ensemble des guildes en prélèvent 10 % pour faire monter en compétence leurs membres, capitaliser de la connaissance, animer la guilde.

Autre changement d’échelle, la DSI d’Axa a instauré plusieurs niveaux de granularité dans ses projets agiles afin de donner une visibilité aux membres des Squads qui dépasse la « user story » sur laquelle ils travaillent. « Il faut être capable d'expliquer aux développeurs ce qu'il y aura derrière le bouton sur lequel ils travaillent et pour cela nous avons mis en place plusieurs niveaux au-dessus de la User Story, avec la Minimum Marketable Feature, qui appartient elle-même à une Epic. Quand on est développeur, on sait à quelle Epic appartient la fonctionnalité sur laquelle on travaille » précise la Coach Agile.

Maintenir la cohérence du SI alors que les développements s'accélèrent, un véritable défi

Fabrice Guéant, responsable
architecture Axa

Autre problématique à traiter, celle de la cohérence d’ensemble du SI. Impossible de laisser les coudées franches aux tribus dans leurs choix d’architectures techniques ou de solutions. « La mission des architectes n'a pas véritablement changé, mais c'est la façon d'opérer leurs missions qui a changé » reconnaît Fabrice Guéant, responsable architecture chez Axa. « Avec le passage à l'agile, on courait le risque de voir les équipes éviter de passer par les architectes. Il y avait aussi un risque d'emballement avec uniquement des décisions courtermistes et enfin un risque de perte de vision transversale. Avant, nous avions 6 DSI métiers et 6 silos, avec 18 tribus, le danger était de créer 18 silos dans cette volonté d'aller vite. »

Ce passage à l’Agile at Scale présentait un risque de segmentation du SI et à terme, de perte d'efficacité, mais il présentait aussi l’avantage pour les architectes d’avoir un retour très rapide sur l’efficacité des architectures qu’ils proposaient aux équipes et ne plus avoir à attendre la toute fin du cycle en V comme c'était habituellement le cas.

La guilde des architectes Axa a revu le rôle des architectes au sein de la DSI. D’une part, celle-ci a mis en place le « Just-in-Time » afin de pouvoir répondre rapidement aux questions posées par les équipes Delivery. Une bibliothèque de standards et de 150 solutions a été mise en place, si bien que lorsqu'un projet démarre et que son « Use Case » est établi, la « Reference Card » correspondante est extraite de cette bibliothèque.

Elle définit comment doit être construite l’application et indique tous les éléments techniques nécessaires à son exploitation. Des indicateurs ont été mis en place afin d’assurer une traçabilité complète des évolutions de l’architecture et la DSI s’est attaché à trouver une voie de sortie à une problématique endémique des SI de tous les acteurs du CAC 40 : le traitement des obsolescences, ce que l’on nomme aussi la dette technique du SI. « Nous avons eu à traiter de gros chantiers liés à la non-prise en compte de cette problématique d'endettement ces dernières années, comme par exemple une grosse migration Windows de nos serveurs, un projet de plusieurs millions d'euros » déplore Fabrice Guéant. « Cette problématique de la dette technique est devenue un enjeu majeur pour le groupe. Le niveau d'endettement de chaque SI est maintenant suivi, ce qui nous donne un levier pour avancer sur cette problématique. »

Des dispositifs pour traiter la problématique de la dette technique

L'architecture, ce n'est pas qu’une affaire d'architectes. Les architectes doivent sortir de leur tour d’ivoire et s’intégrer aux tribus 3 jours par semaine.

Plusieurs mécanismes ont été mis en place afin de ne pas laisser les briques du SI tomber dans l’obsolescence. « A chaque fois que l'on enchaîne les sprints, on est amené régulièrement à faire des choix tactiques. A chaque fois, nous devons rédiger une Technical Story à laquelle il faudra apporter une réponse au sprint suivant, afin de contenir la dette technique », explique Fabrice Guéant.

Autre dispositif en place, à chaque livraison d'un applicatif en production, l'équipe doit tenir compte des montées de version sur l'ensemble des couches sur lesquelles celui-ci repose. « La gouvernance architecture a la capacité de bloquer des projets et les développements sont arrêtés s’il le faut. Cela remonte jusqu'au métier et la levée du NoGo n'est donnée que si un budget est accordé pour effectuer une remédiation à court terme. »

Autre changement majeur dans le travail des architectes du SI, ceux-ci sont plongés au cœur des tribus. Plus question pour eux de rester dans leur tour d’ivoire, ceux-ci passent 3 jours par semaine dans les tribus afin de répondre aux besoins directs des équipes et d’améliorer la communication entre les architectes et les Squads. Enfin, la gouvernance architecture a été élargie à la sécurité, la QOS (qualité de service), l'UX (expérience utilisateur) et les décisions sont validées par cette gouvernance unique.

Le passage à l’Agile at Scale est une véritable transformation culturelle.

Sur ces 2 000 personnes que compte la DSI d’Axa, 400 sont développeurs, un taux plutôt élevé et qui continue de monter : Axa internalise de plus en plus de développeurs et son Webcenter de Lille a vu son effectif grimper leur nombre à 200 au bout de 7 années de fonctionnement. Un moyen de gagner en agilité sur les développements, mais pour Emilie-Anne Guerch, l'agilité, ce n’est pas qu’une histoire de méthodes et de bonnes pratiques : « C'est une véritable transformation culturelle. Chaque collaborateur de la DSI d’Axa doit simplifier la vie de nos clients, chaque développeur doit avoir conscience de cela et ne pas venir le matin uniquement pour appliquer les meilleures pratiques Craftmanship. Nos clients métiers, nos distributeurs, nos agents sont captifs, ils sont obligés d'utiliser nos outils et très longtemps on ne s’est pas posé la question si l’outil confié aux collaborateurs était bon ou pas, était simple à utiliser ou pas. Or c’est important, y compris pour le client final car si l’agent n’a pas une bonne expérience avec son outil, cela rejailli sur le client. La DSI doit être focus sur l’expérience de nos clients, de tous nos clients. »