FR 2961998 A1 20111230 FR 1055024 A 20100623 Signature d'adresses URL en mode de communication continue adaptative La présente invention concerne une communication de données, en mode de communication continue (ou « streaming »). Il peut s'agir par exemple de données multimédia (audio/vidéo) communiquées à un ou plusieurs terminaux distants, selon un flux continu. Bien entendu, les conditions de communication peuvent varier selon par exemple la bande passante à un instant donné du réseau de communication reliant les terminaux au serveur. Pour ne pas perturber la communication en continu, les données envoyées à un terminal donné sont adaptées aux conditions de la liaison entre ce terminal et le serveur. Ainsi, par exemple dans le cas d'une communication de données vidéo, la résolution d'affichage d'une vidéo sur un écran du terminal peut être plus ou moins élevée en fonction des conditions de communication sur la liaison précitée. Les données vidéo elles-mêmes peuvent donc être différentes en fonction de ces conditions de communication, et, en particulier, sont adaptées à ces conditions. Une telle technique est appelée « adaptive streaming ». La présente invention concerne plus précisément une communication utilisant la technique des adresses universelles, en particulier des liens de type URL (pour « Uniform Ressource Locator ») activés à partir des terminaux et pointant vers des plateformes de fourniture de contenus, dans le cadre d'une communication de type « adaptive streaming ». Le protocole « adaptive streaming » est un protocole d'échange de données et de flux audio/vidéo entre un terminal client TER et un serveur de contenu SER permettant, en utilisant des protocoles Internet classiques (http), d'offrir une bonne expérience utilisateur (sur le retour du terminal sur la bande passante ou le débit dont il a bénéficié pour recevoir les données), tout en tenant compte par exemple des variations de bande passante sur la liaison entre le terminal client et le serveur de contenu. Par exemple si le critère retenu pour tenir compte des conditions de la liaison entre le terminal et le serveur de contenus est le débit via cette liaison, le contenu est encodé à différents débits (correspondant donc à des qualités respectives de restitution sur écran, notamment en termes de résolution). Les différents débits sont découpés en segments temporels (ou « fragments de contenu »). La description de ces différents débits et de la segmentation, ainsi que les fragments de contenu, sont mis à disposition du terminal client sur une plateforme de service. Le terminal client récupère la description précitée, sous la forme d'un fichier descriptif Le terminal client demande alors un fragment de contenu identifié dans ce fichier descriptif En fonction de la bande passante disponible, estimée par exemple à partir du temps de téléchargement d'un fragment, le terminal client demande un fragment suivant de qualité inférieure, égale, ou encore supérieure. En particulier, dans une telle solution, le terminal client qui se connecte à une plateforme de service reçoit de celle-ci une partie d'adresse URL pointant sur le contenu vers un serveur de contenu dédié, cette partie d'adresse URL étant par exemple du type http_/ I\Ionnser eur/ i .... srn. Ensuite, le terminal client formule une requête au serveur dédié pour obtenir le fichier descriptif précité, décrivant le contenu (les différents débits disponibles pour livrer le contenu, les différents fragments du contenu disponibles, ou autres) en fonction de l'adresse URL précitée et en utilisant en particulier une adresse URL de type : http://Monserveur/EubPoint.ism/Manifest Le terme "Manifest" dans cette adresse désigne en effet le fichier descriptif précité. Cette terminologie est employée notamment dans un type de streaming adaptatif connu sous le vocable « smooth streaming ». Le fichier descriptif est alors appelé « le manifeste ». Le terminal client analyse le fichier descriptif reçu, sélectionne un débit en fonction de la liaison vers le serveur de contenus, et demande un flux audio/vidéo en générant plusieurs requêtes de fragments sous forme d'adresses URL à ce serveur. Ces adresses URL sont construites par ajout de paramètres propres aux conditions de débit, à un gabarit d'adresse URL prédéterminé, tel que par exemple : http: /Monserveur/PubP'oin.isi ualityLevels(307200,Com 7atibility-=1 andheld), Fragments(video =1.968000) Dans cet exemple, les fragments requis "1968000" sont demandés à un niveau de qualité vidéo "307200", qui est compatible avec les conditions constatées de la liaison terminal-serveur de contenus. Toutefois, les conditions de liaison ne sont pas les seuls critères pour servir un terminal. Déjà, un terminal peut avoir des conditions d'accès restreintes à des contenus, ou, dans l'exemple présenté ci-avant, des conditions restreintes et limitées à certains débits seulement, inférieurs à un débit offrant une qualité donnée à laquelle a droit, au maximum, un utilisateur du terminal. Ainsi, il n'existe pas de moyen de vérifier si un terminal détient bien de tels droits restreints, en particulier en mode de communication continue adaptative. La présente invention vient améliorer la situation. 20 Elle vise à cet effet un procédé de communication de données, dans lequel une première entité serveur émet des données de contenu destinées à un ou plusieurs terminaux. Le contenu est communiqué en une pluralité de fragments successifs selon un mode de communication continue, adaptative (par exemple de type « adaptive streaming »). En particulier, la communication est adaptée en fonction de conditions de liaison entre un terminal et l'entité serveur. Ainsi, la communication de chaque fragment est adaptée aux conditions de liaison entre ce terminal et l'entité serveur. Dans une telle configuration de communication continue adaptative, sur réception d'une requête de fragment de contenu, issue d'un terminal en la forme d'une adresse universelle comportant au moins une valeur courante d'un paramètre de conditions de liaison, l'entité serveur est apte à communiquer à destination du terminal au moins un fragment de contenu qui est fonction de la valeur courante de ce paramètre. Comme décrit à titre d'exemple ci-avant, un tel paramètre peut être un niveau de qualité (sonore ou d'image, ou autres) du fragment sollicité auprès de l'entité serveur. Néanmoins, au sens de l'invention, une partie au moins de l'adresse universelle reçue par la première entité est signée. En particulier, cette adresse universelle comporte une signature d'une première adresse universelle (qui peut correspondre par exemple à une requête initiale du contenu global par le terminal). Cette première adresse universelle comporte en particulier une information liée au paramètre précité de conditions de liaison. 25 L'entité serveur effectue alors les étapes : - vérifier la signature de la première adresse comportant ladite information, - vérifier en outre une compatibilité entre ladite information et la valeur courante que comporte l'adresse universelle reçue, et 30 - en cas de vérifications positives, communiquer à destination du terminal au moins un fragment de contenu fonction de la valeur courante. Ainsi, la présente invention propose de mettre en oeuvre et d'utiliser une technique de signature d'adresse universelle (URL) pour vérifier par exemple si un terminal détient des droits d'accès à 35 des contenus et/ou à des qualités de contenu, en particulier en mode de communication continue adaptative. Néanmoins, la présente invention ne vise pas une simple signature d'adresse URL. En effet, il pourrait venir naturellement à un homme du métier qu'une telle technique de signature d'adresse URL pourrait directement être transposée et adaptée à une communication en mode de type « adaptive streaming ». En réalité, tel n'est pas le cas pour les raisons qui suivent. Si une technique de signature d'adresse URL était directement appliquée à une communication continue adaptative, seule la première demande du fichier descriptif pourrait mettre en oeuvre une signature d'adresse URL. Une telle réalisation ne serait pas optimale car la signature de requêtes URL successives pour solliciter des fragments suivants du contenu ne pourrait pas être mise en oeuvre et ne pourrait pas s'appliquer en l'état. En particulier, les requêtes de fragments de contenu audio/vidéo ne peuvent aujourd'hui qu'utiliser des adresses URL non signées. Ainsi, une fois que le terminal client accéderait au fichier descriptif, plus aucun contrôle d'accès sur les requêtes de fragments de contenu audio/vidéo ne serait mis en oeuvre. Les paramètres ajoutés par le terminal client ne seraient pas non plus contrôlés par le serveur dédié au streaming de contenu. Au sens de l'invention, seule une partie de l'adresse URL de requête de fragment est signée et, dans cette partie, la signature est construite au moins avec une information propre au terminal, cette information étant liée au paramètre précité caractérisant les conditions de liaison entre le terminal et l'entité serveur. Cette information peut être par exemple la qualité maximum de contenu à laquelle à droit le terminal, lorsque le paramètre précité indique une condition de débit possible sur la liaison entre le terminal et l'entité serveur (fixant alors la qualité de contenu à un niveau maximum donné). L'entité serveur vérifie alors l'authenticité de la signature et en outre si l'information précitée est bien compatible avec une valeur de paramètre requise dans l'adresse URL émise par le terminal. Par exemple, si la valeur de paramètre requise pour la communication d'un fragment correspond à une qualité de contenu supérieure à celle à laquelle a droit le terminal, d'après l'information précitée, alors l'entité serveur peut refuser d'accorder le fragment de contenu à la qualité demandée par le terminal dans l'adresse URL. Dans un exemple de réalisation, l'information précitée peut être une valeur seuil du paramètre précité, cette valeur étant propre au terminal (par exemple, un niveau de qualité maximum auquel a droit le terminal, comme décrit à titre d'exemple de réalisation ci-après). Ainsi, l'entité serveur peut vérifier que la valeur courante que requiert le terminal pour la communication d'un fragment est bien compatible avec la valeur seuil indiquée dans une partie d'adresse URL à cet effet. Par exemple, si le terminal a droit habituellement à une qualité maximum de contenu, l'entité serveur vérifie que la qualité requise pour la communication d'un fragment (en tant que valeur courante de paramètre) ne dépasse pas la qualité maximum à laquelle a droit ce terminal (en tant que valeur seuil du paramètre). Ainsi, dans une telle réalisation, le terminal dispose d'un droit d'accès à une qualité de contenu maximum, prédéterminée. La valeur seuil correspond alors au maximum de qualité de contenu à laquelle a droit le terminal, tandis que la valeur courante de paramètre correspond à un maximum de qualité de contenu que permettent les conditions de liaison entre le terminal et l'entité serveur. Bien entendu, il ne s'agit pas de la seule réalisation possible et, en complément ou en variante, le terminal peut disposer aussi d'un droit d'accès à un nombre maximum de fragments de contenu, prédéterminé, par exemple par requête de fragments. La valeur seuil correspond alors à ce nombre maximum de fragments de contenu auquel a droit le terminal, tandis que la valeur courante de paramètre correspond à un nombre maximum de fragments de contenu à communiquer que permettent les conditions de liaison entre le terminal et l'entité serveur. Dans les deux cas, l'entité serveur vérifie que la valeur courante du paramètre dans la requête URL reste inférieure ou égale à la valeur maximum à laquelle a droit le terminal, indiquée dans la requête URL signée. Dans un mode de réalisation, la première adresse universelle précitée peut être construite sur réception d'une requête initiale du contenu global issue du terminal. Il est alors avantageux de déporter la fonction de réponse à cette requête initiale auprès d'une plateforme de service dédiée, distincte de la première entité serveur. Ainsi, dans une telle réalisation, le procédé comporte une étape préalable dans laquelle une deuxième entité serveur transmet à destination du terminal la signature de la première adresse comportant l'information précitée, sur réception de la requête initiale du contenu global, issue du terminal en la forme de la première adresse universelle. Dans une telle réalisation, la deuxième entité serveur est distincte de la première entité serveur, et la deuxième entité serveur comporte une plateforme de service pour répondre au terminal, tandis que la première entité serveur comporte au moins une plateforme de livraison de contenu pour fournir les fragments de contenu au terminal. Il peut être avantageux en effet dans certaines conditions d'avoir recours à une ou plusieurs plateformes de livraison de contenus pour ne pas surcharger la plateforme de service avec la fonctionnalité de livraisons de contenus. La présente invention permet avantageusement de séparer l'entité fournissant la signature (la plateforme de service) de l'entité fournissant le contenu et vérifiant la signature. Néanmoins, dans une variante, les première et deuxième entités peuvent être une même entité serveur. Dans une application avantageuse, les fragments et les valeurs précitées de paramètre lié aux conditions de liaison sont définis dans un fichier descriptif que la première entité serveur transmet à destination du terminal, sur réception d'une requête de ce fichier descriptif issue du terminal en la forme d'une adresse universelle comportant la signature de la première adresse universelle. Dans un mode de réalisation particulier, le procédé peut comporter alors la succession globale d'étapes ci-après, dans lesquelles : sur réception d'une requête initiale du contenu global, issue du terminal en la forme de la première adresse universelle, la deuxième entité serveur transmet à destination du terminal la signature de la première adresse comportant l'information précitée propre au terminal, le terminal émet une deuxième requête d'un fichier descriptif définissant lesdits fragments et lesdites valeurs de paramètre lié aux conditions de liaison, cette deuxième requête étant destinée à la première entité serveur et ayant pour forme une adresse universelle incluant la signature de la première adresse, la première entité serveur, sur réception de la deuxième requête issue du terminal, vérifie la signature et, si la vérification est positive, transmet à destination du terminal le fichier descriptif, sur la base d'une détermination des conditions de liaison et de la description des fragments et des valeurs de paramètre lié aux conditions de liaison, le terminal émet une requête d'au moins un fragment de contenu en la forme d'une adresse universelle comportant : * une valeur courante du paramètre précité pour ce ou ces fragment(s), et * la signature de la première adresse universelle, et, sur la base de l'adresse universelle reçue, la première entité serveur : * vérifie la signature de la première adresse, afin de vérifier une authenticité de l'information précitée, * vérifie en outre une compatibilité entre cette information et la valeur courante que comporte l'adresse universelle reçue, et * en cas de vérifications positives, communique à destination du terminal au moins un fragment de contenu fonction de la valeur courante. La présente invention vise aussi un programme informatique comportant des instructions pour la mise en oeuvre du procédé ci-avant, lorsque ce programme est exécuté par un processeur. Ce programme peut être distribué entre la première entité serveur, le terminal et éventuellement la deuxième entité serveur. A titre d'exemple, la figure 3 commentée ci-après peut constituer une partie au moins d'un organigramme représentant l'algorithme général d'un tel programme. D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels : - la figure 1 illustre un exemple de réalisation de la signature de la première adresse universelle précitée, mise en oeuvre par échanges entre le terminal et la deuxième entité 10 précitée en tant que plateforme de service, - la figure 2 illustre les différents échanges entre le terminal, la plateforme de service et la plateforme de fourniture de contenus, dans un exemple de réalisation d'un système au sens de l'invention, - la figure 3 résume les différentes étapes mises en oeuvre auprès de la plateforme de 15 fourniture de contenus, lorsqu'elle reçoit une requête courante de fourniture de fragment, - la figure 4 illustre schématiquement un exemple d'une première entité pour la livraison de contenus, comportant des moyens adaptés pour la mise en oeuvre de l'invention, - la figure 5 illustre schématiquement une deuxième entité pour la fourniture d'une signature, en tant que plateforme de service, dans un exemple de réalisation de l'invention, 20 - la figure 6 illustre schématiquement un exemple de terminal comportant des moyens adaptés pour la mise en oeuvre de l'invention. On décrit tout d'abord en référence à la figure 1 une technique de signature d'adresse URL appliquée dans un exemple de réalisation de la présente invention. Le vocable « adresse URL » est 25 simplement désigné par « URL » ci-après. Une telle technique est d'ailleurs utilisée habituellement pour effectuer un contrôle d'accès à des contenus multimédias, tels que les contenus audio/vidéo par exemple. Elle consiste à ajouter une information (habituellement une signature cryptographique) à l'URL de demande du contenu. 30 Ainsi, en référence à la figure 1 illustrant les différents types d'URL transmises dans une telle application, un terminal client TER demande un contenu à une plateforme de service SER en émettant la requête REQ. Cette requête comporte typiquement des informations sur le contenu requis dans l'URL envoyée à la plateforme SER. Après vérification des droits de l'utilisateur sur ce 35 contenu auprès de la plateforme SER, cette dernière ajoute à l'URL générique du contenu, par exemple, les paramètres suivants : - l'adresse IP (pour « Internet Protocol ») du terminal client TER, 20 - la durée de validité de l'URL donnée à ce terminal. L'URL renvoyée (portant la référence SGN sur la figure 1) est signée par des moyens cryptographiques auprès de la plateforme SER, avant d'être envoyée au terminal client TER. 5 La même URL signée SGN est alors envoyée ultérieurement depuis le terminal client TER à la plateforme SER pour solliciter les données successives audio/vidéo. La plateforme SER vérifie alors la conformité de l'URL signée et en particulier que : - l'adresse IP du client correspond à la valeur insérée dans l'URL, 10 - 1`URL est bien valide par rapport à sa durée de validité, et - la signature cryptographique de l'URL est bien authentique. Si toutes ces vérifications réussissent alors, la plateforme de service SER retourne au terminal TER le contenu en réponse à la réception de l'URL signée. Sinon, elle redirige éventuellement le 15 terminal vers une page d'erreur. Cette technique est généralement appliquée à du téléchargement (en protocole http). Toutefois, elle peut être adaptée avantageusement aussi à du streaming en temps réel (ou « rtsp », pour « Real Time Streaming Protocol »). On se réfère maintenant à la figure 2 sur laquelle, dans l'exemple représenté, un terminal client TER est apte à communiquer avec une première plateforme SER, de service, et une deuxième plateforme CONT, de fourniture de contenu. 25 Le terminal client se connecte tout d'abord à la plateforme de service SER, en formulant une requête REQ d'un contenu. Le terminal reçoit en retour une URL signée SGN pointant sur le contenu auprès de la plateforme CONT de fourniture de contenu. Dans l'exemple décrit, la requête est formulée avec une contrainte sur un niveau de qualité souhaité : « QualityMaxLevel ». 30 A titre d'exemple, l'URL signée est de type : http://Monserveur/ PubPoint.ism/QualityMaxLevel=600000/Signature, où : - « 600000 » représente un niveau de qualité d'image maximal, par exemple pour une vidéo, et - « Signature » correspond par exemple à une valeur numérique résultat de la fonction de 35 signature de la première URL (fonction de hachage, ou autre). Le terminal client formule alors une requête du contenu auprès de la deuxième plateforme CONT, selon une requête REQ1 incluant cette URL signée SGN, pour obtenir le fichier descriptif du contenu (avec différents débits de fragments du contenu disponible notamment). Ce fichier descriptif peut être par exemple le fichier « manifeste » décrivant le contenu, dans un mode de streaming adaptatif appelé « smooth streaming », avec alors par exemple l'URL suivant pour la requête REQ1 : http://Monservcur/Pueoint.is3n, Oua.litvMaxLevel=600000/Signature; Manifest où "Manifest" désigne le fichier "Manifeste" précité. On relèvera que cette URL comporte la valeur de niveau de qualité "QualityMaxLevel" auquel prétend le terminal, ainsi que la signature calculée notamment avec cette valeur. La plateforme de fourniture de contenu CONT vérifie la signature insérée (étape S10). Si cette dernière est correcte, la plateforme CONT lui retourne le fichier « manifeste » (référence MAN de la figure 2) Le terminal client TER analyse le fichier manifeste reçu, sélectionne un débit, et demande un flux audio/vidéo en générant une requête REQ2 à la plateforme de fourniture de contenu CONT, selon une adresse URL de type : httl://Monserveur/FubPoint.ism/ ualityMaxLevel=600000/Si s(30 7200, Compatibility===Handheld)/Fragments(vide o===1968000) où "Fragments(video=1968000)" désigne un fragment de contenu, et "QualityLevels(307200,Compatibility=Handheld)" désigne une qualité de service souhaitée pour ce fragment, tenant compte des conditions de communication sur la liaison entre le terminal TER et la plateforme CONT. La plateforme de fourniture de contenu CONT vérifie la signature insérée dans cette dernière requête (étape Sil). La plateforme CONT détermine aussi, par exemple, si la qualité vidéo demandée est autorisée pour ce terminal client et si elle peut alors lui être fournie. Si toutes les vérifications réussissent, la plateforme CONT retourne au terminal le flux audio/vidéo correspondant au fragment de contenu demandé FRA. Sinon, la plateforme refuse la communication de contenu ou renvoie une page d'erreur. La signature initiale de l'URL SGN est générée par la plateforme de service SER, après authentification de l'utilisateur et vérification de ses droits. Dans l'exemple décrit, la plateforme de service SER vérifie si le terminal client TER a bien droit à un indice maximum de niveau de qualité (600000). Comme on l'a vu précédemment, l'URL générée par la plateforme de service SER mentionne la qualité maximum autorisée pour ce terminal client TER. Une partie de l'URL générée est signée (cette partie étant par exemple http://Monserveur/PubPoint.isrn/Qualitvl\'iaxLevel=6000001), ce qui garantit l'intégrité et l'authenticité de l'information de qualité maximum autorisée. De fait, un utilisateur malveillant du terminal ne peut pas modifier l'URL en sollicitant une meilleure qualité maximum, la signature de l'URL ne pouvant pas alors être authentifiée. Cette partie d'URL signée est ensuite utilisée par le terminal client TER lors de ses échanges avec la plateforme de fourniture de service CONT pour requérir d'abord le fichier manifeste, puis les fragments successifs du contenu. La plateforme de fourniture de service CONT reçoit donc dans chaque requête la qualité maximum autorisée pour ce terminal client, selon les conditions du réseau (ou plus génériquement de la liaison) entre le terminal TER et la plateforme CONT, laquelle peut donc vérifier si le terminal client demande une qualité compatible (donc inférieure ou égale) avec cette qualité maximum autorisée. Un utilisateur malveillant du terminal ne peut pas alors solliciter une qualité supérieure en modifiant lui-même l'URL, car alors la plateforme de fourniture de service CONT refuserait la requête. La signature garantit ainsi que le paramètre « QualityMaxLevel=600000 » est authentique et respecté. On a représenté schématiquement sur la figure 3 les différentes étapes mises en oeuvre par la première entité serveur en tant que plateforme de fourniture de contenus CONT. Sur réception de la requête REQ2 de fourniture de fragment issue du terminal (S20), la plateforme CONT vérifie tout d'abord la signature SGN qui est ajoutée à l'URL formant la requête REQ2. A cet effet, la plateforme CONT dispose de moyens cryptographiques adéquats. Si la signature n'est pas valide (flèche KO en sortie du test S21), la plateforme CONT peut répondre à la requête REQ2 par une redirection vers une page d'erreur ERR (étape S23). En revanche, si la signature est valide (flèche OK en sortie du test S21), la plateforme CONT détermine la valeur maximum (max quai lev) du critère choisi pour le paramètre relatif aux conditions de liaison (un critère de qualité lié au débit qu'offre la liaison, par exemple). Cette valeur est incluse dans la requête URL qu'envoie le terminal TER à la plateforme de service SER dans la requête de contenu REQ2. Par ailleurs, la plateforme de fourniture de service CONT a reçu dans la requête REQ2 (à l'étape S20) une valeur courante du paramètre relatif aux conditions de liaison (par exemple une valeur de qualité « quai lev» du fragment souhaité, déterminée par exemple à partir du débit qu'a pu mesurer le terminal sur la liaison avec la plateforme CONT). A l'étape S22, la plateforme CONT compare la valeur maximum (max quai lev) à la valeur courante du paramètre (qual lev) et, en particulier, si la valeur courante est supérieure à la valeur maximum (flèche KO en sortie du test S22), le terminal peut être redirigé vers la page d'erreur ERR (étape S23), ou, en variante, recevoir de la plateforme CONT le fragment demandé mais à la qualité de niveau maximum accordée pour ce terminal : «max quai lev ». Si en revanche la valeur courante reste inférieure à la valeur maximum (flèche OK en sortie du test S22), la plateforme CONT transmet à destination du terminal le fragment demandé et à la qualité de niveau adéquat estimée par le terminal: « quai lev » (étape 24). La présente invention permet ainsi d'appliquer avantageusement la technique de signature d' adresse URL au mode de communication de type « adaptive streaming » en tenant compte et en tirant partie des spécificités de ce mode de communication. L'invention fournit ainsi une possibilité de restrictions d'accès, sur de nouveaux critères (tels que la qualité audio/vidéo maximum, ou autres critères décrits à titre d'exemples plus loin), à des contenus pour des terminaux clients d'un service de streaming. La plateforme de service SER, en fonction des droits au service du terminal client, incorpore dans l'URL d'accès au contenu les restrictions propres au terminal client, tandis que la plateforme de fourniture de contenu vérifie, quant à elle, ces restrictions en fonction des demandes formulées par le terminal client. En outre, une telle réalisation permet de ne mettre en oeuvre qu'un unique mécanisme de fourniture de contenus pour tous les terminaux clients, permettant ainsi une simplification du service. Ainsi, un nouveau type de paramètre est ajouté dans les URLs de publication, de fichier descriptif (« manifeste » par exemple), et plus généralement dans le gabarit d'URL, tant pour le gabarit d'URL lui-même que pour sa signature, avantageusement en mode de communication d'adaptive streaming. Les avantages que procure l'invention sont nombreux. Notamment, elle permet de contrôler chacune des requêtes du terminal client et en particulier les paramètres insérés par le terminal client dans WRL de la requête. Elle permet aussi de restreindre, au niveau du service, l'accès à une qualité haute définition, par exemple à certains terminaux clients non autorisés ou simplement non équipés pour ce service. Par ailleurs, comme on le verra ci-après dans la présentation d'une liste plus exhaustive de paramètres susceptibles d'intervenir pour la caractérisation des conditions de liaison entre le terminal et le serveur de contenus, l'invention permet aussi de restreindre le nombre de fragments fournis à certains terminaux clients. Ainsi, la présente invention permet de garantir l'authenticité de certaines informations contenues dans des URLs et utilisées par le terminal client pour demander des fragments successifs de contenus, dans le cadre d'une communication de streaming adaptatif, par exemple de type smooth streaming. La présente invention vise aussi la première entité serveur comportant en particulier des moyens au moins pour : - vérifier la signature de la première adresse comportant l'information précitée, - vérifier en outre une compatibilité entre cette information et la valeur courante que comporte l'adresse universelle reçue, et - en cas de vérifications positives, communiquer à destination du terminal au moins un fragment de contenu fonction de la valeur courante. On a représenté sur la figure 4 une telle entité serveur pour la fourniture de contenus. Cette entité CONT comporte dans l'exemple représenté des moyens REC de réception d'une requête de fragment REQ2 issue d'un terminal. Elle comporte en outre des moyens de calcul CALC pour vérifier la signature SGN de la première adresse comportant l'information précitée propre au terminal. Ces moyens CALC peuvent être agencés en outre pour vérifier aussi une compatibilité COMP entre cette information et la valeur courante que comporte l'adresse universelle reçue REQ2. L'entité serveur CONT comporte en outre un module de communication COM, pour envoyer à destination du terminal au moins un fragment FRA de contenu en fonction de la valeur courante, en cas de vérifications positives. La présente invention vise aussi la deuxième entité serveur comportant des moyens au moins pour transmettre à destination du terminal la signature de la première adresse comportant la valeur seuil, sur réception d'une requête initiale du contenu global issue du terminal en la forme de la première adresse universelle. On a alors représenté sur la figure 5 une telle entité serveur pour la génération de signature SGN. Cette entité SER (du type représenté sur la figure 1) comporte des moyens de réception REC de la première requête de contenu issue du terminal REQ. Cette requête REQ comporte notamment l'information propre au terminal INF (comme par exemple le niveau maximum de qualité d'un fragment autorisé pour le terminal). L'entité serveur SER comporte en outre des moyens de calcul CALC pour générer la signature SGN de cette première requête de contenu REQ, ainsi que des moyens de communication COM de la signature SGN, à destination du terminal. La présente invention vise aussi le terminal comportant alors des moyens au moins pour : - déterminer des conditions de liaison et estimer une valeur courante du paramètre caractérisant les conditions de liaison, - à partir de la description des fragments et des valeurs de paramètre lié aux conditions de liaison (indiqués dans le fichier descriptif précité), former une requête d'au moins un fragment de contenu en la forme d'une adresse universelle comportant : * la valeur courante estimée du paramètre pour ce fragment, et * la signature de la première adresse universelle. On a alors représenté sur la figure 6 un tel terminal TER. Par exemple, le terminal comporte des moyens COND pour déterminer des conditions de liaison et estimer une valeur courante du paramètre PARAM caractérisant les conditions de liaison. Le terminal peut comporter en outre une mémoire MEM pour stocker une description DESC des fragments et les valeurs correspondantes du paramètre lié aux conditions de liaison (par exemple sous la forme d'un fichier «manifeste »). La mémoire du terminal peut stocker en outre la signature SGN qu'il a reçue de l'entité serveur SER générant cette signature. Le terminal comporte ensuite des moyens COM pour former une requête d'au moins un fragment de contenu, destinée à l'entité serveur CONT, sous la forme d'une adresse universelle REQ2 comportant : * la valeur courante estimée PARAM du paramètre pour ce fragment, et * la signature SGN de la première adresse universelle précitée. La présente invention vise aussi un système comportant au moins une entité serveur telle que la première entité précitée CONT, ainsi qu'un terminal TER. Dans une réalisation où les première et deuxième entités sont distinctes, le système comporte en outre une deuxième entité serveur SER, pour bénéficier d'une architecture prévoyant une séparation entre la plateforme de service et la plateforme de livraison de contenus. Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ci-avant à titre d'exemple ; elle s'étend à d'autres variantes. Par exemple, on a décrit ci-avant le contrôle d'un paramètre de communication correspondant à la qualité d'image. En complément ou en variante, le contrôle d'autres paramètres sont possibles, tels que par exemple des paramètres de type : - « AudioAuthorized », fixant qu'une composante audio est autorisée pour le terminal client, - « VideoAuthorized », fixant qu'une composante vidéo est autorisée pour le terminal client, - « FragmentVideoMax », fixant le maximum de fragments vidéo autorisés pour le terminal client, - « FragmentAudioMax », fixant le maximum de fragments audio autorisés pour le terminal client, - « QualityMaxLevel », fixant le maximum de la qualité audio et vidéo autorisé pour un terminal client, - « VideoQualityMaxLevel », fixant le maximum de la qualité vidéo autorisé pour un terminal client, - «AudioQualityMaxLevel », fixant le maximum de la qualité audio autorisé pour un terminal client. L'un au moins de ces paramètres peut être combiné dans la signature à d'autres paramètres, tels que par exemple les paramètres : - « Validity », fixant une durée de validité de toutes les requêtes envoyées par le terminal client, - «IpAddress », déterminant l'adresse IP du terminal client autorisé par la plateforme de service. Par ailleurs, il est indiqué précédemment que le terminal peut être dirigé vers une page d'erreur, en cas de non-authenticité d'une signature d'URL. En variante, si la plateforme CONT refuse la signature, elle peut renvoyer par exemple un code d'erreur explicite permettant au terminal client d'essayer avec une nouvelle qualité vidéo/audio plus réduite, ce qui permet de ne pas faire intervenir l'utilisateur du terminal. REVENDICATIONS1. Procédé de communication de données, dans lequel une première entité serveur (CONT) émet des données de contenu destinées à au moins un terminal (TER), en une pluralité de fragments successifs selon un mode de communication continue, adaptative en fonction de conditions de liaison entre le terminal et l'entité serveur, la communication de chaque fragment étant adaptée auxdites conditions de liaison, procédé dans lequel, sur réception d'une requête d'au moins un fragment de contenu (REQ2), issue d'un terminal en la forme d'une adresse universelle comportant au moins une valeur courante d'un paramètre de conditions de liaison (qual lev), l'entité serveur est apte à communiquer à destination du terminal un fragment (FRA) de contenu fonction de la valeur courante dudit paramètre, caractérisé en ce que ladite adresse universelle (REQ2) inclut une signature d'une première adresse universelle (SGN) comportant une information (max quai lev) relative audit paramètre et propre au terminal, et en ce que l'entité serveur (CONT) effectue les étapes : - vérifier (S21) la signature de la première adresse comportant ladite information, - vérifier en outre (S22) une compatibilité entre ladite information et la valeur courante que comporte l'adresse universelle reçue (REQ2), et - en cas de vérifications positives, communiquer à destination du terminal au moins un fragment (FRA) de contenu fonction de la valeur courante. 2. Procédé selon la revendication 1, caractérisé en ce que ladite information comporte une valeur seuil dudit paramètre, et en ce que l'entité serveur compare la valeur courante que comporte l'adresse universelle reçue (REQ2) à ladite valeur seuil pour vérifier ladite compatibilité (S22). 3. Procédé selon la revendication 2, dans lequel le terminal dispose d'un droit d'accès à une qualité de contenu maximum, prédéterminée, caractérisé en ce que la valeur seuil correspond au maximum de qualité de contenu à laquelle a droit le terminal, et en ce que la valeur courante de paramètre correspond à un maximum de qualité de contenu que permettent les conditions de liaison entre le terminal et l'entité serveur. 4. Procédé selon l'une des revendications 2 et 3, dans lequel le terminal dispose d'un droit d'accès à un nombre maximum de fragments de contenu, prédéterminé, caractérisé en ce que la valeur seuil correspond audit nombre maximum de fragments de contenu auquel a droit le terminal, et en ce que la valeur courante de paramètre correspond à un nombre maximum de fragments de contenu à communiquer que permettent les conditions de liaison entre le terminal et l'entité serveur. 15 5 . Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte une étape préalable dans laquelle une deuxième entité serveur (SER) transmet à destination du terminal ladite signature (SGN) de la première adresse comportant ladite information, sur réception d'une requête (REQ) initiale du contenu global, issue du terminal en la forme de la première adresse universelle. 6. Procédé selon la revendication 5, caractérisé en ce que la deuxième entité serveur (SER) est distincte de la première entité serveur (CONT), en ce que la deuxième entité serveur comporte une plateforme de service et en ce que la première entité serveur comporte une plateforme de livraison de contenu. 7. Procédé selon l'une des revendications précédentes, caractérisé en ce que lesdits fragments et lesdites valeurs de paramètre lié aux conditions de liaison sont définis dans un fichier descriptif (MAN) que la première entité serveur transmet à destination du terminal, sur réception d'une requête dudit fichier descriptif, issue du terminal en la forme d'une adresse universelle (REQ1) comportant ladite signature (SGN) de la première adresse universelle. 8. Procédé selon la revendication 5, caractérisé en ce qu'il comporte les étapes : sur réception d'une requête initiale (REQ) du contenu global, issue du terminal (TER) en la forme de ladite première adresse universelle, la deuxième entité serveur (SER) transmet à destination du terminal ladite signature de la première adresse (SGN) comportant ladite information propre au terminal, le terminal (TER) émet une deuxième requête (REQ1) d'un fichier descriptif définissant lesdits fragments et lesdites valeurs de paramètre lié aux conditions de liaison, ladite deuxième requête (REQ1) étant destinée à la première entité serveur (CONT) et ayant pour forme une adresse universelle incluant ladite signature de la première adresse (SGN), la première entité serveur (CONT), sur réception de la deuxième requête (REQ1) issue du terminal, vérifie (S10) ladite signature et, si la vérification est positive, transmet à destination du terminal (TER) ledit fichier descriptif (MAN), sur la base d'une détermination des conditions de liaison et de la description des fragments et desdites valeurs de paramètre lié aux conditions de liaison, le terminal (TER) émet une requête (REQ2) d'au moins un fragment de contenu en la forme d'une adresse universelle (REQ2) comportant : * une valeur courante dudit paramètre pour ledit au moins un fragment, et * ladite signature de la première adresse universelle, et, sur la base de ladite adresse universelle reçue, la première entité serveur (CONT) : * vérifie (S21) la signature de la première adresse universelle, afin de vérifier une authenticité de ladite information, * vérifie en outre (S22) une compatibilité entre ladite information et la valeur courante que comporte l'adresse universelle reçue (REQ2), et * en cas de vérifications positives, communique à destination du terminal au moins un fragment (FRA) de contenu fonction de la valeur courante. 9. Programme informatique comportant des instructions pour la mise en oeuvre du procédé selon l'une des revendications 1 à 8, lorsque ce programme est exécuté par un processeur. 10 10. Entité serveur (CONT) pour la mise en oeuvre du procédé selon l'une des revendications 1 à 8, caractérisée en ce qu'elle comporte des moyens au moins pour : - vérifier (S21) la signature de la première adresse comportant ladite information, - vérifier en outre (S22) une compatibilité entre ladite information et la valeur courante que 15 comporte l'adresse universelle reçue (REQ2), et - en cas de vérifications positives, communiquer à destination du terminal au moins un fragment (FRA) de contenu fonction de la valeur courante. 11. Entité serveur (SER) pour la mise en oeuvre du procédé selon l'une des revendications 5, 6 et 8, 20 caractérisée en ce qu'elle comporte des moyens au moins pour transmettre à destination du terminal ladite signature (SGN) de la première adresse comportant ladite information propre au terminal, sur réception d'une requête (REQ) initiale du contenu global, issue du terminal en la forme de la première adresse universelle. 25 12. Terminal (TER) pour la mise en oeuvre du procédé selon la revendication 8, caractérisé en ce qu'il comporte des moyens au moins pour : - déterminer des conditions de liaison et estimer une valeur courante dudit paramètre des conditions de liaison, - à partir de la description des fragments et desdites valeurs de paramètre lié aux conditions 30 de liaison, former une requête d'au moins un fragment de contenu en la forme d'une adresse universelle (REQ2) comportant : * la valeur courante estimée dudit paramètre pour ledit au moins un fragment, et * ladite signature de la première adresse universelle (SGN). 13. Terminal (TER) selon la revendication 12, caractérisé en ce qu'il comporte en outre des moyens pour insérer ladite information au moins dans la requête initiale du contenu global pour former ladite première adresse universelle (REQ). 14. Système comportant au moins une entité serveur (CONT) selon la revendication 10 et un terminal (TER) selon l'une des revendications 12 et 13. 15. Système selon la revendication 14, comportant en outre au moins une deuxième entité serveur (SER) selon la revendication 11.