Utilisation des Contrats de Service pour gérer le Système d Information

Transcription

1 Utilisation des Contrats de Service pour gérer le Système d Information Hervé MATHIEU, Thierry GALINHO Laboratoire LITIS, Institut Supérieur d Etudes en Logistique, Université du Havre Quai Frissard, BP 1137, Le Havre Cedex Herve.mathieu@univ-lehavre.fr, Thierry.Galinho@univ-lehavre.fr RÉSUMÉ. Les organisations possèdent des infrastructures supportant le Système d Information de plus en plus distribuées et coûteuses. Ceci implique la mise en place d outils pour évaluer et améliorer la qualité de service concernant le fonctionnement de l entreprise. Pour ce faire, on peut utiliser un réseau de contrats de service (ou réseau de contrats de niveau de service) : chaque contrat contrôle une partie du système d information et évalue la qualité de service grâce à des indicateurs de performance. Nous exploitons ici un outil de gestion basé sur les agents mobiles pour collecter et évaluer les indicateurs définis dans le réseau de contrats, ce qui permet de contrôler la qualité du Système d Information de manière globale. Enfin, nous montrons sur un cas pratique comment des indicateurs simples peuvent être utilisés pour détecter des pannes, de telle manière qu il devient possible de reparamétrer le système pour revenir à un fonctionnement normal, et pour continuer à maintenir ainsi une bonne qualité de service. ABSTRACT. Due to economic constraints, organisations are more and more distributed involving a costly communication and information system infrastructure. This involves setting tools to evaluate and improve the quality of service concerning the enterprise s operation. This can be achieved thanks to a service contract network, (or service level agreement network) : each contract controls a part of the information system and evaluates quality of service and performance indicators. We exploit then a management tool based on mobile agents to collect and evaluate the indicators defined in the SLA network, thus enabling to control the global Information System quality of service. At last, we show on a practical case study how simple indicators can be used to detect technical breakdowns so that new parameters can be set to get back normal functioning, and thus to maintain a good quality of service. MOTS-CLÉS : qualité de service, contrats de service, indicateurs de performance et de qualité. KEYWORDS quality of service, service level agreements, performance and quality indicators.

2 1. Introduction Les entreprises étendues sont mises en place pour réussir un projet spécifique ou bien pour construire une stratégie de collaboration inter-entreprise à long terme. Ainsi, les entreprises étendues peuvent être vues comme des instances du paradigme de l organisation virtuelle. Chaque partenaire peut être vu comme un noeud unique, interagissant avec les autres noeuds de telle manière que l entreprise virtuelle (EV) peut être décrite comme un réseau organisationnel (Tidd et al., 2005). Dans une telle organisation, un système de décision distribué est mis en place, ce qui nécessite un système d information (SI) avec des outils de gestion spécifiques (Malone, 1997) de même que l organisation des processus de travail (ou Business Process) entre les entreprises de l alliance. Le rôle des processus de travail dans l organisation est de remplir les objectifs stratégiques de l entreprise. Pour remplir ce but, différentes applications et différents services, reposant sur une infrastructure opérationnelle, sont utilisés. Ces différents éléments font partie du système d information de l organisation. Il est fondamental d apporter une cohérence globale dans les interactions entre les composants du SI. De plus, chaque élément doit assurer un niveau de service, qui représente sa qualité de service (QoS) (Fouquet, 2000). Ces éléments interagissent sur un modèle client-fournisseur, et la qualité du service offerte par un élément spécifique peut être contrôlée grâce à la mise en place de contrats de service, appelés aussi service level agreements (SLA) entre les entités clients et les entités fournisseurs. Ces contrats définissent des indicateurs permettant d évaluer le fonctionnement du service. Le contrôle et l évaluation d une qualité de service globale, prenant en compte tous les éléments du système d information, conduit à la mise en place d un réseau de contrats, chaque contrat gérant une entité spécifique. Pour gérer dynamiquement la QoS, il est nécessaire tout d abord de modéliser le système d information, de telle manière qu il soit possible d implanter les SLA facilement. Ensuite, les indicateurs définis dans les SLA doivent être mesurés grâce à la collecte de données dans le SI. Enfin, des mécanismes de communication entre les SLA doivent être mis en place pour corréler les informations entre les SLA et établir ainsi une optimisation de la QoS globale. De plus, une connaissance suffisante du fonctionnement du SI et de sa qualité de service effective permet de le gérer proactivement, c est à dire qu il devient possible de mettre en place une administration globale, qui anticipe les besoins et les problèmes (De Franceschi et al., 1996). Dans cet article, nous montrons tout d abord comment mettre en place un réseau de SLA au sein du système d information. Ensuite, nous proposons une implémentation de cette vue logique, qui est un premier pas vers l exploitation d une plate-forme de gestion capable d appréhender la qualité de service d une manière globale. Enfin, nous expérimentons le prototype de cette plate-forme, basé sur le paradigme des agents mobiles, ce dernier ayant l avantage d être particulièrement flexible et adaptatif aux environnements changeants, comme les entreprises virtuelles.

3 2. Contexte Dans la stratégie d une organisation, plusieurs processus de travail, ou Business Process (BP) sont mis en place et sont souvent implémentés selon une approche orientée workflow. Ces processus de travail sont décomposés en tâches élémentaires assignées à différents acteurs. Ces tâches impliquent différentes ressources, qui sont orgnisées selon différents niveaux de décision. Classiquement, une ressource peut appartenir soit au niveau stratégique, tactique ou opérationnel. Le niveau opérationnel est directement lié au fonctionnement de l infrastructure, qui supporte toute l activité de l entreprise. A cause des contraintes économiques, l infrastructure supportant l activité de l entreprise possède une capacité finie qui ne peut être dépassée. Ainsi, il est nécessaire d optimiser dynamiquement son utilisation pour prendre en compte les besoins des entreprises, qui évoluent constamment, spécialement dans les entreprises virtuelles. Pour atteindre ce but, nous devons décrire à la fois la relation entre l organisation et ses propres processus de travail, mais aussi la relation existant entre les processus et les ressources qu ils utilisent. C est pourquoi la construction d un modèle global associant les processus aux ressources utilisées est pertinent. Un tel modèle va permettre d utiliser la connaissance de l organisation pour la gestion proactive des ressources, en phase avec les besoins de l organisation (figure 1): les objectifs de l entreprise sont atteints par les processus de business, chacun d entre-eux étant implémenté par un ou plusieurs workflows. La définition de plusieurs workflows implémentant le même processus de travail peut être trouvée dans les systèmes capables de survie (Carnegie Mellon University, 2000), cette implémentation multiple introduit de la redondance, utile en cas de panne d un des composants du SI. Figure 1. Modèle organisationnel général et simplifié d une entreprise. Ces workflows implémentent des tâches qui effectuent des opérations effectives. Ces tâches utilisent des applications de haut-niveau (les Applications Stratégiques ou AS) qui utilisent les ressources du SI. Les AS, qui représentent la clée de coûte en ce qui concerne l exécution des tâches, basent leur activité sur des ressources logicielles d un niveau moins élevé (Services Applicatifs ou SA), et enfin les SA travaillent eux-mêmes sur des resources matérielles permettant de communiquer et de traiter l information (Services de Base ou SB). Les tâches

4 orchestrent l utilisation des applications et des services, ceux-ci ayant à charge l activité de l organisation (figure 2). Les applications et les services sont organisés de manière hiérarchique. Pour prendre en charge les applications stratégiques, les Services Applicatifs sont disponibles pour fournir des services de base. Les principaux services applicatifs que l ont peut trouver dans une entreprise sont : les services de communication temps réel ce qui englobe le support de la voix, la vidéoconférence, le streaming vidéo ou audio, le broadcast video ou audio, les services d échange de données qui englobent les services transactionnels, les services textuels pour l information et la communication (Intranet/Extranet, Internet, courrier électronique), et les services de traitement ce qui inclue les tâches automatisées, le télé-travail et le Help-Desk. La définition de plusieurs workflows effectuant les mêmes tâches offre une grande flexibilité qui peut être utilisée pour mettre en place des modes dégradés. Par exemple, pour échanger les données entre 2 entités d une entreprise virtuelle, on peut soit utiliser un lien haut-débit, ce qui permet une transmission rapide des données de telle manière qu il devient possible pour les employés de travailler en ligne en mode transactionnel. Cependant, en cas de surcharge des serveurs, il est possible de passer dans un mode de réplication entre les serveurs et les clients, avec une synchronisation régulière entre les données stockées sur le serveur et les données stockées sur le client, ce qui économise de la bande passante et le temps CPU des serveurs mais retarde la mise à jour des serveurs principaux. Pour choisir le workflow qui correspond le mieux au contexte, il est possible d établir un lien entre les processus et les ressources grâce à un formalisme particulier (graphs, réseaux de petri). Ensuite, si on prend en compte les contraintes imposées par les contrats de service (SLA), il est possible de décider quel workflow est le plus adapté à une situation spécifique. Figure 2. Relations entre les processus de travail, les applications stratégiques, les services applicatifs et les services de base dans l entreprise

5 Pour contrôler la QoS globale du système d information, les SLA doivent être mis en place aux interfaces entre les différentes couches (figure 2) et entre les entités coopérantes à l intérieur d une couche. Un SLA est un contrat entre un fournisseur et un consommateur. Ce contrat définit l implication du fournisseur sur la qualité du service fournit. Cette qualité doit être évaluée sur des critères objectifs acceptés par les deux parties. Pour définir et mettre en place le SLA prenant en charge un service stratégique spécifique, ou un des SLA sous-jacent, il est nécessaire d organiser ces SLA dans une relation hiérarchique pour maintenir une cohérence globale dans la définition des SLA et pour être capable de fournir un feedback aux couches supérieures et des directives aux couches inférieures (figure 3). Figure 3. SLA organisés dans une relation hiérarchique. Gérer de bout en bout les SLA dans une entreprise est possible en faisant correspondre les besoins et les objectifs venant des tâches à des indicateurs mesurables appartenant aux couches sous-jacentes. C est un problème considérable de définir et de corréler les indicateurs de performance avec les indicateurs de qualité de l infrastructure. Des standards proposant des indicateurs de performance clé (Key Performance Indicators ou KPI) et des indicateurs de qualité (Key Quality Indicators ou KQI) sont en train d apparaître, grâce à des organisations comme le Telemanagement forum (Telemanagement Forum, 2005). Il apparaît que les indicateurs de base comme le débit du trafic, le nombre de processus s exécutant sur une machine, ou sa charge CPU, permettent de faire des calculs simples (moyenne, écart-type) qui montrent des tendances intéressantes en ce qui concerne l état de la

6 QoS. Les objectifs des tâches globales sont de répondre aux besoin des entreprises, d une manière efficace et cohérente. Les activités de compréhension et l optimisation des tâches globales constituent à elles seules un champ de recherche et la définition d indicateurs de QoS en ce qui concerne les tâches ne sera pas abordé dans cet article. Nous souhaitons ici évaluer l activité du système d information à tous les niveaux de décision, de telle manière qu il soit en mesure de prendre en charge efficacement les tâches qui doivent être faites, ce qui signifie qu il est nécessaire de définir les KQI et les KPI pour les applications stratégiques, les services applicatifs et les services de base. 3. Reporting des SLA et amélioration de la QoS Un bon reporting de SLA repose sur une bonne gestion «verticale», allant des ressources d infrastructure jusqu aux tâches stratégiques ayant pour rôle de remplir les objectifs globaux de l organisation. Pour cela, il est fondamental d établir une relation entre l organisation et ses processus de travail (figure 1), mais il est également important d organiser les ressources de telle manière qu il soit possible d améliorer leur gestion. Plus précisément, il est nécessaire de faire le lien entre chaque ressource et les indicateurs spécifiques permettant d évaluer la qualité de service founit par la ressource. Figure 4. Modèle général et simplifié de l infrastructure de l entreprise La figure 4 présente un modèle très simplifié de l infrastructure. Une description plus précise de ce modèle peut être trouvée dans (Mathieu, 2004). Les ressources d infrastructure sont surveillées et gérées par des processus dédiés, qui sont eux-même régulés par un ensemble de règles. L optimisation de l infrastructure et la surveillance des ressources est effectuée par la collecte et la modification de

7 paramètres propres à une ressource. Des profils de comportement sont établis pour mieux anticiper l utilisation future de chaque ressource. La gestion fine de l infrastructure est la fondation pour respecter la hiérarchie des SLA. Pour gérer efficacement l infrastructure, il est nécessaire d avoir une vue précise de la partie physique du système d information. Cette partie physique contient les informations propre à toute la hiérarchie de l organisation, des services de base jusqu au applications stratégiques. Le respect des directives imposées par la hiérarchie des SLA passe par une bonne configuration des équipements de l infrastructure Une vue physique du système d information Dans notre contexte, la grande difficulté de la gestion de l infrastructure est que nous devons gérer de nombreux SLA, chacun concernant des petites parties de l organisation, et qu il est nécessaire de maintenir une cohérence globale parmi ces SLA. Pour cela, il est nécessaire de gérer ces SLA comme un tout. Le besoin d avoir une gestion des SLA est spécialement importante dans un environnement distribué et dynamique, caractéristique des entreprises virtuellles. Pour effectuer cette gestion des SLA, nous avons besoin d un modèle d infrastructure permettant d établir une relation physique entre les SLA liés logiquement. Pour cela, nous avons défini un modèle logique de l entreprise que nous avons ensuite mis en correspondance avec un modèle physique. La figure 5 montre un modèle logique d entreprise virtuelle constitué de deux entités (entreprise 1 et entreprise 2). Elle montre également la hiérarchie de SLA correspondante. Cet exemple peut être facilement étendu à une entreprise virtuelle composée de N entités.

8 Figure 5. Implémentation du modèle logique de SLA D un point de vue technique, le système d information de l entreprise, des applications stratégiques aux services de base, peut être considérée comme un ensemble de nœuds interconnectés, qui représente les équipements, chacun d entre eux supportant une partie d une application stratégique ou d un service applicatif. Les équipements qui supportent la même application ou le même service forment des clusters, qui définissent ce qu on appelle une zone de gestion spécifique (figure 6). Figure 6. Implémentation physique des AS, SA et SB

9 A cause de la structure dynamique des entreprises virtuelles, l implantation physique des équipements est par nature distribuée, par ailleurs cette implantation évolue constamment. De plus, l émergence de l utilisation importante d équipements mobiles génère une connectivité instable à l intérieur du système Un système de gestion mobile semi-centralisé : Pour gérer une zone représentant un service particulier, il semble approprié de mettre en place un serveur spécifique dans chaque zone, ce serveur étant responsable de la gestion de l activité de la zone. Le rôle du serveur est de gérer la coopération entre les équipements d une même zone, pour obtenir un service de la meilleure qualité possible. Pour cela, il est nécessaire de collecter les données sur des équipements qui reflètent l activité réelle de la zone correspondante. Ceci donne une idée de la QoS réelle offerte dans chaque zone. En plus d une coopération locale dans chacune des zones, il semble approprié pour les serveurs de zone de communiquer pour globaliser la QoS. Une application stratégique repose sur des services applicatifs qui eux mêmes reposent sur des services de base. Il y a donc un besoin de coopération par voie hiérarchique entre les serveurs de zone. La cooperation entre les serveurs d un même niveau hiérarchique est également intéressante. De cette manière, on peut imaginer les serveurs localisés sur un même niveau coopérer ensemble pour faire face à des situations de surcharge de certaines ressources, en se prêtant des ressources critiques par exemple. Un des problèmes majeurs pour arriver à optimiser globlalement la QoS est de trouver un paradigme permettant de gérer efficacement l environnement, en considérant ses caractéristiques propres qui sont : une grande envergure, une nature très distribuée, et une connectivité instable. Pour gérer ces contraintes, un système de gestion centralisé n est pas approprié. Les agents mobiles permettent de contourner les limites imposées par les environnements centralisés en terme de gestion des infrastructures (Tomarchio et al., 2000). L utilisation des agents mobiles a prouvé son efficacité pour résoudre des problèmes clés liés aux infrastructures distribuées comme le routage des paquets dans les réseaux dynamiques (Kramer et al., 2000) (Caro et al., 1998), ou la détection d intrusion (Fenet, 2001). Même si l utilisation des agents mobiles semble adaptée au contexte, il est nécessaire de structurer la manière dont ils sont exploités. Comme il est souligné dans (Schulz et al., 2004), pour exploiter au mieux le paradigme des agents mobiles, il est nécessaire de les faire évoluer dans un cadre défini. Dans notre contexte, nous avons isolé des fonctions bien définies dans le système d information qui sont indépendantes les unes des autres. Ainsi, il nous semble pertinent d utiliser les agents mobiles, chacun d entre eux étant dédié à l une de ces fonctions spécifiques. Les agents mobiles localisé à l intérieur d une zone sont gérés par le serveur de zone. Ainsi, l architecture finale de gestion que nous proposons est partiellement centralisée (figure 7), chaque service étant géré par un serveur spécifique exploitant les agents

10 mobiles à l intérieur de la zone. Ces agents mobiles effectuent toutes les opérations de collecte de données et de gestion (installation, configuration, mise à jour ). Figure 7. Un système à base d agents mobiles partiellement centralisé De plus, un système d information classique est trop étendu et trop complexe pour laisser les agents évoluer comme bon leur semble. Si tel était le cas, il y aurait peu de chances d observer l émergence de propriétés intéressantes. Par conséquent, nous avons choisi de mettre en place à l intérieur de chaque zone un serveur spécifique gérant les agents. Ce serveur s occupe de leur création, de leur gestion, et de corréler les données collectées sur les équipements, de même que de l échange d information avec les autres serveurs. La coopération entre les zones est effectuées en mettant en place des mécanismes d échange et de coopération entre les différentes zones. Dans notre prototype, nous utilisons la plate-forme «aglet» (Open Source, 2003) pour implémenter le système de gestion de QoS: c est une plate-forme opérationnelle, assez complète et gratuite. Nous souhaitons mettre en place des outils de mesure grâce à ces agents. Dans ce cadre, il est important de s assurer que le fait de mesurer n introduira pas une charge trop importante sur les équipements. Il a été montré dans (Mathieu, 2004) que si la taille des agents utilisés reste raisonnable, ce qui signifie que les agents doivent rester simples en terme d itinéraire et d instructions, le trafic et le temps de traitement induits par ces agents peut être négligé.

11 4. Résultats : collecte d indicateurs et construction de profils Dans nos expériences, notre prototype a été utilisé pour extraire certains indicateurs basiques issus de SLA (débit d interface réseau ) pour mettre en place des worfklows de secours en cas de panne réseau, ou de surcharge de base de données. La figure 8 montre la configuration de notre plate-forme de test. Nous avons modélisé une entreprise virtuelle présentée figure 6, cette dernière est interconnectée via des résaux locaux. La figure 8 montre les échanges de données à l intérieur de l entreprise virtuelle (entreprise 1 & entreprise 2). La zone AS1 de l entreprise 1 supporte une application d échange de données. Les nœuds interagissant peuvent être configurés pour échanger des données dans un mode transactionnel ou dans un mode de réplication. Ceci correspond à deux workflows différents supportant la même tâche. Dans un mode transactionnel (i.e. un workflow «normal») le nœud gamma doit prendre en charge les requêtes et y répondre. Dans ce mode, l application supportée par l AS1 (entreprise 2) envoie constamment des requêtes vers gamma, tandis que le mode de réplication, (i.e. le workflow de secours) implique que les données sont seulement échangées de manière périodique : gamma joue le rôle d un serveur «maître» et le serveur «esclave» qui en est le miroir est localisé dans l entreprise 2 (noeud lambda de la zone AS2 ). Lambda se synchronise avec gamma régulièrement : lambda envoie d abord ses données à gamma de telle manière que ce dernier peut mettre à jour sa base de données avec les modifications effectuées sur gamma, puis gamma envoie une copie de la base de donnée vers lambda, de telle manière que lambda travaille sur une copie de la base de données mise à jour. Des agents mobiles surveillant cette application ont été mis en place (agent j). L agent j est géré par le serveur de zone à laquelle appartient lambda. Un agent est lancé chaque minute et récupère le débit du trafic entrant et sortant du nœud lambda. La même configuration existe entre le nœud alpha du SA2 et le nœud beta du SA3. L agent mobile i surveille le trafic entrant et sortant du nœud alpha. La seule différence entre la première configuration et la seconde, est que dans la première la manière dont les données sont échangées (en mode transactionnel ou en réplication) doit être configurée manuellement, tandis que dans la seconde configuration, la manière dont sont échangées les données est configurée automatiquement. Si tout fonctionne correctement, les données entre alpha et beta sont échangées dans un mode transactionnel, ce qui permet de mettre à jour la base de données du nœud alpha instantanément. Cependant, le serveur alpha peut être parfois surchargé en mode transactionnel auquel cas, on passe en mode de réplication, qui est beaucoup moins coûteux en terme de bande passante, mais qui induit un certain retard dans la mise à jour de la base de données maître.

12 Figure 8. Implantation des agents mobiles pour le monitoring des SLA Les figures 9 et 10 montrent les données collectées par l agent mobile surveillant le nœud lambda. La figure 9 montre le trafic généré par l échange de données en mode transactionnel, alors que tout se passe normalement. Lambda envoie régulièrement des requêtes vers gamma ce qui produit un taux d octets en émission assez stable, caractérisée par une moyenne faible, et un écart type proche de 0. Les réponses à ces requêtes (octets reçus) présente un trafic beaucoup plus erratique, qui correspond aux réponses des requêtes qui sont très variables en terme de quantité de données, ce qui est caractérisé par une moyenne plutôt élevée (car il y a beaucoup de données) et un écart-type significatif, qui représente environ 30% de la moyenne. La figure 10 montre un trafic généré par l application d échange de données configurée en mode de réplication, quand tout est normal. On peut observer 2 pointes de trafic très proches apparaissant toute les 30 minutes, la première représente une quantité de données importante qui est reçue, et la seconde représente une quantité similaire, mais envoyée cette fois ci. La première pointe correspond à la mise à jour du serveur maître grâce aux données provenant du serveur esclave, qui a potentiellement été modifié. La seconde pointe est due à la mise à jour de l esclave grâce aux données provenant du serveur maître. Ce type de trafic est caratérisé par un écart type très important (representant presque 3 fois la moyenne). La figure 11 montre une situation où le transfert de données transactionnel présente un profil anormal entre alpha et beta, car le SGBD alpha est surchargé de requêtes provenant de beta. Les requêtes sont toujours émises par beta, mais le serveur ne répond pas entre la 275 ième et la 325 ième minute, car il s écroule. Il est relativement facile de détecter ce type de problème, si nous considérons que la moyenne et que l écart-type calculés sur la figure 9 reflètent un fonctionnement normal de l application. Sur la figure 11, si on s intéresse aux octets reçus, l écart type augmente beaucoup, à cause de l interruption de service, et devient ainsi

13 presque égal à la moyenne. Dans un tel cas (i.e. avec ce type de trafic, quand l écart type excède 50% de la moyenne pour les octets reçus), il y a potentiellement un problème. Grâce à ce critère, il devient possible passer au workflow de secours (mode répliqué). La figure 12 montre l activation de ce mode de secours, comme une conséquence du dysfonctionnement de l application transactionnelle entre SA2 et SA3. Grâce à ce workflow de secours, les données sont toujours échangées, même si les modifications sur le serveur maître alpha ne sont pas faîtes en ligne, mais les données sont synchronisées à chaque cycle de réplication (toute les 30 minutes). Grâce à des indicateurs simples, comme la moyenne ou l écart type du débit, il est possible de contrôler si les SLA sont respectés, et ainsi choisir le bon mode suivant lequel les données seront échangées, pour maintenir une bonne QoS. Figure 9. Fonctionnement normal d une application Figure 10. Fonctionnement normal transactionnelle entre AS1 et AS1 de la réplication entre AS1 et AS1 (échantillonage à la minute) (échantillonage à la minute)

14 Fig. 11. Dysfonctionnement d application Fig. 12. Activation du workflow de secours transactionnelle entre SA2 et SA3 entre SA2 et SA3 (échantillonage à la minute) (échantillonage à la minute) 5. Conclusion et Perspectives Le système d information d une entreprise virtuelle a besoin d être cohérent dans ses actions et doit offrir une bonne qualité de service globale pour atteindre les objectifs de l organisation. De tels buts sont difficiles à atteindre à cause des propriétés caractéristiques des organisations virtuelles : une architecture distribuée, beaucoup d entités inter-dépendantes, qui interagissent sur un modèle clientfournisseur, chacune d entre elle appartenant à différents niveaux stratégiques, avec des objectifs propres. Une possibilité de gérer la qualité de service du SI de manière globale est de mettre en place des contrats de service (SLA) entre les entités du SI. Ces SLA sont utilisés pour définir des indicateurs pertinents pour gérer efficacement chacune de ces entités. Nous montrons comment le réseau de SLA est mis en correspondance avec l infrastructure physique du système d information. Cela permet de structurer le système d information pour faciliter son analyse. Par conséquent, il devient possible de mettre en place un système de gestion, ayant à charge la surveillance des tâches stratégiques du système d information qui permet d assurer une bonne QoS. Grâce à l implémentation d un tel système de gestion, basé sur le paradigme des agents mobiles, nous identifions des tendances intéressantes dans la typologie des échanges de données entre les entités clés du système d information. De cette manière, nous montrons qu un simple calcul effectué sur les données

15 collectées peut être utilisé pour contrôler si les SLA sont respectés, et donc de surveiller la QoS, ce qui permettra d adapter l organisation au contexte (en choisissant le «bon» workflow). Actuellement, le prototype de gestion de QoS est opérationnel. Nous nous intéresserons ensuite à la manière dont les zones peuvent négocier et coopérer pour mieux gérer les impromptus. 5. Bibliographie Carnegie Mellon University, The Survivable Network Analysis Method : Assessing Survivability of Critical Systems, Technical Report, Caro G.D., Dorigo M., AntNet : Distributed Stimergetic Control for Communications Network, Journal of Artificial Intelligence Research, 1998;9: De Franceschi A.S.M., Kormann L.F., Westphall C.B., A performance application for proactive network management, Proceedings of IEEE Second International Workshop on System Management (SMW'96), Toronto, Canada: IEEE Computer Society; 1996, p Fenet S., Toward a paradigm for programing distributed applications based on social insects behaviour : application to network security, PhD Thesis, Fouquet B., Quality of Service Management : networks, servers and applications, Paris : Eyrolles; Kramer K.J., Minar N., Maes P., Tutorial : Mobile Software Agents for Dynamic Routing, Mobile computing and Communications Review, 2000; 3(2): Malone T.W., Is empowerment just a fad? Control, decision making, and IT, Sloan Management Review, 1997: Winter Issue. Mathieu H., Infrastructure and process cross-modelisation for distributed enterprise proactive administration., PhD Thesis, INSA de Lyon, Open Source,Aglets framework ( Schulz S., Schulz M., Tanner A.,Frame of Interest Approach on Quality of Prediction for Agent-based Network Monitoring, Proceedings of the International Conference on Architecture of Computing Systems 2004 (ARCS'04), Augsburg, Germany : Springer; 2004, p The Telemanagement Forum,< Tidd J., Bessant J., Pavitt K., Managing innovation, 3 rd Edition, New York : John Wiley and Sons; Tomarchio O., Puliafito A., Using mobile agents to implement flexible network management strategies, Computer Communications, 2000; 23(8):