Brevet FR3155081A1 — publié le 20250509

L’invention propose une solution pour déterminer la charge d’une plateforme réseau et ajuster des ressources de cette plateforme en fonction de cette estimation. Cette solution comporte : - l’obtention (E10) d’un historique de requêtes (RQ i,r ) reçues par la plateforme réseau (PS) au cours de périodes de temps passées (PT r ) ; - l’obtention (E20) de la charge (LOAD i,r , LOAD k i,r ) de la plateforme réseau (PS) au cours de ces périodes de temps (PT r ) ; - l’entraînement (E80) d’un modèle (MOD i ) avec ces données, - la détermination de la charge de la plateforme réseau (PS) au cours d’une période de temps future par utilisation de ce modèle ; - l’ajustement de ressources de la plateforme pour ladite période de temps future en fonction d’un résultat de cette détermination. Fig. 2 Procédés et entités pour déterminer la charge d’une plateforme réseau et ajuster des ressources de la plateforme en fonction de cette estimation L’invention se situe dans le contexte des réseaux de télécommunications, et plus précisément dans celui de l’optimisation de la qualité du service rendu par des plateformes réseau. L’invention trouve une application privilégiée mais non limitative dans le contexte des réseaux dits de nouvelle génération (en anglais NGN, pour Next Generation Networks) dans lequel des opérateurs de réseaux de télécommunications offrent à des tiers l’accès à des services en mettant à leur disposition des interfaces de programme d’application, ci-après API (en anglais Application Programming Interface). Le dimensionnement et la disponibilité des ressources de ces plateformes (en terme de puissance de calcul, de mémoire, de capacité de stockage par exemple) sont déterminants pour la qualité du service rendu par ces plateformes. Dans l’état actuel de la technique, les ressources allouées par ces plateformes sont ajustées pour répondre à leur charge (an anglais « autoscalling »). Pratiquement, des ressources sont allouées (respectivement libérées) lorsque la charge devient supérieure (respectivement inférieure) à des seuils prédéterminés. Ces techniques bien que satisfaisantes, présentent certains inconvénients en raison du temps nécessaire pour : - dupliquer les environnements d’exécution (par exemple des conteneurs) et démarrer des composants logiciels pour répondre à une montée de charge, et pour : - arrêter des composants logiciels et à libérer les environnements d’exécution en cas de baisse de charge. L’invention vise une solution pour ajuster les ressources d’une plateforme réseau qui ne présente pas ces inconvénients. Objet et résumé de l’invention Ainsi, et selon un premier aspect, l’invention concerne un procédé d’entraînement d’un modèle de détermination de la charge d’une plateforme réseau, ce procédé étant mis en œuvre par un ordinateur et comportant les étapes suivantes : - obtention d’un historique de requêtes émises par au moins un tiers et reçues par la plateforme réseau au cours d’au moins une période de temps passée ; - obtention d’au moins une charge d’au moins un module de ladite plateforme réseau au cours de ladite au moins une période de temps ; - entraînement du modèle avec les des données d’entraînement comportant au moins une donnée temporelle représentative de ladite au moins une période de temps et la dite au moins une charge obtenue, une utilisation (ou inférence) du modèle entraîné permettant de déterminer la charge dudit au moins un module de ladite plateforme réseau au cours d’une période de temps fournie en entrée du modèle. Dans un mode de réalisation, la charge de la plateforme ou d’un module de la plateforme est le nombre de requêtes traitées par unité de temps par cette plateforme ou par ce module. Dans un mode de réalisation, le procédé d’entraînement comporte en outre : - une obtention d’au moins une latence dudit au moins un module de ladite plateforme réseau au cours de ladite au moins une période de temps ; - les données d’entraînement du modèle comportant ladite au moins une latence, une utilisation du modèle entraîné permettant en outre de déterminer la latence dudit au moins un module de ladite plateforme réseau au cours de la période de temps fournie en entrée du réseau. Dans un mode de réalisation, la latence de la plateforme ou d’un module de la plateforme est le temps de réponse global d’une requête par un cette plateforme ou par ce module. Dans un mode de réalisation, les données d’entraînement comportent en outre un identifiant du tiers émetteur de ladite au moins une requête. Ce mode de réalisation permet d’entraîner le modèle à prédire la latence ou la charge induites par les requêtes d’un tiers en particulier. Dans un mode de réalisation, les données d’entraînement comportent en outre un identifiant d’une application dans le cadre de laquelle ladite au moins une requête a été émise. Ce mode de réalisation permet d’entraîner le modèle à prédire la latence ou la charge induites par les requêtes d’une application en particulier. Le modèle utilisé par l’invention peut par exemple être un réseau de neurones récurrent. Ce modèle peut aussi utiliser une forêt comportant au moins un arbre de décision. L’invention vise également un modèle de détermination de la charge d’une plateforme au cours d’une période de temps, ce modèle étant obtenu par un procédé tel que mentionné ci-dessus. Selon un deuxième aspect, l’invention vise un procédé de détermination de la charge d’au moins un module d’une plateforme réseau, ce procédé comportant une étape d’utilisation d’un modèle de prédiction de charge tel que mentionné ci-dessus pour déterminer la charge et éventuellement la latence d’au moins un module de la plateforme réseau au cours d’une période de temps fournie en entrée du réseau. Corrélativement, l’invention concerne une entité de détermination de la charge d’au moins un module d’une plateforme réseau, cette entité exposant au moins une interface de programme d’application permettant de déclencher l’exécution d’au moins une utilisation d’au moins un modèle de détermination de charge entraîné par un procédé d’entraînement tel que mentionné ci-dessus pour déterminer la charge d’au moins un module d’une plateforme réseau au cours d’une période de temps fournie en entrée du réseau. Selon un troisième aspect, l’invention concerne un procédé de fourniture d’un service réseau mis en œuvre par une plateforme réseau et comportant les étapes suivantes : - obtention d’une estimation de la charge d’au moins un module de ladite plateforme réseau au cours d’une période de temps par la mise en œuvre d’un procédé de détermination tel que mentionné ci-dessus ; - ajustement de ressources dudit au moins un module pour ladite période de temps en fonction d’un résultat de ladite détermination ; - traitement d’au moins une requête émise par un tiers pour accéder audit service en utilisant lesdites ressources ajustées. L’invention vise également une plateforme réseau comportant : - un module configuré pour interroger une entité de détermination de charge telle que mentionnée précédemment pour obtenir une estimation de la charge d’au moins un module de ladite plateforme réseau au cours d’une période de temps ; - un module d’ajustement de ressources dudit au moins un module pour ladite période de temps en fonction d’un résultat de ladite détermination ; - un module de traitement d’au moins une requête émise par un tiers pour accéder à un service réseau fourni par ladite plateforme en utilisant lesdites ressources ajustées. Ainsi, et de façon très avantageuse, l’invention propose d’entraîner un modèle pouvant être utilisé pour déterminer, autrement dit prédire, la charge et éventuellement la latence d’une plateforme réseau ou de modules d’une plateforme réseau au cours d’une période de temps future de manière à pouvoir ajuster les ressources de la plateforme ou de certains de ses modules en vue de pouvoir traiter les requêtes qui seront reçues au cours de cette période de temps future avec les ressources ainsi ajustées. Ainsi, les ressources de la plateforme sont dimensionnées en fonction des besoins à venir de la plateforme, et réservées de façon anticipée. Les inconvénients de l’art antérieur liés au temps nécessaire pour dupliquer ou libérer des environnements d’exécution, démarrer ou arrêter des composants logiciels pour répondre à une montée ou à une baisse de charge sont donc résolus par l’invention. Avantageusement, si la latence de la plateforme ou d’un de ses modules est déterminée nulle ou relativement faible pour une période de temps future, l’invention propose, dans un mode de réalisation de ne pas allouer de ressources supplémentaires pour cette période de temps. Dans un mode de réalisation, le procédé d’entraînement comporte en outre : - une étape de comparaison d’une charge réelle ou d’une latence réelle d’au moins un module de ladite plateforme réseau avec la charge ou la latence déterminée de ce dit au moins un module pendant une période de temps et ; - une étape de réentraînement du modèle en fonction d’un résultat de cette comparaison. Ce mode de réalisation permet avantageusement de ré-entraîner le modèle lorsque celui-ci ne détermine plus la charge ou la latence de manière satisfaisante. Dans un mode de réalisation particulier, le modèle n’est ré-entraîné que lorsqu’une telle dérive est constatée. L’invention vise aussi un programme d’ordinateur comportant des instructions pour exécuter les étapes du procédé d’entraînement et/ou les étapes du procédé de détermination de charge et/ou les étapes de fourniture d’un service réseau lorsque ledit programme 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. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations 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, une mémoire non volatile de type flash ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, le support d'informations 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 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. 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 des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures : FIG. 1 La FIG. 1 représente un modèle pouvant être mis en œuvre dans un mode particulier de réalisation de l’invention ; FIG. 2 La FIG. 2 représente les principales étapes d’une procédé d’entraînement conforme à un mode de réalisation de l’invention ; FIG. 3 La FIG. 3 illustre des exemples de données d’’entraînement pouvant être utilisées dans des modes particuliers de réalisation de l’invention ; FIG. 4 La FIG. 4 représente un autre modèle pouvant être mis en œuvre dans un mode particulier de réalisation de l’invention ; FIG. 5 La FIG. 5 représente une entité de détermination de charge conforme à un mode particulier de réalisation de l’invention ; FIG. 6 La FIG. 6 représente une plateforme réseau conforme à un mode particulier de réalisation de l’invention ; FIG. 7 La FIG. 7 représente sous forme d’organigramme les principales étapes d’un procédé de prédiction de charge et les principales étapes d’un procédé de fourniture de service conformes à des modes particuliers de réalisation l’invention; FIG. 8 La FIG. 8 représente l’architecture matérielle d’une entité de détermination de charge et d’une plateforme réseau conformes à l’invention dans modes particuliers de réalisation l’invention. La FIG. 1 représente un modèle MOD i mis en œuvre par ordinateur et configuré pour déterminer ou prédire la charge LOAD i,j et la latence LAT i,j d’une plateforme réseau pour répondre aux requêtes qui seront reçues d’un tiers T i pendant une période de temps future PT j. Dans un autre mode de réalisation de l’invention, le modèle MOD i ne prédit que la charge LOAD i,j . Ce modèle MOD i est entraîné par un procédé d’entraînement PTR conforme à un mode particulier de réalisation de l’invention et dont les principales étapes sont décrites en référence à la FIG. 2 . Ce procédé d’entraînement comporte une étape E10 d’obtention de l’historique des requêtes RQ i,r reçues de ce tiers T i sur des périodes de temps passées PT r (autrement dit un historique des requêtes reçues sur des périodes de temps passées), et une étape E20 d’obtention d’au moins une charge LOAD i,r (et dans cet exemple d’au moins une latence LAT i,r ) de la plateforme au cours de ces périodes. Dans un mode de réalisation, de nouvelles données d’historique de requêtes, de charge et de latence sont reçues tous les jours et agrégées aux données antérieures (étape E30). Différents modèles peuvent être utilisés selon le pas temporel de détermination souhaité et la quantité de données d’historique à traiter par le modèle. Par exemple, si on souhaite prédire la charge (et la latence) de la plateforme pour chaque heure d’une journée, un réseau de neurones récurrent, par exemple du type LSTM (Long Short Term Memory) peut être utilisé. De façon connue, une méthode pour entraîner un réseau de neurones récurrent MOD i peut consister à diviser les données en un ensemble de données d’entraînement et un ensemble de données de test, les données d'entraînement étant utilisées pour former le modèle, les données de test étant utilisées pour évaluer ses performances. Ces données d’entraînement et de test comportent les données temporelles représentatives des périodes de temps au cours desquelles des requêtes ont été reçues par la plateforme, la charge et éventuellement la latence de la plateforme ou d’au moins certains de ses modules au cours de ces périodes de temps. Elles peuvent aussi comporter des données supplémentaires, par exemple un identifiant du tiers émetteur de la requête ou un identifiant d’une application dans le cadre de laquelle le tiers a émis cette requête. Le réseau de neurones est entraîné pour effectuer une tâche de régression consistant à prédire la charge de la plateforme (réseau de neurones à une seule sortie) et éventuellement sa latence (réseau de neurones à deux sorties) au cours d’une période de temps, en fonction des périodes de temps (données d’entrée). Le réseau de neurones peut être validé et mis au point sur l'ensemble des données de test. Dans un autre mode de réalisation, si on souhaite prédire la charge (et la latence) de la plateforme pour des périodes de temps beaucoup plus courtes, par exemple de l’ordre de la minute, on peut utiliser un modèle de régression linéaire, par exemple basé sur un arbre de décision ou sur une forêt d’arbres de décision. De façon connue également, une méthode pour entraîner une forêt d’arbres de décision peut consister à former chaque arbre sur une sous-partie de l'ensemble d'entraînement avec des échantillons aléatoires et des caractéristiques aléatoires (sous-ensemble aléatoire des caractéristiques), chacun des arbres étant entraîné sur sa partie respective de l'ensemble d'entraînement pour prédire la charge de la plateforme en fonction d’une période de temps. Les prédictions individuelles peuvent être agrégées (par exemple en prenant la moyenne des prédictions pour une régression) pour déterminer la prédiction finale de la forêt. Les données de test peuvent être utilisées pour évaluer les performances de la forêt d'arbres de décision, par exemple en utilisant l'erreur quadratique moyenne. Un réseau de type Transformer peut être utilisé. Dans un mode particulier de réalisation, la procédé d’entraînement comporte une étape E40 de préparation des données d’entraînement du modèle. Cette préparation facultative dépend du type de modèle. La FIG. 3 (a) représente le format des données utilisées pour entraîner un réseau de neurones récurrent, par exemple de type LSTM. Dans ce mode de réalisation les données temporelles représentatives des périodes de temps peuvent être des données d’horodatage HD r extraites directement des requêtes. La FIG. 3 (b) représente le format des données utilisées pour entraîner un arbre ou une forêt d’arbres de décision. Dans ce mode de réalisation, les données temporelles représentatives des périodes de temps PTr peuvent être des données calendaires DC r (tranche horaire, heure, jour de la semaine, mois, …) déterminées à partir des données d’horodatage HD r . Comme mentionné précédemment, les données d’entraînement peuvent comporter un identifiant du tiers T i émetteur de la requête ou un identifiant d’une application dans le cadre de laquelle la requête a été émise. Dans un mode particulier de réalisation, et comme représenté à la FIG. 3 (c), les données d’entraînement peuvent aussi comprendre des données contextuelles complémentaires DCC obtenues à partir des périodes de temps PT r . Par exemple, ces données complémentaires comportent : - une information binaire indiquant si la période de temps PTr correspond à un week-end ; ou - une information indiquant que la période de temps PTr correspond à un événement particulier, par exemple un événement sportif, une campagne publicitaire, … Ces données complémentaires permettent d’améliorer le modèle de prédiction lorsque la distribution des requêtes émises par le tiers T i est corrélé à ces données complémentaires, par exemple si le nombre de requêtes augmente en semaine, diminue le weekend et augmente considérablement pendant une campagne publicitaire du tiers. Dans un mode de réalisation, le modèle MOD i est entraîné une première fois, puis ré entraîné lorsqu’on constate une dérive entre la charge LOAD i,j (ou la latence LAT i,j ) prévue par ce modèle sur une période de temps PT j et la charge réelle LOAD R i,j (ou la latence réelle LOAD R i,j ) de la plateforme mesurées pendant cette période de temps PT j . A cet effet, la procédé d’entraînement comporte, dans ce mode de réalisation, une étape E50 d’obtention de la charge LOAD R i,j et de la latence LAT R i,j réelles pendant la période de temps PT j , une étape E60 d’obtention de la charge LOAD i,j et de la latence LAT i,j déterminées par utilisation du modèle MOD i pendant cette période de temps PT j , et une étape E70 de comparaison de ces charge et latence réelles avec les charge LOAD i,j et LAT i,j déterminées par le modèle sur cette période de temps PT j . Dans le mode de réalisation décrit ici, lorsque l’écart entre les charges réelle et prédite ou entre les latences réelle et prédite dépasse un seuil déterminé (par exemple 10%), le modèle est ré-entraîné (étape E80) sur la base des données d’entraînement agrégées à l’étape E30. Dans un mode particulier de réalisation, l’apprentissage du réseau de neurones récurrent met en œuvre un mécanisme d’apprentissage par transfert (en anglais Transfer Learning), de manière à ne ré-entrainer le réseau que sur des périodes courtes, par exemple trois mois, et ainsi réduire le temps d’entraînement. Dans les modes de réalisation décrits précédemment, on considère la charge et la latence de la plateforme réseau prise dans son ensemble. Dans un autre mode de réalisation représenté à la FIG. 4 , la plateforme réseau est composée d’une pluralité de modules fonctionnels MF k et on entraine un modèle MOD k i pour chaque module MF k et chaque tiers T i . Ce mode de réalisation permet avantageusement de prédire la charge LOAD k i,j et la latence LAT k i,j de chacun de ces modules MF k pour traiter les requêtes à venir en provenance du tiers i sur une période de temps PT j . Chacun de ces modules peut être ré-entraîner lorsqu’on constate une dérive entre la charge ou la latence réelle et la charge ou la latence prédite de ce module. Dans le mode de réalisation décrit ici, les modèles MOD i de la plateforme ou MOD k i des modules fonctionnels MF k de la plateforme entrainés sont exposés sous forme d’API. La FIG. 5 représente une entité LPS de détermination de charge conforme à l’invention. Dans le mode de réalisation décrit ici, cette entité LPS offre trois API API 1 , API 2 et API 3 . On suppose dans cet exemple que des modèles MOD i , MOD k i ont été entraînés pour I tiers (i=1 à I). La première API API 1 permet d’obtenir pour un tiers i, la charge LOAD i,j et la latence LAT i,j de la plateforme pour une période de temps à venir PT j . Ces informations de charge et de latence sont obtenues directement par utilisation du modèle MOD i . La deuxième API API 2 permet d’obtenir la charge LOAD j et la latence LAT j de la plateforme pour une période de temps à venir PT j . Ces informations de charge et de latence sont obtenues en prenant en compte les informations de charge et de latence obtenues par utilisation pour chacun des tiers i. La première API API 3 permet d’obtenir pour un tiers i, la charge LOAD k i,j et la latence LAT k i,j de chacun des modules fonctionnels MF k de la plateforme pour une période de temps à venir PT j . Ces informations de charge et de latence par module fonctionnel sont obtenues directement par utilisation des modèles MOD k i . La FIG. 6 représente une plateforme réseau PS conforme à l’invention. Cette plateforme comporte un module de communication COM configuré pour interroger l’entité LPS de détermination de charge afin d’obtenir une estimation de la charge (et dans cet exemple de la latence) de cette plateforme ou de modules fonctionnels de cette plateforme au cours d’une période de temps PT j à venir. Si cette plateforme réseau sert une pluralité de tiers i n , n=1 à N, elle peut interroger l’entité LPS pour chacun de ces tiers i n de sorte à connaître les ressources dont elle aura besoin pour traiter les requêtes de ces tiers pendant la période de temps PT j . Cette interrogation peut être effectuée régulièrement, par exemple toutes les heures. Dans cet exemple, la plateforme réseau PS comporte un module MAR d’ajustement de ressources pour ajuster de façon anticipée, c’est-à-dire avant la période de temps PT j , les ressources fonctionnelles de la plateforme, ou de certains de ses modules, à ses besoins. Cet ajustement de ressources peut par exemple consister à allouer ou à libérer de nouveaux environnements d’exécution, de nouveaux conteneurs, de la mémoire vive, de l’espace disque, à démarrer ou à terminer des processus logiciels. Préférentiellement, la plateforme n’instancie pour une période de temps PTj que les ressources prédites. Dans un mode de réalisation particulier de l’invention, si la latence prédite pour une période de temps est nulle ou très faible (par exemple inférieure à un seuil prédéterminé), aucune ressource n’est allouée. La plateforme réseau PS comporte un module MTR configuré pour traiter les requêtes émises par un tiers pour accéder à un service réseau fourni par la plateforme en utilisant les ressources ajustées. La FIG. 7 représente sous forme d’organigramme les principales étapes d’un procédé PCL de détermination de charge et les principales étapes d’un procédé PFS de fourniture de service conformes à l’invention. On suppose ici que les procédés PCL de détermination de charge et PFS de fourniture de service sont mis en œuvre par l’entité LPS de prédiction de charge et par la plateforme réseau PS. Dans le mode de réalisation décrit ici, et selon une fréquence paramétrable par un administrateur de la plateforme réseau PS, la procédé PFS invoque (étape S10) une des API de l’entité LPS de détermination de charge pour obtenir une estimation de la charge (et dans cet exemple de la latence) de cette plateforme ou de modules fonctionnels de cette plateforme pour traiter les requêtes des tiers i n auxquels la plateforme PS rend des services au cours d’une plage de temps future PT j . L’appel à cet API déclenche une utilisation des modèles MOD in ou MOD k in entraînés pour chacun de ces tiers i n par le procédé PCL de d’estimation de charge (étape P10). Au cours d’une étape P20 du procédé PCL d’estimation de charge, l’entité LPS envoie les estimations de charge et de latence à la plateforme de service PS. Ces estimations sont reçues par la plateforme PS au cours d’une étape S20. Ces estimations peuvent être envoyées de façon globale et/ou par tiers et/ou par module fonctionnel MF k . Au cours d’une étape S30 du procédé de fourniture de service PFS, la plateforme ajuste ses ressources conformément à ces estimations. Dans un mode de réalisation, aucune nouvelle ressource n’est allouée si la latence prévue est nulle ou très faible (inférieure à un seuil). Dans un mode de réalisation, au moins un composant fonctionnel de la plateforme est associé à un coefficient se sensibilité, et la quantité de ressource à allouer à ce composant est fonction de la charge prédite pour ce composant et de ce coefficient de sensibilité. Au cours d’une étape générale S40, la plateforme réseau PS utilise lesdites ressources ajustées pour traiter les requêtes émises par les tiers pendant la période de temps PT j pour accéder audit service en utilisant lesdites ressources ajustées. Dans un mode de réalisation de l’invention, le dispositif utilisé pour entraîner le modèle, l’entité de détermination de charge et la plateforme réseau ont chacun l’architecture matérielle d’un ordinateur telle que représentée à la FIG. 8 . Elle comporte notamment un processeur 10, une mémoire vive 11, une mémoire morte 12 et des moyens de communication 13. La mémoire morte 12 constitue un support d’enregistrement au sens de l’invention dans lequel peut être enregistré un programme d’ordinateur. Dans l’exemple de la FIG. 8 , trois programmes sont représentés mais l’invention couvre les modes de réalisations dans lequel la mémoire morte comporte au moins l’un de ces programmes. En particulier, ce programme d’ordinateur peut être un programme PGE comportant des instructions pour exécuter les étapes d’un procédé d’entraînement PTR tel que décrit en référence à la FIG. 2 . En particulier, ce programme d’ordinateur peut être un programme PGD comportant des instructions pour exécuter les étapes d’un procédé PCL de détermination de la charge d’au moins un module d’une plateforme réseau tel que décrit en référence à la FIG. 7 . En particulier, ce programme d’ordinateur peut être un programme PGS comportant des instructions pour exécuter les étapes d’un procédé PFS de fourniture de service tel que décrit en référence à la FIG. 7 . Procédé (PTR) d’entraînement d’un modèle (MOD i ) de détermination de la charge d’une plateforme réseau (PS), ce procédé étant mis en œuvre par un ordinateur et comportant les étapes suivantes : - obtention (E10) d’un historique de requêtes (RQ i,r ) émises par au moins un tiers (T i ) et reçues par la plateforme réseau (PS) au cours d’au moins une période de temps (PT r ) passée ; - obtention (E20) d’au moins une charge (LOAD i,r , LOAD k i,r ) d’au moins un module de ladite plateforme réseau (PS) au cours de ladite au moins une période de temps (PT r ) ; - entraînement (E80) du modèle (MOD i ) avec des données d’entraînement comportant au moins une donnée temporelle (HD, CAL, EVT) représentative de ladite au moins une période de temps et ladite au moins une charge (LOAD i,r , LOAD k i,r ), une utilisation du modèle entraîné permettant de déterminer la charge (LOAD i,r , LOAD k i,r ) dudit au moins un module de ladite plateforme réseau (PS) au cours d’une période de temps (PT r ) fournie en entrée du modèle. Procédé d’entraînement selon la revendication 1 comportant en outre : - une obtention (E20) d’au moins une latence (LAT i,r , LAT k i,r ) dudit au moins un module de ladite plateforme réseau (PS) au cours de ladite au moins une période de temps (PT r ) ; - lesdites données d’entraînement comportant ladite au moins une latence (LAT i,r , LAT k i,r ), une utilisation du modèle entraîné permettant en outre de déterminer la latence (LAT i,r , LAT k i,r ) dudit au moins un module de ladite plateforme réseau (PS) au cours de ladite période de temps (PT r ) fournie en entrée du modèle. Procédé d’entraînement selon la revendication 1 ou 2 dans lequel les données d’entraînement comportent en outre un identifiant du tiers (T i ) émetteur de ladite au moins une requête ou un identifiant d’une application dans le cadre de laquelle ladite au moins une requête a été émise. Procédé d’entraînement selon l’une quelconque des revendications 1 à 3 comportant en outre : - une étape (E70) de comparaison d’une charge ou d’une latence réelle (LOAD R i,r , LOAD Rk i,r, LAT R i,r , LAT Rk i,r ) d’au moins un module de ladite plateforme réseau avec la charge ou la latence déterminée (LOAD R i,r , LOAD Rk i,r, LAT R i,r , LAT Rk i,r ) de ce dit au moins un module au cours d’une période de temps et ; - une étape (E80) de réentraînement dudit modèle en fonction d’un résultat de ladite comparaison. Procédé d’entraînement selon l’une quelconque des revendications 1 à 4 dans lequel ledit modèle (MODi) est un réseau de neurones récurrent ou dans lequel ledit modèle (MODi) utilise une forêt comportant au moins un arbre de décision. Procédé (PCL) de détermination de la charge d’au moins un module d’une plateforme réseau (PS), ce procédé comportant une étape (P20) d’utilisation d’un modèle de détermination de charge entraîné par un procédé selon l’une quelconque des revendications 1 à 5 pour déterminer au moins la charge de la plateforme réseau (PS) au cours d’une période de temps fournie en entrée du réseau. Procédé (PFS) de fourniture d’un service réseau mis en œuvre par une plateforme réseau et comportant les étapes suivantes : - obtention (P10) d’une estimation de la charge d’au moins un module de ladite plateforme réseau (PS) au cours d’une période de temps par la mise en œuvre d’un procédé de détermination selon la revendication 6 ; - ajustement (P30) de ressources dudit au moins un module pour ladite période de temps en fonction d’un résultat de ladite détermination ; - traitement (P40) d’au moins une requête émise par un tiers pour accéder audit service en utilisant lesdites ressources ajustées. Entité (LPS) de détermination de la charge d’au moins un module d’une plateforme réseau, cette entité exposant au moins une interface de programme d’application (API 1 , API 2 , API 3 ) permettant de déclencher l’exécution d’au moins une utilisation d’au moins un modèle de détermination de charge entraîné par un procédé d’entraînement selon l’une quelconque des revendications 1 à 5 pour déterminer la charge d’au moins un module (MF k ) d’une plateforme réseau (PS) au cours d’une période de temps fournie en entrée du réseau. Plateforme réseau (PS) comportant : - un module (COM) configuré pour interroger une entité de détermination de charge selon la revendication 6 pour obtenir une estimation de la charge d’au moins un module de ladite plateforme réseau (PS) au cours d’une période de temps ; - un module (MAR) d’ajustement de ressources dudit au moins un module pour ladite période de temps en fonction d’un résultat de ladite détermination ; - un module (MTR) de traitement d’au moins une requête émise par un tiers pour accéder à un service réseau fourni par ladite plateforme en utilisant lesdites ressources ajustées. Programme d’ordinateur (PGE, PGD, PGS) comportant des instructions pour exécuter les étapes d’un procédé d’entraînement selon l’une des revendications 1 à 5, ou les étapes d’un procédé de détermination de la charge d’au moins un module d’une plateforme réseau selon la revendication 6 ou les étapes d’un procédé de fourniture de service selon la revendication 7 lorsque ledit programme est exécuté par un ordinateur. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur (PGE, PGD, PGS) selon la revendication 10.