FR 2913554 A1 20080912 FR 0701740 A 20070309 Procédé d'envoi de paquets de données d'un serveur vers des clients par une liaison de données ayant un taux d'erreur donné La présente invention concerne un procédé d'envoi de paquets de données d'un serveur vers des clients par une liaison de données ayant un taux d'erreur donné. L'invention s'applique par exemple dans le domaine de la vidéo à la demande, où le client affiche simultanément les données vidéo qu'il reçoit. La présente demande de brevet fait suite à une demande française déposée le 5 janvier 2007 sous le numéro 07/00059, référencée par la suite demande antérieure . La présente invention se propose d'améliorer encore l'efficacité de l'invention divulguée dans la demande antérieure. Les deux inventions visent à résoudre un problème technique similaire par des approches et des moyens tout à fait différents. Utilisées en combinaison, les deux inventions se complètent et s'avèrent particulièrement efficaces. De nouveaux services de divertissement et de communication sont aujourd'hui offerts aux passagers des avions commerciaux ou d'affaire, ces services étant couramment rassemblés sous la dénomination anglo-saxonne de In Flight Entertainment (qu'on appellera services IFE par la suite). Il peut s'agir par exemple de l'accès à l'internet haut débit ou bien d'un service de vidéo à la demande pour chaque passager. Ainsi, chaque passager peut par exemple choisir de visionner individuellement un contenu vidéo quelconque, comme un film. Par une interface appropriée, chaque passager peut sélectionner ce qu'il souhaite visionner. Le film démarre quasiment instantanément, il n'est même pas nécessaire d'attendre le téléchargement du film, ce qui représenterait un temps assez long. Par la suite, il peut interrompre temporairement le visionnage puis le reprendre ou revenir en arrière pour revoir une séquence ou encore avancer pour sauter des séquences, ceci toujours avec la même instantanéité du démarrage de l'affichage. Pour le passager, tout se passe comme s'il était à la maison devant un téléviseur connecté à un lecteur de disques vidéo. Ce type de service est d'ores et déjà disponible à bord de nombreux avions. Les systèmes actuels utilisent notamment des modules d'affichage au niveau des dossiers des sièges, des modules de saisie au niveau des accoudoirs des sièges, des modules de lecture et de transmission au niveau de la tête de cabine, tous ces modules étant connectés entre eux par des liaisons filaires. Les systèmes IFE ont par conséquent fait exploser la quantité de câblage pour chaque siège, ceci au détriment de la configurabilité de la cabine. Or, la configurabilité de la cabine est un atout marketing important pour les avionneurs, notamment la possibilité pour les clients de choisir le nombre et la disposition des sièges. En effet, à quelques contraintes de sécurité près, les compagnies aériennes sont relativement libres quant à l'agencement intérieur de la cabine lorsqu'elles commandent un avion. Ceci afin qu'elles puissent adapter la cabine au type de clientèle sur la ligne qu'elles comptent exploiter. Le câblage IFE des sièges est donc devenu un frein de plus en plus lourd à la polyvalence des appareils. Mais de la même manière, un système IFE complet et performant est également devenu un atout marketing majeur pour les avionneurs. La concurrence accrue dans le domaine du transport aérien et la démocratisation des voyages en avion qui en a résulté, ont fait que les services IFE, qui ont pu sembler accessoires à leurs débuts, sont devenus indispensables pour conquérir des parts de marché. II convenait donc de réconcilier les contraintes techniques des systèmes IFE avec une configurabilité optimum de la cabine. Ainsi, ayant connaissance de l'essor des technologies de transfert d'information sans fil, certains avionneurs ont-ils, en accord avec les compagnies aériennes et les fournisseurs de systèmes IFE, purement et simplement supprimé certains des câbles IFE allant jusqu'aux sièges, parmi les plus gênants à la configurabilité de la cabine. N'ont été conservés que des câbles reliant les sièges par petits groupes de deux, trois ou quatre sièges. Charge aux fournisseurs de systèmes IFE de s'adapter, notamment en exploitant au maximum le câblage restant, ce qui est l'objet de la présente invention, et en tirant le meilleur profit des technologies sans fil, ce qui est l'objet de l'invention divulguée dans la demande antérieure.35 Développer un protocole de communication sans fil dédié à la vidéo à la demande dans un système IFE aurait sans doute amené à une solution très performante, mais cela aurait sans doute coûté très cher également. C'est pourquoi l'utilisation d'un standard de communication a été préférée. Malheureusement, aucune des normes actuelles ne répond à l'ensemble de la problématique de la vidéo à la demande dans un système IFE. Cependant, compte tenu notamment de la maturité des différentes technologies, les normes IEEE 802.11a, IEEE 802.11b, IEEE 802.11g ou IEEE 802.11n plus connues sous la dénomination commerciale de liaisons WiFi semblent les plus adaptées. Elles ont par conséquent été retenues. En effet, les liaisons WiFi donnent des résultats tout à fait satisfaisants dans des applications vidéo grand public, mais sans contrainte de multi-diffusion ni contrainte d'instantanéité d'affichage. Par la suite, elles seront également rassemblées sous la désignation générique de 802.11. En effet, à bord d'un avion long courrier, plusieurs dizaines voire plusieurs centaines de passagers peuvent visionner simultanément des films différents, chaque passager pouvant interrompre, avancer ou reculer à sa guise dans le film qu'il visionne. Par conséquent, chaque film visionné par un passager constitue une session particulière, le flux de données vidéo correspondant devant être envoyés exclusivement vers l'écran d'affichage d'un seul passager. Par exemple, un système IFE peut diffuser simultanément 300 sessions. Une telle contrainte de multi-diffusion n'existe dans aucune application vidéo grand public actuelle de la liaison WiFi. De même, les applications vidéo actuelles de la liaison WiFi ne fournissent pas une quasi-instantanéité de l'affichage, notamment au démarrage du film. Des temps d'attente de plusieurs secondes, parfois masqués par des messages publicitaires ou d'avertissement, sont nécessaires avant qu'une commande de lecture ne soit réellement exécutée. Ainsi, les applications utilisant une liaison WiFi à la maison exploitent généralement les normes IEEE 802.11 b et IEEE 802.11g, qui fournissent 3 canaux aux alentours de 2,4 gigahertz pour un débit total pouvant aller jusqu'à 90 mégabits par seconde (Mbps) (environ 30 Mbps par canal). Un petit nombre (quelques unités) de flux vidéo peuvent être envoyés simultanément par canal. Ceci n'est pas suffisant dans le cadre de la vidéo à la demande dans un système IFE, pour laquelle la norme IEEE 802.11a semble plus adaptée. Cette dernière fournit 23 canaux entre 5 et 6 gigahertz pour un débit total pouvant aller jusqu'à 600 Mbps (toujours 30 Mbps par canal). Mais la norme IEEE 802.11a n'est quand même pas parfaitement adaptée aux besoins de la vidéo à la demande dans un système I FE. En effet, la norme IEEE 802.11a ne garantit pas qu'un paquet soit reçu, ni même ne garantit qu'un paquet soit reçu à un coût raisonnable. Car les normes 802.11 sont basées sur un mécanisme d'accusé de réception : un message nommé ACK d'après la terminologie anglo-saxonne io ACKnowledgement est envoyé à une borne WiFi émettrice pour chaque paquet de données reçu par une borne WiFi réceptrice. La borne WiFi émettrice renvoie le paquet à la borne WiFi réceptrice jusqu'à ce qu'elle reçoive le message ACK correspondant. Au bout d'un certain nombre de renvois, le paquet n'est plus renvoyé et il est définitivement perdu pour la 15 borne WiFi réceptrice. Par ce mécanisme, outre le fait que de la bande passante est gaspillée pour envoyer les messages ACK, il faut remarquer que pour récupérer un premier paquet perdu, éventuellement de nombreux autres paquets peuvent être perdus par la suite ! Ainsi, si le taux d'erreur est important, c'est-à-dire si le nombre de paquets perdus par rapport au nombre 20 de paquets envoyés est important, du retard peut facilement s'accumuler et des erreurs peuvent apparaître sur l'écran. Ce à quoi les normes 802.11 répondent en diminuant le débit, ce qui n'est pas acceptable dans le cadre de la vidéo à la demande multiple. C'est une caractéristique essentielle des liaisons WiFi standards que de fournir un compromis permanent entre le taux 25 d'erreur et le débit. Si le taux d'erreur augmente, le débit diminue et vice-versa. II est d'ailleurs à noter que des paquets de données peuvent être définitivement perdus et que les données affichées au final peuvent contenir des erreurs, qui se manifestent dans la plupart des cas par des pixels noirs ou non rafraîchis. Certains terminaux d'affichage tentent d'atténuer l'inconfort 30 visuel que peuvent provoquer ces erreurs résiduelles, par des procédés de lissage de l'image par exemple. Assurer un débit constant sur une liaison WiFi est l'un des problèmes techniques auxquels l'invention divulguée dans la demande antérieure se propose de donner une solution. Dans la cabine relativement exiguë d'un avion, même de la taille 35 d'un long courrier, les erreurs ne sont pas dues à la distance entre la borne WiFi émettrice et la borne WiFi réceptrice. Le problème vient d'un phénomène classique connu sous la terminologie anglo-saxonne de micro-fading : à très haute fréquence le niveau de réception peut varier dans le temps et dans l'espace. Dans le cas présent, le micro-fading s'explique d'une part par un phénomène de résonance des molécules d'eau à la fréquence utilisée, l'eau étant très présente dans le corps de chacun des nombreux passagers en mouvement permanent, et d'autre part par un phénomène de réflexion des ondes sur les objets métalliques, le métal étant omniprésent dans la cabine d'un avion. La technologie WiFi, initialement conçue pour faire de l'Internet à la maison, échanger des e-mails et télécharger des fichiers sans réelle contrainte de temps, n'a pas été conçue pour être robuste au phénomène de micro-fading et fournir un débit constant. Certaines normes 802.11 plus récentes prévoient de fournir une qualité de service en terme de latence, de taux d'erreur et de débit. Mais elles reposeront sur un mécanisme de mise en mémoire tampon d'au moins une dizaine de secondes de données, ce qui est incompatible de la quasi-instantanéité d'affichage exigée par la vidéo à la demande dans un système IFE, notamment au démarrage. Les besoins de la vidéo à la demande dans un système IFE ne correspondent donc définitivement pas aux contraintes de développement de la technologie WiFi. C'est une des raisons pour lesquelles il n'existe pas actuellement de vidéo à la demande multiple dans un système IFE sans fil. Aujourd'hui, un module de lecture en tête de cabine est toujours relié aux écrans par une liaison filaire de bout en bout passant par les sièges. L'invention divulguée dans la demande antérieure se propose de résoudre le problème de débit non constant sur une liaison WiFi, afin de permettre la mise en oeuvre de la vidéo à la demande dans un système IFE sans fil. L'invention divulguée dans la demande antérieure est particulièrement efficace lorsque le taux d'erreur nominal sur la liaison est inférieur à 10"2. C'est très souvent le cas dans la pratique, notamment grâce aux mécanismes existants d'accusés de réception implémentés dans les couches OSI de bas niveau. Ainsi, l'invention divulguée dans la demande antérieure assure que si le taux d'erreur nominal est égal ou inférieur à 10-3 au début, alors il tombe en dessous de 10-6 par la suite. Utilisée dans le cadre d'une application multi-client comme de la vidéo à la demande dans un système IFE, elle permet également d'éviter que les dégradations du niveau de réception que peut rencontrer un client particulier n'aient d'impact sur les autres clients. Elle empêche que les mesures de récupération des données perdues par un client ne ralentissent les liaisons des autres clients. Malheureusement, l'invention divulguée dans la demande antérieure est moins efficace dès que le taux d'erreur nominal est égal ou supérieur à 10-2. Dans ce cas extrêmement défavorable, l'invention divulguée io dans la demande antérieure ne parvient plus à corriger efficacement les erreurs, du fait qu'elles sont trop nombreuses. Des tests ont montré que le taux d'erreur se maintient alors à une valeur sensiblement identique. Par conséquent, le taux d'erreur reste élevé pour quelques clients particulièrement lésés. Cependant, un avantage de l'invention divulguée 15 dans la demande antérieure est que ces clients lésés ne perturbent pas les autres clients : un mauvais niveau de réception reste localisé et ne se propage pas. La présente invention se propose d'effectuer une première 20 correction en amont du procédé faisant l'objet de l'invention divulguée dans la demande antérieure. En effet, l'invention divulguée par la demande antérieure n'est pleinement efficace que si l'on peut assurer que le taux d'erreur n'est pas plus grand que 10'3 à tout moment et pour tout récepteur. La présente invention limite le nombre de clients pour lesquels le taux 25 d'erreur est égal ou supérieur 10-2, ce cas étant relativement fréquent sur l'ensemble des passagers d'un avion. L'invention divulguée dans la demande antérieure devient donc efficace pour un plus grand nombre de clients. II faut noter que la présente invention est capable de corriger à tout moment et pour tout client un taux d'erreur élevé, égal ou supérieur à 10-2, mais qu'elle n'est 30 capable de diminuer ce taux d'erreur que jusqu'à un niveau moyen de l'ordre 10-3 ou 10"4, niveau qui est inacceptable dans le cadre de la vidéo à la demande. C'est l'invention divulguée dans la demande antérieure qui permet dans un deuxième temps de diminuer encore le taux d'erreur jusqu'à un niveau très bas de l'ordre 10-6, niveau qui est acceptable dans le cadre de la 35 vidéo à la demande. La présente invention a donc notamment pour but de fournir un taux d'erreur certes moyen, mais sensiblement uniforme sur l'ensemble des clients. Elle assure en tout cas que, sauf cas extrême, aucun client n'a un taux d'erreur tellement catastrophique qu'il serait impossible de le corriger par des mécanismes de retransmission entre le serveur et le client. A cet effet, l'invention a pour objet un procédé d'envoi de paquets de données d'un serveur vers des clients par une première liaison de données ayant un taux d'erreur donné. Les clients sont connectés entre eux par une seconde liaison de données ayant un taux d'erreur moins élevé que celui de la première liaison. Le serveur envoie tous les paquets à tous les clients sur la première liaison, quel que soit le client destinataire de chacun des paquets. Un client qui détecte qu'il n'a pas reçu un paquet dont il est destinataire sur la première liaison demande aux autres clients de lui renvoyer ledit paquet sur la seconde liaison. Par exemple, la première liaison de données peut être une liaison sans fil comme une liaison WiFi et la seconde liaison de données peut être une liaison filaire comme une liaison ethernet. Avantageusement, le serveur peut n'envoyer un paquet donné qu'une fois sur la première liaison, en adressant ledit paquet à tous les clients. Avantageusement là encore, au moins trois clients peuvent être connectés entre eux par la seconde liaison, un client ne demandant un paquet donné aux autres clients qu'une fois sur la seconde liaison, en adressant ladite demande à tous les autres clients. Le serveur peut numéroter les paquets qu'il envoie aux clients, un client détectant sur la base de la numérotation des paquets qu'il n'a pas reçu un paquet. Dans un mode de réalisation, les clients peuvent être connectés entre eux par l'intermédiaire de leurs récepteurs. Les paquets peuvent contenir par exemple des données audio et/ou vidéo utilisables par des modules de lecture que comportent les clients. Ces données audio et/ou vidéo peuvent par exemple être diffusées à des passagers d'un aéronef.35 La présente invention a encore pour principaux avantages de limiter les demandes de retransmission sur la liaison sans fil et donc d'économiser sa bande passante, ce qui n'est pas sans intérêt sur une liaison qui est déjà assez peu fiable sans retransmissions. Elle fournit également un mécanisme très profitable de redondance des clients. En effet, en cas d'interruption puis de reprise du fonctionnement d'un des clients, celui-ci pourra restaurer l'ensemble de ses données sans rien demander au serveur sur la liaison sans fil. Il n'aura qu'à les demander sur la liaison filaire aux autres clients, dont le fonctionnement se sera très probablement maintenu pendant l'interruption. D'autres caractéristiques et avantages de l'invention apparaîtront 15 à l'aide de la description qui suit faite en regard de dessins annexés qui représentent : la figure 1, une illustration par un diagramme d'architecture d'un exemple de mise en oeuvre de la présente invention dans un système de vidéo à la demande à bord d'un aéronef ; 20 la figure 2, une illustration par un diagramme d'architecture d'un exemple de mise en oeuvre de la présente invention dans un récepteur ; la figure 3, une illustration par un diagramme d'architecture d'un exemple de mise en oeuvre de la présente invention en 25 combinaison avec l'invention divulguée dans la demande antérieure. La figure 1 illustre par un diagramme d'architecture un exemple de 30 mise en oeuvre selon la présente invention d'un système de vidéo à la demande à bord d'un aéronef. Dans le mode de réalisation de la figure 1, un serveur 1 envoie par exemple des flux de données audio et vidéo vers trois clients 2, 3 et 4, par l'intermédiaire d'une borne WiFi émettrice 11 et d'une liaison WiFi 12. Il faut noter que tout autre type de liaison peut être envisagé, 35 avec ou sans fil. Dans le présent domaine de l'IFE, les clients 2, 3 et 4 sont par exemple des modules d'affichage vidéo comportant des bornes WiFi réceptrices 5, 6 et 7 et des lecteurs 8, 9 et 10 respectivement. Les clients pourraient également être des modules donnant la position géographique courante de l'aéronef. Avantageusement, les récepteurs 5, 6 et 7 sont connectés entre eux par l'intermédiaire d'une liaison Ethernet 13 conforme à la norme IEEE802.3. Il faut noter que tout autre type de liaison peut être envisagé. Il est cependant souhaitable que la liaison entre les clients 2, 3 et 4 soit plus fiable que la liaison avec le serveur 1, ceci afin de tirer pleinement avantage de la présente invention. De cette manière, les clients 2, 3 et 4 1 o peuvent écouter les flux de données destinés aux autres clients à proximité. Avantageusement, le serveur 1 envoie tous les paquets de données à une seule et même adresse pour l'ensemble du groupe formé par les trois clients 2, 3 et 4. Cette méthode d'envoi est couramment désignée par l'expression anglo-saxonne d'envoi en multicast . Par extension, on 15 parlera par la suite de flux multicast et de paquets multicast pour désigner ces flux et ces paquets envoyés en multicast ou encore d'adresse multicast . Concrètement, les différents flux sont envoyés vers différents ports des récepteurs 5, 6 et 7 partageant la même adresse. Un client peut écouter tous ces ports et revendiquer jusqu'à 4 ports pour son 20 usage propre. Le fait que les flux soient envoyés en multicast est très important. Car si les paquets de données étaient envoyés à une adresse pour chacun des clients 2, 3 et 4, cette méthode d'envoi étant désignée par l'expression anglo-saxonne d'envoi en unicast , chaque client ne pourrait voir que ses propres flux et aucun autre. C'est tout particulièrement le cas 25 lorsqu'on utilise les procédés de cryptages de la norme 802.11. II serait alors impossible de mettre en oeuvre la présente invention. De plus, un flux envoyé en unicast se comporte de manière imprévisible. Quand un paquet est envoyé en unicast , la bande passante qu'il utilise dépend du débit, du nombre de fois qu'il est perdu et de sa taille. Et il nécessite un accusé de 30 réception. Alors que l'utilisation de la bande passante par un paquet multicast ne dépend de rien d'autre que de sa taille. Le taux de transmission est fixé, le nombre de transmission vaut toujours un et il ne nécessite pas d'accusé de réception. Bien que la probabilité pour qu'un récepteur perde un paquet est plus grande en multicast qu' en 35 unicast , du fait qu'il n'y a plus de retransmission couche basse, l'envoi en multicast présente quand même l'avantage que l'utilisation totale de la bande passante peut être connue avec précision, ce qui rend le dimensionnement du système plus facile. Par conséquent, pour mettre en oeuvre la présente invention, il est obligatoire d'utiliser des flux multicast pour envoyer les flux de données audio et vidéo. Le chemin normal d'un paquet dans un flux de données audio et vidéo est celui décrit dans ce qui suit. D'abord, le paquet est envoyé par le serveur 1 à une adresse multicast , par exemple 239.255.1.1, par l'intermédiaire de l'émetteur WiFi 11. Le paquet de données est un paquet RTP (Real-Time Transport Protocol), il contient donc un en-tête RTP avec un numéro de séquence. A titre d'exemple, on peut utiliser l'en-tête RTP décrit par la norme RFC 3551. L'émetteur WiFi 11 retransmet le paquet vers les trois récepteurs WiFi 5, 6 et 7 des trois clients 2, 3 et 4 respectivement. Un seul des trois clients 2, 3 ou 4 est le destinataire du paquet, c'est-à-dire un seul des clients va effectivement utiliser le paquet pour diffusion de son contenu audio ou vidéo. Supposons qu'il s'agit du client 3. Le récepteur 6 du client 3 stocke le paquet dans un espace de mémoire tampon et l'envoie au lecteur 9. Un exemple de structure de la mémoire tampon du récepteur 6 sera donné par la suite. Les récepteurs 5 et 7 ne font que stocker le paquet dans un espace de mémoire tampon, ils ne l'envoient pas à leurs lecteurs respectifs 8 et 10. Dans le cas nominal où le récepteur 6 ne rate pas le paquet, c'est-à-dire si dans la zone du récepteur 6 les effets du phénomène de micro-fading étaient faibles au moment qui a suivi immédiatement l'envoi par l'émetteur WiFi 11, le processus s'arrête là. De même, si l'un ou les deux des récepteurs 5 et 7 n'a pas ou n'ont pas reçu le paquet, c'est-à-dire si les effets du phénomène de micro-fading étaient importants dans les zones des récepteurs 5 et 7 au moment qui a suivi immédiatement l'envoi par l'émetteur WiFi 11, alors rien de plus ne se passe et le processus s'arrête là également. En effet, les clients 2 et 4 n'utilisent pas le paquet de manière effective. Tout au plus peuvent-ils garder une trace du fait que le paquet a été perdu, ce qui est possible sur la base des numéros de séquence dans les en-têtes RTP des paquets reçus. Par exemple, si un paquet comportant le numéro de séquence k est reçu, où k est un entier naturel, alors le paquet suivant doit être numéroté k+1. Si le paquet suivant est numéroté k+2, alors le récepteur peut déduire facilement que le paquet k+1 a été envoyé mais qu'il n'a pas été reçu. Cette explication est très schématique, un exemple d'implémentation plus réaliste sera détaillé par la suite. Par contre, si le récepteur 6 du client 3 n'a pas reçu le paquet, c'est-à-dire si les effets du phénomène de micro-fading étaient importants dans la zone du récepteur 6 au moment qui a suivi immédiatement l'envoi par l'émetteur WiFi 11, alors le paquet doit être récupéré car le client 3 utilise ce paquet de manière effective pour diffusion de son contenu audio ou vidéo via le lecteur 9. Le récepteur 6 envoie donc une requête de retransmission aux récepteurs 5 et 7 par l'intermédiaire de la liaison Ethernet 13. En effet, il est hautement probable que l'un au moins d'entre eux a reçu le paquet. Il faut noter que le fait de ne pas envoyer de requête de retransmission au serveur 1 sur la liaison WiFi 12, ce qui aurait été conforme à l'invention divulguée dans la demande antérieure, permet d'économiser la bande passante sur cette liaison déjà défaillante dans le cas présent. Avantageusement, une unique requête est adressée au récepteur 5 et au récepteur 7 grâce à un seul paquet envoyé en broadcast sur la liaison Ethernet 13. La méthode d'envoi couramment désignée par l'expression anglo-saxonne d'envoi en broadcast permet d'envoyer un paquet à tous les clients d'un réseau. Ainsi, s'il y avait eu d'autres clients que les clients 2 et 4 sur le réseau Ethernet 13, ils auraient aussi reçu la requête de retransmission. La requête de retransmission contient le numéro de séquence du paquet perdu et le port du flux considéré. Lorsque les récepteurs 5 et 7 reçoivent la requête, ils consultent chacun les paquets qu'ils ont stockés dans leurs mémoires tampons et cherchent le paquet dont la retransmission est demandée. Si l'un d'eux l'a reçu, alors il renvoie le paquet en question au récepteur 6. Sinon, il ne répond pas à la requête. Par conséquent, le récepteur 6 peut ne recevoir aucune réponse à sa requête de retransmission ou recevoir une réponse à sa requête ou encore recevoir deux réponses à sa requête. Dans le cas où il reçoit au moins une réponse à sa requête, il stocke cette réponse dans sa mémoire tampon et l'envoie à son lecteur 9 pour diffusion de son contenu. Il faut noter que ce n'est pas un problème si plusieurs paquets comportant le même numéro de séquence RTP circulent simultanément sur la liaison Ethernet 13. En effet, le protocole RTP est capable de détecter et de supprimer les paquets identiques (doublons). II est aussi capable de réordonner des paquets arrivés dans le désordre comme c'est inévitablement le cas ici. Par ailleurs, le récepteur 6 compte les paquets récupérés, ce qui permet de mesurer le taux d'erreur résiduel. Il ne compte une réponse à retransmission qu'une seule fois, en consultant sa mémoire tampon pour savoir si une réponse reçue ne correspond pas à un paquet déjà récupéré précédemment. Les récepteurs 5 et 7 font de même pour les paquets qu'ils ratent et dont ils demandent la retransmission. Le taux d'erreur résiduel de chacun des récepteurs 5, 6 et 7 permet d'évaluer l'efficacité de la présente 1 o invention. Si à la fois le récepteur 5 et le récepteur 7 n'ont pas reçu le paquet demandé par le récepteur 6, alors il n'y a aucune retransmission sur la liaison Ethernet 13. Par conséquent, il reste un taux d'erreur résiduel non nul même après mise en oeuvre de la présente invention. Heureusement, ce 15 taux d'erreur résiduel est meilleur que le taux d'erreur avant mise en oeuvre de l'invention. Des tests effectués par la demanderesse montrent que le plus mauvais taux d'erreur après mise en oeuvre de la présente invention est meilleur que le meilleur taux d'erreur avant. Et ceci reste vrai même si l'un des récepteurs 5, 6 ou 7 a un très mauvais taux d'erreur nominal, par 20 exemple de l'ordre de 10-2. H faut noter que ce n'est pas forcément le cas de l'invention divulguée par la demande antérieure, qui ne s'avère efficace que pour les taux d'erreur nominaux inférieur à 10-2. Par conséquent, il peut être raisonnablement espéré que la présente invention diminue le taux d'erreur jusqu'à celui du meilleur récepteur parmi les récepteurs 5, 6 et 7. Elle 25 diminue significativement le taux d'erreur d'au moins un ou de quelques récepteurs dans une zone donnée qui a de très mauvaises conditions de réceptions, ceci sans utiliser de bande passantesupplémentaire aux dépends des autres récepteurs. 30 Il est important de comprendre que les systèmes connus comportant plusieurs antennes ne sont pas comparables à la présente invention. Parmi ces systèmes peuvent être cités par exemple l'antenne Yagi, qui est formée par une pluralité d'antennes alignées en râteau, ou la 35 technologie MIMO (Multiple-Input Multiple-Output), qui exploite une pluralité d'antennes et de boucles de réception dans un même récepteur. D'une part, dans ces systèmes il s'agit toujours d'un seul client connecté à plusieurs antennes. En aucun cas il ne s'agit d'une communauté de clients interconnectés jouant chacun le rôle d'antenne pour la communauté. D'autre part, dans ces systèmes les antennes sont quasiment colocalisées ou séparées d'une distance extrêmement limitée : quelques centimètres aux fréquences considérées. En aucun cas il ne s'agit d'antennes et de récepteurs réellement distants et connectés par une liaison de données. Enfin, ces systèmes à plusieurs antennes répondent toujours à un problème io technique autre que celui du micro-fading. Ainsi, la pluralité d'antennes formant une antenne Yagi permet de sommer en puissance (donc de façon purement analogique) les signaux reçus pour améliorer la réception d'un signal. La pluralité d'antennes de la technologie MIMO permet essentiellement de multiplier le débit. En aucun cas connu il ne s'agit de 15 pallier la variation ou la diversité dans l'espace du niveau de réception par un échange des informations manquantes entre plusieurs récepteurs indépendants et distants. 20 La figure 2 illustre par un diagramme d'architecture un exemple de mise en oeuvre de la présente invention dans le récepteur 6 de l'exemple de la figure 1. Sur la liaison WiFi 12, le récepteur 6 reçoit n flux de données audio et vidéo f;, iE {1,...,n}. Par exemple, seuls les flux f1, f2 et f3 sont effectivement utilisés par le client :3 dont fait partie le récepteur 6. Le 25 récepteur 6 reçoit les flux f1, f2 et f3 en multicast par l'intermédiaire d'un point de communication dédié appelé SELF. Un point de communication est une structure de données classique, très connue sous sa désignation anglo-saxonne de socket , qui permet de définir le protocole de communication entre un émetteur et un récepteur. Le récepteur 6 stocke les flux f1, f2 et f3 30 en mémoire tampon et les envoie au lecteur 9 en unicast par l'intermédiaire d'une socket LOOP pour diffusion de leur contenu audio ou vidéo. Les autres flux de f4 à fn sont reçus par l'intermédiaire d'une socket PEER et simplement mis en mémoire tampon, ils ne sont pas envoyés au lecteur 9. Par exemple, la mémoire tampon du récepteur 6 35 comporte une structure de stockage par flux, le flux f; étant stocké dans une structure s; pour iE{1,...,n}. Avantageusement, chaque structure s; peut contenir 16 paquets de données indexés de 0 à 15. Dans cet exemple de réalisation, un paquet de numéro de séquence RTP égal à k est stocké à l'emplacement d'indice N = k mod 16. En faisant l'hypothèse que les paquets sont reçus dans l'ordre croissant de 1 en 1 des numéros de séquence RTP, N doit donc normalement varier cycliquement de 0 à 15 par incrément de 1, puis revenir à l'indice 0, et ainsi de suite. A chaque fois qu'un paquet est stocké dans une structure s; où iE {1,2,3}, un module 14 de vérification peut comparer le nouvel indice de stockage avec l'indice de stockage précédent, i o qu'il a mémorisé. Si le nouvel indice ne correspond pas à l'indice que la variation cyclique des indices de stockage permet de prévoir à partir de l'indice précédent, alors cela signifie qu'au moins un paquet a été perdu. Dans ce cas, un module 15 de décorrélation spatiale envoie en broadcast un paquet contenant une requête de retransmission du paquet perdu par 15 l'intermédiaire d'une socket RREQ sur la liaison Ethernet 13, vers les récepteurs 5 et 7 non représentés sur la figure 2. Très probablement, une retransmission du paquet perdu sera reçue ultérieurement en unicast sur la liaison 13 par un module 16 de traitement des retransmissions, par l'intermédiaire d'une socket RECV. Le paquet retransmis sera envoyé au 20 lecteur 9 pour diffusion de son contenu audio ou vidéo. II faut noter que, éventuellement, le module 16 peut lui-même recevoir une requête de retransmission d'un paquet venant du récepteur 5 ou du récepteur 7 par l'intermédiaire de la socket RECV. S'il est présent dans l'une des structures s;, iE{4,...,n}, le paquet demandé est alors 25 retransmis par l'intermédiaire de la socket RREQ. La figure 3 illustre par un diagramme d'architecture un exemple similaire de mise en oeuvre de la présente invention que celui de la figure 2, 30 mais cette fois en combinaison avec l'invention divulguée dans la demande antérieure. Le récepteur 6 est connecté aux mêmes liaisons WiFi 12 et Ethernet 13 et au même lecteur 9. Les mêmes flux f; pour iE{1,...,n} sont reçus et stockés dans les mêmes structures s; pour iE{1,...,n}. Les mêmes modules 14, 15 et 16 implémentent la présente invention, permettant d'envoyer et de recevoir des requêtes de retransmission sur la liaison Ethernet 13 aux récepteurs 5 et 7 non représentés sur la figure 3. Des modules 17 et 18 implémentent l'invention divulguée dans la demande antérieure. Le module 17 de vérification recherche dans les structures s; pour iE {1,2,3}, sur la base des numéros de séquence RTP, si des paquets ont été perdus et n'ont pas pu être récupérés grâce à la présente invention. Le cas échéant, le module 18 de décorrélation temporelle renvoie au serveur 1, non représenté sur la figure 3, une requête de retransmission dudit paquet sur la liaison WiFi 12 par l'intermédiaire d'une socket L5RQ, ceci conformément à l'invention divulguée dans la demande antérieure. II faut noter que les modules 14, 15 et 16 implémentant la présente invention ont priorité sur les modules 17 et 18 implémentant l'invention divulguée dans la demande antérieure. Les modules 14, 15 et 16 opèrent avant les modules 17 et 18. Car il s'agit bien de ne demander des retransmissions au serveur 1 par l'intermédiaire de la liaison WiFi 12 que si aucun des deux récepteurs 5 ou 7 n'a reçu le paquet en question. Ainsi, la présente invention permet de ne pas gaspiller de bande passante sur la liaison WiFi 12. Par son mécanisme de retransmission décalée, l'invention divulguée dans la demande antérieure se propose de pallier le phénomène de micro-fading sous l'angle temporel. La présente invention se propose quant à elle d'y pallier sous l'angle spatial. En effet, à un instant donné une baisse du niveau de réception a lieu à un endroit donné de l'avion, pas partout dans l'avion : l'échelle de variation du micro-fading aux fréquences considérées dans un avion n'est que de quelques centimètres. A cet instant, l'un au moins des clients est susceptible de ne pas être perturbé par le micro-fading. Il peut donc jouer le rôle de récepteur pour les autres clients.30 REVENDICATIONS 1. Procédé d'envoi de paquets de données d'un serveur (1) vers des clients (2, 3, 4) par une première liaison de données (12) ayant un taux d'erreur donné, les clients (2, 3, 4) étant connectés entre eux par une seconde liaison de données (13) ayant un taux d'erreur moins élevé que celui de la première liaison, caractérisé en ce que : le serveur (1) envoie tous les paquets à tous les clients (2, 3, 4) sur la première liaison (12), quel que soit le client destinataire de chacun des paquets ; un client (3) qui détecte qu'il n'a pas reçu un paquet dont il est destinataire sur la première liaison demande aux autres clients (2, 4) de lui renvoyer ledit paquet sur la seconde liaison (13). 2. Procédé selon la revendication 1, caractérisé en ce que la première liaison de données (12) est une liaison sans fil et la seconde liaison de données (13) est une liaison filaire. 3. Procédé selon la revendication 1, caractérisé en ce que la première liaison de données (12) est une liaison conforme à la norme IEEE802.11 et la seconde liaison de données (13) est une liaison conforme à la norme I EEE802.3. 4. Procédé selon la revendication 1, caractérisé en ce que le serveur (1) n'envoie un paquet donné qu'une fois sur la première liaison (12), en adressant ledit paquet simultanément à tous les clients (2, 3, 4). 5. Procédé selon la revendication 1, caractérisé en ce qu'au moins trois clients (2, 3, 4) sont connectés entre eux par la seconde liaison (13). 6. Procédé selon la revendication 1, caractérisé en ce qu'un client (3) ne demande un paquet donné qu'une fois sur la seconde liaison (13), en adressant ladite demande à tous les autres clients (2, 4). 7. Procédé selon la revendication 1, caractérisé en ce que le serveur (1) numérote les paquets qu'il envoie aux clients (2, 3, 4), un client (3)détectant sur la base de la numérotation des paquets qu'il n'a pas reçu un paquet. 8. Procédé selon la revendication 1, caractérisé en ce que les clients (2, 3, 4) sont connectés entre eux par l'intermédiaire de leurs récepteurs (5, 6, 7). 9. Procédé selon la revendication 1, caractérisé en ce que les paquets contiennent des données audio et/ou vidéo utilisables par des modules de lecture (8, 9, 10) que comportent les clients (2, 3, 4). 10. Procédé selon la revendication 9, caractérisé en ce que les données audio et/ou vidéo sont diffusées à des passagers d'un aéronef.