Dunkerque confie ses interfaces à l'EAI iBolt

Marie Varandat

01 Informatique

le 29/05/2008 à 00h00

envoyer
par mail

imprimer
l'article

La communauté urbaine de Dunkerque (CUD), établissement public de coopération intercommunale regroupant 18 communes et 210 000 habitants, a développé, jusqu'en 1990, ses applications. En 1995, un schéma directeur fait opérer un tournant à la DSI : il faut privilégier les applications du marché aux développements internes. Leur adoption progressive va générer une complexité qui freine l'évolution et la réactivité de la CUD et, curieusement, accroît les coûts internes de développement.

Le contexte : trop de coûts d'adaptation du SI

“ Tant que nous étions sur du développement sur mesure, nous maîtrisions notre environnement et nos interfaces, explique Pierre Melerowicz, DSI de la CUD, mais, dès le changement de politique, nous avons perdu cette maîtrise car les éditeurs ne documentent pas toujours les API. En outre, l'arrivée de solutions du marché avec leur propre système d'exploitation a provoqué une hétérogénéité technique dans notre système informatique à la quelle nous n'étions pas habitués. ” La CUD travaill ait uniquement sur AS/400 avant 1995. Ses équipes n'avaient pas les compétences sur d'autres environnements et toutes ses applications gravitent autour du logiciel financier. “ Tout est lié et le problème devenait crucial lorsqu'il s'agissait d'ajouter ou de supprimer un progiciel à l'ensemble. Le seul remplacement de notre application financière impliquait le développement d'une dizaine d'interfaces, détaille Pierre Melerowicz. La charge était énorme, nous n'avions pas les compétences et le problème était sérieux car, à chaque évolution, nous devions retoucher ces interfaces avec des coûts en développement importants. ” En 2006, la CUD met fin à l'escalade des complications et adopte un EAI (outil d'intégration d'applications). Le SI compte alors neuf progiciels principaux, dont trois spécifiques, plus des développements réalisés en interne sur la plate-forme AS/400.

La mise en œuvre : une progression étape par étape

Lorsqu'elle adopte iBolt, de Magic Software, la CUD ne cherche pas particulièrement un EAI, mais plutôt une solution pour automatiser la production d'interfaces. “ Nous sommes arrivés à l'EAI progressivement, et à iBolt en particulier par ce que nous cherchions une solution pragmatique et ouverte sur notre existant AS/400 avec un budget relativement limité ”, précise Pierre Melerowicz.

Les premiers remplacements portent sur les interfaces autour du logiciel financier, cœur du système d'information de la CUD. Le premier projet concerne plus exactement l'arrivée du logiciel de gestion de projet, Artemis, qui gère les opérations communautaires. Essentiel pour la CUD, il instrumentalise les processus de décision de ses opérations. Il fournit également un tableau de bord pour mesurer l'état de ces opérations et de leur budget par rapport aux axes politiques de la communauté urbaine.

Par la suite, la CUD a aussi intégré son système décisionnel utilisé pour l'élaboration budgétaire, ce dernier étant composé d'un module de prospective financière et d'un outil d'analyse l'aidant à gérer ses emprunts de manière dynamique. “ Nous avançons étape par étape en appliquant l'EAI à tout projet d'ajout de logiciel ou de remplacement de l'existant en travaillant sur les processus internes, mais également dans le cadre des échanges avec nos partenaires et notamment les villes qui composent la CUD ”, explique le DSI de la Communauté.

Les gains : du temps et de la traçabilité

Au total, cinq interfaces ont été mises en œuvre depuis l'installation d'iBolt. “ Là où il nous fallait parfois des mois pour développer une interface, il ne faut plus que quelques jours avec iBolt, souligne Pierre Melerowicz. En fait, on ne peut pas vraiment parler de développement, mais plutôt de paramétrage de connecteurs déjà présents dans notre EAI. En outre, nous disposons aujourd'hui d'une traçabilité sur les échanges qui nous faisait défaut auparavant. ” Native dans iBolt, elle offre à la CUD un suivi des incidents et automatise la reprise sur erreur. La communauté a ainsi gagné en qualité de service rendue aux utilisateurs tout en diminuant sa charge de travail sur l'administration. IBolt nous a apporté de manière indirecte une structuration et une cartographie des flux échangés entre les domaines applicatifs, c'est-à-dire les prémices d'une démarche pragmatique d'urbanisation des SI.

Les écueils : un changement culturel fondamental

Les problèmes rencontrés par la CUD lors de cette évolution progressive vers un système “ urbanisé ” sont avant tout d'ordre culturel. Le personnel technique, formé essentiellement à l'AS/400 et au développement d'application, a dû non seulement acquérir de nouvelles compétences techniques, mais, et surtout, apprendre à raisonner différemment. “ Nous sommes encore loin d'exploiter toute la richesse de notre EAI pour la simple raison que nous ne pensons pas en termes d'EAI et d'urbanisation, explique Pierre Melerowicz. Dans un premier temps, nos problèmes étaient claire ment ailleurs et nous ne cherchions qu'une solution pour produire nos interfaces plus vite et à moindre coût. Mais, progressivement, le concept d'urbanisation a fait son chemin à la CUD et nous commençons même déjà à “ penser ” en SOA. ”

La flexibilité acquise avec iBolt a véritablement ouvert des portes en termes de réflexion. Mais ce passage d'une architecture point à point à un système orchestré par l'EAI ne s'est pas fait sans heurts et a nécessité un changement de paradigme de la part des équipes techniques : formation aux nouvelles approches de type SOA et non au produit.