FR 3155328 A1 20250516 FR 2312249 A 20231109 Procédé de téléchargement d’un page web depuis un serveur (S) vers un client (C) à travers un réseau de télécommunication, ledit procédé comportant des étapes de : transmission (S1) d’une requête désignant une page, ladite page référençant un ensemble d’éléments dits dynamiques, nécessitant d’être dynamiquement déterminés, détermination (S2) d’une charge par ledit serveur détermination (S3) dynamique d’un sous-ensemble dudit ensemble dont le cardinal dépend de ladite charge, et incorporation dudit sous-ensemble dans ladite page ; transmission (S4) vers ledit client de ladite page. Figure pour l’abrégé : Fig. 1 téléchargement d’une page web optimisé pour des pics de trafic événementiels DOMAINE DE L’INVENTION La présente invention est relative au téléchargement depuis un serveur vers un client de télécommunication d’une page web référençant un ensemble d’éléments devant être dynamiquement déterminés. Elle s’applique particulièrement aux pages web d’applications web pouvant faire face à des pics de trafic importants, telles que les applications de type « web TV ». Une application de type Web TV vise à offrir les services habituels d’une télévision connectée depuis un navigateur pouvant se connecter à un site web. Un utilisateur d’un ordinateur ou de tout dispositif de télécommunication (de type tablette numérique, smartphone, etc.) peut ainsi se connecter à l’application « web TV » et visualiser un programme audio ou audio-vidéo choisi via son navigateur. Les applications de type « web TV » visent ainsi à offrir un bouquet de contenus audio et/ou vidéo à des utilisateurs, ces contenus pouvant être diffusés en direct (ou « live streaming » en anglais) ou en différé sous la forme de vidéos à la demande. Une telle application peut agréger des contenus de sources différentes. L’offre de contenus peut varier au cours du temps, notamment du fait que par nature les contenus audio-vidéos sont liés à l’actualité, mais aussi parce que les fournisseurs de contenu peuvent faire évoluer leur offre de façon régulière pour des raisons marketing. Également, l’offre contenu peut varier en fonction des utilisateurs. Ceux-ci peuvent être enregistrés auprès de l’application et avoir accès à des contenus qui peut ainsi dépendre de leur profil, y compris de chaînes ou bouquets auxquels ils ont souscrit. Il apparait donc que l’application ne peut pas présenter une page web statique, tout du moins comme page d’accueil, mais une page dynamiquement construite en fonction de l’instant auquel la requête est reçue et de l’utilisateur dont cette requête émane. La page web est alors typiquement constituée d’une trame statique minimale et de références à des éléments qui sont dynamiquement incorporés à la page, afin de construire cette page web à la demande afin qu’elle puisse être produite sur l’interface homme-machine du navigateur de l’utilisateur. Ces éléments peuvent notamment être déterminés par du code informatique (typiquement en langage Javascript) incorporé ou référencé dans la trame de la page web. Ce code informatique est prévu pour récupérer les éléments dynamiques dans des bases de données en fonction par exemple de paramètres contextuels (identifiant de l’utilisateur, heure courante, etc.) et de la logique implémentée par le code informatique. Lorsqu’il reçoit une requête d’un client d’un utilisateur (terminal de télécommunication, ordinateur… hébergeant un navigateur web), le serveur hébergeant l’application web peut renvoyer la trame de page web, charge au client d’exécuter le code informatique et de déterminer puis télécharger les différents éléments constitutifs de la page web, afin de la produire sur l’écran du terminal. Toutefois, une application de type « web TV » peut avoir une vocation commerciale et donc obtenir une visibilité le plus importante possible sur le Web. Cette visibilité passe par de bons référencements auprès des différents moteurs de recherche. Dès lors le serveur hébergeant l’application web ne peut pas renvoyer seulement cette trame de page web et le code informatique car ils ne seraient pas correctement traités par les moteurs de recherche. Notamment, ceux-ci ne sont pas adaptés pour exécuter le code informatique et ne pourraient donc pas récupérer les différents éléments constitutifs de la page web. Dès lors, les moteurs de recherche ne pourraient pas prendre en compte le contenu de ces pages et donc ne pourraient pas les référencer correctement. La page web doit donc être construire par le serveur et transmise aux clients, une fois construite, c’est-à-dire après intégration des différents éléments constitutifs, dynamiquement déterminés. Ce type de fonctionnement est généralement appelé SSR pour « Server Side Rendering » en anglais (« rendu côté serveur » en français). Il s’agit d’une technique utilisée dans le développement web qui consiste à employer des scripts sur un serveur web qui produit une réponse personnalisée pour chaque demande de l'utilisateur (client) sur le site web. Les scripts peuvent être écrits dans l'un des langages de script côté serveur disponibles (comme Javascript, PHP, Python…). Le SSR se distingue du rendu côté client, dans lesquels des scripts intégrés sont exécutés côté client dans un navigateur web, mais les deux techniques sont souvent utilisées conjointement. L'alternative à l'un ou l'autre type de script, ou aux deux, est que le serveur web lui-même fournisse une page web statique. Cette technique fait donc reposer une charge importante sur le serveur qui doit être à même de construire les pages web à la volée pour chaque requête reçue d’un utilisateur. Classiquement, les serveurs sont dimensionnés pour faire face à la charge induite par ce fonctionnement. Toutefois, dans le contexte d’une application de type Web TV, ainsi que précédemment expliqué, le serveur doit faire face à une forte variabilité du nombre de requêtes au cours du temps et à des pics extrêmement importants. Par exemple, avant un événement d’importance (discours du Président de le République, début d’un match d’une compétition sportive, annonce d’une catastrophe…), le serveur peut recevoir un nombre de requêtes plusieurs dizaines de fois plus élevé que le régime nominal (quelques minutes avant). Dimensionner le serveur sur la base de ces pics de charge serait théoriquement possible, mais nécessiterait d’une part de prévoir l’intensité maximale de ces pics, et en outre de disposer de ressources beaucoup trop importantes pour le régime nominal. Dans la mesure où ces pics de charge peuvent être relativement exceptionnels ou en tout cas peu fréquent, ce surdimensionnement serait non optimal en termes de coûts pour l’exploitant du serveur et préjudiciable en termes écologiques. Il existe donc un besoin d’améliorer les propositions actuelles de l’état de la technique. L’invention vise à gérer de façon efficace les pics de trafic sur les serveurs déployant des applications web, notamment de type « web TV », ayant une contrainte de référencement, et en évitant de surdimensionner les serveurs. À ces fins, selon un premier aspect, la présente invention peut être mise en œuvre par un procédé de téléchargement d’un page web depuis un serveur vers un client à travers un réseau de télécommunication, ledit procédé comportant des étapes de : transmission d’une requête désignant une page, ladite page référençant un ensemble d’éléments dits dynamiques, nécessitant d’être dynamiquement déterminés ; détermination d’une charge par ledit serveur ; détermination dynamique d’un sous-ensemble dudit ensemble dont le cardinal dépend de ladite charge, et incorporation dudit sous-ensemble dans ladite page ; transmission vers ledit client de ladite page. Ainsi, le travail computationnel que doit déployer le serveur pour transmettre une page requise peut être dynamiquement adapté à sa charge. Suivant des modes de réalisation préférés, l’invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles : ledit serveur détermine la totalité de l’ensemble d’éléments dynamique si ladite charge est en dessous d’un seuil déterminé. La page entièrement constituée (c’est-à-dire avec l’ensemble des éléments dynamiques déterminés) peut être directement traité par le client, notamment si le client n’est pas adapté pour effectuer ces déterminations comme un moteur de recherche. le procédé comporte en outre une étape de détermination par ledit client du reliquat dudit ensemble (lorsque ce reliquat existe). Le client peut ainsi produire une page complète sur une interface homme-machine, même lorsque le serveur n’a pas déterminé l’entièreté des éléments dynamiques. lesdits éléments sont dynamiquement déterminés par l’exécution de codes informatiques contenus ou référencés dans ladite page web. ladite charge comprend la charge d’un microprocesseur dudit serveur. ledit cardinal dépend en outre dudit client. Il est ainsi possible d’effectuer des échantillonnages sur les clients afin de gérer différemment l’optimisation de charge du serveur. Un autre aspect de l’invention concerne un serveur accessible à un client à travers un réseau de télécommunication, comportant au moins un processeur adapté pour mettre en œuvre : une réception d’une requête désignant une page, ladite page référençant un ensemble d’éléments dits dynamiques, nécessitant d’être dynamiquement déterminés ; une détermination d’une charge par ledit serveur ; une détermination dynamique d’un sous-ensemble dudit ensemble dont le cardinal dépend de ladite charge, et incorporation dudit sous-ensemble dans ladite page ; et une transmission vers ledit client de ladite page Selon un mode de réalisation, ledit client peut alors déterminer le reliquat dudit ensemble. Un autre aspect de l’invention concerne un programme d’ordinateur apte à être mis en œuvre sur un serveur web, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes du procédé tel que précédemment défini. Un autre aspect de l’invention concerne un support de données sur lequel a été mémorisé au moins une série d’instructions de code de programme pour l’exécution d’un procédé tel que précédemment défini. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d’un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés. BREVE DESCRIPTION DES FIGURES la FIG. 1 illustre un contexte de mise en œuvre d’un procédé et d’un serveur, selon des modes de réalisation de l’invention, la FIG. 2 illustre un exemple d’interface graphique pouvant être affiché par un écran associé à un client, selon un mode de réalisation de l’invention, La FIG. 3 schématise un chronogramme selon un mode de réalisation de l’invention. DESCRIPTION DETAILLEE DE MODES DE REALISATION DE L’INVENTION La FIG. 1 illustre un contexte de mise en œuvre d’un serveur S pouvant héberger une application web A. Ce serveur S est accessible à des clients à travers un réseau de télécommunication N. Ce réseau de télécommunication peut typiquement être composé de plusieurs réseaux interconnectés, notamment un réseau d’accès permettant aux clients de se connecter à un réseau principal (lui-même constitué d’une interconnexion de sous-réseaux) ou « backbone » en anglais. Les clients peuvent être localement connectés à un réseau local, LN, par exemple un réseau local sans fil, leur permettant d’accéder à une passerelle P vers le réseau d’accès. Ce réseau local sans fil, communément appelé WLAN pour « Wireless Local Area Network » en anglais peut être conforme aux protocoles Wi-Fi, ou wifi, tels que spécifiés dans les documents normatifs de l’IEEE de la famille 802.11 (ou ISO/CEI 8802-11). Le client peut accéder également directement au réseau d’accès, par exemple à un réseau cellulaire de troisième, quatrième, cinquième génération (3G/4G/5G) par exemple. Les clients peuvent être de différentes natures, leur commun étant de disposer de moyens permettant la connexion au réseau. Il s’agit essentiellement de composants de radiocommunication et de composants électroniques et informatiques permettant la mise en œuvre des piles protocolaires nécessaires à la gestion des protocoles associés au réseau et à la réception et à l’émission de paquets de données. Sur la FIG. 1 , trois types de clients sont représentés : un ordinateur ORD, un terminal mobile de communication, MOB, et un téléviseur connecté TV. Le terminal mobile MOB est typiquement un téléphone intelligent de type « smartphone » ou une tablette numérique…. L’ordinateur peut être un ordinateur fixe (ou « desktop » selon le vocabulaire en langue anglaise) ou portable (ou « laptop »). Le téléviseur TV peut être nativement connecté ou l’être par le truchement d’un dispositif associé tel que par exemple une clé HDMI connecté au téléviseur. Un exemple de dispositif externe communiquant avec un téléviseur TV est Chromecast. Le Chromecast est un appareil lecteur de flux multimédias (passerelle multimédia) en temps réel développé et commercialisé par Google. L'appareil se branche sur le port HDMI d'un téléviseur et communique, par connexion Wi-Fi, avec un autre appareil connecté à Internet (ordinateur, smartphone, tablette…), afin d'afficher sur le téléviseur le contenu multimédia reçu depuis une application compatible avec la technologie Google Cast, depuis le navigateur Google Chrome présent sur un ordinateur, ou depuis certains appareils Android. Dans l’exemple illustratif de la FIG. 1 , les clients ORD et TV peuvent accéder à l’application Web A via le réseau local LN et la passerelle P. Le client MOB accède à l’application web A directement à travers le réseau de télécommunication N. Ces deux types d’accès sont illustratifs et visent essentiellement à montrer la diversité des connexions possibles entre un client et l’application web A. Les clients disposent d’outils logiciels adaptés pour permettre à l’utilisateur de se connecter à une application web et à visualiser un contenu transmis depuis cet application web. En particulier, dans le cas d’une application web de type « Web TV », l’outil logiciel (communément appelé « navigateur » ou « web browser » en anglais) est adapté pour permettre la production d’un contenu audio ou audio-vidéo sur une interface homme-machine associée au client (écran du client, écran externe connecté au client, etc.) Les contenus audio ou audio-vidéos comprennent des contenus diffusés en direct qui peuvent être liés à des chaines de télévision, de radiodiffusion, etc. Il peut également s’agir de contenu à la demande (podcast, vidéo à la demande, VoD (« video on demand ») etc.). L’application web A est prévue pour fournir, sur requête des clients, des pages web référençant différents éléments. Ces éléments peuvent correspondre à des zones de la page web, dont le contenu peut être individuellement déterminé. Par exemple, dans le cas d’une application de type « web TV », les éléments peuvent correspondre à des chaînes, à des contenus vidéos particuliers, à des menus, à des espaces publicitaires, etc. Les éléments peuvent être associés à la fois à une représentation visuelle ou graphique, et à un comportement, notamment lorsqu’il est pointé ou sélectionné par l’utilisateur. Par exemple, un contenu vidéo peut être mis en surbrillance ou être animé différemment, lorsque l’utilisateur le pointe (par exemple au moyen d’une souris, ou d’une télécommande), et être déclenché en plein écran lorsqu’il est sélectionné. La sélection d’autres éléments peut entraîner d’autres actions, comme par exemple l’ouverture d’une nouvelle page web. En particulier, la première page, ou page d’accueil, peut être ainsi dynamiquement déterminée. L’application web peut également contenir des pages dynamiquement déterminées et des pages statiques (code HTML pur). Certaines pages peuvent également être un mix des deux, c’est-à-dire comporter des éléments statiques et des éléments à déterminer dynamiquement. La FIG. 2 illustre un exemple d’interface graphique pouvant être affiché par un écran associé à un client. Cette page d’exemple peut être une page d’accueil. Cette interface graphique peut afficher, de façon concomitante, un contenu, ou flux, vidéo dans une zone C1, et une zone de navigation NAV permettant des interactions avec l’utilisateur du terminal et permettant notamment de changer le flux vidéo à afficher dans la zone C1. La zone de navigation NAV comporte un ensemble de zones CS1, CS2, CS3, CS4, CS5 destinées à l’affichage de flux, ou contenus, vidéos secondaires. Ces contenus secondaires peuvent par exemple correspondre à d’autres chaînes de télévision. La sélection d’une zone secondaire peut déclencher l’affichage du contenu vidéo secondaire dans la zone principale C1. Le contenu précédemment affiché dans cette zone principale C1 peut alors être affiché dans une zone secondaire. L’utilisateur peut ainsi zapper d’un contenu vidéo à un autre vidéo au moyen de cette interface graphique. La zone de navigation peut également comporter des menus M1, M2, M3, M4, M5, permettant d’autres options de navigation, par exemple de changer de source de contenu multimédia : il peut par exemple s’agir de se connecter à un autre serveur de contenu SC, de récupérer des contenus multimédias stockés localement, etc. L’interface graphique peut comporter d’autres éléments non représentés sur la figure : menus, déroulants ou autres, accessibles par exemple au moyen de la sélection d’un menu M1, M2, ML3, M4, M5, ou d’une touche d’une télécommande associée au terminal 10, etc. Ces éléments peuvent permettre d’accéder à encore d’autres options, par exemple à l’ensemble des chaînes de télévision disponible. Comme précisé précédemment, des éléments de cette page peuvent être dynamiquement déterminés afin de refléter les différents contenus disponibles et accessibles à l’utilisateur en fonction de son profil et du temps actuel. La page web référencie donc ces éléments qui doivent être déterminés dynamiquement, et que l’on appellera par la suite « éléments dynamiques ». La page web peut par ailleurs comporter des éléments statiques, c’est-à-dire ne devant pas être dynamiquement déterminés. Ces éléments statiques ne dépendent pas de l’actualité ou de l’utilisateur : il peut s’agir d’informations générales, d’éléments graphiques de la page web toujours présents, de la feuille de style CSS, etc. Selon un mode de réalisation, la page web peut être un canevas, ou une trame, comportant très peu d’éléments statiques et majoritairement constitué d’éléments devant être déterminés de façon dynamique (éléments dynamiques). Le référencement d’éléments dans une page web peut être effectuée par tout moyen connu. Il s’agit typiquement de balises ou de mots-clés du langage HTML (« HyperText Markup Language » en anglais). En particulier, le référencement d’un élément devant être dynamiquement déterminé peut se faire par des moyens techniques permettant de déclencher automatiquement cette détermination. Ces moyens techniques peuvent être des liens vers des ressources contenant du code informatique. Ce code informatique peut être des scripts écrits dans l'un des langages de script côté serveur disponibles (comme Javascript, PHP, Python…). Il est prévu pour récupérer les éléments dynamiques dans des bases de données en fonction par exemple de paramètres contextuels (identifiant de l’utilisateur, heure courante, etc.) et de la logique implémentée par le code informatique. En particulier, il peut être prévu pour récupérer les visuels d’une émission vidéo, d’une chaîne de télévision, d’un menu, ainsi que les actions associées (permettant notamment le déclenche du téléchargement du contenu multimédia associé depuis un serveur de contenu). La FIG. 3 schématise un chronogramme selon un mode de réalisation de l’invention. Dans une étape S1, le client C transmet une requête m1 au serveur S. Cette requête désigne une page disponible sur ce serveur. Cette page peut par exemple être la page d’accueil. Celle-ci peut être désignée par l’URL (pour « Unified Resource Locator » en anglais, ou localisateur de ressource unifié) du serveur S, ou tout autre adresse précédemment provisionnée sur le client. La requête peut être conforme au protocole HTTP (pour « HyperText Transfer Protocol » en anglais). Il peut notamment s’agir d’une requête GET de ce protocole HTTP. Dans une étape S2, le serveur S peut déterminer sa charge. Cette charge représente la capacité du serveur à pouvoir traiter les différentes requêtes m1 reçues des différents clients. Les principales contributions de cette charge du serveur peuvent être la charge du ou des microprocesseurs et, éventuellement, la charge de la mémoire vive du serveur. D’autres facteurs limitants peuvent également être pris en compte. Lorsque plusieurs facteurs sont pris en compte, la charge peut agréger ces différents facteurs afin d’établir une métrique permettant d’effectivement évaluer la capacité du serveur à traiter les requêtes. Selon un autre mode de réalisation, la charge du serveur S peut être estimée par un nombre de requêtes reçues par unité de temps. Cette charge peut être périodiquement déterminée, par exemple à intervalle régulier. Lors de la réception d’une requête, la dernière estimation en date est alors prise en compte. Selon un autre mode de réalisation, le charge du serveur S est déterminée à la réception d’une requête m1. Dans une étape S3, le serveur S détermine dynamiquement un sous-ensemble de l’ensemble des éléments référencés dans la page web demandée par le client. Le cardinal de ce sous-ensemble dépend de la charge déterminée en étape S2. Les éléments déterminés par le serveur sont ensuite incorporés dans cette page web. Ainsi, le nombre ou la proportion des éléments dynamiques effectivement déterminés par le serveur peut varier en fonction de la charge du serveur S. Parmi l’ensemble des éléments devant être dynamiquement déterminés, le serveur peut par exemple déterminer la totalité de ces éléments lorsque la charge est faible ou aucun de ces éléments lorsque la charge est élevée. Entre ces deux situations extrêmes, une balance peut être effectuée en fonction de seuils progressifs ou d’une fonction linéaire, ou selon tout autres mécanismes. D’une façon générale, on peut par exemple déterminer une proportion P d’éléments dynamiques déterminés par le serveur S selon une expression liant cette proportion à la charge L : Dans laquelle f() est une fonction décroissante : plus la charge L est élevée et plus la proportion P est faible. Selon un mode de réalisation, la proportion est égale à 100% tant que la charge L est en dessous d’un seuil déterminé. Autrement dit, dans cette situation le serveur détermine la totalité de l’ensemble des éléments dynamiques. Lorsque la proportion n’est pas égale à 100%, c’est-à-dire lorsque le sous-ensemble des éléments dynamiques déterminés par le serveur est inférieur au nombre d’élément dynamiques référencés dans la page web, l’identification de ces éléments dynamiques de ce sous-ensemble peut être effectuée de différentes façons. Selon un mode de réalisation, l’identification de ces éléments dynamiques peut être arbitraire : par exemple, dans l’ordre de la page web, les premiers éléments dynamiques sont déterminés par le serveur S jusqu’à ce que la proportion P soit atteinte. Selon un autre mode de réalisation, le sous-ensemble est choisi parmi les éléments dynamiques les moins coûteux à déterminer pour le serveur. Par exemple, les éléments dynamiques liés au profil de l’utilisateur (par exemple chaînes de télévision ou bouquets auquel il a souscrit) sont plus coûteux car ils nécessitent une analyse de ce profil et permettent moins facilement une mutualisation pour un grand nombre de clients. Aussi, étant plus coûteux, ils peuvent ne pas être déterminés par le serveur S. Le serveur peut par contre déterminer préférentiellement les éléments dynamiques liés à l’actualité, par exemple. Selon un mode de réalisation, le sous-ensemble est déterminé également en fonction du client C. Le sous-ensemble, tant dans son contenu que dans son cardinal, peut être différent selon les clients. On peut notamment faire dépendre de la charge le cardinal du sous-ensemble de chaque client, afin que le traitement induit par un grand nombre de clients soit adapté à la charge. Plus la charge est élevée sur le serveur, et moins de clients C seront correctement servis. Par exemple, on peut ainsi établir une proportion de clients, P’ (« P prime »), fonction de la charge du serveur. En fonction de cette charge L, il peut être choisir de déterminer l’intégralité (ou une proportion P1 élevée) des éléments dynamiques pour une proportion P’ des clients, et de déterminer aucun (ou une proportion P2 plus faible que P1) des éléments dynamiques pour les autres clients. Le choix des clients peut se faire également de différentes façons, y compris de façon arbitraire : par exemple, par un client tout les N clients avec N=100/P’. Ainsi, selon les différents modes de réalisation, l’adaptation à la charge du serveur peut se faire en déterminant un sous ensemble dont le cardinal est déterminé de façon uniforme pour l’ensemble des clients ou bien, au contraire, adapté pour chaque client. Les éléments dynamiquement déterminés par le serveur S sont incorporés dans la page web. Dans le cas où la charge du serveur est élevée, une page statique peut être transmise au client C. Au lieu de transmettre une page web avec des éléments dynamiques non déterminés, ceux-ci peuvent être remplacés par des éléments statiques. Ainsi la page web peut contenir des informations soit un peu ancienne et non dynamiquement mises à jour, soit des informations génériques. Par exemple, une image statique peut représenter une chaîne de télévision par son logo, plutôt que par une image de l’émission en cours ou de l’émission phare du jour. Dans une étape S4, la page web est transmise vers le client C dans un message m2. Selon un mode de réalisation, tout comme le message de requête m1, ce message de réponse m2 peut être conforme au protocole HTTP. Conformément au protocole, un ensemble de messages m2 peut être transmis afin de transmettre les différents éléments constitutifs de la page web. Dans une étape S5, le client C peut analyser la page web et les différents éléments reçus afin de pouvoir produire la page web sur une interface homme-machine. En particulier, le client C détermine le reliquat des éléments de l’ensemble qui n’ont pas été déterminés côté serveur. Ainsi, tout élément dynamique référencé dans la page web peut être déterminé soit par le serveur S, soit par le client C. Ainsi, la page web produite sur l’interface homme-machine peut être complète et ne pas impacter l’expérience de l’utilisateur. La proportion d’éléments dynamiques déterminés par le serveur versus par le client dépend de la charge du serveur. Lorsque le serveur est chargé, davantage (éventuellement la totalité) d’éléments dynamiques sont déterminés par le client, tandis que lorsque la charge est faible la totalité des éléments dynamiques sont préférentiellement déterminés par le serveur S. Lorsque le serveur est chargé et que la totalité des éléments dynamiques ne sont pas déterminés, il est possible qu’un moteur de recherche récupère une page web incomplète. Dans ce cas-là, ne pouvant lui-même déterminer les éléments dynamiques, il ne pourra correctement référencer la page web. Toutefois, la probabilité qu’un moteur de recherche adresse une requête vers le serveur lors d’un pic d’activité de celui-ci est relativement faible. En outre, les moteurs de recherche adresse des requêtes de façon régulière vers une même page, de sorte que l’impact d’un mauvais référencement sur une requête est minimisé sur un ensemble de requêtes. En outre, il est considéré que le léger inconvénient pouvant résulter de ce risque faible est favorablement contrebalancé par le maintient d’une expérience utilisateur positive, quelque soit la charge du serveur, et le non-surdimensionnement du serveur. Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais est défini par les revendications. Elle est notamment susceptible de nombreuses variantes accessibles à l'homme de l'art. Procédé de téléchargement d’un page web depuis un serveur (S) vers un client (C) à travers un réseau de télécommunication, ledit procédé comportant des étapes de : transmission (S1) d’une requête désignant une page, ladite page référençant un ensemble d’éléments dits dynamiques, nécessitant d’être dynamiquement déterminés, détermination (S2) d’une charge par ledit serveur détermination (S3) dynamique d’un sous-ensemble dudit ensemble dont le cardinal dépend de ladite charge, et incorporation dudit sous-ensemble dans ladite page ; transmission (S4) vers ledit client de ladite page. Procédé selon la revendication précédente dans lequel ledit serveur détermine la totalité de l’ensemble d’éléments dynamique si ladite charge est en dessous d’un seuil déterminé. Procédé selon l’une des revendications 1 ou 2, comportant en outre une étape de détermination (S5) par ledit client du reliquat dudit ensemble. Procédé selon l’une des revendications précédentes, dans lequel lesdits éléments sont dynamiquement déterminés par l’exécution de codes informatiques contenus ou référencés dans ladite page web. Procédé selon l’une des revendications précédentes, dans lequel ladite charge comprend la charge d’un microprocesseur dudit serveur (S). Procédé selon l’une des revendications précédentes, dans lequel ledit cardinal dépend en outre dudit client. Serveur (S) accessible à un client (C) à travers un réseau de télécommunication, comportant au moins un processeur adapté pour mettre en œuvre : une réception (S1) d’une requête désignant une page, ladite page référençant un ensemble d’éléments dits dynamiques, nécessitant d’être dynamiquement déterminés ; une détermination (S2) d’une charge par ledit serveur ; une détermination (S3) dynamique d’un sous-ensemble dudit ensemble dont le cardinal dépend de ladite charge, et incorporation dudit sous-ensemble dans ladite page ; et une transmission (S4) vers ledit client de ladite page. Programme d’ordinateur apte à être mis en œuvre sur un terminal de lecture de flux multimédia, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes du procédé définie dans les revendications 1 à 6. Support de données sur lequel a été mémorisé au moins une série d’instructions de code de programme pour l’exécution d’un procédé selon l’une des revendications 1 à 6.