Nous avons observé un phénomène identique chez plusieurs de nos clients : des Directions Métiers, échaudées par les lourdeurs des processus et de la gouvernance de leurs DSI, se créent leur petite équipe informatique pour gérer des petits projets nécessitant réactivité et agilité. Puis – comme l’informatique reste tout de même un métier – proposent à la DSI de réintégrer cette activité, avec mandat de garder la souplesse et la réactivité.

Le phénomène se comprend : la grande DSI doit gérer des SI complexes et sécurisés, et les grands projets n’échappent généralement pas à des études longues, à des multiples points de validation budgétaires et techniques, et à la mise en ligne de nombreux acteurs pour réussir l’intégration.

Mais au-delà des grands projets classiques, la DSI doit aussi être capable d’avoir une offre vis-à-vis des métiers permettant de fournir des « petits projets rapides » ou jetables. Il faut permettre au métier d’obtenir des victoires rapides pour engranger les gains métiers identifiés au fur et à mesure du processus d’amélioration continue.

Cela prend souvent la forme de petits workflows, de formulaires ou outils intranet, ou encore de petits outils de pilotage permettant de retravailler les données issues du Legacy.

Le développement de ce type de projets implique toutefois certaines conditions pour mettre en place et prendre en charge ces besoins rapides :

  • Une expression de besoin simple. En effet, les besoins ne doivent pas nécessiter une charge forte de construction (rarement plus de 50 jours en général)
  • Une adhérence limitée avec le cœur du SI
  • Une exigence de sécurité moins forte que sur le Legacy
  • Une méthodologie adaptée : un processus itératif entre l’équipe MOA et l’équipe MOE, donc, un représentant du métier suffisamment disponible et une équipe de développement spécialisée sur ce type de méthode et sur les technologies sous-jacentes
  • Un socle technique prêt et maîtrisé impliquant une technologie unique pour répondre aux besoins et des infrastructures dédiées, à la main de l’équipe « développement rapide »
  • Une documentation ajustée au strict nécessaire

Sous ces conditions, la prise en charge de projets rapides ou jetables est possible en limitant les risques inhérents à ce type d’équipes agiles :

  • Risque n°1 : des solutions non maintenables. Il est toujours plus difficile de maintenir une myriade de petites applications qu’un bloc complet. La rapidité n’exclut pas un minimum de méthodologie et de documentation (au moins dans le code), ne serait-ce que pour savoir à quoi sert chaque application et pour pouvoir la faire évoluer le jour où cela devient nécessaire
  • Risque n°2 : une équipe victime de son succès. Enchanté de trouver un canal qui répond vite et bien à ses besoins, le métier peut être tenté de demander à l’équipe agile de répondre à des besoins n’entrant plus dans le cadre ci-dessus. Or ces équipes ne sont généralement pas taillées pour répondre à des gros besoins transverses avec fortes exigences de sécurité
  • Risque n°3 : « l’application-grenouille qui se transforme en bœuf ». Certaines applications, qui devaient être au départ « petites » et « jetables » peuvent devenir – par le jeu d’évolutions et demandes complémentaires – des applications critiques qu’il faut réintégrer dans l’environnement sécurisé de la DSI. Et migrer sur le cœur du système devient alors un nouveau projet en soi…

Christian Semé – Associé d’ISlean Consulting