FR 3111448 A1 20211217 FR 2006509 A 20200622 Procédé d’ordonnancement de tâches dans un système de traitement, dispositif d’ordonnancement associé L’invention concerne un procédé d’ordonnancement d’au moins une tâche dans un système de traitement configuré pour exécuter ladite au moins une tâche. Ledit procédé comporte, pour un premier ensemble de tâches associé audit système, une étape de détermination de valeurs de paramètres d’exécution d’un algorithme métaheuristique configuré pour ordonnancer au moins une tâche associée audit système. Ledit procédé comporte en outre, pour au moins un deuxième ensemble de tâches associé audit système, une étape d’ordonnancement comprenant : - une exécution de l’algorithme métaheuristique paramétré par lesdites valeurs, et, si un critère d’arrêt (CR_STOP) de l’algorithme métaheuristique n’est pas atteint (E20_2), - une mise à jour dudit au moins un deuxième ensemble, par retrait d’au moins une tâche parmi ladite au moins deuxième ensemble, ladite exécution, et ladite mise à jour le cas échéant, étant itérées tant que le critère d’arrêt n’est pas atteint. Figure pour l’abrégé : Fig. 3 Procédé d’ordonnancement de tâches dans un système de traitement, dispositif d’ordonnancement associé La présente invention appartient au domaine général de l’ordonnancement de tâches, telles que par exemple des tâches informatiques, des tâches industrielles, etc. Elle concerne plus particulièrement un procédé d’ordonnancement d’au moins une tâche dans un système de traitement configuré pour exécuter ladite au moins une tâche. Elle concerne également un dispositif d’ordonnancement configuré pour mettre en œuvre un tel procédé. L’invention trouve une application particulièrement avantageuse, bien que nullement limitative, dans le cadre de l’ordonnancement d’applications de mesure de l’état d’un réseau de communication ou de la qualité d’un service supporté par ledit réseau de communication, chaque application de mesure étant par exemple intégrée à un conteneur (ou « container » en anglais). Par « système de traitement », on fait référence ici à une pluralité de processeurs pouvant être répartis entre un ou plusieurs dispositifs de traitement appartenant à un système informatique, chaque dispositif de traitement étant configuré de manière matérielle et logicielle pour exécuter une ou plusieurs tâches informatiques qui lui ont été transmises. Un tel dispositif de traitement peut correspondre par exemple à un ordinateur, serveur, routeur, et plus généralement tout équipement réseau, etc. En outre, le ou lesdits dispositifs de traitement formant le système de traitement peuvent appartenir à un ou plusieurs réseaux de communication et peuvent être regroupés en clusters au sein d’un centre de données (« datacenter » dans la littérature anglo-saxonne). Il est aujourd’hui largement répandu d’avoir recours à des techniques d’ordonnancement de tâches dans les systèmes de traitement. L’utilisation de ces techniques est d’ailleurs la plupart du temps rendue nécessaire, par exemple chez les principaux fournisseurs mondiaux de services et/ou d’équipements réseaux, pour plusieurs raisons, dont : - la complexité des tâches à traiter, - le nombre de tâches à traiter, - la finitude matérielle des systèmes de traitement, ces derniers ne pouvant donc pas exécuter une infinité de tâches de manière simultanée. De manière conventionnelle, l’ordonnancement d’une tâche dans un système de traitement fait référence au fait d’affecter (i.e. attribuer) à ladite tâche, en vue de son exécution et en fonction d’éventuels attributs qui lui sont associés (date d’exécution, durée d’exécution, etc.) : - au moins un dispositif de traitement donné appartenant au système de traitement apte à exécuter ladite tâche, - une date à laquelle ladite tâche de mesure doit être exécutée par le dispositif de traitement qui lui a été ainsi affecté. Il est à noter qu’une tâche peut classiquement faire référence à une tâche unitaire correspondant à l’une des étapes de la mise en œuvre d’un procédé applicatif, ou bien encore de manière toute aussi classique, et selon une définition plus générale, à l’ensemble des tâches unitaires impliquées dans ce procédé applicatif. Le procédé applicatif dont la ou les tâches doivent être ordonnancées peut par exemple résulter de l’utilisation par une entreprise, par un particulier, etc. d’une application logicielle. Le fait que les techniques d’ordonnancement, et plus particulièrement leurs perfectionnements éventuels, fassent aujourd’hui l’objet d’une attention soutenue résulte notamment du développement et de l’utilisation massifs d’applications logicielles destinées à offrir toujours plus de services à des utilisateurs dont le nombre ne cesse également de croitre. Parmi les applications logicielles ainsi visées, on connait par exemple des applications, dites « applications de mesure », qui sont typiquement utilisées par des administrateurs réseaux et qui permettent de mesurer l’état d’un réseau de communication (surveillance de la bande passante, latence dans la transmission de paquets d’information, etc.) ou la qualité d’un service supporté par ledit réseau de communication. De telles applications de mesure sont aujourd’hui souvent déployées dans des systèmes de traitement virtualisés (plateforme de virtualisation, machine virtuelle, conteneur informatique, etc.) en utilisant des techniques d’ordonnancement, comme cela est par exemple détaillé dans le document suivant : « Enhanced edf scheduling algorithms for orchestrating network-wide active measurements », P. Calyam, C.-G. Lee, P. K. Arava, and D. Krymskiy, in 26th IEEE International Real-Time Systems Symposium (RTSS’05). IEEE, 2005. Le recours à un environnement virtualisé présente, de manière connue en soi, des avantages en termes d’accessibilité aux applications (par exemple depuis un terminal mobile comme un smartphone, une tablette, un PC, etc.), de sécurisation des données et de mutualisation des ressources matérielles nécessaires aux exécutions des applications de mesure. Ces avantages sont néanmoins contrebalancés par le fait que la plupart des techniques d’ordonnancement anciennement utilisées n’étaient pas encore suffisamment adaptées à certaines caractéristiques des applications de mesure, comme par exemple : la possibilité de déclencher une exécution de manière périodique et/ou avec un délai d’exécution (avance ou retard), l’existence éventuelle de contraintes de localisation d’une application de mesure (i.e. affectation forcée d’une application de mesure à un dispositif de traitement donné), l’existence d’éventuelles interférences entre différentes applications de mesure (i.e. deux applications de mesure interfèrent entre elles lorsque des paquets destinés à sonder l’état du réseau et transmis par l’une des applications sont considérés comme du trafic réseau par l'autre application, ce qui peut entraîner des mesures erronées). Plus récemment, il a été proposé des techniques d’ordonnancement aptes à prendre en compte ces caractéristiques, sous réserve toutefois d’allouer des ressources de traitement uniquement sur de longues périodes de temps (semaines ou mois), occasionnant ainsi un manque de réactivité qui s’avère être problématique au regard de l’utilisation toujours plus intensive des applications en question. Encore plus récemment, il a également été proposé des techniques d’ordonnancement aptes à traiter de manière plus réactive les sollicitations imposées par des applications, via notamment la mise en œuvre de réaffectations dynamiques (migrations) entre des dispositifs de traitement. Cela étant, ces dernières techniques demeurent très complexes à implémenter, en particulier d’un point de vue algorithmique. Il importe de noter que les différents désavantages présentés par les solutions actuelles de l’art antérieur ont été détaillés ci-avant dans le cadre spécifique des applications de mesure. Néanmoins, ces désavantages concernent en définitive tout type de tâche (tâche résultant de l’utilisation d’une application quelconque, tâche unitaire d’un procédé applicatif, etc.). La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l’art antérieur, notamment ceux exposés ci-avant, en proposant une solution qui permette d’ordonnancer de manière réactive une ou plusieurs tâches dans un système de traitement, cette solution étant en outre plus simple à mettre en œuvre que les solutions de l’art antérieur. De plus, bien que la solution proposée par l’invention soit particulièrement adaptée à l’ordonnancement de tâches exécutées grâce à une ou plusieurs applications de mesure dans un environnement virtualisé (chaque application pouvant par exemple être intégrée à un conteneur), elle n’en reste pas moins applicable à l’ordonnancement de tout type de tâche dans un environnement virtualisé ou non (exemple : tâches informatiques, tâches industrielles, etc.). A cet effet, et selon un premier aspect, l’invention concerne un procédé d’ordonnancement d’au moins une tâche dans un système de traitement configuré pour exécuter ladite au moins une tâche. Ledit procédé comporte, pour un premier ensemble de tâches associé au système de traitement, une étape de détermination de valeurs de paramètres d’exécution d’un algorithme métaheuristique configuré pour ordonnancer, dans ledit système de traitement, au moins une tâche associée audit système de traitement en optimisant une fonction objectif. Le procédé comporte en outre, pour au moins un deuxième ensemble de tâches associé audit système de traitement, une étape d’ordonnancement comprenant : - une exécution de l’algorithme métaheuristique paramétré par lesdites valeurs, et, si un critère d’arrêt de l’algorithme métaheuristique n’est pas atteint à l’issue de ladite exécution, - une mise à jour dudit au moins un deuxième ensemble, par retrait d’au moins une tâche dudit au moins un deuxième ensemble, ladite exécution, et ladite mise à jour le cas échéant, étant itérées tant que le critère d’arrêt n’est pas atteint. Ainsi, la solution proposée par l’invention pour ordonnancer une ou plusieurs tâches (par exemple des tâches de mesure) dans le système de traitement s’appuie sur un algorithme métaheuristique. Il convient de noter que par « ensemble de tâches », il est fait référence à un ensemble pouvant comporter une ou plusieurs tâches. Dit autrement, cette expression « ensemble de tâches » est, au sens de la présente invention, équivalente à l’expression « ensemble comportant au moins une tâche ». La recherche d’un ordonnancement optimal (i.e. d’une solution d’ordonnancement optimisant la fonction objectif) se révèle en effet être un problème d’optimisation particulièrement complexe (NP-difficile) à résoudre. Cette complexité résulte de manière fondamentale de la nature même dudit problème d’optimisation qui est ici dépendante du fait que lesdites tâches sont classiquement associées à des attributs définissant des contraintes spécifiques d’exécution de chacune de ces tâches (contraintes de ressources d’exécution, de date d’exécution, d’allocation à tel ou tel processeur, etc.). Cette complexité inhérente au problème d’optimisation ainsi posé est bien entendu encore accrue lorsque le nombre de tâches à ordonnancer dans le système de traitement est important. Autrement dit, la recherche d’une solution d’ordonnancement d’une ou plusieurs tâches dans le système de traitement se présente sous la forme d’un problème fortement contraint pour lequel il est particulièrement avantageux d’avoir recours à un algorithme métaheuristique. En effet, un tel algorithme d’optimisation adopte un comportement de recherche au sein d’un espace dit « espace de recherche » (par exemple un graphe dans le cas d’un algorithme de fourmis) dans l’optique d’apprendre les caractéristiques du problème auquel une solution est recherchée. Les inventeurs ont dès lors noté qu’un tel comportement était particulièrement approprié dans le cadre de la recherche d’une solution au problème d’ordonnancement. De manière conventionnelle, un algorithme métaheuristique est paramétré au moyen d’un ou plusieurs paramètres d’exécution. Les valeurs affectées à ces paramètres d’exécution déterminent plus précisément le comportement de recherche adopté par l’algorithme métaheuristique. Un choix approprié desdites valeurs permet par exemple de minimiser le risque d’absence de convergence de l’algorithme métaheuristique (exemple : éviter une convergence uniquement vers des optimums locaux) mais également de minimiser certains défauts inhérents au fonctionnement de ce dernier (exemple : possible manque de robustesse vis-à-vis de perturbations desdits paramètres d’exécution). Le procédé selon l’invention propose donc de déterminer des valeurs des paramètres d’exécution de l’algorithme métaheuristique, offrant ainsi la possibilité de paramétrer le comportement de ce dernier au plus juste, notamment pour éviter des défauts tels que ceux mentionnés ci-avant. Dit encore autrement, en permettant de déterminer lesdites valeurs, le procédé selon l’invention offre la possibilité de contrôler le fonctionnement de l’algorithme métaheuristique, et donc in fine la manière dont sont recherchées des solutions d’ordonnancement des tâches qui sont associées au système de traitement (par exemple qui lui ont été soumises pour ordonnancement). La combinaison entre la détermination desdites valeurs et l’exécution de l’algorithme métaheuristique est aisée à mettre en œuvre, et ne requiert aucun traitement coûteux en temps. Qui plus est, l’étape d’ordonnancement est mise en œuvre pour au moins un deuxième ensemble de tâches, ce qui offre la possibilité d’exécuter l’algorithme métaheuristique de manière itérative dès qu’une ou plusieurs tâches sont nouvellement associées au système de traitement. De telles dispositions sont avantageuses en ce qu’elles permettent d’ordonnancer de manière récurrente les tâches, conduisant ainsi à une solution particulièrement réactive. Dans des modes particuliers de mise en œuvre, le procédé d’ordonnancement peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. Dans des modes particuliers de mise en œuvre, chaque tâche est associée à une date d’exécution souhaitée, et, pour chaque ordonnancement candidat trouvé par l’algorithme métaheuristique, à un délai, dit « délai d’exécution effectif », représentatif de la durée suivant laquelle l’exécution de ladite tâche est différée par rapport à ladite date d’exécution souhaitée, ladite fonction objectif comportant un terme égal à la somme des délais d’exécution effectifs respectivement associés aux tâches prises en compte par l’algorithme métaheuristique, ledit terme étant destiné à être minimisé par ledit algorithme métaheuristique. On comprend que la minimisation de ce terme de la fonction objectif revient à satisfaire au mieux les dates d’exécution souhaitées, ces dernières étant par exemple émises par des utilisateurs du système de traitement. Ainsi, la prise en compte de ce terme dans la fonction objectif permet d’influencer le comportement de l’algorithme métaheuristique pour que ce dernier converge vers une solution tendant à éviter un ou plusieurs décalages d’exécution, une accumulation trop importante de décalages d’exécution pouvant en effet entraîner le fait qu’une ou plusieurs tâches ne puissent pas être ordonnancées dans le système de traitement. Dans des modes particuliers de mise en œuvre : - le système de traitement comporte une pluralité de processeurs, - chaque tâche est associée à un attribut « dit contrainte de localisation » définissant au moins un processeur parmi ladite pluralité de processeurs, de sorte que ladite tâche est destinée à être exécutée par un processeur quelconque parmi ledit au moins un processeur défini par ladite contrainte de localisation, - l’algorithme métaheuristique est configuré de sorte à autoriser la migration de chaque tâche entre des processeurs définis par la contrainte de localisation attachée à ladite tâche, ladite fonction objectif comportant un terme égal à un nombre de migrations des tâches prises en compte par l’algorithme métaheuristique, ledit terme étant destiné à être minimisé par ledit algorithme métaheuristique. Par « migration d’une tâche », on fait référence ici au fait qu’une tâche peut être affectée, pour un premier intervalle de temps, à un premier processeur appartenant aux processeurs définis par la contrainte de localisation attachée à cette tâche, puis, pour un deuxième intervalle de temps ultérieur audit premier intervalle de temps, à un deuxième processeur appartenant aux processeurs définis par la contrainte de localisation attachée à cette tâche. On comprend que la minimisation de ce terme de la fonction objectif revient à minimiser la complexité de la solution d’ordonnancement susceptible d’être fournie par l’algorithme métaheuristique, et donc aussi à minimiser les ressources utilisées par le système de traitement. La minimisation de ce terme revient également, de manière similaire à ce qui a été évoqué ci-avant pour le cas d’un terme égal à la somme des délais d’exécution effectifs, à minimiser le risque qu’au moins une tâche ne puisse pas être exécutée à temps (une migration étant en effet consommatrice en temps, et une tâche ne pouvant pas être exécutée lors de sa migration entre deux dispositifs de traitement). Dans des modes particuliers de mise en œuvre, les valeurs de paramètres d’exécution sont déterminées au moyen d’un algorithme mettant en œuvre une méthode de plan d’expériences paramétrée par ladite fonction objectif. De manière connue, une méthode de plan d’expériences fait référence à une suite ordonnée d'essais, chacun de ces essais permettant d'acquérir de nouvelles connaissances quant au fonctionnement (comportement) de l’algorithme métaheuristique sur lequel s’appuie ladite méthode de plan d’expériences, ces connaissances étant acquises vis-à-vis des paramètres qui caractérisent ledit algorithme métaheuristique. Plus particulièrement, chaque essai correspond à une expérimentation (i.e. une mise en œuvre) dudit algorithme métaheuristique pour un jeu donné de valeurs de paramètres d’exécution, un des objets de la méthode de plan d’expériences étant dès lors de comprendre de quelle manière les variations de ces paramètres influencent le comportement de l’algorithme métaheuristique. Il convient de noter que le comportement de l’algorithme métaheuristique est évalué au regard de valeur prise par la fonction objectif lors des différentes expérimentations. Le fait d’acquérir une telle connaissance du fonctionnement de l’algorithme métaheuristique permet de déterminer des valeurs des paramètres d’exécution de sorte, par exemple, à améliorer la robustesse dudit algorithme métaheuristique. Par « amélioration de la robustesse », on fait référence ici à la minimisation de la sensibilité de l’algorithme métaheuristique vis-à-vis de variations de ses paramètres d’exécution (ces variations pouvant faire suite à des perturbations du système de traitement, comme par exemple : retard dans la transmission effective d’une tâche, panne d’un dispositif de traitement modifiant ainsi les contraintes de localisation, etc.). Autrement dit, améliorer la robustesse d’un algorithme revient, d’une part, à garantir la continuité des solutions fournies par un tel algorithme métaheuristique vis-à-vis des paramètres d’exécution (l’objectif est d’éviter que des valeurs très proches des paramètres d’exécution conduisent à des solutions d’ordonnancement complètement différentes), mais également, d’autre part, à maintenir un niveau de performances malgré l'occurrence de perturbations. Dans des modes particuliers de mise en œuvre, ladite méthode de plan d’expériences est la méthode Taguchi. De manière générale, ladite méthode Taguchi est une méthode statistique permettant de réaliser des plans d'expériences ayant pour objectif de réduire la sensibilité aux perturbations externes d’un algorithme faisant l’objet desdites expériences. Cette méthode fournit une approche simple et systématique pour déterminer des valeurs optimales des paramètres d’exécution dudit algorithme, de sorte à en optimiser la robustesse. Dans des modes particuliers de mise en œuvre, l’algorithme métaheuristique est un algorithme de colonies de fourmis mis en œuvre à partir d’un graphe dont chaque nœud correspond à un ordonnancement d’une tâche dans le système de traitement. Les inventeurs ont en effet constaté que ce type d’algorithme métaheuristique, notamment dans sa variante dite « ACS » (acronyme de l’expression anglo-saxonne « Ant Colony System ») fournit de très bons résultats en terme de qualité des solutions d’ordonnancement (minimisation globale de la fonction objectif), ainsi que de simplicité et de rapidité de mise en œuvre. Ces résultats sont encore améliorés lorsque les paramètres d’exécution dudit algorithme de fourmis sont déterminés au moyen de la méthode Taguchi. Dans des modes particuliers de mise en œuvre, les paramètres d’exécution comportent un paramètre permettant de contrôler une quantité minimale de phéromones pouvant être associée à un nœud. L’utilisation d’un tel paramètre se montre avantageuse en ce qu’elle permet d’éviter la stagnation de l’algorithme de fourmis au début de sa mise en œuvre en favorisant la diversification des chemins parcourus par les fourmis ainsi qu’en évitant une convergence vers un optimum local. On note que la quantité de phéromones associée à un nœud dépend d’une quantité pouvant être déposée et/ou s’évaporer lors du passage d’une fourmi sur ledit nœud. Dans des modes particuliers de mise en œuvre, ladite au moins une tâche retirée lors de ladite mise à jour est la tâche dont l’association au système de traitement est la plus récente parmi les tâches dudit au moins un deuxième ensemble de tâches. Dans des modes particuliers de mise en œuvre, l’étape d’ordonnancement est mise en œuvre dès que M tâches sont nouvellement associées au système de traitement par rapport à la mise en œuvre précédente de ladite étape d’ordonnancement, M étant un entier supérieur ou égal à 1. Dans des modes particuliers de mise en œuvre, l’étape de détermination est itérée de manière récurrente de sorte à mettre à jour les valeurs desdits paramètres d’exécution. Procéder ainsi permet de paramétrer au mieux l’algorithme métaheuristique au regard de l’évolution des tâches transmises au système de traitement. Dans des modes particuliers de mise en œuvre, une tâche correspond à une mesure de l’état d’un réseau de communication auquel appartient au moins une partie du système de traitement ou de la qualité d’un service supporté par ledit réseau de communication. Chaque tâche peut être exécutée par exemple grâce à une application de mesure intégrée à un conteneur. Selon un deuxième aspect, l’invention concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé d’ordonnancement selon l’invention lorsque ledit programme d’ordinateur est exécuté par un ordinateur. Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Selon un troisième aspect, l’invention concerne un support d’informations ou d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon l’invention. Le support d'informations ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations ou d’enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Selon un quatrième aspect, l’invention concerne un dispositif d’ordonnancement d’au moins une tâche dans un système de traitement configuré pour exécuter ladite au moins une tâche, ledit dispositif d’ordonnancement comportant un module de détermination configuré pour déterminer, pour un premier ensemble de tâches associées au système de traitement, des valeurs de paramètres d’exécution d’un algorithme métaheuristique configuré pour ordonnancer, dans ledit système de traitement, au moins une tâche associée audit système de traitement en optimisant une fonction objectif. Ledit dispositif d’ordonnancement comporte en outre un module d’ordonnancement comprenant : - un sous-module d’exécution configuré pour exécuter l’algorithme métaheuristique paramétré par lesdites valeurs pour au moins un deuxième ensemble de tâches associé audit système de traitement, - un sous-module de vérification configuré pour vérifier si un critère d’arrêt est atteint ou non à l’issue d’une exécution de l’algorithme métaheuristique mise en œuvre par ledit sous-module d’exécution pour ledit moins un deuxième ensemble, - un sous-module de mise à jour configuré pour mettre à jour ledit au moins un deuxième ensemble, par retrait d’au moins une tâche dudit au moins un deuxième ensemble, lorsque ledit critère d’arrêt n’est pas atteint. Selon un cinquième aspect, l’invention concerne un système informatique comportant un dispositif d’ordonnancement selon l’invention ainsi qu’un système de traitement configuré pour exécuter au moins une tâche destinée à être ordonnancée par ledit dispositif d’ordonnancement. Selon un sixième aspect, l’invention concerne un procédé d’exécution d’au moins une tâche par un système de traitement configuré pour exécuter ladite au moins une tâche. Ledit procédé d’exécution comporte : - une étape d’ordonnancement d’au moins une tâche dans ledit système de traitement conformément à un procédé d’ordonnancement selon l’invention, - une étape d’exécution de ladite au moins une tâche selon l’ordonnancement déterminé au cours de ladite étape d’ordonnancement. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : la figure 1 représente schématiquement, dans son environnement, un mode particulier de réalisation d’un système informatique selon l’invention ; la figure 2 représente schématiquement un exemple d’architecture matérielle d’un dispositif d’ordonnancement 12 selon l’invention appartenant au système informatique 10 de la figure 1 ; la figure 3 représente, sous forme d’ordinogramme, un mode particulier de mise en œuvre d’un procédé d’ordonnancement selon l’invention par le dispositif d’ordonnancement 12 de la figure 2 ; la figure 4 représente un tableau TAB de valeurs de paramètres d’exécution d’un algorithme de fourmis utilisé dans un exemple de mise en œuvre du procédé d’ordonnancement ; la figure 5 représente une matrice L25 d’une méthode Taguchi utilisée dans ledit exemple de mise en œuvre ; la figure 6 représente schématiquement un exemple de mise en œuvre d’un procédé d’exécution selon l’invention. La figure 1 représente schématiquement, dans son environnement, un mode particulier de réalisation d’un système informatique 10 selon l’invention. Dans le mode de réalisation illustré par la figure 1, le système informatique 10 comporte un système de traitement 11. Ledit système de traitement 11 est par exemple déployé dans un environnement virtualisé, un utilisateur pouvant avoir accès à ce dernier en se connectant à une plateforme de virtualisation de type connue en soi au moyen d’un terminal (ordinateur portable, PC, tablette, etc.) en possession dudit utilisateur. Selon un autre exemple, le système de traitement 11 est déployé dans un environnement non virtualisé, de sorte qu’un utilisateur puisse y avoir accès sans qu’il soit nécessaire pour ce dernier de se connecter à une plateforme de virtualisation. Le système de traitement 11 est en outre configuré pour exécuter au moins une tâche. A cet effet, ledit système de traitement 11 comporte une pluralité de dispositif de traitement 11_i (i étant un indice entier supérieur à 1). Dans l’exemple illustré par la figure 1, le nombre de dispositifs de traitement est égal à N, ou N est un nombre entier donné (i=1,…,N). Il importe toutefois de noter qu’aucune limitation n’est attachée au nombre total de dispositifs de traitement 11_i pouvant être inclus dans le système de traitement 11. Lesdits dispositifs de traitement 11_i appartiennent à un réseau de communication (non illustré sur la figure 1) sur lequel ils peuvent s’appuyer pour communiquer entre eux. Par exemple, ledit réseau de communication peut correspondre à un réseau LAN (Local Area Network), WAN (Wide Area Network), WLAN (Wireless LAN), Internet, etc. D’une manière générale, la nature dudit réseau de communication n’est pas un facteur limitant de l’invention, dès lors que les dispositifs de traitement 11_i peuvent échanger des données entre eux, ces données pouvant éventuellement prendre la forme d’une application logicielle, comme par exemple une application de mesure. En outre, bien qu’il soit considéré ici que les dispositifs de traitement 11_i appartiennent à un seul et même réseau de communication, rien n’exclut d’envisager une répartition desdits dispositifs de traitement 11_i entre plusieurs réseaux de communication distincts entre eux, lesdits réseaux de communication étant dès lors raccordés entre eux de manière connue en soi pour permettre aux dispositifs de traitement 11_i d’échanger des données. Lesdits dispositifs de traitement 11_i sont configurés pour exécuter une ou plusieurs tâches qui sont associées au système de traitement 11. Par « tâche associée au système de traitement 11 », on fait référence ici au fait qu’une requête a été émise, par exemple par un utilisateur, pour que ladite tâche soit exécutée par ledit système de traitement 11, c’est-à-dire par l’un des dispositifs de traitement 11_i appartenant audit système 11. Pour exécuter une ou plusieurs tâches, chaque dispositif de traitement 11_i comporte par exemple un ou plusieurs processeurs et des moyens de mémorisation (disque dur magnétique, mémoire électronique, disque optique, etc.) dans lesquels sont mémorisés des données et un programme d'ordinateur, sous la forme d'un ensemble d'instructions de code de programme à exécuter pour mettre en œuvre un procédé d’exécution de la ou des tâches qui ont été transmises audit dispositif de traitement 11_i. Alternativement ou en complément, chaque dispositif de traitement 11_i comporte également un ou des circuits logiques programmables, de type FPGA, PLD, etc., et/ou circuits intégrés spécialisés (ASIC), et / ou un ensemble de composants électroniques discrets, etc. adaptés à mettre en œuvre ledit procédé d’exécution. En d'autres termes, chaque dispositif de traitement 11_i comporte un ensemble de moyens configurés de façon logicielle (programme d'ordinateur spécifique) et/ou matérielle (FPGA, PLD, ASIC, etc.) pour mettre en œuvre ledit procédé d’exécution. Les aspects techniques concernant l’exécution en tant que telle d’une tâche par un dispositif de traitement 11_i sont connus de l’homme du métier et sortent du cadre de la présente invention, si bien qu’ils ne sont pas davantage détaillés ici. Comme mentionné ci-dessus, les dispositifs de traitement 11_i peuvent comporter un ou plusieurs processeurs. Il peut s’agir d’équipements réseau, comme par exemple des serveurs, de terminaux mobiles, comme par exemple un téléphone de type « smartphone », un PC, un ordinateur portable, une tablette, etc. De manière générale, aucune limitation n’est attachée à la nature desdits dispositifs de traitement 11_i dès lors que ces derniers sont en mesure d’exécuter les tâches qui leur ont été transmises. De manière conventionnelle, une tâche peut faire référence à une tâche unitaire correspondant à l’une des étapes de la mise en œuvre d’un procédé applicatif, ce procédé applicatif pouvant être de tout type (procédé de contrôle industriel, par exemple le contrôle du fonctionnement d’une machine ; procédé de traitement de données, par exemple des données boursières ; procédé de traitement de flux audio ou vidéo, par exemple dans le cas du codage ou de la classification audio/vidéo ; etc.). On comprend donc que la nature d’une tâche découle de la nature du procédé applicatif auquel ladite tâche est associée. En conséquence, une tâche peut être de nature informatique, industrielle, etc. Au sens de la présente invention, aucune limitation n’est attachée à la nature des tâches destinées à être exécutées par le système de traitement 11. De manière tout aussi conventionnelle, et selon une définition plus générale, une tâche peut désigner l’ensemble des tâches unitaires impliquées dans la mise en œuvre d’un procédé applicatif, auquel cas il est fait référence à une tâche dite « générale ». Il convient de noter que la mise en œuvre d’un procédé applicatif regroupant un ensemble de tâches unitaires peut par exemple résulter de l’utilisation d’une application logicielle, de sorte que la tâche générale associée à ce procédé applicatif désigne également l’application logicielle elle-même. Dit autrement, la tâche s’identifie à l’application logicielle qui lui est dédiée. Chaque tâche est classiquement associée à une date d’exécution souhaitée. Une telle date d’exécution souhaitée est par exemple définie par un utilisateur souhaitant bénéficier du résultat découlant de l’exécution de ladite tâche à ladite date d’exécution souhaitée. Selon un autre exemple, une date d’exécution souhaitée est définie de manière automatique par le procédé applicatif auquel est associée ladite tâche. Par ailleurs, chaque tâche est associée à une pluralité d’attributs, ces attributs pouvant définir des contraintes spécifiques d’exécution de ladite tâche. Par exemple, chaque tâche est associée à un attribut définissant une date d’exécution au plus tôt de ladite tâche. Ladite date d’exécution au plus tôt désigne donc le premier instant en lequel l’exécution de la tâche peut avoir lieu en prenant en compte une éventuelle périodicité d’exécution de ladite tâche. Il ressort de ce qui précède que ladite date d’exécution au plus tôt borne inférieurement la date d’exécution souhaitée. Selon un autre exemple, éventuellement en complément du précédent, chaque tâche est associée à un attribut définissant un délai, dit « délai maximal d’exécution », représentatif de la durée maximale suivant laquelle l’exécution de ladite tâche peut être différée par rapport à ladite date d’exécution souhaitée. Autrement dit, ledit délai maximal d’exécution correspond à un majorant d’une marge temporelle accordée dans l’exécution de la tâche, permettant ainsi de relâcher la contrainte définie par la date d’exécution souhaitée. Selon encore un autre exemple, éventuellement en complément des précédents, chaque tâche est associée à un attribut dit « contrainte de localisation » définissant au moins un dispositif de traitement parmi ladite pluralité de dispositifs de traitement 11_i, de sorte que ladite tâche est destinée à être exécutée par un dispositif de traitement 11_i quelconque parmi ledit au moins un dispositif défini par ladite contrainte de localisation. Ladite contrainte de localisation peut définir ledit au moins un dispositif de traitement de manière indirecte, par exemple en faisant référence à une zone géographique donnée en laquelle est implémenté ledit au moins un dispositif de traitement. Il convient de noter que l’expression « zone géographique » fait référence ici à tout type de zone délimitée dans l’espace. Aucune limitation n’étant attachée à la délimitation d’une telle zone au sens de la présente invention, dès lors qu’il est possible d’identifier le ou les dispositifs de traitement appartenant à ladite zone géographique. De manière alternative à l’exemple précédent dans lequel la contrainte de localisation porte sur une zone géographique, ou bien éventuellement en complément de cet exemple précédent, ladite contrainte localisation peut définir ledit au moins un dispositif de traitement de manière directe, par exemple en désignant précisément ledit au moins un dispositif de traitement via un identifiant de ce dernier. Autrement dit, dans cet exemple, au moins un dispositif de traitement donné est spécifiquement désigné (si une zone géographique est également désignée, il s’agit alors d’un dispositif de traitement spécifique de cette zone géographique). Bien entendu, encore d’autres types de localisation peuvent être définies par la contrainte de localisation, cet aspect pouvant par exemple dépendre de l’étendue du réseau de communication, du nombre de dispositifs de traitement, de préférences d’utilisation, etc. Cela étant, et pour des raisons de simplification de la description, on considère désormais qu’une contrainte de localisation définit de manière directe ledit au moins dispositif de traitement 11_i parmi la pluralité de dispositifs de traitement intégrés au système de traitement 11, sans faire référence à d’autres aspects (zone géographique, etc.). D’une manière générale, aucune limitation n’est attachée au nombre d’attributs pouvant être associés à une tâche, ni même à la nature de ces attributs, ces aspects étant bien connus de l’homme du métier. A titre d’exemple, tout ou partie des attributs listés ci-après peuvent être envisagés, éventuellement en complément de tout ou partie des attributs déjà mentionnés ci-avant (date d’exécution au plus tôt, délai d’exécution, localisation) : - identifiant : cet attribut définit une donnée permettant d’identifier une tâche parmi les autres tâches. Il peut s’agir par exemple d’un nombre entier, le nombre affecté à une tâche nouvellement associée au système de traitement 11 pouvant être égal au nombre de la tâche précédemment considérée comme étant la plus récente incrémenté d’une unité. De cette manière, il est possible de définir une relation d’ordre sur l’ensemble des tâches associées au système de traitement 11 ; - ressources en termes de calculs (cpu) et/ou de mémoire (ram) et/ou de bande passante nécessaires à l’exécution d’une tâche ; - ressources en termes de calculs (cpu) et/ou de mémoire (ram) et/ou de bande passante nécessaires à la migration d’une tâche d’un dispositif de traitement 11_i vers un autre dispositif de traitement 11_j (i différent de j) ; - date d’exécution au plus tard ; - période d’exécution : cet attribut définit la périodicité selon laquelle une tâche est exécutée ; - durée d’exécution ; - contrainte d’affinité : cet attribut définit, pour une tâche TA à laquelle est associée ledit attribut, le ou les autres tâches devant être exécutées sur le même dispositif de traitement 11_i que celui destiné à exécuter ladite tâche TA ; - contrainte d’anti-affinité : cet attribut définit, pour une tâche TA à laquelle est associée ledit attribut, le ou les autres tâches ne devant pas être exécutées sur le même dispositif de traitement 11_i que celui destiné à exécuter ladite tâche TA. La suite de la description vise de manière plus spécifique le cas d’une tâche de type informatique, et plus particulièrement le cas où une telle tâche informatique correspond à une mesure de l’état du réseau de communication auquel appartient le système de traitement 11 ou de la qualité d’un service supporté par ledit réseau de communication. Une telle tâche est dénommée ci-après « tâche de mesure » (l’expression « élément de mesure » peut également être employée dans l’état de l’art). On considère en outre que chaque tâche de mesure est exécutée grâce à une application de mesure intégrée à un conteneur. Un tel conteneur est par exemple déjà déployé (i.e. installé) sur un dispositif de traitement 11_i, ou bien, selon un autre exemple, est destiné à y être déployé suite à la mise en œuvre d’un procédé d’ordonnancement selon l’invention. Autrement dit, on adopte désormais ici la définition plus générale donnée ci-avant selon laquelle une tâche de mesure s’identifie à l’application de mesure (et donc en définitive aussi au conteneur comprenant cette application de mesure) à laquelle elle est attachée. En conséquence, et au sens de la présente invention, les expressions suivantes « tâche de mesure transmise » et « migration de tâche de mesure » sont respectivement équivalentes aux expressions suivantes « application logicielle transmise (conteneur transmis) » et « migration d’application logicielle (migration de conteneur) ». Par « migration d’une tâche », on fait référence ici au fait qu’une tâche peut être affectée, pour un premier intervalle de temps, à un premier dispositif de traitement 11_i appartenant aux dispositifs définis par la contrainte de localisation attachée à cette tâche, puis, pour un deuxième intervalle de temps ultérieur audit premier intervalle de temps, à un deuxième dispositif de traitement 11_j (l’indice j étant différent de l’indice i) appartenant aux dispositifs définis par la contrainte de localisation attachée à cette tâche. Bien entendu, ce processus peut se prolonger, menant ainsi à davantage de migrations, sachant que rien n’exclut qu’une tâche migre vers un dispositif auprès duquel elle a déjà été affectée auparavant. Pour la suite de la description, on adopte également la convention selon laquelle une tâche de mesure peut être représentée au moyen d’une succession de champs C_l, l étant un indice entier, de la manière suivante : C_1 (C_2 C_3) C_4 C_5 C_6 (C_7 C_8 C_9) (C_10 C_11 C_12) [C_13 … C_{k}] [C_{k + 1} … C_{k + j}] [C_{k + j +1} … C_{n}], chaque champ étant représentatif d’un attribut associé à ladite tâche de mesure. On note que les parenthèses « ( «, « ) », ainsi que les crochets « [« , « ] » sont utilisés ici comme délimiteurs afin de regrouper entre eux des attributs de même nature. Bien entendu, d’autres délimiteurs peuvent être utilisés, voire également aucun délimiteur. Plus particulièrement, on considère que : - C_1 est représentatif de l’identifiant de ladite tâche de mesure, cet identifiant correspondant à un nombre entier. En outre, les identifiants des tâches sont incrémentés d’une unité suivant l’ordre chronologique de transmission desdites tâches au système de traitement 11 ; - C_2 et C_3 sont respectivement représentatifs de la date d’exécution au plus tôt et de la date d’exécution au plus tard ; - C_4, C_5 et C_6 sont respectivement représentatifs de la période d’exécution, de la durée d’exécution et du délai maximal d’exécution ; - C_7, C_8 et C_9 sont respectivement représentatifs des ressources de calculs, de mémoire et de bande passante nécessaires à l’exécution de ladite tâche de mesure ; - C_10, C_11 et C_12 sont respectivement représentatifs des ressources de calculs, de mémoire et de bande passante nécessaires à une migration de ladite tâche de mesure ; - C_13, … , C_{k} sont respectivement représentatifs d’identifiants de dispositifs de traitement 11_i associés à une contrainte de localisation (autrement dit, k – 13 + 1 est inférieur ou égal au nombre de dispositifs de traitement 11_i inclus dans le système de traitement 11) ; - C_{k + 1}, …, C_{k + j} sont respectivement représentatifs d’identifiants de tâches de mesure associées à une contrainte d’affinité ; - C_{k + j +1}, …, C_{n} sont respectivement représentatifs d’identifiants de tâches de mesure associées à une contrainte d’anti-affinité. A titre illustratif, considérons la tâche de mesure suivante : 1 (1 6) 3 2 0 (60 60 60) (1 1 1) [1 2] [ ] [ ] Dans cet exemple, on suppose que les nombres donnés pour des champs temporels (i.e. des champs associés à des attributs faisant référence à une quantité temporelle) sont normalisés par rapport à un référentiel temporel commun à toutes les autres tâches de mesure associées au système de traitement 11. Ladite tâche de mesure a pour identifiant le nombre 1. Sa date d’exécution au plus tôt (respectivement au plus tard) est égal à 1 (respectivement égal à 6). Sa période d’exécution, sa durée d’exécution et son délai maximal d’exécution sont respectivement égaux à 3, 2 et 0 (i.e. l’exécution de cette tâche de mesure ne peut pas être décalée dans le temps). Ses ressources (calculs, mémoire, bande passante) pour l’exécution sont toutes égales à 60. Les ressources (calculs, mémoire, bande passante) pour une migration sont quant à elles toutes égales à 1. Par ailleurs, ladite tâche de mesure est associée à une contrainte de localisation selon laquelle elle doit être exécutée par l’un quelconque parmi deux dispositifs de traitement 11_i (ici il s’agit plus particulièrement des dispositifs 11_1 et 11_2). Enfin, aucune contrainte d’affinité/d’anti-affinité n’est attachée à ladite tâche de mesure. Bien que l’invention soit désormais décrite en considérant qu’une tâche correspond à une tâche de mesure, il importe de noter que l’invention reste applicable indépendamment de la nature des tâches considérées, ces dernières pouvant donc être unitaires et/ou générales, sans limitation quant au procédé applicatif auquel elles peuvent se référer. Le système informatique 10 comporte également un dispositif d’ordonnancement 12 configuré pour réaliser des traitements permettant d’ordonnancer une ou plusieurs tâches de mesure dans le système de traitement 11, en mettant en œuvre ledit procédé d’ordonnancement. De manière conventionnelle, l’ordonnancement d’une tâche de mesure dans le système de traitement 11 fait référence au fait d’affecter (i.e. attribuer) à ladite tâche de mesure, en vue de son exécution et en fonction des attributs associés à ladite tâche de mesure : - au moins un dispositif de traitement 11_i donné appartenant au système de traitement 11, - une date à laquelle ladite tâche de mesure doit être exécutée par le dispositif de traitement affecté. Le dispositif d’ordonnancement 12 selon l’invention, ainsi que le procédé d’ordonnancement selon l’invention, se distinguent néanmoins des dispositifs et procédés de l’état de l’art en ce qu’ils permettent d’ordonnancer de manière réactive (i.e. avec très peu de latence) une ou plusieurs tâches dans le système de traitement 11, tout en étant simples à implémenter. La figure 2 représente schématiquement un exemple d’architecture matérielle du dispositif d’ordonnancement 12 selon l’invention appartenant au système informatique 10 de la figure 1. Tel qu’illustré par la figure 2, le dispositif d’ordonnancement 12 dispose de l’architecture matérielle d’un ordinateur. Ainsi, le dispositif d’ordonnancement 12 comporte, notamment, un processeur 1, une mémoire vive 2, une mémoire morte 3 et une mémoire non volatile 4. Il comporte en outre d’un module de communication 5. La mémoire morte 3 du dispositif d’ordonnancement 12 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 1 et sur lequel est enregistré un programme d’ordinateur PROG conforme à l’invention, comportant des instructions pour l’exécution d’étapes du procédé d’ordonnancement selon l’invention. Le programme PROG définit des modules fonctionnels du dispositif d’ordonnancement 12, qui s’appuient ou commandent les éléments matériels 1 à 5 du dispositif d’ordonnancement 12 cités précédemment, et qui comprennent notamment : - un module de détermination MOD_DET configuré pour déterminer, pour un premier ensemble de tâches associées au système de traitement 11, des valeurs de paramètres d’exécution d’un algorithme métaheuristique configuré pour ordonnancer, dans ledit système de traitement 11, au moins une tâche de mesure associée audit système de traitement 11 en optimisant une fonction objectif, - un module d’ordonnancement MOD_ORD. Ledit module d’ordonnancement MOD_ORD comprend : - un sous-module d’exécution SS_MOD_EXEC configuré pour exécuter l’algorithme métaheuristique paramétré par lesdites valeurs pour au moins un deuxième ensemble de tâches associé audit système de traitement, - un sous-module de vérification SS_MOD_VERIF configuré pour vérifier si un critère d’arrêt CR_STOP est atteint ou non à l’issue d’une exécution de l’algorithme métaheuristique mise en œuvre par ledit sous-module d’exécution pour ledit moins un deuxième ensemble, - un sous-module de mise à jour SS_MOD_MAJ configuré pour mettre à jour ledit au moins un deuxième ensemble, par retrait d’au moins une tâche dudit au moins un deuxième ensemble, lorsque ledit critère d’arrêt n’est pas atteint. Les sous-modules d’exécution SS_MOS_EXEC et de mise à jour SS_MOD_MAJ sont activés de façon itérative tant que le sous-module de vérification SS_MOD_VERIF détermine que le critère d’arrêt n’est pas atteint. Le module de communication 5 permet notamment au dispositif d’ordonnancement 12 de communiquer, via le réseau de communication, avec les dispositifs de traitement 11_i, pour notamment leur transmettre les tâches de mesure à exécuter (autrement dit, dans le cas d’espèce, il est fait référence à la transmission des applications de mesure respectivement associées auxdites tâches de mesure) ainsi que les dates en lesquelles ces tâches de mesure doivent être exécutées conformément au résultat obtenu par le procédé d’ordonnancement. A cet effet, le module de communication 5 comporte une interface de communication, filaire ou non filaire, apte à mettre en œuvre tout protocole adapté au réseau de communication et connu de l’homme du métier. Ainsi, et selon l’invention, l’ordonnancement d’une ou plusieurs tâches de mesure dans le système de traitement 11, par le dispositif d’ordonnancement 12, s’appuie sur un algorithme métaheuristique. L’utilisation d’un algorithme métaheuristique tient au fait que la recherche d’un ordonnancement optimal (i.e. d’une solution d’ordonnancement optimisant la fonction objectif) se révèle être un problème d’optimisation particulièrement complexe à résoudre (NP-difficile). Cette complexité résulte de manière fondamentale de la nature même dudit problème d’optimisation qui est ici dépendante du fait que lesdites tâches sont classiquement associées auxdits attributs définissant des contraintes spécifiques d’exécution de chacune de ces tâches. Cette complexité inhérente au problème d’optimisation ainsi posé est bien entendu encore accrue lorsque le nombre de tâches à ordonnancer dans le système de traitement est important.. La recherche d’une solution d’ordonnancement représente donc un problème fortement contraint. De manière conventionnelle, l’algorithme métaheuristique permet de rechercher une solution au problème d’ordonnancement de manière itérative. Plus particulièrement, des solutions d’ordonnancement candidates sont déterminées à chaque itération ayant lieu lors de l’exécution de l’algorithme métaheuristique. Par « solution candidate » (ou encore « ordonnancement candidat »), on fait référence à une solution permettant d’ordonnancer les tâches associées au système de traitement 11 en respectant les contraintes d’exécution respectivement associées auxdites tâches du fait de leurs attributs. L’objectif final de l’algorithme métaheuristique consiste dès lors à trouver, parmi ces solutions candidates, celle qui optimise la fonction objectif. Ainsi, la notion d’optimalité de l’algorithme métaheuristique est définie au regard de la fonction objectif considérée. On note que l’expression « fonction objectif » est encore équivalente à l’expression « fonction (de) coût ». Il convient de noter que chaque tâche peut également être associée, pour chaque ordonnancement candidat trouvé par l’algorithme métaheuristique, à un délai, dit « délai d’exécution effectif », représentatif de la durée suivant laquelle l’exécution de ladite tâche est différée par rapport à ladite date d’exécution souhaitée. Un tel délai d’exécution effectif correspond donc à un délai réel d’exécution utilisée dans un ordonnancement candidat. Ainsi, une tâche peut être associée à autant de délais d’exécution effectifs qu’il y d’ordonnancements candidats (en considérant qu’un délai d’exécution effectif peut être nul), ces délais d’exécution effectifs pouvant être distincts entre eux. Dans le présent mode de réalisation, l’algorithme métaheuristique est configuré de sorte à autoriser la migration de chaque tâche (prise en compte par ce dernier) entre les dispositifs 11_i de ladite pluralité de dispositifs de traitement définie par la contrainte de localisation attachée à ladite tâche. Par exemple, en reprenant l’exemple précédent dans lequel une tâche de mesure s’écrit : 1 (1 6) 3 2 0 (60 60 60) (1 1 1) [1 2] [ ] [ ] on a que la contrainte de localisation définit les dispositifs de traitement 11_1 et 11_2. Dès lors, la mise en œuvre de l’algorithme métaheurisitique peut mener, par exemple, à une solution d’ordonnancement dans laquelle ladite tâche est affectée au dispositif 11_1 pour les temps t=1 et t=2, puis être migrée vers le dispositif 11_2 pour y être finalement affectée pour les temps t=3, t=4 et t=6. Il convient toutefois de noter que le fait de considérer que des migrations de tâches sont autorisés entre dispositifs de traitement 11_i, sous respect de contraintes de localisation et au moyen d’une configuration idoine de l’algorithme métaheuristique, ne constitue pas une limitation de l’invention. Ainsi, rien n’exclut d’envisager que les migrations soient interdites pour tout ou partie des tâches prises en compte par l’algorithme métaheuristique. De plus, dans le mode de réalisation considéré ici, la fonction objectif comporte deux termes qui sont sommés entre eux. Plus particulièrement, ladite fonction objectif comporte un terme égal à la somme des délais d’exécution effectifs respectivement associés aux tâches prises en compte par l’algorithme métaheuristique, c’est-à-dire les tâches qui sont associées au système de traitement 11 lors de l’exécution dudit algorithme métaheuristique et qui sont donc prises en entrée ce dernier. En outre, ledit premier terme est destiné à être minimisé par ledit algorithme métaheuristique. On comprend que la minimisation de ce premier terme revient à minimiser le risque qu’au moins une tâche ne puisse pas être exécutée à temps (i.e. dans l’intervalle de temps dont les bornes sont définies par les dates d’exécution au plus tôt et au plus tard, tout en prenant en compte un éventuel délai d’exécution borné par le délai maximal d’exécution). De plus, la fonction objectif comporte un deuxième terme égal à un nombre de migrations des tâches prises en compte par l’algorithme métaheuristique (i.e. on comptabilise le nombre de migrations de chaque tâche prise en compte par l’algorithme métaheuristique, et on somme les nombres de migrations ainsi compatibilisés), ledit deuxième terme étant également destiné à être minimisé par ledit algorithme métaheuristique. On comprend que la minimisation de ce deuxième terme revient à minimiser la complexité de la solution d’ordonnancement susceptible d’être fournie par l’algorithme métaheuristique, et donc aussi à minimiser les ressources utilisées par le système de traitement 11. La minimisation de cet terme revient également, encore une fois, à minimiser le risque qu’au moins une tâche ne puisse pas être exécutée à temps (une migration étant en effet consommatrice en temps et une tâche ne pouvant pas être exécutée lors de sa migration entre deux dispositifs de traitement 11_i). Le choix selon lequel la fonction objectif comporte lesdits deux termes ne constitue qu’une variante d’implémentation de l’invention. Ainsi, rien n’exclut que la fonction objectif ne comporte que l’un desdits deux termes ou plus généralement n’importe quelle somme pondérée de ces deux termes. On comprend toutefois que si la fonction objectif comporte uniquement le deuxième terme, il est nécessaire que l’algorithme métaheuristique soit configuré de sorte à autoriser les migrations de tâches. Par ailleurs, rien n’exclut non plus de considérer que la fonction objectif comporte un ou plusieurs termes qui diffèrent des premier et deuxième termes, que lesdits premier et deuxième termes soient pris en compte ou non dans la fonction objectif. D’une manière générale, aucune limitation n’est attachée à la manière dont est définie la fonction objectif, cette dernière pouvant dépendre ou non des attributs associés aux tâches aptes à être exécutées par le système de traitement 11, mais aussi d’éventuelles contraintes d’exécution qui peuvent être attachées audit système de traitement 11 (limitation de la charge de calculs, maximisation du nombre de tâches à exécuter entre deux dates données, etc.). Dans le présent mode de réalisation, l’algorithme métaheuristique utilisé pour ordonnancer le ou les tâches associées au système de traitement 11 est un algorithme de colonies de fourmis. De manière connue en soi, un tel algorithme de colonies de fourmis est considéré comme une métaheuristique à population, où chaque solution susceptible d’être fournie est représentée par une fourmi se déplaçant dans un espace de recherche pouvant être modélisé au moyen d’un graphe. Ainsi, les fourmis se déplacent au sein dudit graphe en marquant les meilleures solutions (le terme « meilleures » caractérisant ici les solutions qui tendent vers l’optimalité mesurée au moyen de la fonction objectif) au moyen de phéromones, et en tenant compte des marquages précédemment effectués pour optimiser leur recherche. Dans le contexte de l’invention, le graphe au sein duquel les fourmis sont destinées à se déplacer est un graphe dont chaque nœud correspond à l’ordonnancement d’une tâche dans le système de traitement 11. Plus particulièrement, et eu égard au fait que le système de traitement 11 comporte une pluralité de dispositifs de traitement 11_i conformément au présent mode de réalisation, chaque nœud du graphe correspond à l’affectation (i.e. l’attribution) à une tâche donnée d’au moins un desdits dispositifs 11_i (une pluralité de dispositifs pouvant être attribués si des migrations sont envisagées) ainsi que d’une date d’exécution (l’exécution de la tâche pouvant éventuellement se répéter si elle est associée à une période d’exécution). Il importe de noter que l’ensemble des nœuds accessibles à une fourmi évolue au cours de son déplacement dans le graphe. En effet, le déplacement d’une fourmi s’effectue sous le respect des contraintes d’exécution associées aux tâches. Ainsi, lorsqu’une fourmi se trouve sur un nœud, seuls les nœuds permettant de définir une solution candidate respectueuse desdites contraintes d’exécution sont accessibles dans la poursuite du déplacement de la fourmi. De telles dispositions permettent classiquement de limiter la charge de calcul générée par l’exécution de l’algorithme de fourmis, en évitant un parcours exhaustif du graphe. De manière conventionnelle, un algorithme de colonies de fourmis peut être mis en œuvre suivant différentes variantes, notamment une variante dite « MMAS » (acronyme de l’expression anglo-saxonne « Max-Min Ant System »), une variante dite « ACS » (acronyme de l’expression anglo-saxonne « Ant Colony System »), etc. qui peuvent finalement être toutes regroupées dans une catégorie dite « ACO » (acronyme de l’expression anglo-saxonne « Ant Colony Optimization »). De telles variantes sont bien connues de l’homme du métier et sont par exemple décrites dans le document : « Ant colony optimization », Dorigo M., Stutzle T., MIT Press, Cambridge, MA, 2004. Pour la suite de la description, on considère de manière nullement limitative que l’algorithme de fourmis utilisé pour ordonnancer la ou les tâches transmises au système de traitement 11 est de type ACS. Dès lors, l’algorithme de fourmis ACS mis en œuvre dans le cadre de la présente invention est classiquement paramétré au moyen de différents paramètres d’exécution qui comprennent, notamment : - α : ce paramètre permet de contrôler l’importance relative des phéromones dans le choix d’un chemin lors du parcours du graphe ; - β : ce paramètre est encore appelé « visibilité » dans l’état de l’art et permet de contrôler l’importance accordée au choix d’un nœud lorsqu’une fourmis est positionnée sur un autre nœud. Dit encore autrement, ce paramètre contrôle l’importance relative des informations heuristiques dans le choix d’un chemin lors du parcours du graphe ; - Q_0 : ce paramètre permet de contrôler l’importance relative donnée à l’intensification ou à la diversification de la recherche d’une solution lors du parcours du graphe. Il s’agit d’une variable aléatoire uniformément distribuée entre 0 et 1 ; - ρ : ce paramètre permet de contrôler la quantité de phéromones évaporée sur les nœuds à chaque itération ; - N_ant : ce paramètre définit le nombre de fourmis explorant le graphe. Dans le présent mode réalisation, l’algorithme ACS utilisé pour l’ordonnancement est également paramétré au moyen d’un paramètre d’exécution min_eva permettant de contrôler une quantité minimale de phéromones pouvant être associée à un nœud (par dépôt et/ou évaporation lors du passage d’une fourmi sur ledit nœud). L’utilisation d’un tel paramètre min_eva est optionnelle, et se montre avantageuse en ce qu’elle permet d’éviter la stagnation de l’algorithme ACS au début de sa mise en œuvre en favorisant la diversification des chemins parcourus par les fourmis ainsi qu’en évitant une convergence vers un optimum local. Bien que l’invention soit ici décrite en considérant que l’algorithme de fourmis est de type ACS, il convient cependant de noter qu’elle reste applicable quelle que soit la variante d’algorithme de fourmis considérée. En outre, et de manière plus générale, le choix consistant à considérer un algorithme de fourmis en tant qu’algorithme métaheuristique ne constitue qu’un exemple d’implémentation de l’invention. En effet, l’invention reste applicable quel que soit l’algorithme métaheuristique considéré, ce dernier étant dans tous les cas paramétré au moyen de différents paramètres d’exécution. Par exemple, il peut s’agir d’un algorithme de recuit simulé, d’un algorithme GRASP (acronyme de l’expression anglo-saxonne « Greedy Randomized Adaptative Search Procedure »), d’un algorithme évolutionniste (exemple : algorithme génétique), etc. En tout état de cause, l’homme du métier sait adapter la présente description en fonction de l’algorithme métaheuristique choisi. La suite de la description vise à décrire un mode particulier de mise en œuvre du procédé d’ordonnancement selon l’invention. La figure 3 représente, sous forme d’ordinogramme, un mode particulier de mise en œuvre du procédé d’ordonnancement selon l’invention par le dispositif d’ordonnancement 12 de la figure 2. Tel qu’illustré par la figure 3, le procédé d’ordonnancement comporte, pour un premier ensemble E_1 de tâches associé au système de traitement 11, une étape E10 de détermination de valeurs des paramètres d’exécution de l’algorithme de fourmis ACS. Ladite étape E10 est mise en œuvre par le module de détermination MOD_DET équipant le dispositif d’ordonnancement 12. La détermination de telles valeurs des paramètres d’exécution de l’algorithme ACS est une étape cruciale du procédé d’ordonnancement, en ce qu’elle offre la possibilité de paramétrer l’algorithme de fourmis ACS. Autrement dit, déterminer de telles valeurs permet de contrôler le fonctionnement de l’algorithme ACS, et donc in fine la manière dont sont recherchées des solutions d’ordonnancement des tâches qui ont été associées au système de traitement 11, et qui sont donc connues de ce dernier, non seulement au moment de l’exécution de l’étape E10, mais également ultérieurement pour éventuellement un ou plusieurs autres ensembles de tâches. Dans le mode de mise en œuvre illustré par la figure 3, les valeurs de paramètres d’exécution sont déterminées au moyen d’un algorithme mettant en œuvre une méthode de plan d’expériences paramétrée par ladite fonction objectif. Il est connu que l’algorithme de fourmis, selon l’une quelconque de ses variantes, donc en particulier l’algorithme ACS, peut présenter une sensibilité importante par rapport à ses paramètres d’exécution. C’est pourquoi la mise en œuvre d’une méthode de plan d’expériences appropriée peut permettre d’en améliorer la robustesse. A cet effet, et selon un exemple préféré de mise en œuvre, la méthode de plan d’expériences utilisée au cours de l’étape E10 pour déterminer les valeurs des paramètres d’exécution est la méthode Taguchi. De manière générale, ladite méthode Taguchi est une méthode statistique permettant de réaliser des plans d'expériences ayant pour objectif de réduire la sensibilité aux perturbations externes d’un algorithme faisant l’objet desdites expériences. Cette méthode fournit une approche simple et systématique pour déterminer des valeurs optimales des paramètres d’exécution dudit algorithme, de sorte à en optimiser la robustesse. Dans son principe général, et en prenant en compte le contexte défini par le présent mode de mise en œuvre, la mise en œuvre de la méthode Taguchi consiste à définir un ensemble de valeurs pouvant être prises par chacun des paramètres d’exécution (α, β, Q_0, ρ, N_ant, min_eva) puis à réaliser une suite d’expérimentations de l’algorithme de fourmis ACS. Plus particulièrement, chaque expérimentation correspond à une mise en œuvre dudit algorithme de fourmis ACS dont les valeurs des paramètres d’exécution sont choisies dans ledit ensemble de valeurs. Le propre de la méthode Taguchi consiste à ne pas tester toutes les combinaisons possibles de valeurs dans ledit ensemble de valeurs, de sorte à réduire le nombre d’expérimentations à faire pour trouver les valeurs respectives des paramètres d’exécution permettant d’optimiser la robustesse de l’algorithme de fourmis ACS au regard des tâches jusqu’alors connues (i.e. les tâches dudit premier ensemble E_1). Le fait de chercher à optimiser la robustesse de l’algorithme de fourmis ACS pour ledit premier ensemble E_1 de tâches permet également de garantir la robustesse pour d’autres tâches susceptibles d’être ultérieurement associées au système de traitement 11. Pour ce faire, la méthode Taguchi s’appuie sur des matrices orthogonales référencées dans l’état de l’art qui permettent de déterminer quelles combinaisons de valeurs des paramètres d’exécution il convient de privilégier pour lesdites expérimentations. La méthode Taguchi n’est toutefois pas davantage décrite ici dans la mesure où elle est connue et très largement documentée. Pour plus de détails, il est possible de consulter le document : « La méthodologie Taguchi : introduction à la recherche technologique-gestion fonctionnelle de la qualité ou gestion «off-line» », Constant C., Revue de statistique appliquée, 37(2), 47-77, 1989. En outre, un exemple détaillé de mise en œuvre du procédé d’ordonnancement est décrit ultérieurement. Il est à noter que le choix selon lequel la méthode de plan d’expériences est la méthode Taguchi ne constitue qu’une variante d’implémentation de l’invention. L’invention reste en effet applicable indépendamment de la méthode de plan d’expériences considérée (plan en étoile, plan factoriel, plan avec matrices de Hadamard, etc.). En outre, et bien que le présent mode de mise en œuvre soit décrit en considérant que les valeurs de paramètres d’exécution sont déterminées au moyen d’un algorithme mettant en œuvre une méthode de plan d’expériences, rien n’exclut non plus de considérer que la détermination desdites valeurs soient mise en œuvre différemment. Par exemple, lesdites valeurs peuvent être déterminées de manière forcée (par exemple par un utilisateur), ou bien encore par des méthodes d’apprentissage supervisées ou non supervisées, etc. D’une manière générale, aucune limitation n’est attachée à la manière dont sont déterminées les valeurs des paramètres d’exécution. Le procédé d’ordonnancement comporte également, pour au moins un deuxième ensemble E_2 de tâches associé audit système de traitement 11, une étape E20 d’ordonnancement. Ladite étape E20 est mise en œuvre par le module d’ordonnancement MOD_ORD équipant le dispositif d’ordonnancement 12. Il est à noter que les tâches comprises dans le deuxième ensemble considéré immédiatement après l’ensemble E_1 comportent au moins les tâches déjà comprises dans ledit premier ensemble E_1. En effet, l’étape E10 vise uniquement à déterminer des valeurs des paramètres d’exécution de l’algorithme métaheuristique et ne fournit donc pas une solution d’ordonnancement en tant que tel. Bien entendu, des tâches autres que celles dans le premier ensemble E_1 peuvent être prises en compte lors de l’exécution de l’étape E20 pour le deuxième ensemble E_2, le nombre desdites autres tâches n’étant pas un facteur limitant de l’invention. Ladite étape E20 d’ordonnancement comporte : - une sous-étape E20_1 d’exécution de l’algorithme métaheuristique paramétré par les valeurs déterminées lors de l’étape E10 (ladite sous-étape E20_1 est mise en œuvre par le sous-module d’exécution SS_MOD_EXEC), et, si un critère d’arrêt CR_STOP de l’algorithme métaheuristique n’est pas atteint à l’issue de ladite exécution (sous-étape E20_2 de vérification de l’atteinte ou non du critère d’arrêt CR_STOP) (i.e. aucune solution d’ordonnancement n’est trouvée par l’algorithme métaheuristique au regard dudit critère d’arrêt CR_STOP) (ladite sous-étape E20_2 est mise en œuvre par le sous-module de vérification SS_MOD_VERIF), - une sous-étape E20_3 de mise à jour dudit au moins un deuxième ensemble E_2, par retrait d’au moins une tâche dudit au moins un deuxième ensemble E_2 (ladite sous-étape E20_3 est mise en œuvre par le sous-module de mise à jour SS_MOD_MAJ). En outre, ladite sous-étapes d’exécution E20_1, ainsi que ladite sous-étape E20_3 de mise à jour le cas échéant, sont itérées tant que le critère d’arrêt CR_STOP n’est pas atteint (ce qui signifie bien entendu que la sous-étape E20_2 de vérification est également itérée). Bien entendu, lorsque le critère d’arrêt CR_STOP n’est pas atteint, l’ensemble de tâches considéré au cours d’une itération desdites sous-étapes est l’ensemble de tâches mis à jour lors de l’itération précédente. Le fait d’itérer l’étape d’ordonnancement E20 permet, en raison des mises à jour des ensembles de tâches considérés au cours desdites itérations, de garantir l’obtention d’une solution d’ordonnancement. En effet, plus l’étape d’ordonnancement E20 est itérée, moins il y a de tâches à ordonnancer du fait desdites mises à jour. Selon un exemple de mise en œuvre, le critère d’arrêt CR_STOP correspond à une durée donnée d’exécution de l’algorithme métaheuristique, de sorte que si aucune solution d’ordonnancement n’est fournie par ledit algorithme métaheuristique une fois ladite durée dépassée, il est considéré que ce dernier n’a as convergé. Alternativement, le critère d’arrêt CR_STOP peut correspondre à un nombre donné d’itérations dudit algorithme métaheursitique. A nouveau, si ce nombre d’itérations est dépassé au cours de ladite sous-étape E20_1, il est considéré que ce dernier n’a as convergé. Selon encore une autre alternative, le critère d’arrêt CR_STOP peut correspondre à un seuil de la fonction objectif, de sorte que si ce seuil n’est pas atteint par les éventuelles solutions d’ordonnancement trouvées par l’algorithme métaheuristique, ces dernières sont jugées non satisfaisantes. D’une manière générale, aucune limitation n’est attachée à la nature du critère d’arrêt CR_STOP considéré dans ledit procédé d’ordonnancement Selon un exemple particulier de mise en œuvre, ladite au moins une tâche retirée lors de ladite sous-étape E20_3 de mise à jour est la tâche dont l’association au système de traitement 11 est la plus récente parmi les tâches dudit au moins un deuxième ensemble E_2 de tâches (par exemple, la tâche transmise en dernier au système de traitement 11 pour ordonnancement). Autrement dit, dans cet exemple particulier, et conformément à la convention de notation adoptée auparavant, la tâche éventuellement retirée est celle dont l’identifiant est le plus grand parmi les identifiants des tâches considérées au cours d’une mise en œuvre de l’étape d’ordonnancement E20. La mise en œuvre de cet exemple se justifie, notamment, par le fait qu’il peut être considéré comme plus prioritaire d’exécuter une tâche ancienne par rapport à une tâche récente. Rien n’exclut cependant de considérer que la tâche retirée lors de ladite sous-étape E20_3 de mise à jour diffère de la tâche dont la transmission au système de traitement 11 est la plus récente. Par exemple, chaque tâche peut être associée à un attribut déterminant un niveau de priorité d’exécution de ladite tâche, ce niveau de priorité n’étant pas corrélé à la date de transmission d’une tâche au système de traitement 11. Dès lors, la tâche retirée lors de ladite sous-étape E20_3 de mise à jour est la tâche dont la priorité est la moins élevée. D’une manière plus générale, aucune limitation n’est attachée à la tâche pouvant être retirée lors de ladite sous-étape E20_3 de mise à jour. En outre, rien n’exclut non plus de considérer le retrait de plus d’une tâche au cours de la mise en œuvre d’une sous-étape E20_3. Par exemple, les N tâches les plus récentes ou les moins prioritaires peuvent être retirées, N étant un entier strictement supérieur à 1. Aucune limitation n’est attachée à la valeur dudit nombre N, ni d’ailleurs aussi au critère que la base duquel le retrait d’une pluralité de tâches est envisagé. Il convient par ailleurs de noter que le retrait d’une tâche n’implique pas que ladite tâche n’est pas exécutée. Une tâche ainsi retirée peut en effet demeurer mémorisée pour être exécutée ultérieurement, lors d’une nouvelle mise en œuvre de l’étape d’ordonnancement E20. Selon un exemple de mise en œuvre, l’étape d’ordonnancement E20 est mise en œuvre dès que M tâches sont nouvellement associées au système de traitement 11 par rapport à la mise en œuvre précédente de ladite étape d’ordonnancement, M étant un entier supérieur ou égal à 1. Par exemple, M est égal à 3. Le fait d’itérer ainsi l’étape d’ordonnancement E20 permet d’ordonnancer des tâches transmises de manière récurrente au système de traitement 11. Il est en outre implicite que l’ordonnancement de tâches nouvellement associées au système de traitement 11 tient compte des tâches éventuellement déjà ordonnancées via ledit procédé d’ordonnancement selon l’invention. Aucune limitation n’est attachée à la valeur dudit entier M. On comprend que plus M est grand, plus le risque de ne pas trouver de solution d’ordonnancement au cours d’une mise en œuvre de la sous-étape E20_1 d’exécution est grand, obligeant ainsi à mettre en œuvre la sous-étape E20_3 de mise à jour. Dit encore autrement, il existe un compromis entre la valeur de M et la rapidité de convergence de l’ordonnancement. Le procédé d’ordonnancement a été décrit jusqu’à présent en considérant que l’étape E10 de détermination de valeurs des paramètres d’exécution était exécutée une seule fois. L’invention ne se limite néanmoins pas à une telle mise en œuvre. En effet, rien n’exclut d’envisager, suivant d’autres modes de mise en œuvre (non représentés sur la figure 3), que l’étape E10 de détermination est itérée de manière récurrente. Le fait d’itérer ainsi ladite étape E10 permet de mettre à jour les valeurs desdits paramètres d’exécution. En effet, les tâches qui sont considérées lors d’une itération de ladite étape E10 sont a priori différentes de celles considérées lors de la précédente mise en œuvre de l’étape E10. Procéder ainsi permet de paramétrer au mieux l’algorithme métaheuristique au regard de l’évolution des tâches transmises au système de traitement 11. A titre illustratif, l’étape E10 est itérée de manière journalière, par exemple à heure fixe. L’invention vise par ailleurs un procédé d’exécution d’au moins une tâche par le système de traitement 11. Ledit procédé d’exécution (non représenté sur les figures) comporte : - une étape d’ordonnancement d’au moins une tâche dans ledit système de traitement 11 conformément au procédé d’ordonnancement selon l’invention, - une étape d’exécution de ladite au moins une tâche selon l’ordonnancement déterminé au cours de ladite étape d’ordonnancement. On décrit désormais un exemple détaillé de mise en œuvre dudit procédé d’exécution. A cet effet, on considère dans cet exemple que le système de traitement 11 comporte deux dispositifs de traitement 11_1, 11_2 (N=2). Ces dispositifs de traitement 11_1, 11_2 peuvent être décrits suivant une convention similaire à celle utilisée pour les tâches de mesure. Plus particulièrement, chaque dispositif de traitement 11_1 s’écrit ici au moyen de différents champs P_1, …,P_k (k étant un indice entier propre à chaque dispositif de traitement) : P_1 (P_2 P_3 P_4) [P_5 … P_k] où : - P_1 est représentatif d’un identifiant du dispositif de traitement (dans le cas présent, il s’agit de l’indice « i » utilisé dans le sigle « 11_i ») ; - P_2, P_3 et P_4 sont respectivement représentatifs des ressources nominales (i.e. en dehors de toute sollicitation) de calculs, de mémoire et de bande passante dudit dispositif de traitement ; - P_5, …, P_k sont respectivement représentatifs des identifiants associés aux applications de mesure (ils s’agit donc aussi des identifiants des tâches de mesure respectivement associées auxdites applications de mesure) qui ont déjà été affectées audit dispositif de traitement en attente de leur exécution, suite par exemple à une précédente mise en œuvre du procédé d’ordonnancement. Dans le présent exemple, on considère que, avant la mise en œuvre dudit procédé d’exécution, le dispositif de traitement 11_1 s’écrit : 1 (100 100 100) [1] et que le dispositif de traitement 11_2 s’écrit : 2 (100 100 100) [2]. On considère en outre que les tâches de mesure dont les identifiants sont respectivement 1 et 2 s’écrivent : - tâche TA_1 avec identifiant 1 : 1 (1 6) 3 2 0 (60 60 60) (1 1 1) [1 2] [ ] [ ] ; - tâche TA_2 avec identifiant 2 : 1 (1 6) 3 1 2 (60 60 60) (1 1 1) [1 2] [ ] [ ]. Autrement dit, avant la mise en œuvre du procédé d’exécution (et donc a fortiori avant la mise en œuvre du procédé d’ordonnancement), un premier ensemble E_1 formé des tâches TA_1 et TA_2 est associé au système de traitement 11. Plus particulièrement, la tâche TA_1 est associé au dispositif 11_1, et la tâche TA_2 est associée au dispositif 11_2. Ces associations préalables font par exemple suite à des requêtes émises par des utilisateurs et ont été mémorisées en vue des exécutions des tâches. Comme mentionné ci-avant, le procédé d’exécution met tout d’abord en œuvre le procédé d’ordonnancement. A cet effet, la mise en œuvre de l’étape E10 de détermination, pour le premier ensemble E_1, s’effectue en utilisant la méthode Taguchi. L’ensemble de valeurs pouvant être prises par chacun des paramètres d’exécution (α, β, Q_0, ρ, N_ant, min_eva) est donné par un tableau TAB illustré en figure 4 . On note que chaque paramètre d’exécution est associé à 5 valeurs possibles. En outre, la méthode Taguchi est exécutée dans le présent exemple en utilisant une matrice dite « L25 » illustrée en figure 5 . Ladite matrice L25 se lit de la manière suivante : - chaque ligne correspond à une expérimentation pour un jeu de valeurs des paramètres d’exécution (autrement dit, dans le présent exemple, 25 expérimentations sont prises en compte) ; - chaque colonne j (j variant de 1 à 6) de la matrice L25 contient 25 indices permettant de savoir quelle valeur du paramètre d’exécution considéré en ligne j (j variant donc là aussi de 1 à 6) du tableau TAB est utilisé dans l’expérimentation associée à cette colonne j de ladite matrice L25. Plus précisément, un indice k (k variant de 1 à 5 puisque chaque paramètre d’exécution peut prendre 5 valeurs) d’une colonne j de la matrice L25 désigne la valeur du paramètre d’exécution située en ligne j et colonne k du tableau TAB. Dans le présent exemple, la méthode Taguchi est également exécutée en réalisant trois itérations des expérimentations associées à la matrice L25. Le fait de considérer trois itérations ne constitue bien entendu qu’une variante d’exécution, et toute autre valeur est envisageable, en particulier un nombre d’itérations plus grand que trois selon les sources de bruit considérées pour les paramètres d’exécution de l’algorithme ACS ainsi que les valeurs extrêmales pouvant être prises par ces sources de bruit (exemples de sources de bruit : exploration probabiliste biaisée du graphe par les fourmis, ordre de parcours des fourmis dans le graphe basé sur le délai maximal d’exécution associé à une tâche, disponibilité CPU/RAM, panne d’un processeur, etc.). Les inventeurs ont néanmoins constaté que le fait d’utiliser trois itérations permettaient de consolider les résultats fournis en sortie de l’étape E10 tout en préservant la charge de calculs. Aussi, à l’issue de l’étape E10, on obtient les valeurs suivantes pour les paramètres d’exécution de l’algorithme ACS : α = 2 ; β = 2 ; Q_0 = 0,5 ; ρ = 0,5 ; N_ant = 10 ; min_eva = 30. Dans cet exemple, on suppose également que trois nouvelles tâches de mesure (et donc trois nouvelles applications de mesure) sont associées au système de traitement 11, suite par exemple à une demande de déploiement desdites trois tâches par un utilisateur. On suppose en outre que l’étape d’ordonnancement E20 est mise en œuvre dès que trois (M=3) tâches sont nouvellement associées au système de traitement 11. Lesdites trois tâches de mesure dont les identifiants sont respectivement 3, 4 et 5 s’écrivent : - tâche TA_3 avec identifiant 3 : 3 (1 6) 3 2 1 (60 60 60) (1 1 1) [1 2] [ ] [ ] ; - tâche TA_4 avec identifiant 4 : 4 (1 6) 6 2 4 (60 60 60) (1 1 1) [1 2] [ ] [ ] ; - tâche TA_5 avec identifiant 5 : 5 (1 6) 6 2 4 (60 60 60) (1 1 1) [1 2] [ ] [ ]. On note que l’ordre d’association des tâches de mesure au système de traitement 11 est déterminé par les identifiants respectifs desdites tâches. Ainsi, la tâche TA_3 (respectivement TA_5) est la première tâche (respectivement la dernière tâche) associée au système de traitement 11 parmi lesdites trois tâches TA_3, TA_4, TA_5. On note par ailleurs que les tâches de l’ensemble E_1 n’ont pour l’instant pas été ordonnancées dans le système de traitement 11. Aussi, on désigne par E_2 un nouvel ensemble de tâches formé des tâches TA_1, TA_2, TA_3, TA_4 et TA_5, l’objectif consistant dès lors à ordonnancer les tâches dudit ensemble E_2 puisqu’il s’agit de toutes les tâches désormais associées au système de traitement 11. Aussi, on suppose que la mise en œuvre de l’étape E20 d’ordonnancement conduit, dans cet exemple détaillé et pour ledit ensemble E_2, au fait que l’algorithme ACS ne converge pas (test effectué lors de la sous-étape E20_2) au cours de la sous-étape E20_1 d’exécution. Par conséquent, l’ensemble E_2 est mis à jour. Plus particulièrement, dans cet exemple, la tâche la plus récente, donc la tâche TA_5, est retirée dudit ensemble E_2 au cours de la sous-étape E20_3. La sous-étape E20_1 est alors itérée pour l’ensemble de tâches mis à jour qui comporte les tâches TA_1, TA_2, TA_3 et TA_4, et une solution d’ordonnancement est obtenue, cette solution étant exécutée par le système de traitement 11. La figure 6 représente schématiquement ladite solution d’ordonnancement ainsi que son exécution. Tel qu’illustré par la figure 6, on considère un référentiel temporel composé de six instants distincts. Chacun de ces instants désigne l’instant de début d’un intervalle temporel. Dans cet exemple, les différents intervalles temporels ainsi considérés ont tous la même durée, à savoir une durée égale à une unité de temps dudit référentiel temporel. En outre, on considère que lesdits intervalles temporels se succèdent sans discontinuité. Ainsi, pour un premier intervalle dont l’instant de début est t=i (i étant un indice entier supérieur ou égal à 1), l’instant de fin dudit premier intervalle est l’instant t=i+1. Cet instant t=i+1 est également l’instant de début de l’intervalle succédant audit premier intervalle. Dès lors, on a que : - la tâche TA_1 est exécutée par le dispositif de traitement 11_1 pendant les intervalles dont les instants de début sont t=1 et t=2. Pendant l’intervalle dont l’instant de début est t=3, la tâche TA_1 migre (flèche en pointillés) vers le dispositif de traitement 11_2, puis est exécutée par ce dernier pendant les intervalles dont les instants de début sont t=4 et t=5 ; - la tâche TA_2 est exécutée pendant les intervalles dont les instants de début sont t=1 et t=6 par le dispositif de traitement 11_2 ; - la tâche TA_3 est tout d’abord affectée au dispositif de traitement 11_2 pendant l’instant t=1, pour y être exécutée pendant les intervalles dont les instants de début sont t=2 et t=3. Pendant l’intervalle dont l’instant de début est t=4, la tâche TA_3 migre vers le dispositif de traitement 11_1, puis est exécutée par ce dernier pendant les intervalles dont les instants de début sont t=5 et t=6 ; - la tâche TA_4 est affectée au dispositif de traitement 11_1 pendant l’instant t=1, pour y être exécutée pendant les intervalles dont les instants de début sont t=3 et t=4. L’invention a été décrite jusqu’à présent en considérant que le système de traitement 11 comportait une pluralité de dispositifs de traitement 11_i. Toutefois, l’invention est également applicable dans le cas où ledit système de traitement 11 comporte un unique dispositif de traitement multiprocesseurs, l’ordonnancement de tâches consistant dès lors à affecter des tâches aux différents processeurs dudit unique dispositif de traitement. Dès lors, dans ce cas, et lorsque chaque tâche est associée à une contrainte de localisation, ladite contrainte de localisation peut définir au moins un processeur parmi la pluralité de processeurs dudit unique dispositif de traitement. En outre, toujours dans ce même cas, l’algorithme métaheuristique est configuré de sorte à autoriser la migration de chaque tâche entre les processeurs dudit unique dispositif de traitement définis par la contrainte de localisation attachée à ladite tâche. Finalement, il convient de noter que l’invention peut également s’appliquer dans le cas où une pluralité de dispositif de traitement sont considérés, dont au moins une partie sont des dispositifs multiprocesseurs. L’ordonnancement de tâches consistant dès lors à affecter des tâches suivant différents niveaux : un premier niveau visant à attribuer uniquement un dispositif de traitement à une tâche, et un second niveau, plus fin que ledit premier niveau, visant à attribuer un processeur à ladite tâche lorsque ledit dispositif de traitement comporte une pluralité de processeurs. Procédé d’ordonnancement d’au moins une tâche dans un système de traitement (11) configuré pour exécuter ladite au moins une tâche, ledit procédé comportant, pour un premier ensemble (E_1) de tâches associé au système de traitement, une étape de détermination (E10) de valeurs de paramètres d’exécution (α, β, Q_0, ρ, N_ant, min_eva) d’un algorithme métaheuristique (ACS) configuré pour ordonnancer, dans ledit système de traitement, au moins une tâche associée audit système de traitement en optimisant une fonction objectif, le procédé comportant en outre, pour au moins un deuxième ensemble (E_2) de tâches associé audit système de traitement, une étape d’ordonnancement (E20) comprenant : - une exécution (E20_1) de l’algorithme métaheuristique paramétré par lesdites valeurs, et, si un critère d’arrêt (CR_STOP) de l’algorithme métaheuristique n’est pas atteint à l’issue de ladite exécution (E20_2), - une mise à jour (E20_3) dudit au moins un deuxième ensemble, par retrait d’au moins une tâche dudit au moins un deuxième ensemble, ladite exécution, et ladite mise à jour le cas échéant, étant itérées tant que le critère d’arrêt n’est pas atteint. Procédé selon la revendication 1, dans lequel chaque tâche est associée à une date d’exécution souhaitée, et, pour chaque ordonnancement candidat trouvé par l’algorithme métaheuristique, à un délai, dit « délai d’exécution effectif », représentatif de la durée suivant laquelle l’exécution de ladite tâche est différée par rapport à ladite date d’exécution souhaitée, ladite fonction objectif comportant un terme égal à la somme des délais d’exécution effectifs respectivement associés aux tâches prises en compte par l’algorithme métaheuristique (ACS), ledit terme étant destiné à être minimisé par ledit algorithme métaheuristique. Procédé selon l’une quelconque des revendications 1 à 2, dans lequel : - le système de traitement (11) comporte une pluralité de processeurs, - chaque tâche est associée à un attribut « dit contrainte de localisation » définissant au moins un processeur parmi ladite pluralité de processeurs, de sorte que ladite tâche est destinée à être exécutée par un processeur quelconque parmi ledit au moins un processeur défini par ladite contrainte de localisation, - l’algorithme métaheuristique (ACS) est configuré de sorte à autoriser la migration de chaque tâche entre des processeurs définis par la contrainte de localisation attachée à ladite tâche, ladite fonction objectif comportant un terme égal à un nombre de migrations des tâches prises en compte par l’algorithme métaheuristique, ledit terme étant destiné à être minimisé par ledit algorithme métaheuristique. Procédé selon l’une quelconque des revendications 1 à 3, dans lequel les valeurs de paramètres d’exécution (α, β, Q_0, ρ, N_ant, min_eva) sont déterminées au moyen d’un algorithme mettant en œuvre une méthode de plan d’expériences paramétrée par ladite fonction objectif. Procédé selon la revendication 4, dans lequel ladite méthode de plan d’expériences est la méthode Taguchi. Procédé selon l’une quelconque des revendications 1 à 5, dans lequel l’algorithme métaheuristique (ACS) est un algorithme de colonies de fourmis mis en œuvre à partir d’un graphe dont chaque nœud correspond à un ordonnancement d’une tâche dans le système de traitement (11). Procédé selon la revendication 6, dans lequel les paramètres d’exécution (α, β, Q_0, ρ, N_ant, min_eva) comportent un paramètre (min_eva) permettant de contrôler une quantité minimale de phéromones pouvant être associée à un nœud. Procédé selon l’une quelconque des revendications 1 à 7, dans lequel ladite au moins une tâche retirée lors de ladite mise à jour (E20_3) est la tâche dont l’association au système de traitement (11) est la plus récente parmi les tâches dudit au moins un deuxième ensemble (E_2) de tâches. Procédé selon l’une quelconque des revendications 1 à 8, dans lequel l’étape d’ordonnancement (E20) est itérée dès que M tâches sont nouvellement associées au système de traitement, M étant un entier supérieur ou égal à 1. Procédé selon l’une quelconque des revendications 1 à 9, dans lequel l’étape de détermination (E10) est itérée de manière récurrente de sorte à mettre à jour les valeurs desdits paramètres d’exécution (α, β, Q_0, ρ, N_ant, min_eva). Procédé selon l’une quelconque des revendications 1 à 10, dans lequel une tâche correspond à une mesure de l’état d’un réseau de communication auquel appartient au moins une partie du système de traitement (11) ou de la qualité d’un service supporté par ledit réseau de communication. Procédé selon la revendication 11, dans lequel chaque tâche est exécutée grâce à une application de mesure intégrée à un conteneur. Programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé d’ordonnancement selon l’une quelconque des revendications 1 à 12 lorsque ledit programme d’ordinateur est exécuté par un ordinateur. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon la revendication 13. Dispositif d’ordonnancement (12) d’au moins une tâche dans un système de traitement (11) configuré pour exécuter ladite au moins une tâche, ledit dispositif d’ordonnancement comportant un module de détermination (MOD_DET) configuré pour déterminer, pour un premier ensemble (E_1) de tâches associées au système de traitement, des valeurs de paramètres d’exécution (α, β, Q_0, ρ, N_ant, min_eva) d’un algorithme métaheuristique (ACS) configuré pour ordonnancer, dans ledit système de traitement, au moins une tâche associée audit système de traitement en optimisant une fonction objectif, le dispositif d’ordonnancement comportant en outre un module d’ordonnancement (MOD_ORD) comprenant : - un sous-module d’exécution (SS_MOD_EXEC) configuré pour exécuter l’algorithme métaheuristique paramétré par lesdites valeurs pour au moins un deuxième ensemble (E_2) de tâches associé audit système de traitement, - un sous-module de vérification (SS_MOD_VERIF) configuré pour vérifier si un critère d’arrêt (CR_STOP) est atteint ou non à l’issue d’une exécution de l’algorithme métaheuristique mise en œuvre par ledit sous-module d’exécution pour ledit moins un deuxième ensemble, - un sous-module de mise à jour (SS_MOD_MAJ) configuré pour mettre à jour ledit au moins un deuxième ensemble, par retrait d’au moins une tâche dudit au moins un deuxième ensemble, lorsque ledit critère d’arrêt n’est pas atteint. Système informatique (10) comportant un dispositif d’ordonnancement (12) selon la revendication 15 ainsi qu’un système de traitement (11) configuré pour exécuter au moins une tâche destinée à être ordonnancée par ledit dispositif d’ordonnancement. Procédé d’exécution d’au moins une tâche par un système de traitement (11) configuré pour exécuter ladite au moins une tâche, ledit procédé d’exécution comportant : - une étape d’ordonnancement d’au moins une tâche dans ledit système de traitement conformément à un procédé d’ordonnancement selon l’une quelconque des revendications 1 à 12, - une étape d’exécution de ladite au moins une tâche selon l’ordonnancement déterminé au cours de ladite étape d’ordonnancement.