L'agilité peut servir d'excuse à toutes les mauvaises pratiques (mais il ne faut pas)

Le cabinet TNP Consultants a publié une étude sur le sourcing agile et fait réagir des décideurs IT de quatre grandes entreprises sur une table ronde. Pour adopter réellement l'agilité, au delà des déclarations enthousiastes, les entreprises n'échapperont pas à de lourdes remises en causes, notamment dans leur organisation et leurs achats de prestations.
PublicitéAcheteurs et DSI sont-ils satisfaits de leurs prestataires lorsque leurs entreprises opèrent des projets en mode agile ? La réponse est plutôt négative selon une étude menée par le cabinet TNP Consultants. Le nombre de répondants étant très faible (une quarantaine de grands comptes français), il faut plutôt y voir des tendances.
Mais les réactions (et débats) de quatre décideurs IT de très grandes entreprises ont apporté des compléments utiles et des controverses appuyant là où ça fait mal. Il s'agissait de Philippe Paban (DSI, Renault), Eric Chambefort (Responsable des SI Facturation Entreprises/Collectivités, EDF), François Charpe (DSI, Harmonie Mutuelle) et Frédéric Masson (responsable agilité IT, SG-CIB). Ils se sont exprimés à l'occasion de la présentation de l'étude par TNP Consultants, le 8 juin 2016 à l'Hôtel Collectionneur à Paris.
L'agile, c'est peut-être à la mode, c'est peut-être très sympathique, mais il y a un prix à payer, des remises en cause à faire. L'entreprise n'y échappera pas, pour elle-même, pour ses achats de prestations et dans sa relation avec ses prestataires.
L'agilité est un véritable enjeu
Les répondants à l'étude de TNP Consultants sont pour les trois quarts des membres de la DSI et pour un quart des acheteurs. Les trois quarts de l'ensemble considèrent l'agilité comme un enjeu stratégique. Dans près de la moitié des cas, plus de 30% du budget des projets informatiques sont consacrés à des projets agiles dont près de la moitié en régie ou équipes mixtes SSII/interne. Le mode agile est employé dans la moitié des cas pour les projets, dans un quart pour la maintenance applicative et pour l'essentiel du solde dans la production informatique.
Mais la maturité des entreprises n'est jugée satisfaisante que dans un tiers des cas. Les directions métiers sont jugées inadaptées au mode agile dans près de la moitié des entreprises. Pour TNP Consultants, « embarquer les métiers est la prochaine frontière », une étape absolument indispensable. « Comment peut-on faire de l'agile sans embarquer les métiers ? C'est absolument impossible ! C'est l'entreprise qui doit être agile, la production, le développement et les budgets qui doivent l'être ! » a réagi François Charpe. Pour lui, acheter une pizza-team n'a de sens que si un projet est en cours : « nous sommes en mode capacitaire et s'il n'y a pas de demande métier, il n'y a pas d'équipe achetée. » Et si le casting n'est pas bon, un changement doit pouvoir se faire sans drame.
La faute des prestataires
Pourtant, les entreprises jugent que le sujet est bien la contractualisation avec les prestataires. Plus que leur propre remise en question. Sans doute une question de confort. Et, d'ailleurs, le mode de recours aux SSII le plus classique pour des opérations en mode agile est le contrat de régie. C'est souple, avec des engagements de moyens... coûteux et sans engagement de résultats. Les engagements de résultats concernent au mieux la date de fin du projet, l'échéance étant connue assez facilement en multipliant le nombre de sprints par la durée de chaque sprint. Par contre, l'expérience utilisateur est passée aux oubliettes.
Pour TNP Consultants, cet état de fait n'est évidemment pas acceptable. L'évolution naturelle devrait être l'engagement de résultat sur des points de fonction. Cet engagement évite de disposer d'un cahier des charges précis -interdit par le mode agile- tout en fixant clairement les objectifs à atteindre. « Les développeurs sont objectivés chez nous sur la qualité de leur code, les responsables fonctionnels sur leur story-telling : c'est un compromis avec les acheteurs qui a l'avantage d'exister et l'inconvénient de séparer les rôles au sein d'une même pizza-team » a relevé Eric Chambefort.
PublicitéNe pas se laisser enfumer agilement par les fournisseurs
La Société Générale refuse de continuer à former les intervenants de ses fournisseurs à l'agilité. Il est même étonnant qu'elle l'ai fait à un moment donné. Forme-t-on à la plomberie un plombier que l'on fait intervenir chez soi ? « Nous remettons en cause nos fournisseurs par un scoring des compétences fournies aux pizza-teams, une unité d'oeuvre achetée étant une équipe achetée » a expliqué Frédéric Masson. Si l'achat de pizza-teams est plus facile auprès de grands fournisseurs, forcément moins nombreux donc plus faciles à gérer administrativement, les bonnes pizza-teams sont plutôt dans les PME. L'achat de prestation de la Société Générale s'est donc adapté.
Eric Chambefort a complété : « il faut casser le mythe de l'agilité qui serait une grande anarchie ; l'agilité exige des méthodes strictes. S'il y a encore 18 mois l'agilité pouvait être un moyen pour les fournisseurs de se dégager de leurs responsabilités et de leurs engagements, ce n'est plus le cas aujourd'hui où nous avons fait évoluer notre cadre contractuel avec un consensus accepté par tous. »
Transformer l'entreprise avant de s'en remettre aux SSII
Les intervenants étaient d'accord pour dire que l'agilité ne pouvait pas être atteinte sans une vraie transformation de l'entreprise. « L'agilité s'inscrit dans un ensemble qui implique une transformation architecturale, avec le cloud, et des méthodes comme Devops » a insisté Philippe Paban. Chez Renault, la règle est bien d'acheter des pizza-teams complètes avec des obligations de résultat sur des points-fonctions.
Mais l'agilité est-elle compatible avec la virtualisation de la présence ? Chez Harmonie Mutuelle, qui dispose de nombreux sites éclatés issus des 14 mutuelles qui ont fusionné pour lui donner naissance, selon François Charpe, « les équipes travaillent de façon virtuelle avec des salles de vidéoconférence, les réunions physiques étant impossibles ».
Co-localisation : deux écoles face à face
Cette manière de faire choque Frédéric Masson pour qui « une équipe donnée doit être à un endroit donné, sauf éventuellement le product owner. » A la Société Générale, les pizza-teams de Bangalore sont entièrement à Bangalore, seul le product owner étant à Paris. Cela dit, des pizza-teams travaillant sur des pans différents d'un projet peuvent être réparties dans plusieurs lieux pourvu que chaque pizza-team soit, elle, dans un seul lieu.
Cela dit, travailler avec des équipes off-shore n'est pas nécessairement possible en mode agile. Pour Philippe Paban, « les équipes off-shore doivent monter en compétences. »
Article rédigé par

Bertrand Lemaire, Rédacteur en chef de CIO
Commentaire
INFORMATION
Vous devez être connecté à votre compte CIO pour poster un commentaire.
Cliquez ici pour vous connecter
Pas encore inscrit ? s'inscrire