Alors qu’approche l’édition 2015 du Lean IT Summit, conférence consacrée cette année au Lean comme stratégie de la transformation digitale, nous avons eu l’occasion de discuter avec Frédéric Charles.
Frédéric est en charge de la stratégie et de la gouvernance SI chez Suez environnement. Acteur de la transformation numérique dans un un grand groupe, Frédéric est aussi à travers son blog (Green SI) et sa présence sur les réseaux sociaux une des figures influentes majeures du monde des DSIs hexagonales.
Frédéric évoque ici un projet au coeur de la stratégie digitale du groupe, projet pour lequel, avec son équipe, il a fait les choix stratégiques de l’agilité et du lean pour le mener à bien. Dans un billet précédent ce blog présentait l’exécution comme vecteur de stratégie digitale : Frédéric en apporte ici un témoignage éloquent. (disclosure : j’ai accompagné Frédéric sur ce projet).
Bonjour Frédéric. Merci de nous consacrer du temps pour échanger autour de ton intervention. Peux-tu présenter le contexte du projet que tu vas présenter au Lean IT Summit ?
En septembre 2014, la branche Eau France de SUEZ environnement a lancé un projet majeur de refonte de son extranet vers les collectivités locales. Après quelque mois d’études de notre existant qui datait de 2007 (une éternité à l’échelle de l’Internet…) et après avoir validé la lettre de mission avec la DG, nous avons lancé un projet ambitieux en terre inconnue. Ce projet visait a mettre en place une plateforme de collaboration sur internet, selon les standards de 2014: plateforme dans le Cloud, construite “mobile first”, avec une architecture “data driven”.
Pourquoi avoir choisi une approche lean et agile pour ce projet stratégique ?
Un des grands intégrateurs de la place avait étudié le projet fin 2013 et nous avait proposé un forfait astronomique. Ce qui avait conduit à la décision de reprendre ce projet en pilotage direct en interne.
Il y avait trois façons d’interpréter cette évaluation :
- la démarche traditionnelle (cycle en V) n’était pas adaptée, car générant de l’inflation en sur-qualité et en sur-communication, pour palier au découpage et silos de ce type de démarches
- le projet était risqué, donc le coefficient multiplicateur du chiffrage était élevé
- la plateforme technologique était nouvelle pour cet intégrateur (open source, API, data management, cloud…) donc il n’avait pas de références fiables pour son chiffrage.
Dans tous les cas on arrivait à la même conclusion: changer l’approche.
L’agile s’est imposé pour répondre à la gestion du risque et à la limite des démarches traditionnelles, notamment sur l’expression de besoin. On ne pouvait imaginer faire le tour de France des collectivités pour valider une expression de besoins. Il fallait être plus agile et imaginer une implication permanente des utilisateurs des collectivités, les “vrais” utilisateurs du système, compatible avec les délais du projet (16 mois, une première version en 3 mois).
Le lean est arrivé dans nos choix pour répondre à la nouveauté technologique qui voulait dire transformation de la DSI. Car peu d’applications dans les DSIs sont aujourd’hui gérés dans le Cloud, fonctionne avec des APIs et sur tous les terminaux mobiles. Mais qui dit changement dit forcément apprentissage, donc l’amélioration continue était un gage d’apprentissage rapide.
Finalement tous les membres de l’équipe, pourtant pas nécessairement enthousiastes au départ, reconnaissent aujourd’hui que c’était la meilleure décision que nous avons ayons prise.
Dans quelle mesure ces approches lean et agile correspondaient à ta vision sur ce projet ?
Comme j’avais pu le traiter dans un billet en 2013, (http://greensi.blogspot.fr/2013/05/votre-dsi-est-elle-prete-pour-le-zero.html), le Lean IT amène une démarche structurée et une philosophie nouvelle pour aborder la transformation progressive et continue de la DSI.
Ces approches lean et agile correspondaient donc à la recherche d’une triple transformation:
- de notre plateforme actuelle en impliquant les utilisateurs en collectivités locales et en étant sûr que nous ne réalisions que des fonctions demandées (afin de maîtriser le budget, divisé par 3 par rapport à l’évaluation initiale)
- de notre équipe, en construisant dès le départ le mode “récurrent” d’évolution permanente des services. Cela veut dire que plus que réaliser un projet, nous affinions notre mode de fonctionnement permanent pour aborder les évolutions et la maintenance.
- de la DSI, pour fabriquer des “assets” et une démarche généralisable sur d’autres projets, notamment la plateforme internet vers les clients consommateurs (https://www.lyonnaise-des-eaux.fr) qui, depuis, a rejoint le Cloud privé et bénéficie de ce retour d’expérience pour “s’agiliser“.
Quelles étaient tes attentes principales avec cette mise en oeuvre du Lean ?
Réussir le projet ! Le lean était au service du projet et non l’inverse.
Et comme nous continuons un an plus tard a fonctionner dans cette démarche, c’est la preuve que nous en tirons un bénéfice, sinon on laisserait tomber.
Cela peut paraître surprenant, mais je connais beaucoup de projets ou de DSIs, où on fait de la qualité parce que c’est obligatoire, et non parce qu’on en tire un bénéfice. Je ne voulais pas “faire du lean pour faire du lean”. D’ailleurs on a parlé d’agilité entre nous; le mot lean n’etait pas utilisé, même si on était dans une démarche lean dès le départ.
Quelles ont été les plus grandes difficultés que tu as rencontrées dans cette mise en oeuvre ?
La rigidité de l’intégrateur avec qui nous avons travaillé au départ. Malgré un contexte contractuel qui lui était plutôt favorable avec du personnel en régie sans engagement, ni de forfait.
Le lean demande de se remettre en cause chaque semaine et de trouver des pistes d’améliorations. Aux premiers temps du projet, le fait de remonter des problèmes et axes d’amélioration dans les équipes de l’intégrateur ne provoquaient que des réactions pour expliquer pourquoi ce n’était pas de sa faute mais celle de l’hébergeur, du brokeur, de la conception … Cela plutôt que voir comment faire pour ne plus reproduire ces erreurs.
Le comble de ce phénomène a été atteint quand, après 3 mois de fonctionnement, il a mandaté un “expert agile” intervenant sur un autre de ses projets, pour nous expliquer en 20 slides pourquoi nous ne savons pas travailler avec lui, sans imaginer revoir ses méthodes…
Aujourd’hui on sait que le problème était qu’il voulait encadrer hiérarchiquement ses développeurs : leurs interactions avec son client SUEZ environnement étaient alors filtrées par un niveau intermédiaire inutile.
Les DSI sous-traitent beaucoup en général pour répondre à des fluctuations des besoins en compétences et à une obsolescence rapide des technologies. Les fournisseurs de la DSI doivent monter à bord de l’agilité, sinon, soit la DSI ne réussira pas à se transformer et aborder le numérique… soit ces fournisseurs seront progressivement écartés.
Les autres difficultés concernent le suivi des budgets du projet dans une démarche par définition peu planifiée à l’avance et où les contrats et les engagements figés sont autant de barrières à l’amélioration continue. A moins de mettre de la souplesse d’amélioration dans ces contrats.
Dans quelle mesure le lean a-t-il permis d’avoir l‘approche centrée sur l’architecture que tu vas présenter ?
Les architectures internet se complexifient avec la séparation des couches et l’augmentation du nombre d’acteurs, par rapport à une informatique interne qui fait tout. Ainsi nous avons mis en place une plateforme hébergée sur un cloud privé sous Openstack chez un opérateur, mais exploité via un autre opérateur (broker) et ses outils d’automatisation, avec de multiples composants techniques (API, ldap, database,…) interconnectés à notre réseau.
Les objectifs de livraison continue et d’une première livraison le plus vite possible, ont cassé l’effet tunnel que l’on constate souvent dans les grands projets. En tout cas cela a mis la pression sur l’équipe impliquée dans l’architecture et l’exploitation, chez tous les acteurs, pour délivrer une plateforme automatisée rapidement. Dans un projet classique le système n’est mis en production que vers la fin, alors que nous voulions une mise en production le plus vite possible.
Les mises en production étant automatisées (lancement d’une seule commande pour déplacer le logiciel d’un environnement à un autre – dev, intégration, pré-prod, prod), cela oblige a tout maitriser dès le départ.
Le lean a permis a chacun de comprendre et de s’approprier le sujet technique du cloud de la plateforme lors des Obeyas hebdomadaires, et de le mettre en visibilité pour son pilotage. Il a fallu 3 mois pour monter cette plateforme Cloud hybride avec toutes ses couches de services (en parallèle des développements). Un délais plus long que prévu mais qui a permis au projet de montrer les premières fonctions en production dans un délais rarement vu sur des projets précédents. Ce qui a donné une plus grande visibilité au projet avant même qu’il ne soit terminé.
Aujourd’hui la mise en production hebdomadaire est un élément de satisfaction important pour les développeurs, qui voient le fruit de leur travail exposé au client après validation. La collaboration des développeurs avec les opérations (exploitation) est essentielle, c’est toute la philosophie de DevOps, qui emprunte beaucoup au lean.
Bien sûr, c’est aussi une source d’agilité pour SUEZ environnement pour la prise en compte de nouveaux besoins de collectivités locales.
Le lean place le client au centre des préoccupations de chacun. Comment l’as-tu intégré dans le processus de réalisation de ce projet
Nous n’avons pas intégré le client autant que nous l’avons voulu au départ.
Mais son implication a été déterminante, notamment lors des activités de design. Tous les écrans ont été travaillés collaborativement avec les experts métiers de SUEZ environnement pour produire des maquettes revues et validées par les clients. D’ailleurs dans le produit final, certains écrans sont ceux produits par nos clients et non ceux proposés au départ.
Puis, lors du déploiement des services, le retour des clients permet de mieux gérer nos priorités qui ont changé plusieurs fois dans le projet. En ce moment je commence le tour de grands clients pour avoir un retour plus complet et écouter sans détour leurs critiques et aussi (heureusement) leurs satisfactions.
En complément de ces échanges, nous avons aussi “simulé le client” en mettant en place une plateforme de supervision pour apprécier la performance de l’extranet depuis plusieurs terminaux. Des clients fictifs sur le cloud se connecte donc régulièrement a l’extranet et jouent des scénarios. Cette supervision nous alimente sur la disponibilité réelle des services, en complément de la disponibilité perçue, et oriente les développeurs sur les zones où l’amélioration des performances est à envisager. Parfois suite à une dégradation provoquée par une nouvelle livraison plus riche que la précédente, c’est donc un outil que l’on pense important pour maîtriser la non régression dans le temps.
Tu avances dans le résumé de ton intervention que les spécifications traditionnelles d’application ne sont plus nécessaires en 2015. Comment l’expliques-tu ?
En ce qui concerne la spécification du produit on a commencé “à l’ancienne” en compilant les 60 pages de besoins arrivées de toutes les directions et de l’existant qu’il fallait conserver. Mais là on a stoppé la modélisation objets et les 3 mois de spécifications minimum qu’on aurait engagé dans un projet classique.
Une première passe agile a été réalisée avec un séminaire réunissant tous les acteurs, Product Owner, fonctionnels, ergonomes web, architecte, support utilisateur… pour structurer ces besoins en 6 pages A0 avec des post-it pour chaque macro-fonction. Cela nous a surtout permis d’élaborer collaborativement un plan de référence permettant de réaliser un premier “lot 0” avant la fin de l’année. Ce furent nos deux premiers affichages dans l’Obeya pour matérialiser notre produit.
A partir de là, la problématique devenait de spécifier juste les users stories nécessaires deux semaines à l’avance. Mais la difficulté rencontrée fut que les développeurs ne comprennent pas nécessairement les users stories rédigées. Beaucoup d’erreurs étaient liées a de mauvaises interprétation des spécifications, alors qu’un temps important était passé pour tout détailler dans les documents… mais avec l’oeil d’un concepteur, pas celui d’un développeur. On a donc supprimé le concepteur.
Et progressivement on a constaté qu’il était plus efficace de spécifier les fonctionnalités directement avec les développeurs au moment où ils travaillent dessus. Aussi certainement parce qu’on a travaillé en amont sur l’architecture d’ensemble et le maquettage, et que nous assurions le rôle de product owner.
L’outil de conception est donc devenu Trello, qui gère des listes des tâches collaboratives, et non plus Word. Le livrable s’est fondu dans le processus. Et une société de service intégrant l’agile et le lean dans son fonctionnement nous a rejoint pour piloter les développements.
A la question, qu’est-ce qui fait référence sans spécifications, ne soyons pas naïfs, même dans un projet traditionnel la réponse c’est: le code et les écrans. Combien d’applications ne sont plus à jour en terme de documents de spécifications et continuent à fonctionner et à être maintenues ? idem pour les bases de données réelles dont les schémas ne sont plus ceux des spécifications depuis longtemps.
D’où mon interrogation sur la nécessité de réaliser encore des spécifications “documents”, quand on ne gère pas des “centrales nucléaires” qui vivent plus de 40 ans. Pourquoi ne pas intégrer les spécifications et leur amélioration directement dans le processus collaboratif. Il y a encore du travail mais la direction me semble bonne et je ne serai pas surpris que pour une catégorie de projets (hors “centrales nucléaires”) que les spécifications disparaissent totalement sans provoquer plus d’émoi que ça.
Quels sont les enseignement principaux que tu retires de ce projet ?
Sans aucun doute, il faut beaucoup plus impliquer les développeurs et organiser le travail autour du développement. Une évidence dans un monde numérique où in fine, du panier client à l’expérience utilisateur, en passant par l’algorithme unique, tout est du code. Mais c’est quelque chose que la DSI avait oublié avec les vagues successives de sous-traitance et d’externalisation. Les développeurs ont quitté la DSI : il faut les y ramener.
Pour quelles raisons,selon le toi, le lean et l’agile sont-ils nécessaires dans un projet numérique ?
C’est vrai que le contexte “numérique” du projet, une plateforme internet de collaboration avec les collectivités locales, se prêtait très bien au lean et à l’agile.
Je pense que c’est nécessaire pour ce type de projets car on fabrique des plateformes évolutives et non des logiciels figés. Une plateforme est complexe et se construit petit à petit, délivrant des services dès les départ, puis de plus en plus de services. C’est tout l’enjeu de l’économie numérique de pouvoir fonctionner à cout marginal zéro, donc une fois le socle posé de rajouter rapidement et à faible coût de nouveaux services.
Une dernière question liée à la conférence : quelles sont les interventions que tu verras en priorité ?
J’attends avec impatience le retour d’expérience d’Yves Caseau chez AXA où il est à la tête du Digital. Yves a été DSI chez Bouygues Telecom, il maîtrise l’architecture des SI et l’entreprise numérique. C’est certainement un de mes mentors les plus inspirant.
Merci Frédéric. Nous avons tous hâte d’assister à ton intervention au prochain Lean IT Summit …
Voir l’interview vidéo que nous a accordée Frédéric.
#hypertextual 