Les Systèmes d’Information Financière Atelier conjoint Banque Mondiale / AFRITAC de l’Ouest / World Bank Institut / Coopération Française Différentes options en termes d’architecture technique. Impact sur l’interopérabilité et l’évolution du système 1- Introduction 2- Intégrer le besoin d’évolution 3- Caractéristiques internes du logiciel 4- Evolution des architectures 5- Avantages du multicouche 6– Quelques exemples 7- Conclusions Présenté par Khalid ALKASSOUM Directeur Technique Softline, Directeur Général Advanced IT advanced.it@laposte.net

1- Introduction (1) L’architecture technique comprend plusieurs aspects Infrastructure matérielle Infrastructure réseau Architecture logicielle Ces aspects sont interdépendants Relèvent de stratégies différentes

1- Introduction (2) - L’infrastructure matérielle Avec la montée en puissance et la baisse des coûts, la très grande majorité des systèmes de gestion tourne aujourd’hui sur des machines de type PC. Sur le plan des serveurs, c’est d’abord le champ d’application et les conditions d’exploitation qui déterminent le choix, mais là encore, les architectures Intel/Windows sont très courantes. Il faut savoir spécialiser les serveurs. Souvent sous-estimés, les autres moyens matériels doivent être « pensés » comme faisant partie du système : Équipements spécifiques réseau Sauvegardes (et rangement des sauvegardes) Alimentation sécurisée Équipements et Aménagements des locaux Disposer d’un politique d’acquisition et de gestion du matériel est primordiale. L’inscrire dans un plan d’investissement permet de consolider la démarche.

1- Introduction (3) - L’infrastructure réseau Deux aspects doivent être distingués : Le réseau local (LAN). Le réseau étendu (WAN). Ces technologies ont beaucoup évolué au cours des 5 dernières années. Le matériel s’est fortement standardisé. La technologie des réseaux étendus, relève des équipements de télécommunication. Une bonne approche consiste à : Acquérir (faire installer et se rendre propriétaire) le réseau local. Le câblage est souvent intégré à la conception des bâtiments. Sous-traiter les communications extérieures et l’accès à un réseau étendu (opérateurs télécoms et sociétés spécialisées) Une architecture logicielle adéquate et une organisation adaptée permettent d’alléger le transit sur le réseau Implications importantes sur la sécurité globale du système.

1- Introduction (4) - L’architecture logicielle Les aspects logiciels sont les plus difficiles à maîtriser, surtout dans le cas des grandes applications spécifiques. Leur développement et leur déploiement impliquent toujours un risque d’échec : Qu’il ne faut jamais sous-estimer Qu’il faut caractériser (puis réduire) Contre lequel il faut opposer une stratégie adéquate Pour mieux contrôler le processus de « fabrication du logiciel », l’un des principaux leviers d’action du génie logiciel est : l’architecture du logiciel Architecturer, pourquoi ? Comment ? …

2- Besoin d’évolution (1) Chaque organisation n’est pas un ensemble de parties juxtaposées avec des objectifs propres, … … mais un réseau de systèmes ayant entre eux des relations et tendant à atteindre un objectif global.

2- Besoin d’évolution (2) – quelques acteurs Loi Organique Finances Règlement Général de la Comptabilité Loi de Finances Dette Pouvoirs Publics Ministères Interventions Investissements Ministère des Finances Ordonnateurs Administrateurs Crédits Contrôleurs financiers Ordonnateurs Economie Recettes Dépenses Comptables DGD DGI DGB TG Budget Nomenclature Budgétaire Plan Comptable de l’Etat TOFE

2- Besoin d’évolution (3) – les flux Comptables Comptables Comptables Ordonnateurs Ordonnateurs Contrôleurs Financiers Administrateurs Crédits Engagements Opération d’Assiette TG Liquidation DGI DGB Identification du Contribuable Prise en charge Prise en charge Budget Paiement Recouvrement DGD Recouvrement Ordonnancement Compta Informations économiques Exécution du Budget / Nomenclature Budgétaire Comptabilisation / Plan Comptable de l’Etat

2- Besoin d’évolution (4) Voir schéma WB

2- Besoin d’évolution (4) Dans une organisation les besoins évoluent Chaque fois qu’une entité évolue, les flux entre entités changent Les entités n’ont pas le même degré d’informatisation On ne peut pas toujours anticiper les pressions de l’environnement extérieur sur le système d’information Or, à l’inverse, le développement informatique a besoin de spécifications précises et stables dans le temps, … Un système d’information mal intégré (ou non intégrable) introduit des frontières artificielles entre les entités. Fragmente l’information => détruit les relations dont dépend le fonctionnement correct des entités

2- Besoin d’évolution (5) Disposer d’un système d’information capable de prendre en compte les contraintes organisationnelles, d’être corrigé rapidement en cas d’erreur, et d’évoluer avec les besoins … … devient un objectif du logiciel, au même titre que les fonctionnalités qu’il doit fournir.

3- Caractéristiques internes du logiciel On peut analyser un logiciel sous 2 angles L’angle fonctionnel (ce qu’il fait) L’angle de ses caractéristiques internes (comment il est fait)

4- L’évolution des architectures (1) Jusqu’au milieu des années 80 : mini-ordinateurs avec terminaux passifs (époque COBOL, RPG …) La programmation structurée a été une première réponse du génie logiciel à la crise du logiciel Fin des années 80, de plus en plus de micro-ordinateurs en tant que machines servant à la gestion : applications monolithiques, monopostes (Epoque dBase) Début des années 90, avec les réseaux de plus en plus accessibles : applications monolithiques, partage de fichiers (Epoque Netware) Milieu des années 90, de plus en plus de serveurs : l’architecture client/serveur s’impose (Epoque Oracle 7, Sybase …) Le génie logiciel accentue ses efforts sur la Programmation Orientée Objets depuis plus de 10 ans …

4- L’évolution des architectures (2) Avec le client/serveur Fin du partage de fichiers et ses problèmes intrinsèques Nombreux autres avantages du SGBD Client plus léger Stockage des procédures dans le SGBD SQL s’impose partout

4- L’évolution des architectures (3) Mais … de nouveaux types de problèmes apparaissent … Les applications de gestion sont de plus en plus complexes L’intégration de plusieurs applications n’est pas si simple que ça La stratégie à deux couches s’adapte mal

4- L’évolution des architectures (4) On rajoute une couche … vers l’architecture multicouche La couche « métier », au centre, va permettre l’abstraction des bases de données. Le client accède à des processus « métiers » L’intégration du système d’information se concentre sur le serveur d’application, la maintenance aussi, le déploiement se simplifie.

5-Avantages du multicouche Abstraction des bases de données Intégration des processus métiers (et du SI) Accroissement de la sécurité Clients plus légers, et déploiement plus facile Concentration de la maintenance Emergence de plateforme spécialisée (serveurs d’applications) fournissant les mécanismes de gestion des objets sur le serveur Plateforme de développement orienté objets plus performantes A condition de maîtriser la POO et les nouvelles plateformes (.Net ou EJB/J2EE, Oracle 9iAs … et les langages associés) ainsi que UML (Unified Modeling Language) Accroissement de la maintenabilité des applications Accroissement de la capacité d’évoluer

6-Quelques exemples Voir tableau WB [1] The timeframes for Malawi and Uganda are estimates as the reforms are in their initial stages [1] The timeframes for Malawi and Uganda are estimates as the reforms are in their initial stages

5-Conclusions Plusieurs technologies sont arrivées à maturité (composants, AS, WEB, C#, .Net, J2EE …) Les environnements de développement logiciel (VS, Delphi 2005, Jbuilder …) ont fortement progressé Orienter les nouveaux développements vers les nouvelles plateformes (.Net, J2EE ou Oracle 9iAS/10g) Adopter l’architecture 3 tiers (et le multicouche en général) est un avantage. Adopter UML pour la conception s’impose dans ce contexte