Fnac : le Devops ne se limite pas à des outils

Mise à jour le 16/11 à 11h20

L'intérêt des entreprises pour le développement agile vise souvent à diminuer la durée de mise sur le marché des nouvelles versions (Time-to-market) et à en faire progresser la qualité. « Mais le Graal, c'est la tranquillité : être en mesure d'assurer que la sortie des nouvelles versions sera un non-événement », résume Serge Esposito, le DSI client (soit la partie e-commerce et magasins) de la Fnac. Et c'est plus facile à dire qu'à faire, comme l'a détaillé le DSI lors d'une session de la Xebicon, la conférence organisée par la société de services Xebia, notamment spécialisée sur le Devops.

L'exercice est tout sauf une sinécure en particulier quand il s'agit de s'attaquer à une application très étendue fonctionnellement et basée sur de multiples couches, développées au fil du temps. « Fnac.com est une solution maison qui, au fil du temps, est devenu une plateforme omnicanal également utilisée en magasins. C'est tout simplement l'application de vente principale du groupe », résume Serge Esposito. Bâtie sur un socle .Net, cette application comporte de multiples couches (back-office, middle-office et front-office), avec des dépendances importantes de l'une à l'autre.

Une centaine de projets par an

La solution est, qui plus est, déployée à l'international et accessible sur tous types de terminaux. Et gère des volumétries considérables : 470 millions de visiteurs uniques par an, un catalogue de 10 millions de produits et des pics atteignant 100 000 commandes par jour. Pourtant, pas question pour le distributeur français de se laisser gagner par l'immobilisme, surtout face à un concurrent comme Amazon. « Cela nous oblige à rester dynamique. En moyenne, une centaine de projets sont lancés chaque année autour de cette application, avec des volumes très variables. Cela peut aller de 15 à 2 000 jours homme », détaille le DSI.

Pour conserver sa flexibilité y compris sur une application massive comme Fnac.com, la direction informatique a commencé par outiller ses processus, selon quatre axes : industrialisation des développements (avec Visual Studio Team Foundation Server de Microsoft), automatisation des déploiements (CA Release Automation), industrialisation des tests (Ranorex) et gestion des versions (AppDynamics). « Avec ce dernier outil, on obtient par exemple une vision de l'impact d'une nouvelle version sans passer par un cycle de qualification lourd en amont, explique Serge Esposito. On se sert par exemple de cette solution pour mener des tests de charge. » Le procédé est assez simple : la Fnac déploie en production la nouvelle version sur un serveur parmi les 18 hébergeant l'application et obtient ainsi très rapidement de premiers indicateurs sur la tenue en charge de la mouture. De son côté, Release Automation de CA permet aux équipes de développement de soumettre leurs demandes de déploiement et tester leurs livraisons sur un environnement masqué des utilisateurs, au sein de la ferme de serveurs. « Nous sommes désormais en mesure de mettre en production en une heure, souligne le DSI. Avec, à la clef, des économies sur l'exploitation (un service externalisé, NDLR) ». Aujourd'hui, Fnac.com est ainsi mis en production chaque jour (mais pour seulement 5 ou 6 évolutions majeures par an). 26 000 mises en production ont été effectuées avec Release Automation depuis 2013 sur l'ensemble du patrimoine informatique de la Fnac.

« Le code reflète l'organisation »

Oui, mais bon. « Le travail sur ces 4 axes est essentiel, mais pas suffisant, résume Serge Esposito. Mais, sur une grosse Bertha comme l'application Fnac.com, nous ne parvenions pas à atteindre notre objectif de mises à jour réalisées sans douleur ». Voici environ un an, la DSI se lance dans une réflexion complémentaire appuyée par le cabinet de conseil Cellenza (spécialisé en technologies Microsoft) et par Xebia. A la clef, deux constats. D'abord, même outillé, le processus en place reste freiné par de multiples points de rupture. « Nous avions besoin d'un pipeline de fourniture des nouvelles versions », résume le DSI. Second constat, probablement plus fondamental : le caractère très sédimentaire de l'application, également handicapée par des défauts d'harmonisation entre ses composants, freine les développements. « C'est ce qu'on appelle la loi de Conway : le code de vos applications est une copie de votre organisation hiérarchique », dit Clément Rochas, de Xebia.

De gauche à droite : Serge Esposito et Clément Rochas.

« En réalité, on utilisait les artefacts de l'agilité sans résoudre le problème de départ, assure Serge Esposito. Il nous fallait étendre le domaine de la lutte. Car notre façon de travailler, en logique projet, comporte intrinsèquement un risque d'ajout de couches sédimentaires ». Sur une application qui souffre déjà de ce défaut. Plus qu'un outillage (même si le plan d'action de Cellenza et Xebia vise aussi à le rationaliser), c'est une révolution culturelle que doit mener le Fnac, une entreprise « qui raisonne en termes de projet », dit le DSI.

L'arrivée des feature teams

Ce dernier s'est lancé dans des actions pilote pour convaincre l'entreprise des bienfaits d'une logique réellement Devops, démarche qui vise à rapprocher développeurs, équipes métiers et exploitants informatiques dans des équipes orientées vers des 'produits', et non plus des projets. Plusieurs 'feature teams' - ces équipes pluridisciplinaires portant la logique Devops - sont en cours d'implémentation, sur la navigation article, le tunnel de vente ou encore le compte client. « Ce n'est forcément évident pour deux raisons. D'abord, l'application est multi-terminaux et multi-pays, ce qui rend les livrables assez volumineux. Ensuite, découper des modules indépendants ou relativement indépendants demeure difficile ; ils partagent au moins une couche de données », détaille Serge Esposito.

En parallèle, le DSI s'est lancé dans ce qu'il qualifie d'actions de fonds « afin d'améliorer la confiance dans les livrables ». La Fnac en travaille ainsi sur la qualité du code, sur l'intégration des tests fonctionnels lors des phases de développement ou encore sur la généralisation de la fonction d'activation et de désactivation des évolutions lors des passages en production. Pour ne plus trembler lors des mises en production.

A lire aussi :

Tests applicatifs : les approches DevOps et agiles gagnent du terrain

Les 3 grandes étapes de la mise en place du DevOps

Devops : les DSI français se voient trop beaux

Photo credit: julien via Visualhunt / CC BY-NC-SA