Il faut sauver le soldat SI legacy !

Pourtant, il ne faut pas oublier les avantages qu’il peut avoir et qui méritent de le sauver. Je vous explique pourquoi.

Retour sur le SI legacy

L'informatique n'est pas née d'hier. Pour de nombreuses entreprises, il existe un ensemble d'applications spécifiques qui ont été développées. Parfois, elles datent de la création même de l'entreprise. Ces applications ont évolué pour s'adapter aux nouveaux besoins tout au long de la vie de l'entreprise. Elles constituent donc un vrai patrimoine adapté à l'organisation. Au fil du temps, ces applications sont souvent devenues complexes et lourdes à faire évoluer. Leur coût de maintenance augmente au point de devenir prohibitif par rapport au gain escompté.

Il est alors tentant de vouloir changer tout le système, de le refondre, ou de le migrer vers un nouveau système réputé mieux conçu et donc forcément moins cher à maintenir. Ces vieilles applications représentent pourtant une valeur pour l'entreprise à ne pas sous-estimer. Souvent, leurs règles de gestion ont été oubliées avec le temps ou ont été mal documentées. Migrer vers un nouveau système expose ainsi à un risque de nombreuses régressions, à des surcoûts et des retards, et des insatisfactions pour les utilisateurs.

Une question de méthode

Dans le même temps, il faut bien faire évoluer le SI afin de continuer à l'adapter aux nouveaux besoins, à rechercher ces fameuses innovations gages de survie par rapport à une concurrence de plus en plus exacerbée. Comment faire en sorte que l'innovation disruptive recherchée par toute entreprise ne s'accompagne pas de destruction de valeur pour celle-ci, en l'occurrence l'abandon du patrimoine que constitue son SI legacy en le migrant ? En fait, la lourdeur de la maintenance de ces vieilles applications est souvent liée à la méthode qui a été employée pour les créer.

Des cycles en V classiques avec cahiers des charges très touffus et monolithiques, maîtrises d'ouvrage constituées et régaliennes, délais incompressibles pour les recettes et mises en production... C'est souvent le maintien de ces méthodes de travail dans un monde toujours plus agile qui est le responsable de ces coûts et de ces délais plutôt que le SI lui-même. En effet, comme pour tout ancien bâtiment qu'on souhaite rénover, on peut très bien isoler certains éléments d'un SI existant afin de les faire évoluer indépendamment les uns des autres.

C'est le travail de l'urbaniste. Il permet d'identifier les liens entre les composants afin d'identifier les frontières fonctionnelles et les aménager pour créer des entités autonomes. Une fois celles-ci constituées, on peut leur appliquer des méthodes agiles à l'échelle qui permettent de les faire évoluer rapidement (accélérer le time to market) tout en gérant les dépendances inévitables dans un SI legacy. Ces méthodes peuvent néanmoins remettre en cause les structures des organisations existantes et se heurter à des résistances.

Il en va ainsi des SI legacy comme de tout patrimoine. Il ne sert à rien de vouloir le changer si on garde les mêmes méthodes pour construire le nouveau : celui-ci sera très vite aussi lourd à maintenir que celui-là et le gain de la migration sera bien vite estompé. En revanche, si on modifie les méthodes de travail en les appliquant aux anciens SI, on s'apercevra bien vite qu'il n'est plus forcément nécessaire de les abandonner à travers une migration en "big bang" qui, alors, pourrait s'apparenter à une fuite en avant.

Le défi n'est donc pas tant la rénovation du SI historique que la remise en cause des méthodes elles-mêmes qui l'ont construit. Ces méthodes sont ancrées dans des habitudes, dans des organisations qu'il est souvent très difficile de faire bouger. L'implication de la hiérarchie à tous les étages est essentielle pour que cette transformation puisse être menée à son terme et vaincre les résistances. Ici, il s’agit d’un vrai changement de culture d’entreprise qui doit être opéré et impulsé depuis le sommet.