Méthodes agiles : y a-t-il un pilote dans le métier ?

[SERIE What’s Next CIO IT-Métier] Appliquées aux projets, les méthodes agiles ont permis de casser les silos entre disciplines et d’obtenir des résultats beaucoup plus rapidement. Reste que, réservée aux seules équipes IT, elles ne permettent pas de résoudre les problématiques complexes d’usage. Une suite logique voudrait donc que le product owner viennent du métier. Ça se discute.

>> Un article What’s Next, CIO ? L’observatoire des tendances stratégiques et opérationnelles des DSI

“Pour savoir où nous en sommes en termes de méthodes agiles, il faut d’abord se souvenir de ce que nous cherchions au départ, à savoir délivrer vite et bien”, rappelle François Raynaud, DSIN de la direction commerce d’EDF SA. Pour l’énergéticien, comme pour beaucoup d’entreprises concernées par l’adoption de la méthode, le mot d’ordre a donc été de changer le fusil d’épaule, de s’organiser et de faire ainsi en sorte que des évolutions aboutissent en moins de trois mois voire trois jours pour les plus simples. “Pour y parvenir, nous avons étudié plusieurs pistes. Et, face à nos ERP, nous avons dû modulariser les fonctionnalités, intégrer des API, déployer des micro-services., etc. En résumé, faire quelque chose de moderne en tenant compte des problématiques cyber et de de conformité by-design. Cela d’autant qu’avec des architectures réparties, on commence à penser cloud et data centric, donc à des évolutions d’architectures profondes”, ajoute François Raynaud. Un troisième défi, fut de faire en sorte que la DSI devienne une activité métier parmi d’autres au service des autres en étant force de proposition. “Il fallait stopper la dissociation métier SI/MOA/MOE. Parce qu’on voit bien, qu’à défaut, à la moindre difficulté la question de la responsabilité est rapidement mise en jeu”, précise le DSI. 

Pas de product owner métier, pas de projet ?

Mais l’IT n’a pas forcément les moyens de se rendre compte de l’impact business des petits incidents. Il est en effet difficile, voire impossible, de traiter tous les irritants au fil de l’eau. “On ne fait pas de l’agile pour faire de l’agile. Cela permet, avant tout,  de réussir à se parler et à faire une vraie recherche d’impact sur ce qui est utile pour les usagers”, confirme Hélène Brisset, directrice du numérique au sein d’Île-de-France Mobilités. Pour certains DSI le product owner (PO), qui désigne le chef de produit digital dans les méthodes agiles, devrait provenir du métier et être inclus dans une équipe multi-compétences avec de la cyber, des développeurs, des UX, etc. “Cela permet une vraie compréhension des recettes et du mode de fonctionnement de ce type d’organisation. Sur l’ensemble des fonctions”, assure Christophe Huerre, DSI Groupe de Thales. Derrière, cela se traduit par une communauté de travail avec des utilisateurs métier désormais impliqués qui parlent le même langage que l’IT. Tout le monde se réunit et apporte sa compétence pour aboutir en périmètre/qualité/délai. C’est une co-construction, un collectif au service d’un objectif.

“Chez Thales nous respectons une règle fondamentale qui consiste à dire que le product owner doit systématiquement venir du métier dès lors que nous avons affaire à un projet complexe, confie, assure Christophe Huerre. Et donc pas de producteur owner métier, pas de projet ! Récemment, nous avons développé un CRM, typiquement le genre de projet où l’on peut facilement dépenser beaucoup pour finalement ne rien produire. Ici, le PO venait d’une division marketing défense et, clairement, c’est à 50% grâce à cela que nous avons réussi à produire un système fonctionnel, en mesure de gérer des informations confidentielles et sans casser la tirelire.” François Raynaud, lui, préfère conserver les product owners à son bord : “Notre expérience nous conduit à positionner les product managers côté métier bien sûr, mais les PO côté DSIN car ils doivent avoir une double compétence métier/SI, qui est plus fréquente côté SI que métiers.” Pour lui, cette double compétence permet de sécuriser les questions à se poser afin de ne rien oublier et de savoir comment les retranscrire dans le séquencement des travaux.

Chez EDF, de l’agile, oui, mais à l’échelle

Si, au sein de la direction commerce d’EDF, le nombre d’évolutions délivrées chaque année a été multiplié par 10, il a d’abord fallu passer par une phase d’acculturation des collaborateurs. “Ça ne se décrète pas ! C’est une question de temps, assure François Raynaud. Il a fallu l’instaurer en plusieurs années mais, aujourd’hui, c’est redoutablement efficace car tout le monde est aligné.” Les équipes de François Raynaud se sont appuyées sur le framework SAFe – Scaled Agile FrameWork, sorte de fusée à trois étages favorisant un alignement stratégique à travers un portfolio et des actions prioritaires appelées epics. “Premier niveau, on sait à quel pan de la stratégie va correspondre une action, quel est son périmètre et quelles sont ses perspectives de gains et de performances. Deuxième niveau entre les directions des opérations métier et la DSI, vient la planification. Ce qu’on appelle la value stream, enfin, au 3eme niveau, la réalisation est confiée à des trains d’équipes agiles. Aujourd’hui, nous prolongeons la dynamique sur le run, pour faire en sorte que les équipes suivent la qualité de fonctionnement technique et fonctionnelle et se mettent en situation d’améliorer le fonctionnement par elles-mêmes.”, détaille François Raynaud. Pour lui, il s’agit également de faire en sorte de couvrir les processus de bout en bout, pas uniquement des morceaux de processus, en veillant à ce que les données circulent de manière fluide et efficace tout au long des étapes. 

Une question d’inspiration, surtout et avant tout

Pour Mickaël Réault, CEO fondateur de Sindup, éditeur d’une plateforme de veille stratégique, la place du pilote n’est pas gravée dans le marbre. Selon lui, il n’y aurait pas de schéma d’organisation idéal, mais plutôt un prérequis essentiel à savoir la vision du produit. Chez Sindup, l’affection du rôle de PO se fait d’une part en fonction du produit mais également selon la personne la plus à même de piloter ou copiloter le projet jusqu’à son terme. Le product owner pourra donc être ainsi au sein de l’équipe R&D, du service clients ou du service marketing.

Et, quelle que soit la configuration, les compétences de chacun seront toujours mobilisées à des degrés différents selon la technicité du projet à réaliser. “Que le product owner soit à l’IT ou au sein de la direction métier importe moins que sa capacité à penser le produit en se projetant véritablement dans son usage. Si ce profil est identifié, il faut miser sur lui ! Il s’agira ensuite de l’aider à s’entourer des compétences nécessaires pour prendre en compte tous les enjeux, notamment techniques. Imaginer un produit ou une fonctionnalité est plus une question d’inspiration et d’envie de le voir exister pour s’en servir qu’une histoire de compétences particulières. En effet les compétences peuvent soit s’acquérir, soit se réunir. En revanche l’inspiration, elle, on l’a ou on ne l’a pas !”