FR 3083342 A1 20200103 FR 1856039 A 20180629 Définition de règle de supervision d'un système La présente invention concerne le domaine de la gestion des risques en temps réel, en particulier les systèmes de supervision permettant de détecter des signes précurseurs de perturbations pouvant affecter la continuité d'activité. Elle trouve notamment des applications dans la surveillance de réseaux informatiques, le support aux équipes SOC (Security Opération Center) par exemple dans la cyber sécurité. Par exemple, pour alerter de la surcharge d'une entité du réseau ou encore du dysfonctionnement partiel ou total d'une entité du réseau. L'invention trouve plus généralement des applications dans tout système incluant des dispositifs de détection ou de mesure, par exemple les pièces d'un bâtiment comprenant des thermomètres. Des dispositifs connus de gestion des risques en temps réel prévoient d'émettre des alertes, par exemple lorsque des seuils de température sont atteints. Les possibilités de paramétrage offertes par de tels dispositifs sont souvent réduites, le paramétrage étant principalement réalisée au moment de la programmation de la solution. De plus, le paramétrage est souvent complexe et peut nécessiter une formation supplémentaire. La présente invention vient améliorer la situation. Un premier aspect de l'invention concerne un procédé de supervision d'un système, le procédé comprend: la définition d'une règle au moyen d'une interface permettant à un utilisateur de sélectionner des paramètres parmi des ensembles de paramètres préétablis et d'afficher la règle dans un langage naturel ; l'exécution d'au moins une action relativement à au moins une cible lorsque la règle est vérifiée. Il est ainsi possible de définir efficacement et de manière plus fiable des règles complexes qui déterminent l'exécution d'actions permettant, par exemple, d'alerter de la survenance d'un incident ou de prévenir la survenance d'un incident. En effet, l'interface permet à l'utilisateur de sélectionner des paramètres parmi des ensembles de paramètres préétablis, ce qui empêche l'introduction d'erreurs dans la 2 définition de la règle. Cela permet également à l'utilisateur de définir une règle rapidement et sans faire appel à un langage de programmation. De plus, la règle définie est affichée en langage naturel ce qui permet à l'utilisateur d'effectuer un contrôle plus fiable et rapide. Par langage naturel, il est entendu un langage humain ou langage ordinaire. Plus précisément un langage intelligible par une personne non forcément experte du domaine informatique. Cela exclut tout langage formel tel qu'un langage informatique. Par « vérification de la règle », il est entendu que la règle est comparée avec le système ou plus précisément les caractéristiques des entités du système (également nommées valeur de propriété, ex. température, humidité, taux d'utilisation, etc.). Si les caractéristiques satisfont la règle, la règle est vérifiée. A une règle définie correspond au moins une action, cette action peut, par exemple, être prédéfinie. Par « système » (ou système comprenant des entités), on entend tout système dont la structure est assimilable ou apparentée à la structure d'une base de données, notamment de base de données orientée objet. Ainsi, une représentation du système et des entités qui le compose peut être stockée sur une telle base de données. Le système comprenant des entités peut également être appelé modèle métier. Selon un mode de réalisation, la définition de la règle peut comprendre l'établissement : d'une requête comportant des critères de sélection permettant de déterminer un groupe d'entités parmi les entités comprises dans le système , d'un critère relatif au groupe d'entités, le critère étant défini par une combinaison de paramètres sélectionnés et d'une valeur. Ainsi la requête permet de sélectionner, au moyen de critères de sélection (ex. salariés, bâtiments, zone géographique, etc.), un groupe d'entités (ex. salarié A, bâtiments X et Y, etc.). La vérification de la règle peut consister alors à comparer une ou plusieurs caractéristiques (ex. température, humidité, etc.) de ces entités du groupe avec le critère relatif au groupe d'entités (ex. une température supérieure à 10°C, une humidité supérieur à 83%, etc.). Selon un mode de réalisation, le procédé peut comprendre en outre une 3 vérification du critère relatif au groupe (ex. une température supérieure à 10°C, une humidité supérieur à 83%, etc.), cette vérification se base sur une source de données prédéterminée. Selon un mode de réalisation, l'au moins une action peut être une étape d'un flux de travaux. Par « flux de travaux » (i.e. workflow en anglais), on entend une suite d'actions. Ainsi plusieurs actions peuvent être exécutées selon une séquence déterminée permettant, par exemple, de prendre des mesures correctives successives lorsque la précédente mesure n'a pas été suffisante. Le flux de travaux est avantageusement un Graphe Fonctionnel de Commande des Étapes et Transitions, Grafcet, tel que normalisé (CEI 60848:2013 Février 2013) par l'Union technique de l'électricité (UTE). Selon un mode de réalisation, l'au moins une cible peut comprendre une entité du système. Selon un mode de réalisation, l'au moins une action (ex. envoyer un SMS) peut être précisée par au moins une requête comportant des critères de sélection (ex. aux employés présents dans le bâtiment A) permettant de déterminer un deuxième groupe d'entités. Cela permet de déterminer relativement à quelles entités l'action est exécutée. Selon un mode de réalisation, l'au moins une action est un envoi d'une notification. Par exemple, la notification peut être envoyée à une des entités du système. Les notifications peuvent être transmises par mail, SMS, message vocal ou application mobile. Cela permet d'avertir les entités du deuxième groupe de la survenance ou du risque de survenance d'un incident. Les notifications peuvent : - requérir un acquittement du destinataire. - requérir un acte ou une opération de la part du destinataire. - comporter des questions. -etc. 4 Selon un mode de réalisation, l'au moins une action est une émission d'une commande informatique (ex. commande de sauvegarde d'urgence vers un site distant). Un deuxième aspect de l'invention concerne un programme informatique comportant des instructions pour la mise en oeuvre des étapes du procédé selon le premier aspect de l'invention, lorsque ces instructions sont exécutées par un processeur. Un troisième aspect de l'invention concerne un dispositif adapté pour mettre en oeuvre la méthode décrite ci-avant. D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels: - La figure 1 schématise une base de données, une source de données, une entité et un ordinateur implémentant une interface selon un mode de réalisation de 1 ' inventi on. La figure 2 illustre une interface permettant la définition d'une règle, selon un mode de réalisation de l'invention. - La figure 3 est un diagramme illustrant les étapes d'un procédé selon un mode de réalisation de l'invention. - La figure 4 décrit un dispositif configuré selon un mode de réalisation de l'invention. La figure 1 schématise un ordinateur 1, une base de données 2, une source de données 3 et une cible 4. L'ordinateur permet d'implémenter une interface au moyen de laquelle l'utilisateur peut définir une règle comme cela est décrit à la figure 2. La base de données 2 permet de stocker une représentation du système et des entités qui compose le système. Les entités représentent des éléments du système, par exemple les salariés, les bureaux, les outils informatiques, les bâtiments de l'entreprise. Les entités peuvent être organisées les unes par rapport aux autres selon une organisation hiérarchique ou plus généralement par des relations. Les entités peuvent être regroupées par classe ou type, par exemple la classe des salariés. Chaque entité peut être une instance de la base de données. Les entités peuvent posséder des propriétés dont les valeurs sont stockées dans la base de données 2, par exemple la température d'une entité « salle », ou encore le taux d'utilisation d'un disque dur d'une entité « ordinateur ». La base de données 2 ainsi décrite est une base de données dans laquelle les objets sont les entités. La base de données utilisée peut être une base de données orienté objet mais également une base de données relationnelle ou encore une base de données orientée documents. La source de données 3 transmet à l'ordinateur 1 des données spécifiques. Ces données permettront à l'ordinateur 1 de mettre à jour dans la base de données 2 la valeur d'une propriété de l'entité correspondant à la source de données 3. Par exemple, les données reçues d'un capteur de température (source de données 3) d'un bureau B permettront de mettre à jour la valeur de la propriété « température » de l'entité « bureau B ». La source de données 3 peut être un capteur physique, ou plus généralement un objet connecté (dont les données spécifiques peuvent être transmises par exemple par le protocole MQTT - Message Queuing Telemetry Transport), mais également un équipement informatique (serveur, routeur - dont les données spécifiques sont transmises par exemple par le protocole SNIVIIP - Simple Network Management Protocol), un site internet (dont les données spécifiques sont transmises par exemple par le protocole HTTP - Hypertext Transfer Protocol), une autre base de données. En général, plusieurs sources de données 3 sont utilisées - par exemple un capteur 3 est utilisé pour chacune des entités (ex. salle), chaque capteur 3 ayant le même type de données transmises. La cible 4 peut être un destinataire d'une notification, par exemple un salarié ou un terminal mobile. La cible 4, peut également être le destinataire de la commande informatique. Dans les deux cas, le destinataire, c'est-à-dire la cible 4, peut être une entité du système ou un destinataire extérieur au système. L'ordinateur 1 exécute une action relativement à cette cible 4 lorsque la règle est vérifiée. 6 Les actions peuvent être l'émission d'une commande informatique ou l'envoi de notification à la cible 4. L'émission d'une commande informatique à destination de la cible 4 peut se faire par l'envoi d'un script qui peut être exécuté par ou sur la cible 4. La commande informatique peut, par exemple, commander une sauvegarde d'urgence vers un site distant. La commande informatique peut, dans un autre exemple, être le démarrage d'un second serveur et le transfert d'une partie des opérations réalisées par un premier serveur vers ce deuxième serveur afin de réduire la charge du premier serveur. L'envoi de notifications peut se faire par email, par SKIS (« Short Message Service »), par message vocal ou par une application mobile. L'envoi de notifications se fait plus généralement par toute voie de communication électronique. Les notifications peuvent requérir un acquittement du destinataire. Les notifications peuvent requérir un acte ou une opération de la part du destinataire. Les notifications peuvent comporter des questions. La définition des actions peut nécessiter des informations particulières relatives à la cible 4, ces informations sont alors stockées comme propriétés dans la base de données 2. Par exemple, lorsque l'envoi de notifications est fait par email, une adresse mail peut être stockée en tant que valeur d'une propriété « adresse mail » d'une entité du système, par exemple, la propriété « adresse mail » d'un salarié. L'ordinateur 1 peut alors faire un appel à la base de données 2 pour obtenir la valeur de la propriété « adresse mail » de la cible 4 afin d'exécuter l'action. La cible 4 peut notamment être toute entité du système disposant d'un moyen de communication électronique permettant de recevoir une notification ou une commande informatique. Dans l'exemple de la figure I, l'ordinateur 1 de l'utilisateur affiche l'interface, fait la liaison entre la source de données 3 et la base de données 2 et exécute une action lorsque la règle définie par l'utilisateur est vérifiée Il est également possible de prévoir une entité informatique distincte (par exemple un serveur) qui centralise toutes ces 7 fonctions autres que celle d'afficher l'interface et de définition de la règle. La figure 2 illustre un exemple d'interface permettant la définition d'une règle qui lorsqu'elle est vérifiée entraîne l'exécution d'une action. L'interface comporte une boîte de dialogue 30 permettant la définition de la règle et une zone d'affichage 31 permettant l'affichage de la règle définie par l'utilisateur au moyen de la boîte de dialogue 30. La boîte de dialogue 30 et la zone d'affichage 31 peuvent être affichées : - simultanément sur un écran de l'ordinateur 1 de l'utilisateur, ou - de manière séquencée, o par exemple la boîte de dialogue 30 est affichée en premier puis, une fois la règle définie (i.e. les entrées de la boîte de dialogue 30 complétées), la zone d'affichage 31 apparaît. o il est également possible de prévoir que la zone d'affichage 31 apparaisse en premier et que l'accès à la boîte de dialogue 30 se fasse suite à la sélection de la zone d'affichage 31, permettant ainsi de prévoir l'affichage de plusieurs règles simultanément et d'afficher la boîte de dialogue 30 correspondant à la règle que l'utilisateur souhaite définir ou modifier. Cet affichage de la zone 31 permet ainsi la lecture de la règle en langage naturel. La boîte de dialogue 30 peut comporter plusieurs entrées. Deux types d'entrées sont par exemple présentes dans la boîte de dialogue de la figure 2, des entrées de type menu déroulant permettant à un utilisateur de sélectionner des paramètres parmi des ensembles de paramètres préétablis et des entrées de type champ de saisie de texte. Les entrées de type menu déroulant permettent à l'utilisateur de sélectionner des paramètres parmi des ensembles de paramètres préétablis, ce qui évite d'introduire des erreurs dans la définition de la règle. Les entrées représentent chacune un élément de la règle. Ainsi, la boîte de dialogue peut comprendre : - une entrée représentant un quant ficateur 10 (ex Tous, N'importe quel, Au moins 8 un, Au moins deux, etc.), le quantificateur sélectionné dans l'exemple de la figure 2 est « N'importe quel », - une entrée représentant une opération 11 (ex : Valeur moyenne, Valeur Médiane, Valeur Maximale, Valeur actuelle), l'opération sélectionnée ici est « Valeur moyenne », - des entrées représentant une plage temporelle 12, 13, la plage temporelle sélectionnée ici est entre « Maintenant » et « 4 heures avant », - une entrée représentant une condition 14 (ex : Supérieur à, Egale à, Inférieur à), la condition sélectionnée ici est « Supérieur à ». Ces entrées sont ici représentées par des entrées de type menu déroulant. La boîte de dialogue peut également comprendre des entrées de type champ de saisie de texte, par exemple : - une entrée représentant une requête 20, la requête établie dans l'exemple de la figure 2 est « /Sites/Site avec pour nom taris'/Bâtiment/*/Etage de niveau '0' ». Une telle requête permet d'interroger la base de données 2 (stockant la représentation du système et des entités) pour obtenir l'ensemble des rez-de-chaussée des bâtiments du site de Paris. - une entrée représentant une caractéristique cible 21, la caractéristique cible établie ici est « Etage.capteur.température », c'est-à-dire la température relevée par les capteurs d'étage. La caractéristique cible correspond à une propriété d'une entité, la valeur de celle-ci est mise à jour par les données transmises par la source de données 3. - une entrée représentant une valeur 22, la valeur établie ici est « Site.maxTempAutorisee », c'est-à-dire la température maximale autorisée. La valeur 22, la condition 14, la plage temporelle 12, 13 et l'opérationl 1 constituent les paramètres qui, combinés, définissent le critère relatif au groupe d'entités. Lorsque l'utilisateur a défini la règle, c'est-à-dire a sélectionné les paramètres préétablis et a renseigné les champs de saisie de texte la règle s'affiche dans la zone d'affichage 31. La règle est alors affichée dans un langage naturel, c'est-à-dire qu'il n'est plus nécessaire de faire appel à un langage de programmation pour définir la règle. L'utilisateur peut, une fois la règle affichée dans la zone d'affichage 31, vérifier 9 s'il a correctement défini la règle. Dans l'exemple de la figure 2, les entrées ainsi renseignées et sélectionnées définissent une règle qui s'affiche en langage naturel dans la zone d'affichage 31: La température moyenne au cours des 4 dernières heures du rez-de-chaussée de n'importe quel bâtiment du site de Paris est supérieure à la valeur maximale autorisée ». Dans un autre exemple, l'utilisateur sélectionne les paramètres préétablis et renseigne les champs de saisie tel que décrit ci-dessous : - le quantificateur 10 : « Tous » ; - l'opération 11 : « Valeur actuelle » ; la condition 14 : « Supérieur à » ; la requête 20 : «/Sites/{Site dont nom est 'Bruxelles}/(Division dont nom est `Groupe devise'/WersonnePf Laptop » - la caractéristique cible 21 : « Laptop.Sondes.Taux utilisation disque dur » ; - la valeur 22 : « 90 % ». Les entrées ainsi renseignées et sélectionnées définissent une autre règle qui s'affiche en langage naturel dans la zone d'affichage 31 : « Tous les ordinateurs portables des personnes appartenant à la division «Groupe devises» au sein du site de Bruxelles ont un taux d'utilisation disque dur supérieur à 90% ». La figure 3 est un diagramme illustrant les étapes d'un procédé selon un mode de réalisation de l'invention. À l'étape Sl, le système, les entités qui le composent ainsi que les relations et/ou les hiérarchies entre les entités sont définis. Ces éléments sont alors implémentés dans la base de données 2. Les valeurs des propriétés des entités sont également ajoutées à la base de données 2. Les valeurs des propriétés peuvent être renseignées de manière statique, c'est-à-dire renseignées au moment de l'étape de paramétrage (S1) et ne pas évoluer lors de l'exécution des étapes suivantes. Les valeurs des propriétés peuvent également être renseignées de manière dynamique, c'est-à-dire renseignées au moment de l'étape de paramétrage (S1) et adaptées en fonction des données transmises par la source de données 3. Par exemple, la source de données 3 peut être un thermomètre transmettant la valeur de la température mesurée dans une pièce P avec une fréquence prédéterminée. Si la température a évolué, la valeur de la propriété température de l'entité pièce P est mise à jour. À cette étape, les sources de données 3 sont également configurées, par exemple la fréquence de la transmission de leurs données est déterminée. De plus, il est déterminé quelles propriétés sont mises à jour par les données de chaque source de données 3. Ainsi, chaque source de données est associée à au moins une entité et une propriété de cette entité. L'ordinateur 1 et plus particulièrement la boîte de dialogue 30 de l'interface est configuré, c'est-à-dire que les entrées, notamment les ensembles de paramètres préétablis sont définis afin de s'adapter au système et aux sources de données 3 implémentés. À l'étape S2, la règle est définie, par exemple au moyen de la boîte de dialogue 30 de l'interface présentée à la figure 2. L'utilisateur dans chaque entrée de type menu déroulant sélectionne le paramètre parmi les paramètres préétablis et renseigne les entrées de type champs de saisie de texte. L'affichage de la boîte de dialogue 30 peut se faire en sélectionnant la zone d'affichage 31 dans laquelle apparaîtra la règle. L'affichage de la boîte de dialogue 30 peut également se faire en sélectionnant la règle afin de la modifier lorsque la règle est prédéfi ni e. À l'étape S3, la règle est affichée dans la zone d'affichage 31. L'utilisateur peut sélectionner la zone d'affichage 31 afin de faire apparaître la boîte de dialogue 30 précédemment décrite, afin de modifier la règle. L'interface peut prévoir plusieurs zones d'affichage 31 afin que l'utilisateur puisse définir et vérifier plusieurs règles simultanément. À l'étape S4, l'utilisateur peut définir une action correspondant à la règle ou à chacune des règles si plusieurs zones d'affichage 31 sont prévues. L'action correspondant à une règle peut nécessiter des informations particulières relatives à la cible 4. Ces informations peuvent être stockées comme propriété 11 dans la base de données 2 ou bien inclus dans la définition de l'action. Par exemple, lorsque l'action consiste à envoyer une notification, par exemple une notification envoyée par email, une adresse mail est stockée comme valeur de la propriété « adresse mail » de la cible 4 lorsque celle-ci est une entité du système. L'action peut également être exécutée relativement à une cible 4 extérieure au système. Pour définir l'action lorsque les informations particulières sont stockées dans la base de données 2, une requête peut être établie pour que lorsque l'action est exécutée, la base de données 2 soit interrogée conformément à cette requête afin de renvoyer à l'ordinateur 1 la valeur de la propriété, ici adresse mail, de la cible 4 ou de chaque cible 4. L'action est alors définie par sa requête et par le contenu de la notification adressée aux cibles 4 dont l'information particulière est requêtée. De même, lorsque l'action est l'émission d'une commande informatique, l'action est définie par sa requête et par le script adressé aux cibles 4 dont l'information particulière (ex. adresse IP, etc.) est requêtée. Une même action peut être relative à plusieurs cibles 4, ainsi la requête cible les valeurs de la propriété de plusieurs entités. L'exécution de l'action entraîne alors l'émission de commande informatique ou de notification simultanément à plusieurs cibles 4. Plusieurs actions peuvent être définies pour une même règle. Chaque action est alors définie comme cela a été précédemment décrit. Les actions correspondant à une même règle sont alors organisées sous la forme d'un flux de travail (par exemple sous forme d'un Grafcet : Graphe Fonctionnel de Commande des Étapes et Transitions), c'est-à-dire qu'une séquence d'actions est définie, l'exécution de chaque action nécessitant qu'une condition soit remplie et que certaines actions précédentes aient été exécutées. Par exemple, il peut être pertinent de définir une séquence d'envoi de notifications à des cibles 4 différentes. La première notification est envoyée, en l'absence de réponse de la part de la cible 4 destinatrice de cette première notification (première condition), une deuxième notification est envoyée à une deuxième cible 4 et ainsi de suite. On a ainsi une séquence d'actions qui permet d'assurer la réception d'au moins une notification, ce qui est d'autant plus important lorsqu'il est nécessaire d'agir rapidement sur le système suite à une défaillance d'une de ses entités. 12 La définition des actions peut être prédéfinie, l'utilisateur choisit alors simplement l'action ou la séquence d'action qu'il souhaite associer avec la règle. À l'étape S5, la règle est vérifiée, c'est-à-dire que les valeurs des propriétés des entités requêtées par la règle vérifient celle-ci. Dans ce cas l'action ou la séquence d'actions associée à cette règle est exécutée. La figure 4 représente un exemple de dispositif dans un mode de réalisation de l'invention. Dans ce mode de réalisation, le dispositif 400 comprend une mémoire 405 pour stocker des instructions permettant la mise en oeuvre du procédé, les données de mesures reçues, et des données temporaires pour réaliser les différentes étapes du procédé tel que décrit précédemment. Le dispositif comporte en outre un circuit 404. Ce circuit peut être, par exemple : - un processeur apte à interpréter des instructions sous la forme de programme informatique, ou - une carte électronique dont les étapes du procédé de l'invention sont décrites dans le silicium, ou encore - une puce électronique programmable comme une puce FPGA (pour « Field-Programmable Gate Array » en anglais), comme un SOC (pour « System On Chip » en anglais) ou comme un ASIC (pour « Application Specific Integrated Circuit » an anglais). Les SOC ou système sur puce sont des systèmes embarqués qui intègrent tous les composants d'un système électronique dans une puce unique. Un ASIC est un circuit électronique spécialisé qui regroupe des fonctionnalités sur mesure pour une application donnée. Les ASIC sont généralement configurés lors de leur fabrication et ne peuvent être que simulés par l'utilisateur. Les circuits logiques programmables de type FPGA (Field-Programmable Gate Array) sont des circuits électroniques reconfigurables par l'utilisateur. 13 Ce dispositif comporte une interface d'entrée 403 par exemple pour la réception de données de mesures de capteurs, et une interface de sortie 406 pour la l'envoi des notifications ou des commandes vers la cible 4. Enfin, l'ordinateur peut comporter, pour permettre une interaction aisée avec un utilisateur, un écran 401 et un clavier 402. Bien entendu, le clavier est facultatif, notamment dans le cadre d'un ordinateur ayant la forme d'une tablette tactile, par exemple. En fonction du mode de réalisation, le dispositif 400 peut être un ordinateur, un réseau d'ordinateurs, un composant électronique, ou un autre appareil comportant un processeur couplé de manière opérationnelle à une mémoire, ainsi que, selon le mode de réalisation choisi, une unité de stockage de données, et d'autres éléments matériels associés comme une interface de réseau et un lecteur de support pour lire un support de stockage amovible et écrire sur un tel support (non représentés sur la figure). Le support de stockage amovible peut être, par exemple, un disque compact (CD), un disque vidéo/polyvalent numérique (DVD), un disque flash, une clé USB, etc. En fonction du mode de réalisation, la mémoire, l'unité de stockage de données ou le support de stockage amovible contient des instructions qui, lorsqu'elles sont exécutées par le circuit de commande 404, amènent ce circuit de commande 404 à effectuer ou contrôler les parties interface d'entrée 403, interface de sortie 406, stockage de données dans la mémoire 405 et/ou traitement de données des exemples de mise en oeuvre du procédé proposé décrits dans les présentes. Le circuit de commande 404 peut être un composant implémentant le contrôle des unités 403, 405 et 406 du dispositif 400. En outre, le dispositif 400 peut être mis en oeuvre sous forme logicielle, auquel cas il prend la forme d'un programme exécutable par un processeur, ou sous forme matérielle (ou « hardware »), comme un circuit intégré spécifique application (ASIC), un système sur puce (SOC), ou sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant électronique décrit ci-avant (ex. FPGA, processeur). Le dispositif 400 peut également utiliser des architectures hybrides, comme par exemple des architectures basées sur un CPU+FPGA, un GPU (Graphics Processing Unit) 14 ou un MPPA (Multi-Purpose Processor Array). Par ailleurs, le schéma fonctionnel présenté sur la figure 3 est un exemple typique d'un programme dont certaines instructions peuvent être réalisées auprès de l'équipement décrit. A ce titre, la figure 3 peut correspondre à l'organigramme de l'algorithme général d'un programme informatique au sens de l'invention. Bien entendu, l'invention n'est pas limitée aux modes de réalisation décrits précédemment et fournis uniquement à titre d'exemple. Elle englobe diverses modifications, formes alternatives et autres variantes que pourra envisager l'homme REVENDICATIONS1. Procédé de supervision d'un système, le procédé comprend: - la définition (S2) d'une règle au moyen d'une interface permettant à un utilisateur de sélectionner des paramètres parmi des ensembles de paramètres préétablis et d'afficher la règle dans un langage naturel ; l'exécution (S5) d'au moins une action relativement à au moins une cible lorsque la règle est vérifiée. 2. Procédé de supervision d'un système selon la revendication 1, dans lequel la définition de la règle comprend l'établissement : - d'une requête comportant des critères de sélection permettant de déterminer un groupe d'entités parmi les entités comprises dans le système , - d'un critère relatif au groupe d'entité, le critère étant défini par une combinaison de paramètres sélectionnés et d'une valeur. 3 Procédé de supervision d'un système selon la revendication 2, comprenant une vérification du critère relatif au groupe d'entités, cette vérification se base sur une source de données prédéterminées. 4. Procédé de supervision d'un système selon l'une des revendications précédentes, dans lequel l'au moins une action est une étape d'un flux de travaux. 5. Procédé de supervision d'un système selon la revendication 4, dans lequel le flux de travaux est un Graphe Fonctionnel de Commande des Étapes et Transitions, Grafcet. 6. Procédé de supervision d'un système selon l'une des revendications précédentes, dans lequel l'au moins une cible comprend une entité du système. 7. Procédé de supervision d'un système selon la revendication 6, dans lequel l'au moins une action est précisée par au moins une requête comportant des critères de 16 sélection permettant de déterminer un autre groupe d'entités parmi les entités comprises dans le système. 8. Procédé de supervision d'un système selon l'une des revendications précédentes, dans lequel l'au moins une action est un envoi d'une notification à une des entités du système. 9. Procédé de supervision d'un système selon la revendication, dans lequel la notification est envoyée par mail, SMS, message vocal ou application mobile. 10. Programme informatique comportant des instructions pour la mise en oeuvre des étapes du procédé selon l'une des revendications précédentes, lorsque ces instructions sont exécutées par un processeur. 11 Dispositif de supervision d'un système, le dispositif comprenant : un circuit (404) pour la définition (S2) d'une règle au moyen d'une interface permettant à un utilisateur de sélectionner des paramètres parmi des ensembles de paramètres préétablis et d'afficher la règle dans un langage naturel ; un circuit (404) pour l'exécution (S5) d'au moins une action relativement à au moins une cible lorsque la règle est vérifiée.