Management

L'agilité à l'échelle implique une nouvelle approche avec les prestataires

---

Le cabinet TNP a réuni quatre managers IT de grandes entreprises le 9 novembre 2017 pour échanger sur l'agilité à l'échelle en pratique.

PublicitéLa démarche agile est loin d'être généralisée en entreprises alors que, pourtant, elle devrait l'irriguer pour lui permettre de s'adapter en permanence à son contexte. Cette contradiction entre théorie et pratique était au coeur d'une matinée organisée par le cabinet de consultants TNP le 9 novembre 2017. Si la thématique était l'agilité à l'échelle, c'est à dire une agilité étendue à tous les métiers et toutes les fonctions, force est de constater que l'agilité tout court reste déjà problématique et est loin d'être généralisée.
En introduction, une enquête sur une quarantaine d'entreprises, un tiers des répondants étant côté DSI, le solde côté acheteurs, a souligné cette contradiction. Ainsi, une minorité de projets est aujourd'hui menée en méthodes agiles, aucun répondant ne réalisant une majorité de ses projets dans ce mode. Les projets agiles sont rarement menés grâce aux centres de service classiques. Le plus souvent, ce sont donc des prestataires dédiés qui sont installés dans les locaux mêmes de l'entreprise. Si l'off-shore agile est déclaré possible par la plupart des répondants, personne ne le pratique. Et, selon TNP, c'est bien le sourcing classique qui serait le principal frein à l'agilité, les acheteurs étant peu formés au sujet.

Le rôle du product owner au coeur de l'agile

Malgré tout, la transformation agile des directions métier semble bien amorcée. Les métiers de « product owner » et de « business analyst » semblent connus et reconnus. Mais ces fonctions sont encore trop souvent confiées à des prestataires malgré un souhait de les internaliser. Il en résulte une difficulté majeure : la démarche des entreprises est de privilégier le forfait sur la régie mais un forfait « projet achevé » est par définition impossible sur de l'agile puisque le projet n'est pas défini au départ. Il reste la possibilité de réaliser du forfait à l'unité d'oeuvre ou du forfait par sprint mais la logique demeure plutôt celle de la régie, même si des « forfaits » sont proclamés.
« Le product owner est celui qui comprend les métiers et l'IT et sait quand trancher » a défini Nicolas Barois, Product Owner distribution des offres, Directeur de projet SI, chez Voyages-SNCF. Le cas échéant, selon lui, il doit savoir quand ne pas trancher et s'en rapporter à une autorité supérieure. Sur ce point, Christophe Lepage, Chief Information Officer chez BNP Asset Management, a été en désaccord : « il faut qu'il ait toujours la possibilité de trancher ». Au groupe Malakoff Médéric, où une refonte globale de SI autour d'un progiciel est en cours, l'agile est surtout utilisé pour les fonctions périphériques, surtout au niveau front-office. Et Alexandre Chauvin, Directeur de l'Usine Front & Digital & Data chez Malakoff Médéric, a confirmé que le Product Owner devait se trouver au sein des métiers, en ayant une capacité de décision, y compris de définition de trajectoire.

PublicitéInterne ou externe, est-ce vraiment important ?

Mais, du coup, est-il vraiment possible de recourir à de la prestation pour tenir ce rôle ? « Dans les pays Anglo-saxons comme en Asie, la distinction interne/externe n'a pas d'importance car le personnel change d'entreprise selon les opportunités, du coup il est préférable d'avoir toute l'équipe sur le même plateau » a relevé Christophe Lepage (Chief Information Officer chez BNP Asset Management). Chez Malakoff Médéric, les prestataires choisis sont au maximum des indépendants mais cela contrarie les démarches d'achat qui visent à limiter le nombre de prestataires et donc à massifier les recours. Ce recours à des indépendants évite une trop forte volatilité tout en gardant la souplesse de l'externe. Le plateau agile de Voyages-SNCF, lui, a été placé à Nantes, ce qui a comme effet de réduire mécaniquement le turn-over, moindre qu'à Paris.
Chez Alstom, l'off-shore agile est l'option choisie. « Mais ce n'est plus l'offshore d'il y a dix ans avec le métier à Paris et une IT taylorisée en Inde : notre scrum-master est en Grande-Bretagne, notre lead architect est un Indien à Paris, nous avons des développeurs en Inde et le product-owner à Paris » a raconté Guillaume Rabier, Design Authority VP chez Alstom. Pour que cela marche, a-t-il cependant averti, il est indispensable de recourir à une très forte industrialisation dès le départ, sans latitude laissée au métier sur les choix technologiques. Malgré tout, le métier doit garder une certaine autonomie, la Design Authority se comportant en distributeur de services self-service, faute de quoi la tentation sera trop grande de contourner les règles posées et de basculer en shadow-IT.

Une contractualisation problématique

« Avec l'agile, beaucoup pensaient pouvoir faire n'importe quoi alors que c'est le contraire : l'agile exige beaucoup de méthodes et de rigueur » a confirmé Christophe Lepage. Une des réunions menées a permis de rassembler toutes les équipes concernées dans une même pièce, avec discussion sur le planning de sprints. Il a raconté : « cette réunion a permis à des équipes différentes de se parler et de prendre conscience des dépendances entre projets ». L'agile ne s'applique cependant pas à l'évolution de projets lourds développés avec cycles en V : « nous n'avons pas vu de résultats vraiment probants dans ce cas » a confirmé Nicolas Barois.
Mais, du coup, comment contractualiser sur un projet où personne ne sait à quoi il aboutira ? Comment jauger le prestataire ? Guillaume Rabier a estimé avoir perdu assez de temps dans des réunions visant à donner des indicateurs de vélocité des prestataires. Il est surtout allergique aux indicateurs-clés qu'il a qualifié de « pastèques » : verts en apparence mais cachant quantité de problèmes. Il reste, comme l'a observé Nicolas Barois, des indicateurs sur les capacités en personnels fournis et, surtout, la mesure de la satisfaction métier. Mais, pour Guillaume Rabier, « les livraisons régulières sont là pour restaurer la confiance entre l'IT et le métier même s'il ne faut pas totalement s'affranchir de la mesure. »

Article rédigé par

Bertrand Lemaire, Rédacteur en chef de CIO

Partager cet article