Projets informatiques et méthodes agiles

A l’occasion d’un projet informatique, on vous a peut-être déjà proposé d’utiliser une « méthode agile ». C’est une méthode de conduite d’un projet informatique selon quelques principes qui visent à lutter contre la lourdeur, le formalisme, et l’opacité de conduites de projets plus classiques. Ces défauts-là démotivent souvent le donneur d’ordres, qui constate des retards sans explications, une dérive des coûts qui semble inéluctable, sans garantie que le résultat final présentera bien toutes les caractéristiques fonctionnelles demandées.
Les méthodes agiles sont donc une tentative de lutter contre ces défauts, en préconisant plusieurs règles simples, mais parfois difficiles à appliquer :
- impliquer au maximum le client (ou le donneur d’ordres en entreprise), faire qu’il soit au contact des équipes de développement,
- livrer fréquemment des versions intermédiaires du logiciel à concevoir,
- privilégier la programmation, éventuellement commentée dans le code, à la rédaction de la documentation technique,
- accepter que les spécifications du logiciel à livrer évoluent pendant sa conception.
Ce ne sont que quelques-unes des valeurs et des règles formalisées dans les différentes méthodes agiles pratiquées en informatique, et dont la méthode Scrum est une des plus en vogue actuellement. En principe, l’emploi de telles méthodes agiles est largement indépendant de choix informatiques techniques concernant le langage de programmation, l’architecture du logiciel, ou la base de données utilisée.

Les partisans de ces méthodes agiles ont raison dans leur critique de méthodes plus classiques, souvent génératrices d’un formalisme et d’une lourdeur administrative étouffants … et très rémunérateurs pour certains intervenants extérieurs. Mais la réussite de ces méthodes agiles a conduit à en multiplier les variantes, à les théoriser, et les formaliser toujours plus. Certaines constituent maintenant un véritable petit univers, avec leurs règles, leur vocabulaire, parfois leurs outils conçus pour accompagner leur mise en œuvre, et donnent lieu à divers ouvrages et publications. Des spécialistes pointus de telle ou telle méthode agile sont souvent mis en avant par des prestataires postulant pour un projet informatique.
Ce professionnalisme et cette spécialisation ne sont pas en soi néfastes. Toutefois, l’idée initiale de ces méthodes agiles est née du constat de la difficulté à faire travailler de concert des informaticiens et des donneurs d’ordre (peu importe le nom qu’on leur donne) :
- les uns sont souvent intellectuellement absorbés par des problèmes dont la nature échappe complètement aux autres,
- les cœurs de métiers des uns et des autres sont très éloignés et les vocabulaires employés ne se recouvrent guère,
- et pour les personnes chargées de coordonner tout cela, une des difficultés est de trouver et de placer au bon endroit les nécessaires interprètes entre ces mondes différents.
Bien évidemment, une conduite de projet réussie est surtout une question d’exécution et de pratique, largement autant que de connaissance et de théorie.

Force est de constater que les partisans des méthodes agiles – et surtout les partisans inconditionnels d’une méthode agile, quelle qu’elle soit, au détriment des autres – peuvent parfois tomber dans le travers d’une approche un peu dogmatique, où votre société est sensée se plier aux conditions de réussite de leur méthode. Or ce n’est pas toujours possible.

Les projets informatiques des sociétés d’assurance, en particulier, présentent généralement quelques spécificités qui, si elles n’interdisent pas a priori l’emploi de ces méthodes agiles, exigent quand même qu’on en tienne compte, et que les personnes chargées de conduire ces projets informatiques aient l’ouverture d’esprit nécessaire pour s’adapter.

Dès qu’une société d’assurance atteint une certaine taille, ses projets informatiques les plus importants atteignent eux-mêmes une taille conséquente, et requièrent la participation de nombreuses personnes, notamment de nombreux informaticiens. La méthode Scrum, par exemple, prévoit que l’équipe projet soit animée par un « ScrumMaster » : c’est un animateur, dont le rôle est de faciliter le travail de l’équipe de développement, et de veiller à ce que la méthode Scrum soit correctement appliquée. Le ScrumMaster n’est donc pas un chef de projet au sens classique du terme, et cette méthode veut que l’équipe de développement s’auto-gère et travaille directement avec le chef du produit, que d’autres méthodes classiques appellent parfois maître d’ouvrage (il est appelé « Product Owner » dans la terminologie de Scrum).
Le problème est qu’une équipe ne peut plus s’auto-gérer quand elle devient trop nombreuse. Et si certains de ses membres n’ont pas l’habitude de travailler ainsi, ce qui est souvent le cas d’informaticiens internes, le besoin d’une hiérarchie plus classique se fait rapidement sentir. Cette nécessité ne condamne pas forcément une méthode agile à ne s’appliquer qu’aux projets de taille réduite, mais elle oblige (elle oblige le ScrumMaster dans le cas de Scrum) à adapter sa méthode pour prendre en compte cette réalité, quitte, sur ce point comme sur d’autres, à ne pas être beaucoup plus performant qu’avec une méthode plus classique : le ScrumMaster devra protéger les principaux avantages de sa méthode, tout en cohabitant avec des personnes dont les rôles, nécessaires, reprennent en partie ceux qu’on rencontre dans des méthodes classiques.

De plus, un projet informatique d’une société d’assurance est souvent un projet de remplacement, partiel ou total, d’un système ou d’un sous-système déjà en place. Ce remplacement peut avoir plusieurs raisons (par exemple techniques, ou économiques), mais le système en place est généralement déjà relativement complet sur le plan fonctionnel. Il a permis jusque là à la société d’assurance de fonctionner et de se développer, ses services se sont organisés parallèlement à l’utilisation de cet outil informatique. Les contrats sont gérés et les diverses obligations réglementaires sont satisfaites. Les commerciaux et peut-être certains partenaires ont des liens informatiques avec ce système. Il est donc hors de question de le remplacer par autre chose qui ne présenterait pas, dès son déploiement, au moins le même niveau fonctionnel.
L’idée préconisée par les méthodes agiles de livrer fréquemment des versions intermédiaires, pour impliquer le donneur d’ordres et le faire réagir sur l’adaptation du logiciel à ses attentes, rencontre ici une limite évidente. On pourra – et on devra bien sûr – tester les versions intermédiaires, mais leur déploiement, sauf exception, est inenvisageable. Le bénéfice attendu sur l’implication et la collaboration du donneur d’ordres en sera diminué. Et ceci relativise l’importance à accorder aux débats un peu illusoires entre les tenants des différentes méthodes agiles, au sujet du rythme de ces livraisons : la méthode Scrum, par exemple, vise un rythme régulier et fréquent (1 mois, parfois moins).

Enfin, dans une société d’assurance, la durée de vie des systèmes informatiques les plus importants se compte en décennies. Dès qu’ils sont opérationnels, ces systèmes entament une longue carrière d’évolutions, d’adaptations, et de transformations plus ou moins importantes. On les connecte à d’autres systèmes reposant parfois sur d’autres technologies, conçus par d’autres équipes informatiques utilisant peut-être d’autres langages. La durée de vie de ces systèmes est parfois plus longue que la carrière professionnelle de leurs concepteurs.
Une documentation technique de ces systèmes est indispensable. Elle devrait même faire l’objet de plusieurs déclinaisons, dont au moins une destinée, dans une société d’assurance, à divers services (actuariat, comptabilité, juridique) qui demandent souvent des évolutions du système informatique. Ces services pourraient ainsi mieux comprendre – sans entrer inutilement dans les détails techniques – les conséquences informatiques de leurs demandes, que ce soit en termes de délais ou de coûts.
La fourniture d’une documentation technique de qualité fait partie du projet informatique d’une société d’assurance, et doit être considérée pratiquement sur le même plan que la réalisation du logiciel lui-même. Les méthodes agiles doivent ici intégrer cette contrainte.

 

En résumé, qu’elles soient agiles ou non, les méthodes de conduite des projets informatiques de votre entreprise doivent évidemment s’adapter à vos spécificités. L’inverse est malheureusement une tentation fréquente chez des spécialistes qui n’ont que leur méthodologie à mettre en avant, et à qui il leur manque l’expérience de situations contrariantes, où leurs théories s’appliquent mal.
Les méthodes agiles mettent utilement en valeur des aspects essentiels de la relation entre le donneur d’ordres et l’équipe réalisant un projet informatique. Mais votre entreprise mène certainement des projets informatiques qui s’inscrivent dans un historique déjà complexe, avec des intervenants d’âge et de cultures informatiques diverses, donc des conditions très différentes de celles, par exemple, de la réalisation ex nihilo d’un logiciel destiné à être vendu. Les responsables à qui vous confierez la conduite de vos projets informatiques devront en être conscients : vous n’attendez pas d’eux une compétition avec, à l’extérieur, d’autres spécialistes de cette même méthode qu’ils appliquent (peu importe laquelle), vous attendez d’eux qu’ils gèrent mieux que d’autres vos projets, avec leurs spécificités et leurs contraintes.