Brevet FR2954646A1 — publié le 20110624

Procédé de fonctionnement d'un dispositif informatique d'un réseau informatique, programme d'ordinateur, dispositif informatique et réseau informatique correspondant La présente invention concerne le fonctionnement des dispositifs informatiques actifs dans un réseau informatique tel qu'un réseau de télécommunication, ces dispositifs étant formés par exemple par des routeurs, des commutateurs, etc. A ce jour, le fonctionnement classique de ces dispositifs actifs est essentiellement basé sur un mode de traitement planifié de sorte que chacun de ces dispositifs réagit de façon prédictive aux stimuli et/ou événements en provenance de leur environnement. Par exemple, dans le cas d'un routeur, sa capacité à réagir de façon plus ou moins optimale est influencée par le contenu et la quantité d'informations à traiter conformément aux règles de routage et de filtrage préétablis comme par exemple le débit du trafic en fonction du niveau de qualité de service attendu ou la gestion de résilience et le choix des routes alternatives en cas de problèmes (ex. rupture d'une liaison, etc). Il est également important de souligner l'impact de l'organisation (architecture) de ces équipements actifs en terme de sécurité de l'information. Etant donnée la complexité croissante des réseaux de télécommunication (fixe, mobile, sans fil, ad hoc, distribué, etc) et des usages divers et variés (téléphonie, télématique, bureautique, domotique, etc), ce mode d'organisation et de fonctionnement statique s'avère de plus en plus inadapté aux contraintes de la qualité de service, ce notamment, en terme de gestion optimale de la sécurité de l'information. Actuellement le fonctionnement habituel d'un dispositif informatique d'un réseau informatique est de prendre des décisions à partir notamment de communications de messages qu'il réalise avec les autres dispositifs du réseau, c'est-à-dire, dans le cadre de la présente invention, à partir de messages entrants dont il est le destinataire et/ou de messages sortants dont il est l'émetteur. Ces communications de messages lui permettent de détecter des évènements à partir desquels il prend, selon des règles prédéterminées, des décisions affectant son fonctionnement et en particulier l'envoi de messages sortants. Par exemple, un premier routeur ne recevant pas de réponse à ses messages sortants (communication de message) qu'il émet à destination d'un second routeur, en déduit que ce second routeur est indisponible (évènement) et modifie en conséquence sa table de routage afin que les messages soient routés vers un autre routeur disponible (envoi de messages sortants). Le but de l'invention est de permettre aux dispositifs d'un réseau de prendre des décisions significativement améliorées. 2 A cet effet, l'invention a pour objet un procédé de fonctionnement d'un dispositif informatique d'un réseau informatique, caractérisé en ce que le dispositif informatique : - consulte une base de données d'évènements comprenant une donnée d'évènement : + générée par un autre dispositif informatique du réseau informatique à partir d'au moins un échange de message, et + enregistrée par l'autre dispositif informatique dans la base de données d'évènements, - analyse la donnée d'évènement de la base de données d'évènements pour obtenir un résultat d'analyse d'évènement, - génère un message sortant en fonction de critères comprenant le résultat d'analyse d'évènement, et - émet le message sortant. Grâce à l'invention, le dispositif informatique prend une décision sur la base d'évènements détectés par d'autres dispositifs informatiques du réseau informatique. Pour reprendre l'exemple précédent, l'invention permet au premier routeur de manière avantageuse de changer sa table de routage lorsqu'un autre dispositif du réseau détecte l'indisponibilité du second routeur, alors même qu'il ne l'a lui-même pas encore détectée. L'invention permet en particulier d'optimiser les opérations primordiales des réseaux de télécommunication, telles que le routage et le filtrage des messages dans le réseau. Selon d'autres aspects de l'invention, le procédé de fonctionnement d'un dispositif informatique comprend l'une ou plusieurs des caractéristiques suivantes : - le dispositif informatique est conforme à un modèle d'architecture en couches protocolaires et le dispositif informatique génère le message sortant en : - sélectionnant, en fonction des critères, un protocole de communication pour une des couches protocolaires, et en - générant le message sortant selon le protocole de communication sélectionné, - le dispositif informatique est conforme à un modèle d'architecture en couches protocolaires et le dispositif informatique génère le message sortant en : - sélectionnant, en fonction des critères, des paramètres d'un protocole de communication d'une des couches protocolaires et, en - générant le message sortant selon le protocole de communication paramétré avec les paramètres sélectionnés, - le dispositif informatique : - participe à une communication de message, et - analyse la communication de message pour obtenir un résultat d'analyse de communication de message, et les critères comprennent le résultat d'analyse de communication de message, et - le dispositif informatique : - consulte une base de données d'historique d'actions comprenant un compte rendu d'action : + généré par un autre dispositif informatique du réseau informatique à partir d'une action affectant l'envoi de messages sortant par cet autre dispositif informatique et + enregistré dans la base de données d'historique d'actions par l'autre dispositif informatique et - analyse la donnée d'action pour obtenir un résultat d'analyse d'action, et les critères comprennent le résultat d'analyse d'action. L'invention concerne également un programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un tel procédé, lorsque ledit programme d'ordinateur est exécuté sur un ordinateur. L'invention concerne en outre un dispositif informatique d'un réseau informatique, comprenant : - des moyens pour consulter une base de données d'évènements comprenant une donnée d'évènement : + générée par un autre dispositif informatique du réseau informatique à partir d'au moins une communication de message avec cet autre dispositif informatique et + enregistrée par l'autre dispositif informatique dans la base de données d'évènements, - des moyens pour analyser la donnée d'évènement pour obtenir un résultat d'analyse d'évènement, - un module de pilotage pour déterminer si un message sortant doit être envoyé et, si un message sortant doit être envoyé, pour générer un message sortant et - des moyens pour émettre le message sortant, et le module de pilotage est conçu pour tenir compte de critères comprenant au moins le résultat d'analyse d'évènement, pour réaliser au moins l'une des fonctions parmi : - la détermination si un message sortant doit être envoyé, et - la génération du message sortant. L'invention concerne enfin un réseau informatique, comprenant une pluralité de tels dispositifs informatiques. On va à présent décrire un mode de réalisation préféré de l'invention, à titre d'exemple non limitatif. La description de ce mode de réalisation fait référence aux figures annexées suivantes : - la figure 1 qui représente un exemple de réseau informatique selon l'invention ; et - la figure 2 qui représente les étapes d'un exemple de procédé de fonctionnement de chaque dispositif informatique du réseau informatique de la figure 1. Un réseau informatique 100 selon l'invention est représenté sur la figure 1. Il s'agit par exemple d'un réseau de télécommunication. Dans la présente description, le terme de réseau signifie aussi bien un seul réseau informatique, par exemple un réseau local, qu'un ensemble de réseaux informatiques interconnectés entre eux, tel que le réseau Internet. Le réseau 100 comprend des dispositifs informatiques 1021...1025, aussi appelés « noeuds » du réseau 100. En particulier, dans l'exemple illustré, le dispositif 1023, est un routeur de communication. Chacun des dispositifs 1021...1025 est conforme à un modèle donné d'architecture en couches protocolaires. Les dispositifs 1021...1025 sont par exemple conformes au modèle OSI ou bien au modèle TCP/IP. Tous les dispositifs du réseau 100 sont conçus pour pouvoir communiquer les uns avec les autres, en s'échangeant des messages. A cet effet, chaque dispositif 1021...1025 comprend un module de communication 1041...1045 comprenant, d'une part, des moyens de réception 1061...1065 conçus pour recevoir des messages entrants provenant d'autres dispositifs du réseau 100 et, d'autre part, des moyens d'émission 1081...1085 conçus pour émettre des messages sortants à destination d'autres dispositifs du réseau 100. Chaque dispositif 1021...1025 comprend en outre des moyens d'analyse de communication 1101...1105 conçus pour analyser au moins un message entrant et/ou au moins un message sortant, afin d'obtenir un résultat d'analyse de communication. Les moyens d'analyse de communication 1101...1105 sont par exemple conçus pour: - détecter qu'un message transporte des données sensibles nécessitant une protection optimale, - calculer le temps d'aller/retour d'un message à partir de messages de requête, - détecter, à partir des communications, une rupture d'une liaison physique ou logique. Chaque dispositif 1021...1025 comprend en outre des moyens de génération de donnée d'évènement 1121...1125 conçus pour générer une donnée d'évènement à partir du résultat d'analyse de communication. Chaque dispositif 1021...1025 comprend en outre des moyens d'enregistrement d'évènement 1141...1145 conçus pour enregistrer la donnée d'évènement dans une base de données d'évènements 1161...1165i commune à tous les dispositifs du réseau 100, c'est-à-dire que tous les moyens d'enregistrement d'évènement 1141...1145 sont conçus pour enregistrer les données d'évènements dans cette même base de données 1161...1165. Dans l'exemple illustré, la base de données d'évènements est distribuée entre des dispositifs du réseau 100, c'est-à-dire que les données qu'elle contient sont enregistrées en partie sur chacun de ces dispositifs. Cependant, la base de données d'évènements est vue de l'extérieur, et en particulier pour la lecture et l'écriture, comme une base de données unitaire. En variante non illustrée, la base de données d'évènements est contenue dans un seul dispositif du réseau. Par ailleurs, le terme de base de données ne doit pas être interprété de manière restrictive. La base de données d'évènements peut être constituée de plusieurs base de données, consultées en même temps ou tour à tour. Chaque dispositif 1021...1025 comprend en outre un module de pilotage 1181...1185 conçu pour prendre une décision affectant notamment des messages sortants. En particulier, le module de pilotage 1181...1185 est conçu pour générer des messages sortants en fonction de la décision prise. Dans le cas du routeur 1023, les moyens de pilotage 1183 comprennent par exemple une table de routage et des règles pour modifier la table de routage en fonction de critères, comme cela sera expliqué plus loin. Chaque dispositif 1021...1025 comprend en outre des moyens de génération de compte-rendu 1201...1205 conçus pour générer un compte-rendu à partir d'au moins une décision prise par le module de pilotage 1181...1185. Chaque dispositif 1021...1025 comprend en outre des moyens d'enregistrement de compte-rendu 1221...1225 conçus pour enregistrer le compte-rendu dans une base de données d'historique 1241...1245 commune aux dispositifs du réseau 100. Dans l'exemple illustré, la base de données d'historique est également distribuée entre des dispositifs du réseau 100. Dans une variante non illustrée, elle pourrait, comme pour la base de données d'évènements, être contenue dans un seul dispositif. Chaque dispositif 1021...1025 comprend en outre un module d'analyse événementielle 1261...1265. Le module d'analyse événementielle 1261...1265 comprend des moyens de consultation de base de données d'évènements 1281...1285 conçus pour consulter la base de données d'évènements 1161...1163, et des moyens d'analyse d'évènement 1301...1305 conçus pour analyser une ou plusieurs données d'évènements consultées, afin d'obtenir un résultat d'analyse d'évènement. En outre, de préférence, les moyens de consultation 1281...1285 sont conçus pour consulter au moins une autre base de données 129 d'évènements dits contextuels, que la base de données d'évènements 1161...1165 renseignée par les dispositifs du réseau 100. Cette autre base de données 129 est par exemple : une base de données de malware et/ou d'alertes de sécurité, une base de données dite EIR (de « Equipment Identity Register ») comprenant des informations de sécurité relatives à des téléphones mobiles, une base de données de météo, etc. Ainsi, de préférence, les moyens d'analyse 1301...1305 sont en outre conçus pour analyser une ou plusieurs données de l'autre base de données 129 et tenir compte de cette analyse dans le résultat d'analyse d'évènement. Le module d'analyse événementielle 1261...1265 comprend en outre des moyens de consultation de base de données d'historique 1321...1325 conçus pour consulter la base de données d'historique 1241...1245i et des moyens d'analyse de compte-rendu d'action 1341...1345 pour analyser un ou plusieurs comptes-rendus consultés, afin d'obtenir un résultat d'analyse d'historique. Afin de tenir compte des bases de données d'évènements 1281...1285 et 129, ainsi que de la base de données d'historique 1241...1245i le module de pilotage 1181...1185 est conçu pour prendre une décision en fonction de critères comprenant au moins le résultat d'analyse de communication, le résultat d'analyse d'évènement et le résultat d'analyse d'historique, cette décision affectant les messages sortants émis par la suite. Dans le cas du routeur 1023, les règles des moyens de pilotage 1183 sont conçues par exemple pour modifier la table de routage en fonction des critères précédents, afin de générer des messages sortants correspondant au routage de messages entrants suivant la nouvelle table de routage. Ainsi, chaque dispositif informatique 102,...1025 est apte à fonctionner en prenant en compte, non seulement les évènements qu'il détecte (au moyen du résultat d'analyse de communication), mais également les évènements détectés par d'autres dispositifs du réseau 100 (au moyen du résultat d'analyse d'évènement), ainsi que les décisions prises par d'autres dispositifs du réseau 100 (au moyen du résultat d'analyse d'historique). En référence à la figure 2, un exemple de fonctionnement des dispositifs informatiques 102,...1025 va être décrit. Les étapes 200 à 204 suivantes concernent le renseignement de la base de données d'évènements 116,...1165 par un dispositif du réseau 100, par exemple le dispositif 1022. Au cours d'une étape 200, les moyens d'analyse de communication 1102 analysent au moins une communication de message à laquelle participe le dispositif informatique 1022 et produisent en conséquence un résultat d'analyse de communication. Au cours d'une étape 202, les moyens de génération d'évènement 1123 génèrent une donnée d'évènement à partir du résultat d'analyse de communication. Au cours d'une étape 204, les moyens d'enregistrement d'évènement 1143 enregistrent la donnée d'évènement dans la base de données d'évènements 116,...1165. Les étapes 206 à 210 suivantes concernent le renseignement de la base de données d'historique, par un dispositif du réseau 100, par exemple le dispositif 1024. Cependant, ces étapes pourraient également être mises en oeuvre par le dispositif ayant renseigné la base de données d'évènements (le dispositif 1022 dans l'exemple précédent). Au cours d'une étape 206, les moyens de pilotage 1184 prennent une décision affectant les messages sortants, émis par les moyens d'émission 1084 de ce dispositif 1024. Au cours d'une étape 208, les moyens de génération de compte-rendu 1204 du dispositif 1024 génèrent un compte-rendu à partir de la décision prise. Au cours d'une étape 210, les moyens d'enregistrement de compte-rendu 1224 enregistrent le compte-rendu dans la base de données d'historique 124,...1245. Les étapes 212 à 224 suivantes concernent l'utilisation des deux bases de données pour une prise de décision améliorée, par exemple par le dispositif 1023. Au cours d'une étape 212, le dispositif 1023 participe à une communication de message. Cette communication comprend la réception d'au moins un message entrant et/ou l'émission d'au moins un message sortant par le module de communication 1043. Au cours d'une étape 214, les moyens d'analyse de communication 1103 analysent la communication pour obtenir un résultat d'analyse de communication. Au cours d'une étape 216, les moyens de consultation de base de données d'évènements 1283 consultent la base de données d'évènements 1161...1163 et y trouvent en particulier la donnée d'évènement enregistrée par le dispositif 1022. En outre, au cours de cette étape, ils consultent également la base de données 129. Au cours d'une étape 218, les moyens d'analyse d'évènement 1303 analysent la donnée d'évènement enregistrée par le dispositif 1022, ainsi qu'au moins une donnée enregistrée dans la base 129, pour obtenir un résultat d'analyse d'évènement. Au cours d'une étape 220, les moyens de consultation de la base de données d'historique 1323 consultent la base de données d'historique 1241...1245 et y trouvent en particulier le compte-rendu enregistré par le dispositif 1042. Au cours d'une étape 222, les moyens d'analyse de compte-rendu 1343 analysent le compte-rendu enregistré par le dispositif 1024, pour produire un résultat d'analyse d'historique. Au cours d'une étape 224, le module de pilotage 1183 prend une décision affectant les messages sortants émis par la suite, à partir des critères comprenant au moins le résultat d'analyse de communication de message, le résultat d'analyse d'évènement, et le résultat d'analyse d'historique. La prise de décision en fonction des critères précédents affecte les messages sortants : - pour déterminer si un message sortant doit être envoyé (cas 1), et/ou - pour générer un message sortant devant être envoyé (cas 2). Dans le premier cas, le module de pilotage 1183 détermine, en fonction des critères précédents comprenant au moins le résultat d'analyse de communication, le résultat d'analyse d'évènement et le résultat d'analyse d'historique, si un message sortant doit être envoyé. Dans le second cas, le module de pilotage génère, en fonction des critères comprenant au moins le résultat d'analyse de communication, le résultat d'analyse d'évènement et le résultat d'analyse d'historique, un message sortant, ce dernier possédant ainsi des caractéristiques choisies en fonction des critères précédents. Au cours d'une étape 226, le module de pilotage 1183 détermine si un message sortant doit être envoyé. Suivant la décision prise à l'étape 220, la détermination est faite en fonction des critères précédents ou non (par exemple dans le cas d'un message sortant automatique dont l'envoi est prédéterminé). Si un message sortant doit être envoyé, le module de pilotage 1183 génère, au cours d'une étape 228, un message sortant. Suivant la décision prise à l'étape 220, la génération est faite en fonction des critères précédents ou non. Si la génération est faite en fonction des critères précédents, le module de pilotage 1183 génère, par exemple, le message sortant en sélectionnant, en fonction des critères précédents, un protocole de communication pour une des couches protocolaires et en générant le message sortant selon le protocole de communication sélectionné. Par exemple, le protocole de communication sélectionné offre un meilleur niveau de sécurité. En variante ou en complément, le module de pilotage 1183 génère, par exemple, le message sortant en sélectionnant, en fonction des critères précédents, des paramètres d'un protocole de communication d'une des couches protocolaires et en générant le message sortant selon le protocole de communication paramétré avec les paramètres sélectionnés. Dans tous les cas, au moins l'une des étapes 222 et 224 est réalisée en fonction des critères précédents qui comprennent au moins le résultat d'analyse d'évènement et dans l'exemple décrit, au moins le résultat d'analyse de communication de message, le résultat d'analyse d'évènement et le résultat d'analyse d'historique. Au cours d'une étape 230, les moyens d'émission 1083 émettent le message sortant. On remarquera que le procédé de prise de décision mis en oeuvre par le dispositif 1023 est également mis en oeuvre par les autres dispositifs du réseau 100. Ainsi, par exemple, la prise de décision réalisée à l'étape 206 précédente peut également tenir compte du contenu des bases de données. Par ailleurs, l'invention n'est pas limitée à l'exemple de réalisation précédent. En particulier, chaque dispositif du réseau ne remplit pas obligatoirement les trois fonctions de renseignement de la base de données d'évènements, renseignement de la base de données d'historique et prise de décision améliorée à partir des bases de données précédentes. Ainsi, une partie des dispositifs pourrait ne remplir que l'une ou deux des trois fonctions précédentes, voire aucune. Par exemple, un dispositif du réseau ne pourrait être conçu que pour renseigner la base de données d'évènements, sans renseigner la base de données d'historique ni prendre de décision améliorée à partir de ces bases de données. En outre, dans l'exemple précédent, la décision améliorée est prise en fonction du résultat d'analyse d'évènement, du résultat d'analyse de communication, et du résultat d'analyse d'historique. Cependant, de manière générale, la décision améliorée est prise au moins en fonction du résultat d'analyse d'évènement. On conçoit ainsi que l'invention est basée principalement sur l'introduction de nouveaux procédés plus appropriés aux besoins technologiques du moment et des années à venir. C'est la raison pour laquelle, l'un des apports principaux de l'invention concerne l'amélioration du mode de fonctionnement actuel des réseaux de télécommunication : statique, planifié, rigide. Dans cette perspective, l'invention proposée peut être mise en oeuvre par un ou des programmes d'ordinateur et est basée sur l'organisation et le traitement dynamique et contextuel des équipements des réseaux de télécommunication en fonction : 1. des événements survenus dans le passé (vision du passé) : a. base de données dédiée afin de capitaliser les événements pertinents en fonction: i. des filtres statiques basés sur des conditions préétablies, ii. des filtres dynamiques conditionnés par des seuils, 2. des informations fonctionnelles pertinentes concernant l'état du trafic en local et en provenance d'autres composants du réseau (vision du présent) : a. module de pilotage dédié basé sur une planification : i. statique : modalités de traitement restreint et une capacité d'opération limitée quantitativement et qualitativement, ii. semi-automatique : modalités de traitement évolutives et une capacité d'opération conditionnée quantitativement et qualitativement, iii. automatique : modalités de traitement dynamique et une capacité d'opération étendue quantitativement et qualitativement, 3. des hypothèses, des prévisions et des visions à distance de l'évolution du réseau (vision du futur). Le périmètre fonctionnel de chacun des protocoles de télécommunication est borné à la fois selon l'utilité attendue et selon le contexte d'usage. Par conséquent, les événements liés au bon ou au mauvais fonctionnement des différentes couches protocolaires peuvent révéler un certain nombre d'informations sur la nature « spatio-temporelle » d'un dysfonctionnement. Dans ce contexte, les échanges inter-protocolaires permettent à chacune des couches protocolaires de se renseigner, de s'alerter mutuellement et de s'adapter (avec un degré de liberté plus ou moins optimal) aux circonstances. Par exemple, le protocole ICMP (couche 4 : transport ù du model OSI / model TCP/IP) est un bon candidat afin de mieux comprendre la nature de ce type d'échanges (http://abcdrfc.free.fr/rfc-vf/rfc792.html). Ainsi le système selon l'invention est fondé sur : o La mise en valeur des expériences : expériences vécues (passé), o La capitalisation des observations actuelles : expériences en cours (présent), o L'estimation des perspectives : expériences à vivre (futur). L'un des apports principaux de ce système est basé sur la proposition : 1. d'un nouveau mode de traitement « circulaire / sphérique » des éventements « protocolaires » des réseaux de télécommunication : a. interactions inter-protocolaires : entre les mêmes couches et les mêmes protocoles, b. interactions intra-protocolaires : entre les couches et les protocoles différents, 2. d'une nouvelle manière d'enrichissement événementiel spatio-temporel : a. spatial : plus large et au-delà de l'équipement impacté, b. temporel : canalisation temps réel et temps différé des événements, 3. d'une logique décisionnelle multidimensionnelle : a. gestion locale et résolution contextuelle/planifiée des événements, b. gestion globale et résolution contextuelle/planifiée des événements, 4. des mécanismes de pilotage modulaire : a. pilotage planifié : en fonction d'un objectif/d'un usage fonctionnel prédéterminé : i. par exemple : les mécanismes de filtrage en fonction d'une politique de sécurité dédiée (choix d'un protocole en fonction de la sensibilité des informations à transporter ou à cause des vulnérabilités détectées ...), b. pilotage contextuel : en fonction d'un objectif/d'un usage fonctionnel « émergent » i. par exemple : les mécanismes de routage en fonction de la disponibilité des ressources et/ou d'une alerte critique (choix d'un mode de transport plus adapté en fonction de gravité des incidents ou des informations communiquées par d'autres équipements actifs ...), ii. au vu des paramètres contextuels et/ou combinatoires, 20 25 30 35 5 10 c. pilotage métier : en fonction d'un objectif /d'un usage spécialisé : i. par exemple : la gestion des bandes passantes (débit) des flux de trafic en fonction des critères préétablis/contraintes fonctionnelles (ex. temps réel pour les flux multimédia et temps différé pour les flux email ...), d. pilotage collectif : en fonction des objectifs fixés par la communauté i. par exemple : la gestion collective des solutions antimalware/anti-virus afin de mieux maîtriser la propagation des virus, etc (synchronisation des filtres, des bases de données des signatures des virus, ...). Ces axes de développement peuvent être mis en oeuvre et être exploités de façon locale ou de façon centralisée (ex. gestion centralisée des firewalls, des routeurs, des commutateurs, etc). 15 REVENDICATIONS1. Procédé de fonctionnement d'un dispositif informatique (1021 ; ... ; 1025) d'un réseau informatique (100), caractérisé en ce que le dispositif informatique : - consulte (216) une base de données d'évènements (1281...1285) comprenant une donnée d'évènement : + générée (202) par un autre dispositif informatique (1021 ; ... ; 1025) du réseau informatique (100) à partir d'au moins une communication de message à laquelle participe cet autre dispositif informatique, et + enregistrée (204) par l'autre dispositif informatique (1021 ; ... ; 1025) dans la base de données d'évènements (1281...1285), - analyse (218) la donnée d'évènement pour obtenir un résultat d'analyse d'évènement, - détermine (226) si un message sortant doit être envoyé, - si un message sortant doit être envoyé : + génère (228) le message sortant, et + émet (230) le message sortant, et en ce qu'au moins une étape parmi : - la détermination (226) si un message sortant doit être envoyé, et - la génération (230) du message sortant, est réalisée en fonction de critères comprenant au moins le résultat d'analyse d'évènement. 2. Procédé selon la revendication 1, dans lequel le dispositif informatique est conforme à un modèle d'architecture en couches protocolaires et dans lequel le dispositif informatique génère (228) le message sortant en : - sélectionnant, en fonction des critères, un protocole de communication pour une des couches protocolaires et, en - générant le message sortant selon le protocole de communication sélectionné. 3. Procédé selon la revendication 1 ou 2, dans lequel le dispositif informatique est conforme à un modèle d'architecture en couches protocolaires et dans lequel le dispositif informatique génère (228) le message sortant en : - sélectionnant, en fonction des critères, des paramètres d'un protocole de communication d'une des couches protocolaires et, en- générant le message sortant selon le protocole de communication paramétré avec les paramètres sélectionnés. 4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel le dispositif informatique - participe (212) à une communication de message et - analyse (214) la communication de message pour obtenir un résultat d'analyse de communication de message, et dans lequel les critères comprennent le résultat d'analyse de communication de message. 5. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel le dispositif informatique - consulte (220) une base de données d'historique d'actions comprenant un compte rendu d'action + généré (208) par un autre dispositif informatique du réseau informatique à partir d'une action affectant l'envoi de messages sortant par cet autre dispositif informatique et + enregistré (210) dans la base de données d'historique d'actions par l'autre dispositif informatique et - analyse (222) la donnée d'action pour obtenir un résultat d'analyse d'action, et dans lequel les critères comprennent le résultat d'analyse d'action. 6. Programme d'ordinateur caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 5, lorsque ledit programme d'ordinateur est exécuté sur un ordinateur. 7. Dispositif informatique (1021 ; ... ; 1025) d'un réseau informatique (100), caractérisé en ce qu'il comprend : - des moyens (1281 ; ... ; 1283) pour consulter une base de données d'évènements (128,...1285) comprenant une donnée d'évènement : + générée par un autre dispositif informatique du réseau 35 informatique à partir d'au moins une communication de message avec cet autre dispositif informatique et 30+ enregistrée par l'autre dispositif informatique dans la base de données d'évènements, - des moyens (1301 ; ... ; 1303) pour analyser la donnée d'évènement pour obtenir un résultat d'analyse d'évènement, - un module de pilotage (1181 ; ... ; 1185) pour déterminer si un message sortant doit être envoyé et, si un message sortant doit être envoyé, pour générer un message sortant et - des moyens (1081 ; ... ; 1085) pour émettre le message sortant, et en ce que le module de pilotage est conçu pour tenir compte de critères comprenant au moins le résultat d'analyse d'évènement, pour réaliser au moins l'une des fonctions parmi : - la détermination si un message sortant doit être envoyé et - la génération du message sortant. 8. Réseau informatique, caractérisé en ce qu'il comprend une pluralité de dispositifs informatiques selon la revendication 7.