FR 2947123 A1 20101224 FR 0954145 A 20090619 Procédés de transmission entre un émetteur et un récepteur, avec transmission d'une donnée additionnelle en fonction de la longueur d'au moins deux paquets, émetteur et récepteur correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communication de données par paquets (suivant par exemple le modèle de référence OSI (pour �Open System Interconnection � en anglais, ou � Interconnexion de Systèmes Ouverts � en français)). Plus précisément, l'invention concerne une technique de transmission de données entre un émetteur et un récepteur, permettant à l'émetteur de transmettre des données principales, sous forme de paquets, et au moins une donnée additionnelle. L'invention s'applique à tout type de donnée additionnelle, et notamment mais non exclusivement à une donnée de type classe de trafic, associée à un paquet isolé ou à un ensemble de paquets appartenant au flux d'une même session établie entre un émetteur et un récepteur. 2. ARRIÈRE-PLAN TECHNOLOGIQUE Traditionnellement, dans les réseaux de communications de données par paquets mettant en oeuvre un émetteur et un récepteur, l'aspect QoS (pour � Quality of Service � en anglais, ou � Qualité de Service � en français) peut s'avérer primordial dans le cas d'applications réparties au moyen d'un tel réseau, nécessitant un traitement en temps réel. Deux grands modèles d'architecture de Qualité de Service ont été proposées dans l'industrie des réseaux basés sur l'usage de la famille de protocoles IP. Ces deux modèles sont baptisés � Differentiated Services � (� DiffServ � ou � Services Différenciés � en français) et � Integrated Services � (� IntServ � ou � Services Intégrés � en français).Le premier � DiffServ � est un mécanisme à granularité grossière, basé sur la notion de Classe de Service (� Class of Service � en anglais) pour la gestion du trafic ; en contraste le second � IntServ � est un mécanisme à granularité fine basé sur la notion de flux. Le premier modèle, DiffServ, tel que notamment défini par l'IETF dans les normes RFC 2474, RFC 2475, RFC 2597, RFC 3086, RFC 3246, RFC 3290 et RFC 4594, utilise un marquage de paquet pour classifier et traiter indépendamment chaque paquet. Il n'y a aucune garantie spécifique de bande passante aux paquets d'un même flux et il n'y a pas dans ce modèle de fonctionnalité de contrôle d'admission pour les nouveaux flux. Chaque paquet contient dans son entête la valeur de la classe de trafic à laquelle il appartient et donc la qualité de service qui doit lui être fourni par chaque noeud du réseau. Ainsi une hiérarchie de traitement des paquets est envisageable. L'information de classe de services peut-être présente à différents niveaux du modèle OSI suivant la politique de mise en oeuvre de la QoS. Dans la majorité des cas, on retrouve ce marquage pour le protocole de niveau deux (c'est-à-dire la couche liaison) ou de niveau trois (c'est-à-dire la couche réseau). Dans le cas où ces informations de classe de service se retrouvent au niveau trois de la couche OSI, elles sont par exemple dans les entêtes des datagrammes IP (via l'utilisation, pour l'IPv4, du champ TOS (pour � Type Of Service � en anglais, ou � Type de Service � en français) codé sur 8 bits dont les 6 premiers bits constituent le champ DSCP (pour � Differentiated Services Code Point � en anglais, ou � Point de Code de Services Différenciés � en français) et les deux derniers bits constituent le champ ECN (pour � Explicit Congestion Notification � en anglais, ou � Notification Explicite de Congestion � en français) et pour l'IPv6 du champ � Traffic Class � (� Classe de Trafic � en français) identique au champ TOS de l'IPv4. Dans le cas où les informations de classe de service se retrouvent au niveau 2 de la couche OSI, elles sont par exemple dans les entêtes des trames Ethernet (représentées par un champ de 3 bits appelé � User priority-Frame priority � (en français � priorité utilisateur, priorité de frame �) tel que défini dans la norme IEEE 802.Q et ses annexes. Le second modèle, IntServ, tel que défini par l'IETF dans la norme RFC 1633, utilise un concept basé sur la notion de flux associé à un protocole de signalisation sur le chemin parcouru par les paquets. Ce modèle permet que la manière dont est signifiée la QoS soit préservée de bout en bout. La QoS est indiquée dans la requête générée par l'émetteur et est interprétée par le récepteur, de manière à fournir un service particulier pour le flux de données (correspondant à la requête) ; le flux de données est alors identifié par une combinaison d'adresse source, adresse destination, protocole de transport, port source et port destination. Le protocole de signalisation garantit que les ressources nécessaires sont disponibles à chaque saut du chemin (� hop � en anglais) de noeud en noeud pour ce flux avant que celui-ci ne soit admis à circuler sur le réseau. Ce protocole peut-être par exemple, le protocole RSVP (acronyme anglais de � Resource ReSerVation Protocol � ou � Protocole de Réservation de Ressources � en français) qui est mis en oeuvre dans une couche de communication au dessus de IP (IPv4 ou IPv6). Afin de définir la correspondance entre un flux et une réservation donnée de ressources dans les noeuds du réseau, tous les paquets appartenant à un même flux sont identifiés soit de manière explicite, soit de manière implicite. Dans le cas d'une identification explicite de flux, les paquets ont un champ référencé dans l'entête. Par exemple, une information de label de flux est présente dans les en-têtes de paquets IPv6 (couche 3 du modèle OSI ; le label de flux est un champ de 20 bits). Dans le cas d'une identification implicite de flux, l'identification du flux auquel appartient un paquet peut être réalisée par analyse, par exemple, d'un ensemble de trois ou quatre champs d'un paquet, tels que le type de protocole applicatif, le numéro de port du protocole de niveau transport, l'adresse source et l'adresse destination. Ainsi, il apparaît clairement que la mise en oeuvre d'une gestion de la QoS (selon le modèle DiffServ ou IntServ) nécessite l'insertion de bits spécifiques dans les paquets échangés entre un émetteur et un récepteur. Cela a pour effet de surcharger la bande passante du canal de communication reliant l'émetteur et le récepteur. De plus, cela induit une charge en ressource processeur non négligeable de la part de l'émetteur ainsi que du récepteur, mais également de la part de tous les noeuds du réseau sur le chemin de ces paquets. En effet, il faut insérer, lire ou analyser les champs nécessaires à la gestion de la QoS. De plus, dans le cas où les paquets transmis par l'émetteur sont chiffrés, il faut récupérer les informations relatives à la gestion de la QoS en déchiffrant chaque paquet (et ce quelle que soit la valeur de classe de trafic), ce qui augmente encore la charge en ressource processeur. Or un problème récurrent dans le domaine des réseaux de communication est de savoir comment économiser la bande passante ainsi que la charge en ressource processeur. On connaît, dans l'état de la technique, une solution développée par la société Nokia et décrite dans le brevet US 7,050,403. Cette solution, appliquée à la couche 3 du modèle OSI, consiste à ne pas insérer de façon explicite les bits représentant la valeur de la classe d'un paquet (i.e. les bits DSCP de l'octet TOS dans le protocole IPv4) en tirant profit du fait que les paquets émis sont soit de tailles courtes (dans le cas du transport d'échantillons de voix nécessitant un traitement en temps réel) soit de tailles grandes (dans le cas de transport de données classiques tel que le transfert de fichiers ne nécessitant pas un traitement en temps réel) de par le contenu de ces paquets. En effet, en partant de ce constat, on peut ne pas utiliser les bits de classe de trafic d'un paquet car en réception, pour classifier ce paquet il suffit de comparer la longueur du paquet reçu avec une valeur seuil pour classifier ledit paquet selon deux catégories (paquets courts et paquets longs). Ainsi, en appliquant cette technique, on économise le temps de traitement ainsi que la charge processeur pour insérer, lire ou analyser les bits DSCP de l'entête d'un paquet IP. Cette technique pourrait aussi s'appliquer à un modèle de QoS de type IntServ (pour identifier au plus deux flux) ainsi qu'à la couche de niveau 2 du modèle OSI. Toutefois, un inconvénient de la solution Nokia est que cette dernière est restrictive car elle ne permet pas de gérer les cas où plus de deux classes de trafic sont utilisées dans un réseau offrant plus de deux classes de services. De plus, si la solution Nokia est mise en oeuvre, un émetteur peut aisément générer uniquement des paquets de petite taille afin qu'ils bénéficient tous d'un traitement privilégié, annulant ainsi le bénéfice d'une classification des paquets pour les traitements différenciés du modèle DiffServ qui ne comporte pas de contrôle d'admission. Ainsi, un attaquant malveillant peut aisément mettre en oeuvre un déni de service (c'est-à-dire que le récepteur peut être saturé par l'envoi d'une multitude de paquets de petites tailles). Un autre inconvénient de la solution Nokia apparaît lors de la mise en oeuvre de celle-ci dans un contexte de mise en communication de dispositifs, ou de réseaux LAN, par le biais d'un tunnel de niveau deux (mise en oeuvre de ponts (pour � Local Area Network � en anglais ou � Réseau Local � en français) conformes au standard IEEE 802.1Q). Les paquets transitant dans le tunnel (appelés � paquets tunnel �) sont ordinairement chiffrés par une première une tête de tunnel (point d'entrée du tunnel). A l'extrémité de ce tunnel, une deuxième tête de tunnel reçoit ce paquet tunnel, le déchiffre, et en extrait la trame de niveau 2 initialement encapsulée pour enfin la transmettre sur le réseau LAN auquel elle est connectée, à destination du terminal destinataire. La première tête de tunnel peut marquer le paquet tunnel qui transporte une trame du terminal source avec une indication de la classe de trafic qui correspond au besoin de l'application grâce à un mécanisme de reconnaissance de trafic, ou bien la première tête de tunnel peut dans un modèle de QoS avec réservation (de type IntServ) procéder à une réservation de ressources selon un protocole de signalisation de QoS tel que RSVP. Il apparaît clairement à l'exposé de ce contexte que si on applique la solution Nokia, un attaquant, interceptant les trames émises d'une première tête de tunnel vers une deuxième tête de tunnel (avec chiffrement des paquets), peut aisément déterminer les paquets nécessitant un traitement rapide ou non (i.e en temps réel ou non). Il a donc, par ce moyen, connaissance de l'importance du contenu des paquets, ce qui peut être perçu comme contraire au principe de confidentialité. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique de transmission, entre un récepteur et un émetteur, d'au moins une donnée additionnelle, en économisant la bande passante d'un canal de communication principal alloué à la transmission de données principales. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique permettant d'optimiser le temps de traitement des paquets (à la réception) ainsi que les ressources mémoires utilisées. Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique permettant de protéger ladite donnée additionnelle en cas d'interception des paquets émis. Notamment une telle technique peut s'appliquer à une transmission entre une première et une deuxième tête de tunnel et ne nécessite pas, dans le cas où les paquets émis par la première tête de tunnel sont chiffrés, que la deuxième tête de tunnel ait à les déchiffrer systématiquement pour obtenir ladite donnée additionnelle. Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique permettant d'éviter la perte d'une donnée lorsque celle-ci est référencée explicitement dans un champ d'un en-tête d'un paquet. En d'autres termes, la technique ne doit pas être impactée par des modifications potentielles (voire la perte) de certains champs des paquets de données par des dispositifs intermédiaires (routeurs,... ). Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique compatible avec la fonction de fragmentation au niveau de la couche IP. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une technique de contrôle permettant d'empêcher un déni de service (sur le récepteur) par un attaquant malveillant ou permettant de détecter la réception de paquets modifiés par ledit attaquant. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de transmission de données entre un émetteur et un récepteur sous forme de paquets. L'émetteur effectue des étapes consistant à : - appliquer un encodage sur une donnée additionnelle, qui est additionnelle à des données principales, l'encodage générant un premier ensemble d'au moins deux valeurs de longueur ; - former une séquence d'au moins deux paquets à partir desdites données principales et selon une technique de formation de paquet prédéterminée, de sorte qu'un second ensemble formé par la longueur de chaque paquet de ladite séquence correspond au premier ensemble généré par l'encodage ; - transmettre lesdits paquets formés audit récepteur. Le principe général de l'invention, côté émetteur, consiste donc à appliquer un encodage permettant d'éviter la transmission explicite d'une donnée additionnelle via l'émission de bits réservés à cet effet sur un canal de communication principal alloué à la transmission de données principales (ou via l'émission de bits sur un canal de communication secondaire). Remarquons que les données principales peuvent être générées par l'émetteur ou bien préalablement reçues par l'émetteur (par exemple sous la forme de paquets). L'encodage utilise quant à lui la modulation de la longueur d'au moins deux paquets successifs (et pas nécessairement consécutifs) émis sur ledit canal afin de pallier le problème exposé précédemment. Ainsi, la présente invention permet d'économiser de la bande passante entre l'émetteur et le récepteur en créant un canal de communication caché, basé sur le canal de communication principal mais ne nécessitant aucune bande passante supplémentaire (autre que celle du canal de communication principal). La solution Nokia n'envisage pas l'utilisation d'un encodage, ni a fortiori l'usage d'une technique de formation de paquet en fonction du résultat de cet encodage. Elle tire uniquement avantage de la structure des paquets émis. Contrairement à la solution Nokia qui ne peut véhiculer que deux valeurs d'une donnée additionnelle, la donnée additionnelle peut, dans la présente invention, prendre un nombre quelconque de valeurs (qui peut donc être supérieur à deux, et même relativement grand si nécessaire). Par exemple, ce nombre peut être directement proportionnel au nombre de paquets successifs utilisés pour transmettre la donnée additionnelle. En effet, dans le cas particulier où chaque paquet prend une longueur parmi deux longueurs possibles, on peut transmettre une donnée additionnelle pouvant prendre 2AN valeurs possibles, avec N le nombre de paquets successifs utilisés pour transmettre la donnée additionnelle. Cette famille d'encodage est simple à mettre en oeuvre et peu coûteuse : il suffit d'utiliser une correspondance directe entre les longueurs des paquets successifs et la donnée additionnelle. Par exemple, un encodage peut être présenté comme un enchaînement de longueurs de paquets successifs. Il permet de distinguer au moins deux valeurs de donnée additionnelle. Par exemple pour une première valeur, on fait correspondre la séquence de longueur suivante L1 = 20 octets et L2 = 100 octets, et pour une deuxième valeur, on fait correspondre la séquence de longueur suivante L1 = 40 octets et L2 = 60 octets. Remarquons que plus une séquence de longueurs est grande, plus il est, au moins pour certaines séquences, facile de détecter û voire de corriger - des erreurs de transmission (en effet, pour au moins certains couples de séquences, on augmente la distance entre les deux valeurs possibles si on n'utilise pas tout le spectre de séquences possibles). Un autre exemple d'encodage peut être présenté par une règle simple comme l'association d'un bit à zéro pour une longueur paire d'un paquet et d'un bit à un pour une longueur impaire d'un paquet; cette règle pouvant s'appliquer pour au moins deux paquets du flux de donnée principal. Par exemple, soit un flux de donnée principal représenté par la suite de T paquets porteurs notés P_1, P_2,....P_T (avec T un entier par exemple égal à 8, ou 32), alors une donnée additionnelle dont la représentation binaire est 110 peut être encodée par l'émission de trois paquets (par exemple P_2, P_6, P_15) dont les longueurs correspondent à la série de longueurs ayant la caractéristique suivante : impaire, impaire, paire. En reprenant l'exemple, les longueurs des paquets P_2, P_6, P_15 sont impaire, impaire et paire respectivement. Sans la connaissance de l'encodage (et donc de l'ordonnancement des paquets véhiculant la donnée additionnelle), un attaquant malveillant ne peut pas retrouver la donnée additionnelle ainsi transmise. En effet, l'utilisation d'un encodage permet de protéger avantageusement une donnée additionnelle en répartissant l'information utile de celle-ci dans plusieurs paquets. Ainsi un attaquant malveillant aurait à intercepter et analyser plusieurs paquets, ce qui est difficile à mettre en oeuvre sans la connaissance de l'encodage utilisé (or l'encodage n'est partagé qu'entre l'émetteur et le récepteur ; un tiers n'a pas connaissance dudit encodage). Remarquons enfin que le procédé peut aussi être utilisé lorsqu'au moins une partie des données principales est chiffrée. En effet, la donnée additionnelle étant transmise via la modulation de longueur d'une séquence de paquets successifs, elle n'est donc pas chiffrée et peut être récupérée par le récepteur sans que ce dernier ait à déchiffrer les données principales. Il en découle donc un gain en performance au niveau du récepteur. De plus, la connaissance de la donnée additionnelle (par exemple la classe de service) par ce moyen permet de mieux choisir le traitement à effectuer sur les paquets. En l'occurrence, ce traitement peut être un déchiffrement du contenu des paquets via l'utilisation d'un module matériel dédié (ou � hardware � en anglais) ou bien d'un logiciel (� software � en anglais) suivant le délai de latence spécifié. Ainsi on alloue de manière avantageuse les ressources du récepteur. Dans un mode de réalisation particulier de l'invention, dans l'étape consistant à former une séquence d'au moins deux paquets à partir desdites données principales, l'émetteur applique une première technique de formation de paquet consistant à, pour au moins un paquet, construire une partie utile dudit paquet, uniquement à partir desdites données principales. Ainsi, l'usage de cette technique de formation de paquet permet d'optimiser la bande passante disponible. En effet, avec cette technique, aucune information non utile n'est véhiculée à travers le canal de communication principal. De plus, la combinaison de cette technique de formation de paquet avec l'encodage utilisé pour définir la longueur d'au moins deux paquets permet de se prémunir contre un attaquant malveillant souhaitant saturer le récepteur. En effet, le récepteur peut détecter aisément l'envoi de paquets � frauduleux � émis par l'attaquant malveillant (soit ils ne correspondent pas au format attendu, soit la donnée additionnelle est une donnée de marquage permettant de prouver que c'est bien l'émetteur qui a envoyé ces paquets à destination du récepteur). Dans un mode de réalisation particulier de l'invention, dans l'étape consistant à former une séquence d'au moins deux paquets à partir desdites données principales, l'émetteur applique une deuxième technique de formation de paquet consistant à, pour au moins un paquet, construire une partie utile dudit paquet en concaténant des données principales avec une ou plusieurs données de bourrage, si nécessaire. Ainsi, les paquets générés utilisent des données principales en association avec des données de bourrage (ou de � padding � en anglais). De plus, la combinaison de cette technique de formation de paquet avec l'encodage utilisé pour définir la longueur d'au moins deux paquets permet de se prémunir contre un attaquant malveillant souhaitant saturer le récepteur. En effet, le récepteur peut détecter aisément l'envoi de paquets � frauduleux � émis par l'attaquant malveillant (soit ils ne correspondent pas au format attendu, soit la donnée additionnelle est une donnée de marquage permettant de prouver que c'est bien l'émetteur qui a envoyé ces paquets à destination du récepteur). Dans le cas de l'utilisation d'un générateur pseudo-aléatoire, si la graine dudit générateur est partagée entre l'émetteur et le récepteur et que des vérifications sont opérées sur les données de bourrages par le récepteur, un attaquant malveillant, qui souhaiterait saturer le récepteur, et qui aurait intercepté des paquets transmis entre l'émetteur et le récepteur (suite à l'écoute du canal de communication) ne pourrait pas utiliser les informations collectées suite à l'interception des paquets pour effectuer des attaques de type déni de service. Selon une caractéristique avantageuse, la donnée additionnelle est relative à une caractéristique des données principales. Ainsi, transmettre une donnée additionnelle, qui est une caractéristique liée aux données principales, permet de garantir que le paquet reçu a bien été émis par l'émetteur et non par un attaquant malveillant (par exemple la donnée additionnelle peut être un � checksum � (ou une � somme de contrôle � en français) sur les données principales incluses dans le paquet ou sur l'ensemble des données principales permettant alors de garantir l'intégrité des données principales incluses dans le paquet ou de l'ensemble des données principales). En outre, la donnée additionnelle ainsi associée à une caractéristique liée aux données principales permet de pouvoir déterminer simplement un traitement à appliquer en réception sur les données principales. La donnée additionnelle est par exemple une représentation de la classe de service caractérisant les données principales. Dans un mode de réalisation particulier de l'invention, dans l'étape consistant à former une séquence d'au moins deux paquets à partir desdites données principales, l'émetteur applique une troisième technique de formation de paquet consistant à, pour au moins un paquet, construire une partie utile dudit paquet en concaténant des données principales avec des données secondaires. Par exemple, la technique de formation de paquet permet de construire un paquet en combinant au moins une partie des données principales (par exemple un flux vidéo) avec au moins une partie des données secondaires (par exemple un flux audio) afin d'obtenir la longueur voulue pour ledit paquet. Ainsi dans le cas d'une application, côté récepteur, nécessitant des données issues de deux flux (telle que par exemple une application fournissant la réception une chaîne de télévision en mode continu), les deux flux arrivant ainsi en même temps, il n'est plus nécessaire de mettre dans un tampon de mémoire un premier flux puis de le combiner avec la réception du deuxième flux. Ainsi on gagne en temps de traitement ainsi qu'en ressource mémoire utilisée. Remarquons que les trois techniques de formation exposées précédemment peuvent être combinées pour former une séquence de paquets désirée. Selon une caractéristique avantageuse, la donnée additionnelle est relative à une caractéristique commune aux données principales et secondaires. Par exemple, si les données principales et secondaires correspondent à des flux de données (par exemple un flux audio et un flux vidéo) ayant une caractéristique commune (par exemple une même valeur de classe de service,..), le fait de transmettre via le canal caché une seule fois l'information additionnelle permet d'économiser le débit du canal caché (en transmettant via la modulation de la longueur d'au moins deux paquets une information commune aux flux de données passagers). Selon une caractéristique avantageuse, la donnée additionnelle correspond à une information appartenant au groupe comprenant : - une valeur d'une classe de service associée aux données principales ; - un identifiant de flux associé à une réservation préalable de ressources effectuée dans l'émetteur, le récepteur et/ou au moins un dispositif ou lien de transmission intermédiaire, ledit identifiant de flux se rapportant aux données principales. Ainsi, l'utilisation de cette technique permet de mettre en oeuvre une politique de Qualité de Service (par exemple de type DiffServ ou IntServ) sans émettre explicitement les bits d'informations permettant de définir l'appartenance d'un ensemble de paquets à une classe de service donnée, ou à un flux donné. Selon une caractéristique avantageuse, le procédé comprend une étape préalable consistant à synchroniser l'émetteur avec le récepteur pour l'encodage à appliquer par l'émetteur et/ou pour la technique de formation de paquet. Ainsi, la phase de synchronisation permet à l'émetteur et au récepteur de partager la même technique d'encodage utilisée pour transmettre ladite information additionnelle. Sans cette étape de synchronisation, le récepteur n'est pas capable d'extraire l'information additionnelle émise par l'émetteur. Cette synchronisation peut s'effectuer soit de manière dynamique (via des échanges entre l'émetteur et le récepteur ou éventuellement avec un dispositif tiers (tel un serveur)) soit de manière statique (lors d'une phase de personnalisation, par exemple au cours d'une configuration en usine de l'émetteur et du récepteur). Dans un mode de réalisation particulier de l'invention, l'émetteur et le récepteur sont une première et une deuxième tête de tunnel respectivement, entre lesquelles est établi un tunnel, lesdits paquets formés étant des paquets tunnels transmis via ledit tunnel. Ainsi, les ressources du récepteur (mémoires, utilisation ou non de composants matériels,...) peuvent être utilisées au mieux pour traiter les paquets tunnels. De plus, le fait de transmettre de cette manière la classe de service permet de protéger cette information. En effet, si elle avait été stockée explicitement dans un champ (par exemple le champ DS du paquet IP tunnel), elle n'aurait pas été prise en compte par le fournisseur d'accès Internet et aurait même été réécrite par une valeur décidée par ce fournisseur pour la bonne gestion de son réseau WAN. Dans un mode de réalisation particulier de l'invention, le procédé est remarquable en ce que l'émetteur est un terminal source et le récepteur est une première tête de tunnel, un tunnel étant établi entre ladite première tête de tunnel et une deuxième tête de tunnel, ledit tunnel offrant au moins deux protocoles de transport; la donnée additionnelle est une information identifiant l'un desdits au moins deux protocoles de transport. Ainsi, le terminal source n'a pas à transmettre explicitement à la première tête de tunnel la valeur associée au protocole de transport que ladite première tête de tunnel doit utiliser pour émettre des paquets vers une deuxième tête de tunnel. Un gain non négligeable de la bande passante disponible entre le terminal source et la première tête de tunnel est ainsi obtenu. Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de transmission de données entre un émetteur et un récepteur sous forme de paquets. Le récepteur effectue des étapes consistant à : - recevoir une séquence d'au moins deux paquets comprenant des données principales ; - obtenir un ensemble d'au moins deux valeurs de longueurs, formé par la longueur de chaque paquet reçu de ladite séquence ; - appliquer un décodage sur ledit ensemble d'au moins deux valeurs de longueur, le décodage générant une donnée additionnelle qui est additionnelle auxdites données principales ; - extraire lesdites données principales des paquets reçus, en fonction d'une technique de formation de paquet prédéterminée, utilisée par l'émetteur pour former ladite séquence à partir des données principales. Le principe général de l'invention, côté récepteur, consiste donc à appliquer un décodage permettant d'éviter la transmission explicite, côté émetteur, d'une donnée additionnelle via l'émission de bits réservés à cet effet sur un canal de communication principal alloué à la transmission de données principales (ou via l'émission de bits sur un canal de communication secondaire). Le décodage utilise la modulation de la longueur d'au moins deux paquets émis sur ledit canal afin de pallier ce problème. Ainsi, la présente invention permet d'économiser de la bande passante entre l'émetteur et le récepteur en créant un canal de communication caché, basé sur le canal de communication principal mais ne nécessitant aucune bande passante supplémentaire (autre que celle du canal de communication principal). De plus, contrairement à la solution Nokia qui ne peut véhiculer que deux valeurs d'une donnée additionnelle, la donnée additionnelle peut, dans la présente invention, prendre au moins trois valeurs distinctes. En effet, l'ensemble des valeurs prises par une donnée additionnelle est relativement grand. Enfin dans le cas particulier où au moins une partie de données principales est chiffrée, cette technique permet d'éviter de déchiffrer, côté récepteur, les données principales chiffrées afin d'obtenir la donnée additionnelle, qui est par exemple la valeur de la classe de service associée aux données principales. Il en découle donc un gain en performance au niveau du récepteur. De plus, la connaissance de la donnée additionnelle (par exemple la classe de service) par ce moyen permet de mieux choisir le traitement à effectuer sur les paquets. En l'occurrence, ce traitement peut être un déchiffrement du contenu des paquets via l'utilisation d'un module matériel dédié (ou � hardware � en anglais) ou bien d'un logiciel (� software � en anglais) suivant le délai de latence spécifié. Ainsi on alloue de manière avantageuse les ressources du récepteur. Selon une caractéristique avantageuse, la donnée additionnelle correspond à une information appartenant au groupe comprenant : - une valeur d'une classe de service associée aux données principales ; - un identifiant de flux associé à une réservation préalable de ressources effectuée dans l'émetteur, le récepteur et/ou au moins un dispositif ou lien de transmission intermédiaire, ledit identifiant de flux se rapportant aux données principales. Ainsi, l'utilisation de cette technique permet de mettre en oeuvre une politique de Qualité de Service (de type DiffServ ou IntServ) sans émettre explicitement les bits d'informations permettant de définir l'appartenance d'un paquet à une classe de service ou à un flux. Selon une caractéristique avantageuse, le procédé comprend une étape préalable consistant à synchroniser le récepteur avec l'émetteur pour le décodage à appliquer par le récepteur et/ou pour la technique de déformation de paquet Ainsi, la phase de synchronisation permet à l'émetteur et au récepteur de partager la même technique d'encodage utilisée pour transmettre ladite information additionnelle. Sans cette étape de synchronisation, le récepteur n'est pas capable d'extraire l'information additionnelle émise par l'émetteur. Cette synchronisation peut s'effectuer soit de manière dynamique (via des échanges entre l'émetteur et le récepteur ou éventuellement avec un dispositif tiers (tel un serveur)) soit de manière statique (lors d'une phase de personnalisation, par exemple au cours d'une configuration en usine de l'émetteur et du récepteur). Dans un mode de réalisation particulier de l'invention, l'émetteur et le récepteur sont une première et une deuxième tête de tunnel respectivement, entre lesquelles est établi un tunnel, lesdits paquets reçus étant transmis via ledit tunnel. Ainsi, les ressources du récepteur (mémoires, utilisation ou non de composants matériels,...) peuvent être utilisées au mieux pour traiter les paquets porteurs tunnels. Dans une variante avantageuse, il est proposé un procédé de transmission de données entre un émetteur et un récepteur, sous forme de paquets, comprenant des étapes consistant à : - appliquer un encodage sur une donnée additionnelle qui est additionnelle à des données principales, permettant de déterminer la longueur d'au moins un paquet; - former ledit au moins un paquet à partir des données principales, selon une technique de formation de paquet, de sorte que ledit au moins un paquet possède la longueur définie par l'encodage ; - transmettre lesdits paquets formés audit récepteur. Ainsi, contrairement à la technique Nokia qui n'envisage pas l'utilisation d'un encodage, la technique proposée implique l'usage d'un encodage. Selon une caractéristique particulière de cette variante avantageuse, dans l'étape consistant à appliquer un encodage sur la donnée additionnelle, l'émetteur applique un encodage permettant de déterminer la longueur d'un paquet, parmi au moins trois groupes de longueurs, en fonction de ladite donnée additionnelle. Ainsi, le récepteur n'a pas à attendre la réception de plusieurs paquets pour obtenir une donnée additionnelle et ainsi appliquer un traitement approprié. Le temps de latence (à la fois au niveau de l'émetteur et au niveau du récepteur) est donc faible grâce à l'emploi de cet encodage. Par exemple, ledit deuxième encodage peut consister à définir une longueur, notée L, d'un paquet telle que la valeur R = L mod N (où N est un nombre entier supérieur ou égal à trois et mod est l'opération de réduction modulaire) correspond à la donnée additionnelle à transmettre. De manière avantageuse, N est une puissance de deux ; ainsi pour transmettre k bits (k strictement supérieur à deux) d'une donnée additionnelle via un paquet donné, il suffit de déterminer la longueur L de ce paquet telle que la valeur L mod 2^k correspond à la donnée additionnelle à transmettre. L'avantage d'utiliser une puissance de deux pour le nombre N réside dans le fait que le récepteur n'a qu'à obtenir les k bits de poids faibles de la représentation binaire de la longueur L pour obtenir les k bits constitutifs de la donnée additionnelle. Aucun traitement supplémentaire n'est alors nécessaire pour obtenir les bits d'information de la donnée additionnelle. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur. Ce produit programme d'ordinateur comprend des instructions de code de programme pour la mise en oeuvre du procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un moyen de stockage lisible par ordinateur, éventuellement totalement ou partiellement amovible, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation). Dans un autre mode de réalisation, l'invention concerne un émetteur comprenant : - des moyens d'encodage appliqués sur une donnée additionnelle, qui est additionnelle à des données principales, lesdits moyens d'encodage générant un premier ensemble d'au moins deux valeurs de longueur ; - des moyens de génération de paquets permettant de former une séquence d'au moins deux paquets à partir desdites données principales et selon une technique de formation de paquet prédéterminée, de sorte qu'un second ensemble formé par la longueur de chaque paquet de ladite séquence correspond au premier ensemble généré par l'encodage ; - des moyens de transmission, permettant de transmettre lesdits paquets formés. Avantageusement, les moyens de génération de paquets comprennent des moyens de construction, selon une première technique, permettant de construire, pour au moins un paquet, une partie utile dudit paquet, uniquement à partir desdites données principales. Avantageusement, les moyens de génération de paquets comprennent des moyens de construction, selon une deuxième technique, permettant de construire, pour au moins un paquet, une partie utile dudit paquet, en concaténant des données principales avec une ou plusieurs données de bourrage, si nécessaire. Préférentiellement, la donnée additionnelle est relative à une caractéristique des données principales. Avantageusement, les moyens de génération de paquets comprennent des moyens de construction, selon une troisième technique, permettant de construire, pour au moins un paquet, une partie utile dudit paquet, en concaténant des données principales avec des données secondaires, les données principales étant des données issues d'un premier flux à transmettre depuis l'émetteur vers le récepteur, les données secondaires étant des données issues d'un second flux à transmettre depuis l'émetteur vers le récepteur. Préférentiellement, la donnée additionnelle est relative à une caractéristique commune aux données principales et secondaires. Avantageusement, la donnée additionnelle correspond à une information appartenant au groupe comprenant : - une valeur d'une classe de service associée aux données principales ; - un identifiant de flux associé à une réservation préalable de ressources effectuée dans l'émetteur, le récepteur et/ou au moins un dispositif ou lien de transmission intermédiaire, ledit identifiant de flux se rapportant aux données principales. Avantageusement, l'émetteur est une première tête de tunnel, un tunnel étant établi entre ladite première tête de tunnel et une deuxième tête de tunnel, lesdits paquets formés étant des paquets tunnels transmis via ledit tunnel. Dans un autre mode de réalisation, l'invention concerne un récepteur comprenant : - des moyens de réception d'une séquence d'au moins deux paquets comprenant des données principales ; - des moyens d'obtention permettant d'obtenir un ensemble d'au moins deux valeurs de longueurs, formé par la longueur de chaque paquet reçu de ladite séquence ; - des moyens de décodage appliqués sur ledit ensemble d'au moins deux valeurs de longueur, les moyens de décodage générant une donnée additionnelle qui est additionnelle auxdites données principales ; - des moyens d'extraction permettant d'extraire lesdites données principales des paquets reçus, en fonction d'une technique de formation de paquet prédéterminée, utilisée par l'émetteur pour former ladite séquence à partir des données principales. Préférentiellement, la donnée additionnelle correspond à une information appartenant au groupe comprenant : - une valeur d'une classe de service associée aux données principales ; - un identifiant de flux associé à une réservation préalable de ressources effectuée dans l'émetteur, le récepteur et/ou au moins un dispositif ou lien de transmission intermédiaire, ledit identifiant de flux se rapportant aux données principales. Avantageusement, le récepteur est une première tête de tunnel, un tunnel étant établi entre ladite première tête de tunnel et une deuxième tête de tunnel, lesdits paquets réceptionnés étant des paquets tunnels réceptionnés. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - la figure la illustre une configuration typique de deux réseaux LAN interconnectés par un réseau privé virtuel (VPN) mettant en oeuvre un tunnel entre une première tête de tunnel et une deuxième tête de tunnel à travers un réseau de communication étendu; - la figure lb présente selon un modèle classique en couches, une pile de protocoles d'une tête de tunnel dans laquelle peut être mis en oeuvre la technique de l'invention ; - la figure 2a présente le format d'une trame Ethernet du tunnel véhiculant une trame Ethernet utilisateur, ce format étant utilisé dans le cadre d'un mode de réalisation particulier de la présente invention ; - la figure 2b présente le format d'une trame Ethernet du tunnel véhiculant un message de contrôle du tunnel, ce format étant utilisé dans le cadre d'un mode de réalisation particulier la présente invention ; - la figure 3 illustre une configuration de deux réseaux LAN interconnectés par un réseau privé virtuel (VPN) mettant en oeuvre un tunnel, via l'utilisation d'une première tête de tunnel (comprenant des moyens d'encodage) et d'une deuxième 15 tête de tunnel (comprenant des moyens de décodage) selon un mode de réalisation particulier de l'invention ; - la figure 4 présente un algorithme de transmission et d'encodage mis en oeuvre dans une première tête de tunnel, selon un mode de réalisation particulier de l'invention ; 20 - la figure 5 présente un algorithme de réception et de décodage mis en oeuvre dans une deuxième tête de tunnel, selon un mode de réalisation particulier du procédé de l'invention ; - la figure 6 présente des formats de paquets sur le tunnel, selon des modes de réalisations particuliers de l'invention ; 25 - la figure 7 présente un schéma d'un terminal et d'une tête de tunnel aptes à mettre en oeuvre la technique de transmission selon un mode de réalisation particulier de l'invention ; - la figure 8 présente un schéma bloc d'une tête de tunnel apte à mettre en oeuvre la technique de formation de trames selon un mode de réalisation particulier de 30 l'invention ; - la figure 9 présente un schéma d'un terminal et d'une première tête de tunnel aptes à mettre en oeuvre la technique de transmission selon un mode de réalisation particulier de l'invention ; 10 - la figure 10 présente un algorithme de transmission et d'encodage mis en oeuvre dans un terminal, selon un mode de réalisation particulier de l'invention ; - la figure 11 présente un algorithme de réception et de décodage mis en oeuvre dans une première tête de tunnel, selon un mode de réalisation particulier de l'invention. 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. La figure la illustre une configuration typique de deux réseaux LAN interconnectés par un réseau privé virtuel (VPN) mettant en oeuvre un tunnel 100 entre une première tête de tunnel 101 et une deuxième tête de tunnel 102, à travers un réseau de communication étendu 107 (Internet par exemple). Ce tunnel 100 interconnecte deux réseaux locaux LAN A 103 et LAN B 104. Chacun des réseaux locaux LAN 103 et 104 comporte un équipement d'accès Internet (passerelle domestique, ou � Home Gateway �, pouvant intégrer un pare-feu (� Firewall �) 105 et 106, des équipements de type PC 109 et 111, des serveurs 110 et 113 permettant le stockage et le partage de medias numériques (de type audio, vidéo, photo), ainsi que des équipements de restitution des médias numériques 108 et 112. Une tête de tunnel peut être intégrée dans un équipement audiovisuel comme par exemple un téléviseur numérique. Elle peut aussi être présente dans un équipement de type PC sous la forme d'un programme réalisant les fonctions associées à celle-ci. Une fois que le tunnel 100 est établi, les équipements 108, 109, et 110, connectés au réseau LAN A 103, sont capables de communiquer avec les équipements 111, 112 et 113, connectés au réseau LAN B 104. Par exemple, l'équipement 108 connecté au réseau LAN A 103 peut communiquer avec le serveur 113 connecté au réseau LAN B 104. Dans cette figure la, on a représenté un réseau de communication simple avec un seul tunnel, mais il est bien entendu qu'une même tête de tunnel peut être amenée à gérer plusieurs tunnels (à destination d'une ou de plusieurs autres têtes de tunnel) pour interconnecter un premier réseau LAN à plusieurs autres réseaux LAN, et qu'un même réseau LAN peut comprendre plusieurs têtes de tunnel. En outre, dans un souci de simplification, n'ont pas été représentés les équipements d'infrastructure dans le réseau étendu, tels que les routeurs Internet. En relation avec la figure lb, nous allons maintenant décrire le cheminement d'une trame Ethernet issue d'un des équipements 108, 109, 110 (connectés au réseau LAN B 103) et qui va entrer dans le tunnel 100. Pour ce faire, on va utiliser un modèle en couches décrivant les couches de protocoles nécessaires à la mise en oeuvre de ce tunnel 100. Dans ce modèle ne sont pas représentés les éléments de protocole nécessaires aux fonctions autres que la mise en oeuvre du tunnel. La première tête de tunnel 101 comporte une interface physique Ethernet 122 qui reçoit les trames Ethernet issues des équipements 108, 109, 110 et les remet à la couche liaison 121 pour aiguillage soit vers la couche réseau 120, pour les trames Ethernet à destination de l'équipement comportant la tête de tunnel, soit vers la fonction de pont (� bridge �) 123, pour les autres trames Ethernet. La fonction de pont 123 réalise les opérations classiques d'un pont Ethernet telles que le filtrage des trames Ethernet et la propagation de ces trames vers le ou les port(s) Ethernet de sortie approprié(s). Le filtrage des trames Ethernet est classiquement réalisé par une fonction de pont (� bridge �) en vérifiant que l'adresse de destination est en adressage de type � unicast� (terme anglais signifiant à destination d'un seul destinataire) dans une liste. En effet, à chacune des interfaces du pont est associée une liste contenant les adresses MAC des noeuds joignables par cette interface. On entend par noeuds joignables par une interface de pont donnée, les noeuds (aussi dits noeuds locaux) qui sont connectés sur le même réseau LAN que l'interface de pont donnée, ou les noeuds (aussi dits noeuds distants) qui sont connectés sur un autre réseau LAN interconnecté au réseau LAN local par l'intermédiaire d'au moins un pont, autre que le pont de l'interface donnée. Ces listes sont construites par analyse des paquets provenant du LAN auquel l'interface est connectée. Les adresses sources des paquets émis sur le réseau LAN, autres que ceux émis par l'interface donnée, sont enregistrées pour former cette liste. Il est à noter que la liste ainsi formée pour une interface de pont donnée ne permet pas de distinguer les adresses des noeuds connectés au même réseau LAN que l'interface donnée de celles des noeuds connectés à un autre réseau LAN séparé par un autre pont. Ainsi, l'adresse de destination d'une trame entrant par l'une des interfaces d'un pont est comparée au contenu des listes associées aux autres interfaces de ce même pont. Si l'adresse de destination d'une trame est présente dans l'une de ces listes, la trame est envoyée vers son destinataire par le biais de l'interface correspondante (uniquement). Sinon, la trame est envoyée vers toutes les interfaces du pont. Sur le pont sont attachées une interface Ethernet 121 et au moins une interface virtuelle 124 de type Ethernet. Une interface virtuelle 124 est créée pour chaque tunnel instancié par l'application 114 à qui elle remet les trames Ethernet qui doivent transiter sur les tunnels respectivement instanciés. D'une manière générale, le protocole d'encapsulation du tunnel représenté par l'application 114 réalise les opérations nécessaires à la mise en oeuvre de chaque tunnel, parmi lesquelles on trouvera notamment la configuration, le filtrage et l'encapsulation (formation d'un paquet tunnel) et l'extraction d'une trame. Comme on le verra par la suite, le procédé selon l'invention est mis en oeuvre par l'application 114. Les trames reçues de l'interface virtuelle 124, après traitement par l'application 114, sont remises sous la forme d'un paquet (ou trame) de données à travers une interface applicative (� socket � en anglais) 115 à un protocole de transport fiable TCP 117 ou non fiable UDP 119, respectivement sécurisés par les protocoles SSL 116 et DTLS 118. Après traitement par un protocole de transport pour former le paquet (ou trame) tunnel, on remet celui-ci à la couche réseau 120. Le datagramme IP ainsi formé avec le paquet (ou trame) tunnel peut maintenant être transmis sur le réseau LAN à travers les couches liaison 121 et physique 122. La réception d'une trame en provenance du tunnel 100 suivra dans la deuxième tête de tunnel le cheminement inverse à celui présenté ci-dessus. La figure 2a présente le format d'une trame Ethernet du tunnel véhiculant une trame Ethernet utilisateur, ce format étant utilisé dans le cadre d'un mode de réalisation particulier la présente invention La figure 2a présente le format d'une trame Ethernet 260 du tunnel véhiculant une trame Ethernet utilisateur, ce format étant utilisé dans le cadre d'un mode de réalisation particulier de la présente invention. Il comporte : un champ d'en-tête Ethernet 261, un premier datagramme IP 262 véhiculant lui-même un paquet tunnel 250 de niveau 2, et un champ FCS 263 (pour � Frame Check Sequence � en anglais ou � séquence de contrôle de trame � en français). Le paquet tunnel 250 comporte quatre parties : - un champ d'en-tête du protocole de transport 251 (à savoir TCP ou UDP dans cet exemple) ; - un champ d'entête du protocole d'encapsulation 252 (à savoir L2TP ou TLS dans cet exemple, qui sont décrits notamment dans les documents suivants : � IETF RFC-3931, "Layer two tunneling protocol ù version 3 (L2TPv3)", J. Lau and ail, March 2005 � et � IETF RFC-2246, "The TLS Protocol Version 1.0" �), - un champ d'en-tête de niveau 2 du protocole embarqué 253 (à savoir Ethernet dans cet exemple), et enfin - un champ de données utilisateurs 254, qui lui-même comporte un second datagramme IP complet si aucune fragmentation n'a été opérée lors de son transit depuis l'équipement source. La figure 2b présente le format d'une trame Ethernet 260 du tunnel véhiculant un message de contrôle du tunnel 270, ce format étant utilisé dans le cadre d'un mode de réalisation particulier la présente invention. Ces messages sont échangés entre une première et une deuxième tête de tunnel afin d'établir les tunnels et de les gérer. Le message 270 comporte 6 parties : - un champ d'entête 271 de douze octets initialisé à la valeur FF sauf le dernier bit qui est un indicateur 272 indiquant si le message est une requête (valeur 0) ou une réponse (valeur 1) ; - un champ ID 273 qui est l'identification de l'émetteur (identification de session) ; - un champ commande 274 (ouverture/fermeture du tunnel, découverte de topologie dans un réseau de TEP avec relais, etc ) ; - un champ de statut 275 pour le cas de message de réponse ; - un champ 276 de longueur des données ; - un champ 277 de données complémentaires à échanger entre une première et une deuxième tête de tunnel. La figure 3 illustre une configuration de deux réseaux LAN interconnectés par un réseau privé virtuel (VPN) mettant en oeuvre un tunnel, via l'utilisation d'une première tête de tunnel 300 (comprenant des moyens d'encodage) et d'une deuxième tête de tunnel 301 (comprenant des moyens de décodage) selon un mode de réalisation particulier de l'invention. La première tête de tunnel TEP 300 comprend une première zone mémoire 308 de stockage des paquets de donnée reçus, cette zone mémoire étant gérée en mode FIFO (pour � First In, First Out � en anglais ou � Premier Entré, Premier Sorti � en français). Elle comporte également une deuxième zone mémoire 309 de stockage des valeurs de la classe de service associées à chaque paquet de donnée reçu. Chaque valeur de classe de service représente la méthode selon laquelle ce paquet doit être traité lors du transport via le tunnel 302. Cette classe de service est soit déterminée à partir d'une valeur explicitement indiquée dans un champ du paquet de donnée, soit déterminée selon une combinaison de plusieurs champs du paquet de données, tels que l'adresse source, l'adresse destination, le numéro de port du protocole de transport sur le réseau LAN. Dans ce dernier cas, cette combinaison de valeurs de plusieurs champs est associée à une classe de service soit arbitrairement, soit selon un protocole de signalisation de classe de service connu au préalable du terminal 319 et de la première tête de tunnel TEP 300. Ainsi, les paquets de données 306, 307 émis par le terminal 319 sont interceptés sur le réseau LAN par la première tête de tunnel TEP 300 ; ensuite, leurs classes de service respectives sont déterminées, les paquets de données sont stockés dans la mémoire 308, et les classes de service respectives stockées dans la mémoire 309. Un encodeur 312 selon l'invention, après une phase de synchronisation avec le décodeur 313 d'une deuxième tête de tunnel TEP 301, accède à la mémoire 308 pour lire le paquet suivant à transmettre sur le tunnel. Selon cette implémentation, les paquets de données stockés en mémoire 308 (accessible par l'encodeur 312) sont déjà chiffrés ; le décodeur ne peut donc pas lire, dans ces paquets, une valeur de classe de service. Ainsi pour déterminer la valeur de la classe de service à associer à ce paquet de donnée, chaque emplacement mémoire contenant un paquet de donnée comporte un champ qui est un index vers la classe de service dans la mémoire 308, classe correspondante à ce paquet. Ce champ est rempli lors de la réception d'un paquet de donnée en provenance d'un terminal par la première tête de tunnel TEP 300 avant de procéder au chiffrement. L'encodeur 312 accède ainsi à la valeur de la classe de service pour un paquet de donnée à transmettre via le tunnel, puis accède à la table d'encodage 310. Chaque entrée de cette table contient un enregistrement avec un premier champ correspondant à une des valeurs possibles que peut prendre la classe de service, et un deuxième champ correspondant à un ensemble des longueurs que devront prendre les paquets de données encodés successifs (et pas nécessairement consécutifs) qui constituent les éléments d'une même séquence ; c'est cette séquence de longueur de paquets qui correspond à 1' encodage réalisé selon l'invention. Ainsi selon l'invention, cette séquence de longueur de un ou plusieurs paquets de données définit la classe de service à appliquer pour le transport de ces paquets dans le tunnel sur le réseau étendu. Dans l'exemple de la figure 3, une séquence peut ainsi être constituée de trois paquets successifs (par exemple consécutifs, mais pas nécessairement) dont les longueurs sont conformes au résultat de l'encodage. Il est alors considéré que ces paquets successifs contiennent des données principales. De façon préférentielle, on choisira des longueurs proches et inférieures à la valeur du MTU (pour � Maximum Transmission Unit � en anglais ou � Taille Maximum de l'Unité de Transfert � en français) du tunnel de façon à optimiser la quantité de trafic supporté par ce tunnel. Le nombre de paquets d'une séquence est connu par le décodeur 313 de la deuxième tête de tunnel TEP 301 après la phase de synchronisation. Ainsi une même tête de tunnel TEP (telle que la deuxième tête de tunnel TEP 301) ayant établi plusieurs tunnels avec plusieurs têtes de tunnel TEP (telles que la première tête de tunnel TEP 300) pourra appliquer plusieurs décodages simultanément, chacun étant adapté aux paramètres du tunnel correspondant. Dans une première méthode, l'encodeur 312 modifie la longueur du paquet qu'il vient de lire en mémoire 308 par concaténation entre ce premier paquet et une partie du paquet suivant correspondant à un même flux (indication implicite ou explicite du paquet d'appartenance à ce flux) et devant donc être traité avec la même classe de service. Cette classe de service est alors une donnée additionnelle à communiquer en relation avec les données principales, par le biais d'une modulation de longueur de paquets constitués de données principales et transmis entre la première tête de tunnel TEP 300 et la deuxième tête de tunnel TEP 301. Dans l'exemple de la figure 3, l'encodeur 312 produit ainsi une séquence de trois paquets 303, 304, 305. L'encodeur 312 procède pour une séquence complète puis transmet la séquence des paquets 303, 304, 305 sur le tunnel et recommence la préparation de la séquence suivante si des paquets de données reçus d'un terminal restent à transmettre sur le tunnel. La séquence des paquets 303, 304, 305 est ensuite reçue à l'autre extrémité du tunnel dans la deuxième tête de tunnel TEP 301 par le décodeur 313. Suite à la phase de synchronisation, ce décodeur 313 est en attente d'une séquence comprenant un nombre d'éléments donné, communiqué lors de la phase de synchronisation par l'encodeur 312. Dans une variante, ce nombre d'éléments est fixe, connu au préalable, et identique pour la première et la deuxième tête de tunnel TEP 300 et 301. Ainsi dans l'exemple de la figure 3, ce nombre est de trois éléments qui correspondent aux trois paquets 303, 304, 305. Le décodeur analyse les longueurs de ces trois éléments. Puis par lecture dans la table de décodage 311 qui a été remplie de façon identique à la table de codage 310, le décodeur 313 est capable de retrouver l'enregistrement correspondant au triplet de longueurs et y lire la valeur de la classe de service correspondante, avec laquelle les paquets chiffrés doivent être traités dans la deuxième tête de tunnel TEP 301. Ainsi la deuxième tête de tunnel TEP 301 comporte des moyens de déchiffrement en nombre fixe et de natures diverses : - un moyen haute performance, sous forme de matériel dédié capable de traiter un nombre fixe de paquets par intervalle de temps ; - un moyen ordinaire, de performances moindres par le biais d'un 15 traitement uniquement logiciel exécuté par le processeur générique de la deuxième tête de tunnel TEP. Les mémoires 314 et 315 servent au stockage des paquets de donnée qui vont être traités respectivement par les moyens à haute performance et par les moyens à performance ordinaire. 20 Dans la deuxième tête de tunnel TEP 301, la capacité du décodeur 313 à déterminer la classe de service sans devoir déchiffrer au préalable les paquets reçus permet de traiter de manière différente les paquets reçus. Ainsi cette classe de service, dans l'implémentation décrite, correspond au délai de traitement dans les première et deuxième têtes de tunnel. Une valeur particulière de cette classe de service correspond à 25 un traitement avec faible délai, ce qui correspond par exemple au besoin d'un trafic de données vidéo dans des applications de type téléconférence, en contraste une autre valeur particulière correspond au besoin d'une application de transfert de fichier auquel on peut appliquer un délai de traitement plus long sans préjudice pour ce type d'application. 30 Il est à noter que d'autres types de traitement peuvent être appliqués de manière distincte en fonction de la donnée additionnelle (ici la classe de service) véhiculée par le biais de la modulation de longueurs des paquets transitant entre les première et deuxième têtes de tunnel TEP 300 et 301. 10 Par exemple, les paquets correspondant à une application de type téléconférence sont encodés avec une classe de service correspondant au délai de traitement avec faible durée dans la deuxième tête de tunnel TEP 301 et sont écrits en mémoire 314 pour être déchiffrés grâce aux moyens haute performances de la deuxième tête de tunnel TEP 301 et être ainsi transmis au terminal 318 après un délai faible, sans devoir attendre la fin du traitement de paquets ne nécessitant pas un faible délai de traitement (qui eux sont écrits dans la mémoire 315). Pour opérer cet aiguillage et classifier des paquets selon leurs besoins, il est nécessaire de connaître la classe de service avant d'exécuter le déchiffrement lui-même. La méthode de l'invention permet d'atteindre cet objectif sans sacrifier de bande passante utile (c'est-à-dire sans adjonction d'une indication supplémentaire explicite dans les paquets émis par la première tête de tunnel TEP 300). La figure 4 présente un algorithme de transmission et d'encodage mis en oeuvre dans la première tête de tunnel TEP 300, selon un mode de réalisation particulier de l'invention. La première tête de tunnel TEP 300 est en attente dans une étape 408, puis elle reçoit un paquet (dit paquet passager) en provenance d'un terminal dans une étape 400 que la première tête de tunnel TEP 300 de façon classique va ensuite transporter après encapsulation dans un paquet tunnel. Ce paquet passager a une identification soit explicite, soit implicite, d'appartenance à un flux, auquel la première tête de tunnel associe une classe de service. L'identification du flux auquel appartient ce paquet peut être implicite et réalisée par l'analyse d'un ensemble de trois ou quatre champs du paquet tels que le type de protocole applicatif, le numéro de port du protocole de niveau transport, l'adresse source et destination. Ainsi la première tête de tunnel TEP 300 identifie un trafic correspondant à un flux et au type d'application et en déduit la classe de service à appliquer à ce paquet passager. Dans le cas d'une identification explicite de flux par un champ du paquet, un protocole de signalisation de classe de service peut avoir permis à la première tête de tunnel TEP 300 d'avoir connaissance de la classe de service à associer à ce flux identifié. Dans une variante de réalisation, un paquet passager peut également contenir un marquage explicite de la classe de trafic. Ce marquage est alors contenu dans le paquet que la première tête de tunnel TEP 300 va associer, lors d'une étape de classification, à une classe de service, pour le traitement à appliquer à ce paquet lors du transport dans le tunnel après encapsulation Ce marquage explicite de chaque paquet est par exemple réalisé par le truchement d'un champ de priorité défini dans la majorité des cas pour le protocole de niveau deux ou trois, pour les protocoles de la famille TCP/IP selon les principes définis dans le modèle DiffServ. Pour le niveau trois (IP), le marquage explicite est constitué par un champ appelé DSCP qui contient la classe du paquet. Pour les protocoles de niveau 2, par exemple Ethernet, le marquage explicite est un champ de trois bits dans l'entête de niveau 2, appelé � User priority ù Frame priority � (en français � priorité utilisateur priorité de trame �) et défini dans la norme IEEE 802.1Q et ses annexes. Dans cette étape 400, selon le type de protocole utilisé par le terminal 319, la première tête de tunnel TEP 300 va être en mesure d'associer un paquet reçu à une classe de service définissant le traitement qui doit être appliqué à ce paquet lors du transport dans le tunnel entre les première et deuxième têtes de tunnel. Dans une étape 401, ce paquet après classification et chiffrement, est stocké dans la mémoire 308 de la figure 3 avec un index pointant sur la classe de service associée à ce paquet. Dans une étape 402, selon un premier mode de réalisation, l'encodeur lit l'entrée dans la table d'encodage qui correspond à la valeur de la classe de service en utilisant cette valeur qui correspond à l'index d'accès dans la table d'encodage. L'encodeur obtient, dans l'enregistrement correspondant à cet index, une série composée d'une ou plusieurs longueurs à appliquer par l'encodeur pour construire une séquence de paquets à transmettre via le tunnel. La première tête de tunnel va alors appliquer une modulation de longueur des paquets à transmettre via le tunnel. La séquence de paquets à transmettre correspond à un ensemble de paquets successifs (mais pas nécessairement consécutifs) dont les longueurs correspondent à la série obtenue par l'encodeur. Dans un autre mode de réalisation non détaillé ici, le décodeur n'utilise pas de table d'encodage et applique une règle d'encodage qui sera connue également de la deuxième tête de tunnel TEP 301, par exemple signalée par la première tête de tunnel TEP 300 lors de l'étape 403 de synchronisation. Cette règle, sera établie par exemple comme suit : chaque bit de la valeur de la classe de service détermine si la longueur correspondante dans la séquence des longueurs à appliquer pour l'encodage est paire ou impaire, un bit a zéro correspond ainsi à une longueur paire pour le paquet dans la séquence, un bit à un à une longueur impaire pour le paquet dans la séquence. Le nombre de bits de la classe de service sera par exemple de trois, ce qui alors permet la représentation de huit classes de services. Ceci, même si le système ne peut en utiliser qu'un nombre inférieur (par exemple : deux) selon la richesse des mécanismes implémentés dans les têtes de tunnel. Selon les principes connus par l'homme du métier, ces mécanismes sont limités par les ressources matérielles et logicielles utilisées pour la conception des têtes de tunnel, permettent de différentier le traitement des paquets selon un certain nombre de classes de service correspondantes. Une séquence d'éléments (longueurs de paquets) pour encoder une classe de service comportant au moins trois éléments (trois longueurs de paquets) permet de réduire suffisamment les risques de fausses détections dans le cas de la réception d'un ensemble de paquets ne constituant pas une séquence codée selon l'invention. Dans une étape 403, l'encodeur dans la première tête de tunnel TEP 300 vérifie s'il est nécessaire de procéder à une phase de synchronisation avec le décodeur dans la deuxième tête de tunnel TEP 301. En effet, cette synchronisation n'est nécessaire que pour initier les envois de séquences encodées sur le tunnel, pour mettre à jour les paramètres de l'encodage s'ils doivent être modifiés (comme par exemple pour leur donner des valeurs différentes de leurs valeurs par défaut). Ces paramètres sont essentiellement la règle d'encodage (nom d'une table connue de l'encodeur et du décodeur, ou énoncé d'une fonction réalisant la transformation de la valeur à encoder en une série de longueurs de paquets d'une séquence) et le nombre de paquets dans une séquence encodée (si ce nombre est différent de la valeur par défaut). Dans l'affirmative, l'encodeur initie une phase de synchronisation avec le décodeur dans la deuxième tête de tunnel TEP 301 ; cette phase se base par exemple sur l'envoi d'une trame de contrôle du tunnel avec un champ d'information contenant les paramètres d'encodage. Cette méthode peut être simple dans un premier mode de réalisation où la longueur de séquence de codage est fixe et connue des première et deuxième têtes de tunnel TEP 300 et 301. Dans un second mode de réalisation, elle peut être plus complexe pour optimiser l'usage du tunnel tout en permettant à l'encodeur d'indiquer la longueur de la séquence ainsi que la règle d'encodage ou la référence de la table de décodage à utiliser si celle-ci est multiple ; par exemple pour correspondre à des marquages différents de la priorité paquet selon des protocoles de niveau 3 différents. Ainsi, chaque protocole peut avoir une table d'encodage (respectivement décodage) différente. Dans une étape 404, l'encodeur construit un paquet d'une longueur correspondant à l'élément de la séquence de longueurs, indiqué par la table d'encodage ou obtenu par application de la règle d'encodage. Différents modes de réalisation de cette étape sont décrits par la suite, en relation avec la figure 6. Dans une étape 405, on vérifie si le nombre d'éléments de la séquence de longueur est atteint selon le nombre évalué à l'étape 402. Dans la négative, on enchaîne sur une étape 406 identique à l'étape 404. Dans l'affirmative, on passe à l'étape 407 où l'encodeur envoie sur le tunnel la série de paquets construite selon la séquence de paquets de longueurs déterminées à l'étape 402. Enfin après l'étape 407 on reboucle à l'étape 408 pour attendre les informations suivantes en provenance du terminal source. La figure 5 présente un algorithme de réception et de décodage mis en oeuvre dans la deuxième tête de tunnel TEP 301, selon un mode de réalisation particulier du procédé selon l'invention. Le décodeur détecte dans une étape 500 l'initialisation d'une phase de synchronisation où typiquement l'encodeur signale le début d'une séquence encodée selon l'invention, la règle d'encodage et le nombre d'éléments de la séquence de paquets encodés. Alternativement, si un cycle d'échange est déjà initié, le décodeur reçoit un paquet du tunnel, élément d'une séquence avec paquets encodés. Il est rappelé que la séquence fournie par l'encodeur définit des longueurs de paquets successifs, mais pas nécessairement consécutifs. On se limitera dans la description ci-dessous au fonctionnement du décodeur dans le cas où la séquence de longueur concerne un ensemble de paquets consécutifs. Dans une étape 501, le décodeur procède à la lecture du premier paquet de la séquence sur le tunnel et le stocke dans une mémoire intermédiaire puis vérifie dans une étape 502 si le nombre de paquets encodés correspondant à l'indication de la phase de synchronisation a été reçu. Dans la négative, le décodeur procède à la lecture du paquet suivant sur le tunnel dans une étape 503 et refait le test de l'étape 502. Dans l'affirmative, le décodeur 313 procède dans une étape 504 à une lecture dans la table de décodage 311 de la figure 3 ; il balaie cette table 311 en comparant la séquence de longueurs des paquets reçus aux champs correspondants de l'ensemble des enregistrements de la table et obtient la valeur encodée dans la séquence par lecture du champ � classe de service � dans l'enregistrement correspondant. Dans une étape 505, il route alors les paquets reçus sous leur forme chiffrée selon la valeur de la classe de service vers la mémoire 314 ou respectivement la mémoire 315, où ils seront déchiffrés par des moyens matériels sous une faible latence ou des moyens logiciels avec une latence normale pour être ensuite des-encapsulés et transmis sur le réseau LAN à destination du terminal 318. Comme déjà mentionné précédemment, des traitements distincts en fonction de la classe de service sont ainsi appliqués en fonction de la classe de service (donnée additionnelle) fournie par analyse de la modulation de la longueur des paquets (données principales) reçus. A la fin de l'étape 505, le décodeur reboucle vers l'étape 500. La figure 6 présente les différents modes de réalisation de l'étape 404 de la figure 4. Dans un premier mode, le paquet 600 construit par l'encodeur à la longueur désirée est obtenu par concaténation du paquet 610 lu dans la mémoire 608 avec une partie du paquet 611. Il est à noter que les paquets 610, 611 sont disposés dans la mémoire 608 en fonction de leur appartenance à un même flux pour lequel une classe de service a été négociée entre le terminal et la première tête de tunnel ou en fonction d'un même marquage de classe de service. Les valeurs identifiant les classes de services sont stockées dans une mémoire 609 où, selon la figure 6, deux valeurs 612 et 613 sont stockées. Dans un second mode de réalisation, le paquet 601 est construit par l'encodeur par insertion du paquet initial 603 auquel on rajoute une donnée de bourrage 604 pour obtenir la longueur désirée. Ces données de bourrage peuvent être générées par exemple par un générateur d'aléa ou par un générateur pseudo-aléatoire (tels que défini par exemple dans les normes ANSI X9.17 ou NIST SP 800-90) ou encore en suivant des valeurs de bourrage prédéterminées. Dans un troisième mode de réalisation, une zone mémoire 607 contient une troisième information associée de manière commune aux deux autres informations transportées dans ce troisième mode de réalisation. Ce peut être le cas pour un paquet de donnée contenant une information audio, associé à un paquet de donnée contenant une information vidéo. Dans le cas d'une application audio-visuelle, cette troisième information peut être une métadonnée comme la localisation géographique d'une scène. C'est la valeur de cette donnée en zone mémoire 607 qui sera encodée pour déterminer la longueur à produire pour le paquet 602. De façon identique au premier mode de réalisation l'opération d'encodage se fait soit par une indexation dans une table d'encodage soit par application d'une règle d'encodage. L'encodeur construit un paquet de cette longueur par insertion du paquet initial 605 (aussi appelée données principales, comme par exemple des données vidéo), puis insertion d'une partie 606 de la seconde information (aussi appelée données secondaires, comme par exemple des données audio) pour obtenir la longueur de paquet que l'on cherche à construire, longueur qui est déterminée à partir de la valeur de la troisième information contenue en mémoire 607. Le paquet peut éventuellement être construit par utilisation en outre de données de bourrage. Selon ce qui a déjà été décrit précédemment, cette valeur sert d'index dans la table d'encodage. L'enregistrement obtenu contient une série de longueurs de paquets à construire pour effectuer l'encodage de la troisième valeur. Il est rappelé que la séquence obtenue par l'encodeur définit des longueurs de paquets successifs, mais pas nécessairement consécutifs. Ceci permet notamment de mettre en oeuvre l'invention indépendamment du débit de l'application générant les données principales et/ou du débit de l'application générant les données secondaires. La figure 7 présente un schéma d'un terminal et d'une tête de tunnel aptes à mettre en oeuvre le procédé de transmission selon un mode de réalisation particulier de l'invention. En effet, cette figure représente une variante du mode de réalisation dans laquelle la première tête de tunnel TEP 300 décrite précédemment (renumérotée 701 dans ce nouveau contexte) peut gérer simultanément l'encodage de plusieurs flux de paquets de données. Comme expliqué précédemment, la valeur de la classe de service est encodée par la première tête de tunnel TEP 701 pour un paquet reçu d'un terminal 700. Le paquet est alors traité par une unité 708 de classification de paquet qui détermine la classe de service selon laquelle ce paquet doit être traité. Afin d'effectuer cette classification, le paquet doit comporter soit un marquage de priorité, soit un identificateur de flux auquel une classe de service a été associée au préalable, par exemple par le biais d'un échange de messages de signalisation de qualité de service entre le terminal 700 et la première tête de tunnel TEP 701. Cette unité 708 va router le paquet vers une des mémoires 702, 703, 704 en fonction de la classe de service associée suite à la classification de ce paquet. Chaque zone mémoire est dédiée à une classe de service donnée, dont la valeur est stockée dans une mémoire de classe de service couplée à la mémoire de paquets. Par exemple sur la figure 7, la mémoire 709 stocke la valeur de la classe de service et est associée à la mémoire de paquets 704 qui va stocker les paquets de donnée des flux associes à cette classe de service. La suite de cette variante représentée par la figure 7 se déroule comme décrit lors de la description détaillée de la figure 3. Ainsi les paquets de la mémoire 704 sont lus par un encodeur 707 (respectivement les encodeurs 706 et 705 pour les mémoires 703 et 702) et encodés à l'aide de la table d'encodage 711 puis transmis sur le tunnel via l'unité 710. La figure 8 présente un schéma bloc d'une tête de tunnel 801 générique apte à mettre en oeuvre la technique de formation de paquets (aussi appelés � trames �) selon un mode de réalisation particulier de l'invention. La mémoire 811, en mode FIFO, fonctionne comme une mémoire pour le stockage temporaire lors de la réception des paquets émis par un terminal 800 et permet ensuite un traitement de ces paquets dans le même ordre que celui de leur réception. La mémoire RAM 812 (pour � Random Access Memory � en anglais, ou � Mémoire Volatile � en français) fonctionne comme une mémoire principale, une zone de travail, etc., de l'unité centrale 810, et contient par exemple la table d'encodage et de décodage. La capacité de mémoire peut être étendue par une RAM optionnelle reliée à un port d'extension (non illustré). Les unités 813 et 814 sont des composants matériels dédiés pouvant être utilisés pour effectuer des opérations de chiffrement / déchiffrement, ou des traitements particuliers au cours de la classification de paquets. Ces composants matériels peuvent comprendre un circuit logique, par exemple de type FPGA (pour � Field-Programmable Gate Array � en anglais, ou � Réseau de Portes Programmables in situ � en français) ou de type ASIC (pour � Application Specific Integrated Circuit � en anglais, ou � Circuits Intégrés Dédiés à des Applications Spécifiques � en français). Un utilisateur peut interagir avec cette tête de tunnel 801 par le moyen d'un terminal 800 connecté au réseau LAN ou à distance via le tunnel 802. L'unité centrale 810 est capable, à la mise sous tension, d'exécuter des instructions à partir de la ROM (pour � Read-Only Memory � en anglais, ou � Mémoire non volatile � en français) de programme 815 ou à partir d'un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non. Après la mise sous tension, l'unité centrale 810 est capable d'exécuter des instructions provenant de la mémoire principale 812 en relation avec une application logicielle après que ces instructions ont été chargées à partir, par exemple, de la ROM de programme 815. Une telle application logicielle, lorsqu'elle est exécutée par l'unité centrale 810 provoque la réalisation de tout ou partie des étapes des organigrammes illustrés précédemment sur les figures 4, 5, 10 et 11. Il doit être noté que l'ensemble des étapes des figures 4, 5, 10 et 11, incluant les différentes variantes de réalisation peuvent être réalisés sous forme de programme pour ordinateur. Cependant, pour des raisons de performance, il peut être avantageux de réaliser au moins certaines fonctions par un matériel dédié comme les unités 813 et 814. La figure 9 présente un schéma d'un terminal et d'une première tête de tunnel aptes à mettre en oeuvre le procédé de transmission selon un mode de réalisation particulier de l'invention. Contrairement au mode de réalisation décrit jusqu'à présent, l'encodage est réalisé par le terminal 900, et le décodage par la première tête de tunnel TEP 301 décrite précédemment (renumérotée 901 dans ce nouveau contexte). Par ailleurs, la valeur encodée n'est pas la classe de service d'un paquet tunnel mais l'information de sélection par le terminal 900 du type de protocole de niveau transport à utiliser par la première tête de tunnel TEP 901 pour le tunnel qui va transmettre les trames émises par ce terminal 900. Il est à noter que ce mode de réalisation est utilisable en combinaison du mode de réalisation décrit jusqu'alors. Ainsi la première tête de tunnel TEP 901 a établi par exemple deux tunnels (ou un tunnel unique à deux porteuses) gérés par une unité 906, chaque tunnel utilise un protocole de transport distinct UDP, TCP ou SCTP, et se termine sur une même tête de tunnel TEP distant. Deux mémoires 904 et 905 servent au stockage intermédiaire des paquets tunnels qui vont être transportés respectivement sur les premiers et deuxième tunnels, qui dans cet exemple utilisent respectivement les protocoles de transports UDP et TCP. L'encodeur 902 du terminal 900, sous le contrôle d'une application du terminal, va encoder la sélection du protocole de transport tunnel parmi par exemple trois valeurs possibles (représentatives des protocoles UDP, TCP, SCTP). Dans une variante, il serait possible également d'encoder le choix d'options de sécurisation plus ou moins forte du tunnel par sélection de la méthode de sécurisation tels que les protocoles TLS, DTLS et IPsec. Cet encodage est fait par utilisation d'une table d'encodage 907 dont les enregistrements contiennent un champ � type de protocole de transport tunnel � et un champ de séquence de longueurs des trames (ou paquets) à émettre par le terminal. Une variante telle que décrit dans le mode de réalisation principal peut être l'usage d'une règle simple d'encodage, deux bits suffisent à encoder un choix parmi trois protocoles de transport tunnel, un bit à 0 étant encodé par une longueur de trame paire, un bit à 1 par une longueur de trame impaire. Ainsi deux trames (ou paquets) émises par le terminal 900, consécutives pour un même couple d'adresse destination et adresse source dans ces trames indiquera la sélection du protocole de transport tunnel pour le transport de ces trames (ou paquets) sur le tunnel. Afin de lever une ambiguïté de présence ou d'absence d'information encodée, l'encodeur 902 va d'abord procéder à une synchronisation avec le décodeur 903 de la première tête de tunnel TEP 901, par l'émission d'un message contenant une valeur spécifique connue du décodeur 903, ce message n'étant pas retransmise sur le tunnel par la première tête de tunnel TEP 901. Puis l'encodeur génère deux trames (ou paquets) de données avec les longueurs correspondant à l'encodage de la sélection du protocole de transport. Le décodeur 903 suite à la phase de synchronisation, reçoit la séquence de trames (ou de paquets) et à l'aide de la table de décodage 908 obtient la sélection du protocole de transport tunnel faite par le terminal 900. Les paquets de données sont ensuite stockés dans les mémoires 904 ou 905 correspondant à cette sélection, en attente de transmission sur le tunnel par l'unité 906. La figure 10 présente un algorithme de transmission et d'encodage mis en oeuvre dans un terminal, selon un mode de réalisation particulier du procédé selon l'invention. L'encodeur reçoit dans une étape 1000, un ensemble de paquets à émettre via un tunnel vers une destination, ainsi qu'une indication de la sélection du protocole de transport à utiliser par le tunnel. Dans une étape 1001, l'encodeur 902 accède à la table d'encodage pour lire l'enregistrement comportant le type de protocole transport correspondant à la demande pour l'émission de ces paquets. Dans ce même enregistrement, il obtient la séquence des longueurs de paquet correspondant à l'encodage du type de protocole de transport. Dans une étape 1002, l'encodeur 902 construit un premier paquet (de la séquence à construire) d'une longueur correspondant à la première longueur de la séquence selon l'encodage, par segmentation ou insertion d'information de bourrage selon l'alignement imposé par le protocole définissant ces paquets (octet pour Ethernet). Dans une étape 1003, l'encodeur vérifie si le nombre de paquets de la séquence d'encodage est atteint. Si la réponse est négative, il construit, lors de l'étape 1004, le paquet suivant de la même façon que pour le premier paquet. Si la réponse est positive, l'encodeur 902 vérifie à l'étape 1005, de façon identique à l'étape 403 de la figure 4, s'il est nécessaire de procéder à une phase de synchronisation ; auquel cas, il génère un message de contrôle de tunnel, dédié à la synchronisation, à destination de la première tête de tunnel TEP 901, identique a celui de l'étape 403 de la figure 4. Il permet à l'encodeur 902 de transmettre les paramètres de l'encodage tels que la référence d'une table d'encodage stockée au préalable dans la tête de tunnel distante, ou bien la référence d'une fonction d'encodage, associée au nombre de paquets d'une séquence de paquets correspondant à une valeur encodée. Dans l'étape 1006 le terminal procède à la transmission des paquets de la séquence encodée, puis reboucle vers l'étape 1000 pour l'attente des prochains paquets à émettre. La figure 11 présente un algorithme de réception et de décodage mis en oeuvre dans la première tête de tunnel TEP 901, selon un mode de réalisation particulier du procédé selon l'invention. Dans une étape 1100, le décodeur 903 de la première tête de tunnel TEP 901 détecte la réception d'un message de synchronisation émis par l'encodeur 902. Ce message contient les paramètres de l'encodage, tels que le nombre de paquets de la séquence ; il se met alors en attente du premier paquet de la séquence encodée. Ou bien il reçoit directement le paquet suivant, si une phase d'émission de paquets avec encodage est déjà initialisée. Dans une étape 1101, le décodeur 903 analyse le paquet reçu et le stocke dans une mémoire intermédiaire, dans une étape 1102 il vérifie si ce paquet est le dernier de la séquence. Si la réponse est négative, dans une étape 1103, il procède à la lecture du paquet suivant, qui est ensuite également stocké en mémoire et retourne a l'étape 1102. Si la réponse est positive à l'étape 1102, il procède dans une étape 1104 à la lecture de l'enregistrement dans la table de décodage 908 qui contient un champ avec la séquence de longueurs de paquet identique à la séquence reçue. Le champ type de protocole du même enregistrement contient alors le type de protocole de transport tunnel à utiliser par la première tête de tunnel TEP 901 pour l'envoi de ces paquets. Dans une étape 1105, le décodeur 903 place les paquets reçus dans la mémoire 904 ou 905 selon le type de protocole de transport tunnel obtenu à l'étape 1104. À la suite de cette étape, le décodeur reboucle à l'étape 1100. Il apparaît et convient de noter, au vu de la description détaillée des modes de réalisation qui précèdent, que l'invention s'applique plus généralement dans le simple cadre de la communication par paquets, depuis un dispositif émetteur vers un dispositif récepteur, de données (dites données principales), par modulation des longueurs des paquets selon un encodage prédéterminé appliqué à une donnée additionnelle (par rapport aux données principales) à communiquer depuis le dispositif émetteur vers le dispositif récepteur. De plus, il convient de noter que les modes de réalisation qui précèdent traitent d'une donnée additionnelle représentant une classe de service associée à au moins un flux transmis entre un émetteur et un récepteur. La donnée additionnelle peut être représentative de toute autre caractéristique d'un ou de plusieurs de ces flux transmis entre l'émetteur et le récepteur. La donnée additionnelle peut être aussi une donnée de marquage permettant de prouver que c'est bien l'émetteur qui a envoyé ces paquets à destination du récepteur. Enfin, la donnée additionnelle peut être une donnée indépendante du flux de données principal servant de support à la transmission de cette donnée additionnelle.20 REVENDICATIONS1. Procédé de transmission de données entre un émetteur (101 ; 300 ; 701 ; 900) et un récepteur (102 ; 301 ; 901) sous forme de paquets (260 ; 303, 304, 305 ; 600, 601, 602), caractérisé en ce que l'émetteur effectue des étapes consistant à : - appliquer (402) un encodage sur une donnée additionnelle, qui est additionnelle à des données principales, l'encodage générant un premier ensemble d'au moins deux valeurs de longueur ; - former (404, 405, 406 ; 1002, 1004) une séquence d'au moins deux paquets à partir desdites données principales et selon une technique de formation de paquet prédéterminée, de sorte qu'un second ensemble formé par la longueur de chaque paquet de ladite séquence correspond au premier ensemble généré par l'encodage ; - transmettre (407 ; 1006) lesdits paquets formés audit récepteur. 2. Procédé selon la revendication 1, caractérisé en ce que, dans l'étape (404) consistant à former une séquence d'au moins deux paquets à partir desdites données principales, l'émetteur applique une première technique de formation de paquet consistant à, pour au moins un paquet : - construire une partie utile dudit paquet (600), uniquement à partir desdites données principales (610, 611). 3. Procédé selon la revendication 1, caractérisé en ce que, dans l'étape (404) consistant à former une séquence d'au moins deux paquets à partir desdites données principales, l'émetteur applique une deuxième technique de formation de paquet consistant à, pour au moins un paquet : - construire une partie utile dudit paquet (601) en concaténant des données principales (603) avec une ou plusieurs données de bourrage (604), si nécessaire. 4. Procédé selon l'une quelconque des revendications 2 et 3, caractérisé en ce que la donnée additionnelle est relative à une caractéristique des données principales. 5. Procédé selon la revendication 1, caractérisé en ce que, dans l'étape (404,405,406) consistant à former une séquence d'au moins deux paquets à partir desdites données principales, l'émetteur applique une troisième technique de formation de paquet consistant à, pour au moins un paquet : - construire une partie utile dudit paquet (602) en concaténant des données principales (605) avec des données secondaires (606), les données principales étant des données issues d'un premier flux à transmettre depuis l'émetteur vers le récepteur, les donnéessecondaires étant des données issues d'un second flux à transmettre depuis l'émetteur vers le récepteur. 6. Procédé selon la revendication 5, caractérisé en ce que la donnée additionnelle est relative à une caractéristique commune aux données principales et secondaires. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que la donnée additionnelle correspond à une information appartenant au groupe comprenant : - une valeur d'une classe de service associée aux données principales ; - un identifiant de flux associé à une réservation préalable de ressources effectuée dans l'émetteur, le récepteur et/ou au moins un dispositif ou lien de transmission intermédiaire, ledit identifiant de flux se rapportant aux données principales. 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que l'émetteur et le récepteur sont une première et une deuxième tête de tunnel respectivement, entre lesquelles est établi un tunnel, lesdits paquets formés étant des paquets tunnels transmis via ledit tunnel. 9. Procédé de transmission de données entre un émetteur (101 ; 300 ; 701 ; 900) et un récepteur (102 ; 301 ; 901) sous forme de paquets (260 ; 303, 304, 305 ; 600, 601, 602), caractérisé en ce que le récepteur effectue des étapes consistant à : - recevoir (501, 503 ; 1101) une séquence d'au moins deux paquets comprenant des données principales ; - obtenir (502 ; 1102) un ensemble d'au moins deux valeurs de longueurs, formé par la longueur de chaque paquet reçu de ladite séquence ; - appliquer (504 ; 1104) un décodage sur ledit ensemble d'au moins deux valeurs de longueur, le décodage générant une donnée additionnelle qui est additionnelle auxdites données principales ; - extraire (1105) lesdites données principales des paquets reçus, en fonction d'une technique de formation de paquet prédéterminée, utilisée par l'émetteur pour former ladite séquence à partir des données principales 10. Procédé selon la revendication 9, caractérisé en ce que la donnée additionnelle correspond à une information appartenant au groupe comprenant : - une valeur d'une classe de service associée aux données principales ; - un identifiant de flux associé à une réservation préalable de ressources effectuée dans l'émetteur, le récepteur et/ou au moins un dispositif ou lien de transmission intermédiaire, ledit identifiant de flux se rapportant aux données principales. 11. Procédé selon l'une quelconque des revendications 9 à 10, caractérisé en ce que l'émetteur et le récepteur sont une première (300) et une deuxième tête (301) de tunnel respectivement, entre lesquelles est établi un tunnel (302), lesdits paquets reçus étant transmis via ledit tunnel. 12. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 8 et/ou le procédé selon au moins une des revendications 9 à 11, lorsque ledit programme est exécuté sur un ordinateur. 13. Moyen de stockage lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 8 et/ou le procédé selon au moins une des revendications 9 à 11. 14. Emetteur (101 ; 300 ; 701 ; 900) permettant de transmettre des données vers un récepteur (102 ; 301 ; 901) sous forme de paquets (260 ; 303, 304, 305 ; 600, 601, 602), ledit émetteur étant caractérisé en ce qu'il comprend: - des moyens d'encodage (310 ; 711 ; 907), permettant d'encoder une donnée additionnelle, qui est additionnelle à des données principales, lesdits moyens d'encodage générant un premier ensemble d'au moins deux valeurs de longueur ; - des moyens de génération de paquets (312 ; 705, 706 ; 902), permettant de former une séquence d'au moins deux paquets à partir desdites données principales et selon une technique de formation de paquet prédéterminée, de sorte qu'un second ensemble formé par la longueur de chaque paquet de ladite séquence correspond au premier ensemble généré par l'encodage ; - des moyens de transmission, permettant de transmettre lesdits paquets formés. 15. Récepteur (102 ; 301 ; 901) permettant de recevoir des données d'un émetteur (101 ; 300 ; 701 ; 900) sous forme de paquets (260 ; 303, 304, 305 ; 600, 601, 602), ledit récepteur étant caractérisé en ce qu'il comprend: - des moyens de réception d'une séquence d'au moins deux paquets comprenant des données principales ; - des moyens d'obtention permettant d'obtenir un ensemble d'au moins deux valeurs de longueurs, formé par la longueur de chaque paquet reçu de ladite séquence ;- des moyens de décodage (311, 313 ; 903, 908) dudit ensemble d'au moins deux valeurs de longueur, les moyens de décodage générant une donnée additionnelle qui est additionnelle auxdites données principales ; - des moyens d'extraction permettant d'extraire lesdites données principales des paquets 5 reçus, en fonction d'une technique de formation de paquet prédéterminée, utilisée par l'émetteur pour former ladite séquence à partir des données principales.