Bernard RATAFIKA ’L’histoire d’un système d’information’

Responsable de la division Communication et Secrétariat des Conseils

Mon premier contact avec le monde des Instituts remonte à janvier 1990. Muni d’un beau diplôme consacré à la gestion des systèmes d’information, j’avais l’opportunité de mettre en application des connaissances fraîchement acquises à l’ESSEC.

Le cas de l’IEDOM apparaissait comme un cas d’école : de fortes attentes des utilisateurs, un environnement technique à renouveler, un clivage culturel entre la micro et la « grosse informatique », des méthodes de travail ne correspondant à l’état de l’art dans le domaine. Et, pour simplifier le problème, il existait une contrainte externe puissante liée au calendrier de mises en place de nouvelles applications imposé par le législateur (loi sur les chèques, …) et/ou la réglementation bancaire (réforme BAFI, …).

Dans un premier temps, un audit du système d’information a été réalisé entre octobre 1990 et mars 1991, soit sur des délais très courts, probablement trop courts, car la démarche n’a pu être explicitée suffisamment pour garantir une adhésion totale des principaux intéressés et permettre une appropriation entière des recommandations formulées.

Dans un deuxième temps, la conduite d’une étude de type schéma directeur a débuté en septembre 1991 pour s’achever en juin 1992. Six catégories d’actions ont été identifiées, après analyse des scénarios envisageables :

  • le développement de nouvelles applications,
  • la rénovation d’applications existantes,
  • le choix et la mise en oeuvre de progiciels,
  • le remplacement du matériel existant,
  • les migrations résultant du changement d’environnement technique,
  • l’accompagnement du changement avec notamment des actions de formation,

soit, sur une période s’étalant sur quatre ans, une véritable révolution plus que des évolutions successives. Le pari très ambitieux a finalement été relevé par tous, en agences comme au siège, car il répondait à un souhait partagé de modernisation d’un outil vieillissant resté à l’écart des évolutions technologiques. D’importants moyens, notamment en termes de ressources financières, ont été mis en oeuvre. Les résultats obtenus ont été probants, mais l’expérience a montré que, particulièrement dans le cas de petite structures telles que l’IEDOM, les vraies limites à de tels projets tiennent à l’impossibilité pour les uns et les autres de se dédoubler, spécialement pour assurer une gestion optimale des appuis extérieurs (prestataires de service) …

La preuve d’une réelle mise à niveau du système d’information de l’IEDOM peut être illustrée par la mise en application de concepts innovants, il y a quinze ans, tels que l’interconnexion entre les sites afin de parvenir à une exhaustivité des données, le travail sur des bases de données relationnelles, l’échange entre utilisateurs de fichiers micro via le réseau de la « grosse informatique ».

J’ai pu constater, quelques années après, la qualité du travail accompli, tant dans les phases de conception que dans celles de réalisation des applications ou au niveau de choix matériels adaptés à notre configuration ; en effet, en août 2000, je revenais au siège de l’IEDOM pour une autre mission. Il s’agissait alors d’assurer une coordination avec les équipes techniques de la Banque de France pour le déploiement dans un environnement technique nouveau de certaines applications de la banque centrale nationale : on parlait alors d’architecture client-serveur, d’impressions déportées, de performances des réseaux, de réseaux virtuels, …

Une nouvelle révolution s’appliquait à l’architecture du système d’information de l’IEDOM consécutivement au rapprochement avec la Banque de France : également, dans ces circonstances, j’ai pu apprécier combien le facteur temps est essentiel car, en autorisant les intéressés à prendre du recul sur des évènements subis, il leur permet de convenir, a posteriori, de l’évidence des solutions mises en place.

Toute réforme suppose des mesures d’accompagnement, des explications pour que les principaux acteurs l’adoptent mais ces pré requis ne sont souvent pas remplis faute d’une anticipation suffisante : on peut bien sûr théoriser sur la gestion du changement, les freins au processus d’innovation. Dans les faits, on ne peut nier les dégâts collatéraux, pendant un laps de temps plus ou moins long, qu’entraîne une réforme subie.

Septembre 2009

  1. Guadeloupe  
  2. Saint-Barthélemy  
  3. Saint-Martin  
  4. Martinique  
  5. Guyane  
  6. Saint-Pierre-et-Miquelon  
  7. Accueil site  
  8. Mayotte  
  9. La Réunion