Evolution du système d’information

Exemple de situation de Système d’information

Le SI est souvent conçu pour répondre aux fonctionnalités A et B, et ce rapidement avec un démarrage en production 8 mois plus tard. Dans une seconde phase, laquelle est envisagée car la réussite du projet sera là, les fonctionnalités d’évolution A’ et B’ seront mises en place, démarrage prévu 6 mois plus tard.

Les équipes de conception et de réalisation livrent dans les temps leur production. Puis vient la phase II : faire évoluer le SI. L’exemple que nous utiliserons ici pour illustrer notre propos est le multi-langue : Le code langue signifie d’une part que l’affichage des écrans se fera dans la langue de l’utilisateur, mais également que les règles de gestions seront celles du pays de l’utilisateur, en adéquation relative avec le code langue. (La fiscalité par exemple est différente en Espagne, en France, en Belgique, les règles de gestion sont propres au pays).

Les questions auxquelles il convient de répondre sont nombreuses :
  comment implémenter l’évolution code langue ?
  faut-il modifier toutes les tables ?
  faut il modifier tous les programmes ?
  une phase de test va-t’elle être nécessaire ?
  quels sont les impacts sur le SI ?

Evolution du coté de la base de données

On est en droit de penser que la phase II va être aussi longue que la phase I et que le SI risque de perdre quelques atouts de ses caractéristiques, si des modifications dans les tables et programmes ne sont pas passées par la phase de conception et d’optimisation du modèle de données.

Evolution du coté des programmes

Pour certains traitements batch, ce code langue peut faire changer la manière de réaliser le traitement, en fonction des temps d’accès à la base de données par exemple, alors que la phase de conception aurait pu prendre cet aspect en amont et réduire les effets néfastes coté traitements. Dans les aspects programmes, si l’analyste-réalisateur peut aller chercher la règle de gestion dans un paramétrage spécifique au code langue, il aurait fait la conception organique des programmes de manière différente pour rendre ces aspects code langue - règles de gestions plus facile à gérer.

Evolution sur l’organisation

Plus loin encore, c’est au niveau de l’intégration sur le site de production que des problèmes de paramétrage, de mise au point risquent de se poser et être la source de bugs. Les phases de maintenance et d’évolution future du SI (oui encore) risquent également de voir apparaître des dysfonctionnement liés à la mise en place de ces évolutions ; les problèmes deviendront d’autant plus complexes que les solutions auront été trouvées rapidement.

Les solutions possibles

L’idéal on l’a bien compris et de pouvoir faire la conception la plus large possible avec les options dans la même phase :

  phase une : conception des fonctionnalités A et A’
  phase deux : conception des fonctionnalités B et B’

Il n’est pas identique en terme de SI livrable de faire deux phases découpées par fonctions complètes en multi-langue, ou deux phases découpées par code langue.

En termes de qualité de SI, la solution avec une conception complète est plus viable, tant sur les maintenances à venir sur les programmes, que sur la motivation et l’intérêt des ressources humaines intervenant sur le projet.