Brevet FR3141777A1 — publié le 20240510

L’invention concerne un procédé (100) de détection de risque de défaut de périphérique informatique, dans lequel des moyens de calcul informatique mettent en œuvre les étapes suivantes : - obtention (120) de données relatives à un état courant d’un périphérique informatique ; - filtrage (130) des données obtenues de manière à ne retenir que certaines de ces données, ces données retenues formant des données filtrées ; - application (140) aux données filtrées d’un algorithme immunitaire artificiel à sélection négative, de manière à distinguer des données formant un profil de défaut vis-à-vis de données formant un profil de fonctionnement normal ; - application (150) aux données formant le profil de défaut d’un algorithme à forêts aléatoires, de manière à détecter un ou des composants à risque de défaut au sein du périphérique informatique. Figure pour l’abrégé : figure 3 Maintenance préventive de périphérique informatique L’invention concerne la maintenance des périphériques informatiques. Elle concerne en particulier la maintenance de terminaux de paiements. L’exploitation d’un terminal de paiement situé chez un professionnel, tel un commerçant, est parfois suspendue du fait de dysfonctionnements du terminal. Il est alors nécessaire de réaliser une opération de maintenance sur le terminal, soit manuellement par l’envoi d’un opérateur sur place, soit à distance par le biais d’un serveur de gestion de terminaux de paiements permettant de transmettre des modifications logicielles au terminal. Cependant, ces opérations de maintenance correctives sont coûteuses et le temps d’indisponibilité du terminal gênant pour les usagers. On connaît dans l’état de la technique un procédé de maintenance prédictive visant à anticiper un dysfonctionnement d’un terminal. Il consiste à alerter le serveur, et éventuellement un opérateur, dès qu’un seuil prédéterminé, correspondant en particulier à un nombre de cycles d’opérations du terminal, est atteint. Ainsi, l’alerte envoyée permet par l’envoi d’un opérateur, ou par le biais du serveur, d’effectuer une opération de maintenance visant à prévenir un dysfonctionnement, de manière à éviter une indisponibilité éventuelle du terminal. Cependant, les seuls d’alerte fixés sont arbitraires, limités à certains paramètres, indépendant les uns des autres, généralisés à tous les terminaux, de sorte que des alertes sont soulevées pour des terminaux qui pourraient pourtant continuer à fonctionner normalement, quand d’autres alertes ne sont pas soulevées pour des terminaux qui tombent finalement en panne. En outre, le grand nombre de variables et de paramètres des terminaux rend difficile la fixation prédéterminée de seuils pertinents permettant de prévenir un dysfonctionnement à temps et de manière appropriée. La maintenance d’un terminal est donc parfois inutile, parfois insuffisante, et ainsi toujours coûteuse et gênante. L'invention a notamment pour but d’optimiser la maintenance de périphérique informatique. Elle a également pour but de parvenir à anticiper un dysfonctionnement de manière optimale malgré un grand nombre de données à traiter. A cet effet l’invention a pour objet un procédé de détection de risque de défaut de périphérique informatique, dans lequel des moyens de calcul informatique mettent en œuvre les étapes suivantes : - obtention de données relatives à un état courant d’un périphérique informatique ; - filtrage des données obtenues de manière à ne retenir que certaines de ces données, ces données retenues formant des données filtrées ; - application aux données filtrées d’un algorithme immunitaire artificiel à sélection négative, de manière à distinguer des données formant un profil de défaut vis-à-vis de données formant un profil de fonctionnement normal ; - application aux données formant le profil de défaut d’un algorithme à forêts aléatoires, de manière à détecter un ou des composants à risque de défaut au sein du périphérique informatique. Ainsi, le filtrage permet de trier le grand nombre de données reçues pour n’en retenir que certaines à traiter afin d’identifier aux étapes suivantes un éventuel défaut à venir d’un périphérique. En diminuant, via le filtrage, le nombre de données à traiter par les algorithmes à sélection négative et à forêts aléatoires, on rend le procédé rapide, et apte à être intégré sur un dispositif autonome, tel qu’un serveur de gestion de terminaux de paiement. L’algorithme immunitaire à sélection négative permet d’identifier, parmi les données filtrées, celles qui forment des données associées à un périphérique en état normal de fonctionnement, pour les rejeter. Ainsi, seules les données associées à un périphérique qui n’est pas en état normal de fonctionnement, ou qui risque de ne plus l’être prochainement, sont transmises à l’étape suivante. Enfin, l’algorithme à forêts aléatoires, ou à forêts d’arbres décisionnels, permet d’identifier, grâce aux données associées à un dysfonctionnement actuel ou futur d’un périphérique, les composants du périphérique responsables de ce dysfonctionnement. Ainsi, le procédé permet de traiter l’ensemble des données provenant du périphérique pour identifier s’il est à risque, et, le cas échéant, quels sont ses composants responsables du risque de dysfonctionnement. L’invention permet donc une maintenance préventive et optimisée, soulevant des alertes uniquement dans des cas appropriés, de façon à éviter toute opération de maintenance inutile. L’invention permet également le traitement d’un grand nombre de données de manière rapide. Avantageusement, les moyens de calcul informatique mettent en œuvre les étapes suivantes : - identification, lors de l’étape d’application de l’algorithme immunitaire, de types de données permettant la distinction entre le profil de défaut et le profil de fonctionnement normal ; - identification, lors de l’étape d’application de l’algorithme à forêts aléatoires, de types de données permettant la détection de la ou des caractéristiques en défaut ; - les types de données identifiés lors des deux étapes d’identification formant des types de données à filtrer, intégration à l’étape de filtrage des types de données à filtrer, de manière à ce que, lors d’une réitération du procédé, l’étape de filtrage soit réalisée sur la base des types de données à filtrer. Ainsi, le procédé inclut une boucle d’autorégulation. Cette boucle vise à identifier les données à filtrer lors de l’étape de filtrage sur la base des étapes qui lui succèdent. Ainsi, dans un mode de mise œuvre, à chaque itération du procédé, des types de données sont identifiés à la sortie de l’algorithme immunitaire à sélection négative, ceux permettant d’identifier un périphérique en état de dysfonctionnement actuel ou futur. En particulier, les paramètres, c’est-à-dire les noms des variables du périphérique auxquels se réfèrent ces données peuvent être identifiés comme des types correspondant à des données à traiter à l’itération suivante. De même, à la sortie de l’étape de l’algorithme à forêts aléatoires, les données ayant permis d’identifier des composants à risque du périphérique sont retenus comme faisant partie de types de données à filtrer. Dès lors, lorsque le procédé est exécuté de nouveau, à l’étape de filtrage, les moyens de calcul conservent les données provenant du périphérique qui sont associés aux types de données filtrées, en particulier les données associées aux paramètres ayant été jugés importants à considérer lors des itérations précédentes. Les autres données sont-elles non traitées par les étapes suivantes. Dans un mode de mise en œuvre alternatif, plutôt que de retenir certains types de données à traiter aux itérations suivantes, les moyens de calcul procèdent de manière inverse : ils identifient les types de données à ne pas considérer lors du filtrage, celles qui ne se sont pas avérées utiles, pour ne traiter uniquement, lors de l’itération suivante, que les données pertinentes. En résumé, dans les deux modes de mise en œuvre et dans toute combinaison de ces de modes, les moyens de calcul informatique identifient, en sortie d’algorithme immunitaire et en sortie d’algorithme à forêts aléatoires, des types de données à filtrer à l’étape de filtrage pour les prochaines itérations du procédé. Cette autorégulation permet d’améliorer constamment la précision du procédé, tout en diminuant le nombre de données à traiter. De préférence, au préalable, les types de données à filtrer étant inexistant, les moyens de calcul informatique mettent en œuvre, sur une base de données d’apprentissage, une étape d’entraînement relative au filtrage, de manière à identifier des premiers types de données à filtrer. Ainsi, on entraine les moyens de calcul à identifier de premiers types de données à filtrer pour éviter aux algorithmes à sélection négative et à forêts aléatoires d’avoir à traiter un trop grand nombre de données lors des premières itérations du procédé. Avantageusement, au préalable, les moyens de calcul informatique mettent en œuvre, sur une base de données d’apprentissage, une étape d’entraînement de l’algorithme immunitaire artificiel à sélection négative, de manière à former des détecteurs de profils de défaut de périphériques informatiques. Ainsi, on entraine l’algorithme à sélection négative au préalable, de manière à lui faire créer des détecteurs de profil de défaut pertinents avant que ces détecteurs ne soient appliqués à des données de périphériques en conditions réelles. De préférence, une distance d’affinité relative aux détecteurs de profils de défauts est une distance de Jaro-Winker. Avantageusement, au préalable, les moyens de calcul informatique mettent en œuvre, sur une base de données d’apprentissage, une étape d’entraînement de l’algorithme à forêts aléatoires, de manière à apprendre à détecter des caractéristiques en défauts de périphériques informatiques. Ainsi, on entraîne au préalable l’algorithme à forêts aléatoires à identifier les composants responsables d’un dysfonctionnement actuel ou futur d’un périphérique, avant d’appliquer cet algorithme aux données de périphériques en conditions réelles. De préférence, le périphérique est un terminal de paiement. Ainsi, les moyens de calcul obtiennent des données du terminal, relatives à l’ensemble des paramètres du terminal, de manière à en déduire si ce terminal risque de dysfonctionner prochainement, et, le cas échéant, quels sont les composants responsables de ce risque. Les moyens permettent alors d’effectuer une maintenance préventive du terminal. Avantageusement, les données du terminal de paiement obtenues sont relatives à : - un compteur de touches pressées du terminal ; - un nombre de rechargement de système d’exploitation du terminal ; - un nombre de redémarrage du terminal ; - un numéro de version d’un logiciel du terminal ; - un type de connexion Internet du terminal ; - un état d’une connexion Internet du terminal ; - un type de connectique du terminal ; - un état d’une connectique du terminal ; - un code constructeur du terminal ; - un type de matériel informatique intégré dans le terminal. On prévoit également selon l’invention un procédé de maintenance de périphérique informatique, dans lequel des moyens de calcul informatique mettent en œuvre les étapes suivantes : - mise en œuvre du procédé de détection de risque de défaut, d’un périphérique informatique, tel que décrit précédemment ; - en fonction du défaut détecté, identification d’une correction à effectuer relative à une configuration logicielle du périphérique. Ainsi, les moyens identifient une action à effectuer, par exemple un changement de configuration logicielle, pour prévenir un dysfonctionnement du terminal. L’action identifiée est directement issue du procédé d’identification de risque de défaut, elle est liée aux composants identifiés. De préférence, les moyens de calcul informatique mettent en outre en œuvre une étape de correction automatique du périphérique en appliquant la correction identifiée sur le périphérique. Ainsi, la correction identifiée est opérée de manière automatique, sans qu’une intervention manuelle soit nécessaire. On prévoit également selon l’invention un serveur de maintenance comprenant des moyens de calcul informatique aptes à mettre en œuvre les étapes des procédés décrits précédemment. On prévoit également selon l’invention un système de paiement comprenant un serveur de maintenance tel que décrit plus haut et au moins un terminal de paiement, le terminal de paiement étant apte à transmettre au serveur des données relatives à un état courant du terminal. On prévoit également selon l’invention un programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes des procédés décrits précédemment. On prévoit également selon l’invention un support d'enregistrement lisible par ordinateur comprenant des instructions qui, lorsqu'elles sont exécutées par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes des procédés décrits précédemment. Brève description des figures L'invention sera mieux comprise à la lecture de la description qui va suivre donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés dans lesquels : la est un schéma d’un système comprenant un serveur selon un mode de réalisation de l’invention ; la est un schéma d’un module autonome du serveur de la ; la est un logigramme d’un procédé d’identification de risque de défaut de périphérique selon un mode de mise en œuvre de l’invention ; la est un logigramme d’un procédé de maintenance selon un mode de mise en œuvre de l’invention ; la est un logigramme d’un procédé d’initialisation selon un mode de mise en œuvre de l’invention. Description détaillée La illustre schématiquement un serveur de gestion de terminaux de paiements 10 et un terminal de paiement 5. Le serveur 10 comprend des moyens de calcul informatique conventionnels 11, incluant une mémoire dure, une mémoire vive, un processeur. Ce serveur 10 comprend également, sous forme exécutable et enregistrée, un programme d’ordinateur 12 mettant en œuvre, lorsqu’il est exécuté par les moyens 11, les procédés 100 à 300 décrits plus bas. Ce serveur se divise, sur le plan logiciel, entre un module de supervision 1, un module autonome 2, un module d’ordonnancement 3 et un module d’affectation 4. Ces modules font appels aux mêmes moyens de calcul 11 et au même programme d’ordinateur 12. Alternativement, il pourrait s’agir de programmes d’ordinateur distincts opérant sur le même serveur 10. Alternativement encore, il pourrait s’agir de programmes distincts opérants sur des dispositifs distincts munis de leurs propres moyens de calcul informatique. Ces agencements ne changent rien aux procédés décrits plus bas. Le module 11 de supervision a pour rôle de recevoir des informations de la part de terminaux de paiements à superviser, en particulier du terminal 5. Ces informations comprennent l’ensemble des données émises par le terminal 5, relative à l’état courant du terminal 5, dont certaines seront mentionnées plus bas. Le module autonome 2 a pour rôle de réaliser le procédé 100 d’identification de risque de défaut du terminal 5 décrit plus bas. Il reçoit de la part du module de supervision 1 les données du terminal 5, et en déduit si le terminal 5 est en risque de défaut, le cas échéant quels sont ses composants responsables du risque de dysfonctionnement. Le module 3 d’ordonnancement a pour rôle, à partir de données reçues du module 1 de supervision et du module 2 autonome, de décider d’actions possibles à envisager pour le terminal 5, si celui-ci comporte un risque de dysfonctionnement. Le module 4 d’affectation a pour rôle de transmettre les décisions d’action, en particulier les changements de configuration décidés, au terminal de paiement 5. Le terminal de paiement 5 est un terminal de paiement conventionnel, comprenant des moyens de calcul informatique conventionnels 51 configurés pour faire fonctionner le terminal. Ces moyens 51 sont aptes à transmettre régulièrement les données du terminal 5 au serveur 10, et en particulier à son module de supervision 1. Ils sont également aptes à recevoir des ordres de modifications logicielles depuis le module d’affectation 4. On va maintenant s’intéresser au module autonome 2, en référence à la . Il peut être divisé sur le plan logiciel en trois sous-modules : un sous-module de filtrage 21, un sous-module d’optimisation 22, et un sous-module de décision 23. Les données du terminal 5, fournies par le module de supervision 1, ont vocation à circuler depuis le sous-module 21 jusqu’à la sortie du sous-module 23, les données de sortie étant alors transmise au module d’ordonnancement 3. Cependant, se trouve aussi au sein du module autonome 2 une boucle d’autorégulation, illustrée par les flèches 24 et 25, entre les sous-modules 21, 22 et 23. Ainsi, comme décrit plus bas, le sous-module d’optimisation 22 est apte à identifier, lors du traitement de données, des types de données à filtrer. Le sous-module de décision 23 est apte à faire de même, l’ensemble de ces types de données à filtrer étant transmis au module 21, par les renvois 24 et 25 en vue de l’amélioration continue du filtrage. On va maintenant décrire, en référence aux figures 2 et 3, un procédé 100 de détection de risque de défaut dans le terminal 5. A l’étape 110, le terminal 5 envoie, par le biais de ses moyens 51, des données relatives à l’état du terminal au module de supervision 1 du serveur 10. A l’étape 120, le module de supervision 1 transmet ces données au module autonome 2, plus concrètement au sous-module de filtrage 21. Un extrait de l’ensemble des données obtenues par ce sous-module de filtrage pour plusieurs terminaux de paiement est le tableau suivant. Les types des données des terminaux sont écrits dans la première colonne de gauche. Un type de donnée est donc le nom d’une variable, tandis qu’une donnée est la valeur de cette variable, dans les autres colonnes. Seuls certains des types de données sont dans cet extrait, les types de données réels à traiter par le sous-module de filtrage 21 étant plus nombreux. Les données correspondantes à chacun de ces types, issues du terminal 5, donc relatives à l’état du terminal 5, sont celles de la deuxième colonne de gauche. Les autres colonnes sont relatives à des données relatives à l’état d’autres terminaux. En effet, le sous-module 21 de filtrage reçoit des données issues d’un grand nombre de terminaux de paiements différents. Ces données sont relatives, notamment, à un compteur de touches pressées du terminal, un nombre de rechargement de système d’exploitation du terminal (type de donnée « OS COUNTER » dans l’extrait), un nombre de redémarrage du terminal 5, un numéro de version d’un logiciel du terminal (ligne « protocolVersion »), un type de connexion Internet du terminal (ligne « Wifi »), un état d’une connexion Internet du terminal, un type de connectique du terminal (ligne « USBD type »), un état d’une connectique du terminal, un code constructeur du terminal (ligne « productCode »), un type de matériel informatique intégré dans le terminal (ligne « TECHNOLOGY »). De manière générale, toutes les données relatives à des états, statiques ou dynamiques, d’un terminal de paiement, sont susceptibles d’être envoyées au sous-module de filtrage 21. A l’étape 130, le sous-module de filtrage 21 filtre ces données par type de données. Ainsi, il ne retient que certains types de données de la colonne de gauche. Ce tableau de données filtrées est le suivant. Toutes les données de ce tableau étaient incluses dans les données reçues initialement (toutes n’étaient pas illustrées dans l’extrait), mais seules les données de ce deuxième tableau sont envoyées par ce sous-module 21 de filtrage au sous-module d’optimisation 22. Là encore, la deuxième colonne de gauche représente les données issues du terminal 5. On reviendra plus bas sur les types de données à filtrer qui sont identifiés lors de ce procédé. A l’étape 140, le sous-module d’optimisation 22 met en œuvre un algorithme immunitaire artificiel à sélection négative sur les données filtrées du terminal 5 reçues depuis le sous-module de filtrage 21. Le but de cet algorithme est d’identifier si cet ensemble de données correspond à un profil de panne, ou dysfonctionnement, actuel ou futur, du terminal 5, cette identification se faisant au moyen de détecteur de profils de défaut générés au préalable par apprentissage. Si aucun des détecteurs opérés par cet algorithme de profil de défaut n’identifie un profil de défaut, cela signifie qu’il n’est pas nécessaire d’opérer une correction sur le terminal 5, et le procédé passe directement à l’étape 160. En revanche, si un détecteur de profil de défaut issu de cet algorithme identifie l’ensemble de données comme correspondant à un défaut, actuel ou futur, alors cet ensemble de données est transmis au sous-module 23 d’optimisation. Dans la suite, on considèrera que l’on dans ce trouve dans ce dernier cas. La manière dont les détecteurs de défauts sont générés serait décrite plus bas. A l’étape 145, ce sous-module d’optimisation 22 envoie au sous-module de filtrage 21, par la boucle de retour 24, des types de données à filtrer qui ont été identifiés lors de cette étape de sélection négative. Ils s’agit des noms des variables utilisées ayant permis d’identifier que le terminal 5 présentait un profil de défaut. Alternativement, le sous-module pourrait envoyer les autres types de données, par exemple les noms de variable qui se sont avérées inutiles. A l’étape 150, le sous-module de décision 23 met en œuvre un algorithme à forêts aléatoires sur l’ensemble de données du terminal 5 transmis par le sous-module d’optimisation 22. Cet algorithme permet d’identifier quel est le ou quels sont les composants du terminal 5 responsables du défaut identifié par le sous-module d’optimisation 22. Cette identification du ou des composants se fait grâce à l’entrainement préalable de cet algorithme à forêts aléatoires sur une base d’apprentissage. A l’issue de cette étape, dite décisionnelle, on dispose de l’identification de caractéristiques considérées comme en défaut ou en risque de défaut, relatives aux composants du terminal 5. On peut donc soulever une alerte pour corriger ces caractéristiques afin de prévenir une panne ou l’aggravement d’une panne courante du terminal 5. A l’étape 155, ce sous-module de décision 23 renvoie au module de filtrage 21 des types de données à filtrer. Ils correspondant aux noms des variables ayant permis de caractériser un ou plusieurs composants du terminal comme étant en défaut ou en risque de défaut. Alternativement, ils peuvent correspondre aux noms des autres variables, celles s’étant avérées inutiles. On va maintenant revenir sur la boucle d’autorégulation formée par les renvois ou boucles de retour 24 et 25 depuis les sous-modules respectifs 22 et 23, jusqu’au-module de filtrage 21. En effet, à chaque itération du procédé 100, pour le terminal 5 mais aussi pour les autres terminaux, des types de données à filtrer sont envoyés aux étapes 145 et 155 au sous-module de filtrage 21. Ces types de données sont stockés par le sous-module 21 en vue d’être utilisés à la prochaine itération du procédé. Il peut être décidé que seuls les types de données les plus renvoyés, et non tous, seront considérés comme des types de donnée « à filtrer » par ce sous-module 21. Alternativement, il peut s’agir des types renvoyés un certain nombre de fois proportionnellement à d’autres, ou ayant atteint un nombre prédéterminé de données renvoyées correspondantes. Grâce à cette boucle d’autorégulation, les moyens de calcul 11 améliorent le procédé 100 itération après itération. En effet, les données à filtrer deviennent de plus en plus pertinentes et de moins en moins nombreuses, ce qui rend les étapes suivantes plus rapides et justes. On va maintenant décrire un procédé 200 de maintenance du terminal 5, en référence à la . L’étape 210 de ce procédé correspond aux étapes 110 à 155 du procédé 100 d’identification de défaut du terminal 5. Ainsi, à la fin de l’étape 210, une ou plusieurs caractéristiques du terminal 5 sont identifiés comme dysfonctionnelles. A l’étape 220, la décision de l’algorithme à forêts aléatoire, qui correspond à un ou plusieurs caractéristiques du terminal en défaut ou en risque de défaut, est envoyée au module d’ordonnancement 3. Ce module en déduit automatiquement une correction à effectuer sur le terminal 5, et envoie cette correction choisie au module d’ordonnancement 4. La correction à choisir a été configurée, manuellement, au préalable, en fonction des caractéristiques de défaut identifiées. Alternativement, des moyens de calcul ont été entraînés, par apprentissage sur une base d’apprentissage, à déduire une correction adéquate en fonction du ou des défauts identifiés. A l’étape 230, le module d’ordonnancement 4 réalise à distance la correction à effectuer sur le terminal 5. On va maintenant décrire un procédé initialisation 300 du module 2 avant son implémentation dans le serveur 1, en référence à la . Avant mise en œuvre du procédé 100 et donc avant la première mise en œuvre de la boucle d’autorégulation, le sous-module de filtrage 21 n’inclut aucun types de données à filtrer. C’est pourquoi, à l’étape 70, on entraîne le sous-module 21, en relation avec les moyens 11, à identifier les types de données à filtrer en vue de l’étape 130 du procédé 100 de détection de risque de défaut. Pour cela, on soumet aux moyens 11 une base de données d’apprentissage, de manière à ce que les moyens 11 y identifient les types de données à filtrer. Ces types correspondent à des données considérées comme utiles pour les étapes suivantes du procédé. En particulier, il s’agit des noms des variables, de la première colonne de gauche des tableaux montrés plus haut, ayant un impact sur la détection d’un risque de défaut dans l’algorithme immunitaire, ou sur la décision choisie dans l’algorithme à forêts aléatoires. En d’autres termes, ces types de données à filtrer sont les types de données utiles aux déterminations à effectuer par la suite par le module autonome. Une fois ces types de donnés à filtrer identifiés, ils sont implémentés dans le sous-module 21 de filtrage avant la première itération du procédé de détection de risque de défaut 100 sur des données réelles, dont celles du terminal 5. Ainsi, grâce à cette étape 70, lors de la première itération du procédé 100, le sous-module de filtrage 21 inclut déjà des types de données à filtrer à l’étape 130. A l’étape 80, on entraîne l’algorithme immunitaire artificiel à sélection négative sur une base de données d’apprentissage, de manière à ce qu’il forme un ou plusieurs détecteurs de profil de défaut. La distance choisie dans cet algorithme, permettant de définir les seuils d’affinité des détecteurs de profil de défaut, est celle de Jaro-Winkler. Alternativement, on pourrait choisir une distance euclidienne. Ces détecteurs de profil de défaut visent à identifier des ensembles de données, chaque ensemble correspondant à un terminal, qui correspondent à un ou plusieurs dysfonctionnements actuels ou à venir du terminal. Une fois les profils de défaut générés par l’apprentissage, ils sont implémentés dans le sous-module d’optimisation 22, avant la première itération du procédé de détection de risque de défaut 100 sur des données réelles, dont celles du terminal 5. Ces détecteurs de profils détecteront alors les défauts des terminaux. A l’étape 90, on entraîne l’algorithme à forêts aléatoires sur une base de données d’apprentissage. De cette manière, on entraine l’algorithme à identifier, à partir d’un ensemble de données correspondant à un défaut actuel ou futur du terminal, le ou les caractéristiques du terminal en défaut. Ces étapes d’apprentissage, ou d’initiation, 70 à 90, peuvent être mises en œuvre séparément, sur des bases d’apprentissage distinctes, ou conjointement sur une même base d’apprentissage. Une fois réalisées, le procédé 100 peut être mis en œuvre au moyen des types de données à filtrer identifiées à l’étape 70, des détecteurs de profils de défaut générés à l’étape 80, et des arbres décisionnels générés à l’étape 90. L'invention n'est pas limitée aux modes de réalisation présentés et d'autres modes de réalisation apparaîtront clairement à l'homme du métier. Procédé (100) de détection de risque de défaut de périphérique informatique (5), dans lequel des moyens (11) de calcul informatique mettent en œuvre les étapes suivantes : - obtention (120) de données relatives à un état courant d’un périphérique informatique (5) ; - filtrage (130) des données obtenues de manière à ne retenir que certaines de ces données, ces données retenues formant des données filtrées ; - application (140) aux données filtrées d’un algorithme immunitaire artificiel à sélection négative, de manière à distinguer des données formant un profil de défaut vis-à-vis de données formant un profil de fonctionnement normal ; - application (150) aux données formant le profil de défaut d’un algorithme à forêts aléatoires, de manière à détecter un ou des composants à risque de défaut au sein du périphérique informatique (5). Procédé (100) selon la revendication précédente, dans lequel les moyens (11) de calcul informatique mettent en œuvre les étapes suivantes : - identification (145), lors de l’étape (140) d’application de l’algorithme immunitaire, de types de données permettant la distinction entre le profil de défaut et le profil de fonctionnement normal ; - identification (155), lors de l’étape d’application (150) de l’algorithme à forêts aléatoires, de types de données permettant la détection de la ou des caractéristiques en défaut ; - les types de données identifiés lors des deux étapes d’identification formant des types de données à filtrer, intégration (145, 155) à l’étape de filtrage des types de données à filtrer, de manière à ce que, lors d’une réitération du procédé (100), l’étape de filtrage (130) soit réalisée sur la base des types de données à filtrer. Procédé (100) selon la revendication précédente, dans lequel, au préalable, les types de données à filtrer étant inexistant, les moyens de calcul informatique mettent en œuvre, sur une base de données d’apprentissage, une étape d’entraînement (70) relative au filtrage, de manière à identifier des premiers types de données à filtrer. Procédé (100) selon l’une quelconque des revendications précédentes, dans lequel, au préalable, les moyens de calcul informatique mettent en œuvre, sur une base de données d’apprentissage, une étape (80) d’entraînement de l’algorithme immunitaire artificiel à sélection négative, de manière à former des détecteurs de profils de défaut de périphériques informatiques. Procédé (100) selon la revendication précédente, dans lequel une distance d’affinité relative aux détecteurs de profils de défauts est une distance de Jaro-Winker. Procédé (100) selon l’une quelconque des revendications précédentes, dans lequel, au préalable, les moyens de calcul informatique mettent en œuvre, sur une base de données d’apprentissage, une étape (90) d’entraînement de l’algorithme à forêts aléatoires, de manière à apprendre à détecter des caractéristiques en défauts de périphériques informatiques. Procédé (100) selon l’une quelconque des revendications précédentes, dans lequel le périphérique est un terminal de paiement (5). Procédé selon la revendication précédente, dans lequel les données du terminal (5) de paiement obtenues sont relatives à : - un compteur de touches pressées du terminal ; - un nombre de rechargement de système d’exploitation du terminal ; - un nombre de redémarrage du terminal ; - un numéro de version d’un logiciel du terminal ; - un type de connexion Internet du terminal ; - un état d’une connexion Internet du terminal ; - un type de connectique du terminal ; - un état d’une connectique du terminal ; - un code constructeur du terminal ; - un type de matériel informatique intégré dans le terminal. Procédé (200) de maintenance de périphérique informatique, dans lequel des moyens de calcul informatique mettent en œuvre les étapes suivantes : - mise en œuvre du procédé (100) de détection de risque de défaut, d’un périphérique informatique (5), selon l’une quelconque des revendications précédentes ; - en fonction du défaut détecté, identification d’une correction (220) à effectuer relative à une configuration logicielle du périphérique (5). Procédé (200) selon la revendication précédente, dans lequel les moyens de calcul informatique (11) mettent en outre en œuvre une étape de correction (230) automatique du périphérique en appliquant la correction identifiée sur le périphérique (5). Serveur (10) de maintenance comprenant des moyens de calcul informatique (11) aptes à mettre en œuvre les étapes d’un procédé (100, 200) selon l’une quelconque des revendications 1 à 10. Système de paiement comprenant un serveur de maintenance (10) selon la revendication précédente et au moins un terminal (5) de paiement, le terminal de paiement (5) étant apte à transmettre au serveur des données relatives à un état courant du terminal. Programme d'ordinateur (12) comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes d’un procédé (100, 200) selon l’une quelconque des revendications 1 à 10. Support d'enregistrement lisible par ordinateur comprenant des instructions qui, lorsqu'elles sont exécutées par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes d’un procédé selon l’une quelconque des revendications 1 à 10.