Brevet FR2827450A1 — publié le 20030117

La présente invention concerne un procédé de diffusion d'un contenu en temps réel à partir d'une source vers une pluralité de terminaux récepteurs, à travers un réseau informatique, par exemple Internet. L'Internet permet aujourd'hui de diffuser en temps réel des contenus multimédias, tels que des émissions de télévision, des films vidéo, des conférences et autres programmes, vers une large audience de terminaux récepteurs. Il existe principalement deux méthodes pour diffuser en temps réel des données depuis une source vers une pluralité de terminaux récepteurs, à travers l'Internet. En référence à la figure 1, la première méthode, dite"unicast", consiste à envoyer le même contenu autant de fois qu'il y a de terminaux récepteurs T1,..., Ti, ..., Tn. La source S établit une liaison point-à-point avec chacun des terminaux récepteurs, décompose le contenu à diffuser en paquets de données IP, encore appelés"datagrammes", duplique chaque datagramme IP en n exemplaires, n étant égal au nombre de terminaux récepteurs Ti, et envoie ces n exemplaires vers les n terminaux récepteurs T1,..., Ti,.... Tn respectivement. En référence à la figure 2, la seconde méthode, dite"multicast", permet à la source S de diffuser un contenu multimédia vers une pluralité de terminaux récepteurs T1,..., Ti,..., Tn, en un seul envoi. Lors de la diffusion du contenu, la source S émet des datagrammes IP, lesquels sont dupliqués en cascade par des noeuds du réseau, que l'on appellera par la suite des"routeurs", afin d'être acheminés jusqu'aux terminaux récepteurs T1,..., Ti,.... Tn. Si aucun terminal Ti ne demande à recevoir les paquets de données émis par la source, ces derniers ne sont pas acheminés au-delà du premier noeud du réseau et sont donc perdus. Lorsqu'un terminal Ti souhaite recevoir le contenu multimédia diffusé par la source S, il envoie une requête d'acquisition de ce contenu en direction de la source S, à travers l'internet, en utilisant le protocole IGMP (Internet Group Management Protocol). Le premier routeur multiast, recevant déjà les datagrammes IP diffusés par la source et qui reçoit cette requête, se charge de dupliquer les datagrammes IP puis les achemine vers le terminal Ti ou vers un autre routeur. Par"routeur multicast", on entend désigner un noeud du réseau qui reçoit les datagrammes diffusés par la source et les achemine vers un ou plusieurs terminaux, après les avoir éventuellement dupliqués. Pour recevoir un contenu diffusé par une source, en mode unicast ou multiast, chaque terminal récepteur doit au préalable récupérer un fichier descriptif SDP (Session Description Protocol) associé à la source, par exemple par téléchargement depuis un site Web. La structure du fichier SDP, définie par l'IETF (Internet Engineering Task Force), est décrite dans le document RFC2327. Ce fichier est destiné à véhiculer les informations requises pour permettre aux terminaux récepteurs de recevoir les contenus multimédias diffusés par la source. A chaque source correspond un fichier SDP général, contenant toutes les informations utiles pour se mettre en réception de cette source, quel que soit le contenu diffusé par celle-ci. En outre, à chaque contenu diffusé (émission TV, film, conférence, etc. ) par la source correspond un fichier SDP spécifique contenant toutes les informations requises pour recevoir ce contenu particulier. Le fichier SDP général de la source est valable quel que soit le contenu diffusé par la source, alors que le fichier SDP d'un contenu spécifique n'est valable que pour la diffusion de ce contenu. Le protocole de transmission de données essentiellement utilisé pour la diffusion en temps réel, en mode unicast ou multiast, à travers l'Internet est le protocole RTP (Real-time Transfer Protocol). Il est généralement associé au protocole RTCP (Real-time Transfer Control Protocol) de contrôle des flux de données qui permet aux terminaux récepteurs de faire remonter vers la source des rapports de réception contenant des informations QoS (Quality of Service) sur la qualité de la réception, telles que l'indication du débit de réception et le taux de perte de datagrammes. Selon le protocole RTP, pour diffuser un contenu multimédia, la source émet une pluralité de flux de données, chaque flux véhiculant les données correspondant à un média spécifique. A titre d'exemple, pour diffuser un film vidéo en deux langues, la source émet un flux vidéo et deux flux audios pour les deux langues respectivement. En outre, les données d'un même média, par exemple vidéo ou audio, peuvent être véhiculées par plusieurs flux ayant des débits de données différents. A titre d'exemple, pour diffuser la composante vidéo d'un contenu audiovisuel, la source peut émettre trois flux vidéos, à 400kbit/s chacun, dont un flux vidéo de base Vb, un premier flux vidéo de rehaussement Ve1 (Video enhancement 1) et un second flux vidéo de rehaussement Ve2 (Video enhancement 2). En réception, suivant leurs capacités, les terminaux récepteurs utilisent le flux vidéo de base en y ajoutant éventuellement le flux vidéo Ve1 et/ou le flux vidéo Ve2 afin d'obtenir une meilleure qualité vidéo. En variante, la source peut émettre trois flux vidéos à 400kbit/s, 800kbit/s et 1200kbit/s respectivement, les terminaux récepteurs sélectionnant l'un seul de ces trois flux suivant leurs capacités. Pour recevoir un contenu multimédia véhiculé par n flux, les terminaux récepteurs utilisent n paires de ports de communication, chaque paire comprenant un port RTP et un port RTCP, pour recevoir les n flux et émettre les n rapports de réception correspondant à ces n flux. Les ports de communication RTP et RTCP associés d'une même paire se suivent, le port RTP étant pair et le port RTCP impair. En unicast, la source établit autant de liaisons point-à-point qu'il y a de terminaux récepteurs. On peut donc sans difficulté mesurer l'audience de la source en temps réel en dénombrant les liaisons point-à-point établies. Cependant, la technique unicast est gourmande en bande passante et donc inadaptée à la diffusion vers un large public. La technique multiast permet de réduire considérablement la consommation en bande passante. Cependant, elle ne permet pas de mesurer l'audience de la source de façon simple. En effet, la source émet son contenu audiovisuel en un seul envoi, sans pouvoir dénombrer les terminaux en réception. Le problème technique posé par la présente invention consiste donc à proposer un procédé de diffusion en temps réel d'un contenu à partir d'une source vers une pluralité de terminaux récepteurs, à travers un réseau informatique, dans lequel chaque terminal récupère des données descriptives associées à la source, la source diffuse le contenu à travers le réseau et les terminaux récepteurs acquièrent le contenu diffusé, à partir desdites données descriptives, qui permette de mesurer l'audience de la source. Le problème est résolu par le fait qu'on insère dans lesdites données descriptives l'adresse d'un serveur de collecte et chaque terminal récepteur signale qu'il est en réception par l'envoi d'un rapport d'audience à ladite adresse. La présente invention tire son origine d'un problème de diffusion en multiast. Toutefois, la demanderesse entend ne pas limiter la portée de sa demande à cet exemple particulier mais l'étendre à tout type de diffusion, et notamment à la diffusion en unicast. Dans l'art antérieur, le protocole RTCP permettait de faire remonter des informations vers la source. La solution immédiate au problème de l'invention était donc d'utiliser ce protocole pour mesurer l'audience en multiast. La demanderesse a cependant cherché une solution moins immédiate mais plus satisfaisante. En séparant la source et le collecteur de rapports d'audience, on s'affranchit des inconvénients du protocole RTCP qui, du fait qu'il est intimement lié au protocole RTP, fait remonter une quantité considérable d'informations vers la source, surtout dans le cas de la diffusion de contenus véhiculés par une pluralité de flux, et on mesure de façon simple l'audience. La solution de la présente invention présente l'avantage supplémentaire de ne pas surcharger la source par des remontées de rapports d'audience. La source peut ainsi exploiter toutes ses capacités exclusivement pour la diffusion. En outre, l'adresse étant insérée dans les données descriptives associées à la source, le terminal récepteur la récupère sans effectuer d'action spécifique et sans équipement supplémentaire. Avantageusement, on insère dans lesdites données descriptives une information de périodicité de façon à ce que chaque terminal récepteur envoie périodiquement un rapport d'audience au serveur de collecte. Dans un mode de réalisation particulier, le terminal insère dans le rapport d'audience au moins l'une des informations du groupe contenant une indication géographique de localisation, une langue préférée et une information de qualité de réception. Grâce à cela, on peut dresser les profils des terminaux récepteurs, autrement dit connaître leurs caractéristiques de récepteurs. La connaissance de ces profils permettra à un centre de programmation d'adapter la grille de programmation de la source afin de cibler de façon plus fine les terminaux récepteurs, en fonction de leurs profils. De préférence, le serveur de collecte attribue une information d'horodatage à chaque rapport d'audience reçu. Ainsi tous les rapports d'audience sont horodatés par la même horloge. Avantageusement, le serveur de collecte élabore un bilan d'audience, à partir des rapports d'audience des terminaux. Le serveur de collecte pourra ensuite transmettre ce bilan au centre de programmation de la source, lequel l'exploitera afin d'adapter la grille de programmation de la source. De préférence encore, une pluralité de sources diffusant des contenus vers une pluralité de groupes de terminaux récepteurs, l'ensemble des terminaux appartenant aux différents groupes envoient des rapports d'audience vers le même serveur de collecte. Le serveur de collecte peut ainsi servir de centre d'audiométrie pour plusieurs sources. On peut insérer les données descriptives associées à la source dans un fichier SDP. On peut aussi diffuser l'adresse du serveur de collecte à travers un canal de signalisation associé à la source. L'invention concerne également un serveur de collecte pour la mise en oeuvre du procédé défini ci-dessus, comprenant des moyens pour recevoir des rapports d'audience d'au moins une source de diffusion, des moyens de traitement agencés pour élaborer un bilan d'audience à partir des rapports d'audience reçus et des moyens pour émettre ledit bilan vers un centre de programmation associé à ladite source. La présente invention sera mieux comprise à l'aide de la description suivante d'un mode de réalisation particulier du procédé de diffusion et d'une forme de réalisation particulière du serveur de collecte de l'invention, en référence au dessin annexé sur lequel : - la figure 3 représente une vue schématique d'une pluralité de terminaux récepteurs, d'une source de diffusion, d'un centre de programmation et d'un serveur de collecte ; - la figure 4 représente une vue schématique de l'un des terminaux récepteurs, de la source de diffusion et du serveur de collecte de la figure 3, d'un site Web, et les différentes étapes du procédé de diffusion selon le mode de réalisation particulier de l'invention ; - les figures 5 à 7 représentent des organigrammes du procédé de diffusion selon le mode de réalisation particulier de l'invention et - la figure 8 représente un schéma bloc fonctionnel du serveur de collecte de la figure 3. Sur la figure 3, on a représenté un réseau informatique, en l'espèce l'Internet, une pluralité de terminaux T1, T2,..., Ti,..., Tn, une source de diffusion S, un centre de programmation CP et un serveur de collecte SC. Dans l'exemple particulier de la description, la source S est une chaîne de diffusion audiovisuelle, que l'on appellera par la suite"chaîne 1", hébergée par un serveur audiovisuel de l'Internet et destinée à diffuser en mode multiast des contenus audiovisuels (émissions télévisées, films vidéos, etc. ), à travers Internet, vers des terminaux récepteurs. Le serveur audiovisuel pourrait héberger d'autres sources de diffusion. Le centre de programmation CP est destiné à établir une grille de programmation pour la diffusion des contenus audiovisuels par la source S et à créer, pour la source S, un fichier descriptif SDP général, contenant toutes les informations nécessaires pour permettre à un terminal de se mettre en réception de la source S, ainsi que, pour chaque contenu diffusé, un fichier descriptif SDP spécifique contenant toutes les informations requises pour recevoir ce contenu. Les fichiers descriptifs SDP, associés à la source S, sont transmis au site Web SW à partir duquel ils peuvent être téléchargés par des terminaux. On notera ici que la structure d'un fichier SDP, telle que définie par l'IETF, est la suivante : Session description v= (protocol version) o= (owner/creator and session identifier). s= (session name) i=* (session information) u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information-not required if included in ail media) b=* (bandwidth information) One or more time descriptions (see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Zero or more media descriptions (see below) Time description t= (time the session is active) r=* (zero or more repeat times) Media description m= (media name and transport address) i=* (media title) c=* (connection information - optional if included at session-level) b=* (bandwidth information) k=* (encryption key) a=* (zero or more media attribute lines) Les champs marqués du caractère"*"sont optionnels. Pour plus d'informations concernant la structure de données SDP, le lecteur est invité à se reporter au document RFC2327 issu de l'IETF. Le serveur de collecte SC, connecté à l'Internet, est destiné à recueillir des rapports d'audience envoyés par des terminaux récepteurs Ti. Il comprend une interface 90 de connexion à l'Internet, un bloc 91 de réception des rapports, un bloc 92 d'horodatage des rapports, un bloc de traitement 93, un bloc 94 d'émission de ce bilan vers la source S et un bloc 95 de modification de la période d'envoi des rapports. Tous ces éléments sont reliés à une unité centrale de commande, non représentée, destinée à commander le fonctionnement du serveur SC. Les blocs 91, 94 et 95 sont reliés à l'interface de connexion 90. Le bloc d'horodatage 92, interposé entre le bloc de réception 91 et le bloc de traitement 93, est destiné à horodater les rapports reçus. Le bloc de traitement 93, connecté au bloc d'émission 94, est destiné à élaborer des bilans statistiques d'audience comprenant des histogrammes établis à partir des rapports reçus. En référence aux figures 4 à 7, on va maintenant décrire le procédé de diffusion en temps réel d'un contenu audiovisuel, à partir de la source S, vers une pluralité de terminaux Ti, à travers l'Internet, en mode multiast. Dans l'exemple particulier de la description, le contenu diffusé est un film vidéo intitulé"la grande vadrouille". Dans une étape 1, le centre de programmation CP insère un champ, ici intitulé"d", associé au serveur de collecte SC, dans le fichier SDP spécifique du contenu à diffuser, à savoir le film"la grande vadrouille", ainsi que dans le fichier SDP général de la source S. Le champ"d", représenté ci-après, contient toutes les informations requises pour permettre à un terminal récepteur Ti d'envoyer périodiquement un rapport d'audience au serveur de collecte SC. Champ d d= Le champ "d", lequel constitue en définitive une commande d'envoi de rapports d'audience vers le serveur SC, contient l'indication du réseau auquel appartient le serveur SC, le type de l'adresse du serveur SC, l'adresse du serveur SC, le numéro du port de communication du serveur SC et la période 1 d'envoi des rapports vers le serveur SC. Le fichier SDP de la source et le fichier SDP du film sont transmis au site SW et peuvent être téléchargés depuis ce site par des terminaux. A titre d'exemple, le fichier SDP du film"la grande vadrouille", diffusé par la chaîne 1, contient les informations suivantes : v=O o=chaine1 IN IP4 126.16. 64.4 s=La grande vadrouille u=http ://www. chaine1. fr/films/la~grande~vadrouille. htm e=infos@chaine1. fr c=IN IP4 224. 2, 17, 12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 m=application 32416 udp wb d=IN IP4 224.2. 1.1 32416 300 Le champ"d"indique que : - le serveur SC appartient à Internet ; - l'adresse du serveur SC est de type IP4 ; - l'adresse IP du serveur SC est 224. 2. 1. 1 ; - le numéro du port de communication du serveur SC est 32416 et - la période r d'envoi des rapports d'audience est égale à 300 secondes. Dans une étape 2, chaque terminal Ti souhaitant recevoir le film récupère le fichier SDP spécifique associé à ce film ou le fichier SDP général de la source S. on rappelle ici que le fichier SDP du film n'est valable que pour la diffusion du film considéré, alors que le fichier SDP de la source permet de se mettre en réception de la source à tout moment, quel que soit le contenu diffusé par celle-ci. Pour récupérer l'un de ces deux fichiers SDP, dans une étape 2a, le terminal se connecte au site Web SW et lui adresse une requête d'acquisition du fichier considéré. Sur réception de cette requête, dans une étape 2b, le site Web SW transmet le fichier requis au terminal Ti, qui le mémorise. La source S diffuse le film vidéo en mode multiast, à travers l'Internet. Pour cela, elle émet des paquets de données IP, véhiculant le contenu audiovisuel, en un seul envoi, à travers l'Internet, vers une pluralité de terminaux récepteurs. Dans une étape 3, à partir des informations contenues dans le fichier SDP reçu, chaque terminal Ti souhaitant recevoir le film acquiert les paquets de données IP diffusés par la source S à travers l'Internet. L'étape 3 se décompose en plusieurs sous-étapes : - le terminal Ti envoie une requête d'acquisition du contenu audiovisuel diffusé par la source S, à savoir le film vidéo"la grande vadrouille", en direction de la source S, à travers l'Internet, par le protocole IGMP, (étape 3a) - le premier routeur multiast RM qui reçoit cette requête duplique les paquets IP reçus provenant de la source (étape 3b) puis - il achemine les paquets IP dupliqués vers le terminal Ti, à travers l'Internet (étape 3c). On rappelle ici que par"routeur multicast", on entend désigner un noeud du réseau qui reçoit les paquets IP diffusés par la source et les achemine vers un ou plusieurs terminaux, après les avoir éventuellement dupliqués, si nécessaire. Dans une étape 4, sur réception du premier paquet de données IP diffusé par la source S, le terminal Ti envoie un rapport d'audience au serveur de collecte SC, à travers l'Internet. Ce premier rapport signale au serveur SC que le terminal Ti vient de se mettre en réception de la source S. Il contient des informations relatives au terminal récepteur Ti, en l'espèce une indication géographique de localisation du terminal Ti, la langue préférée du terminal Ti, le débit de réception du terminal Ti et le taux de perte de paquets IP reçus. Le terminal Ti réitère l'étape 4 périodiquement, à la fréquence 1h, afin de signaler au serveur SC qu'il est en réception de la source S, jusqu'à ce qu'il interrompe la réception des paquets IP diffusés par la source S. Avant d'interrompre la réception, s'il en a la possibilité, le terminal Ti envoie un dernier rapport d'audience signalant au serveur SC qu'il va cesser de recevoir. Le serveur SC reçoit les rapports d'audience provenant de tous les terminaux Ti du groupe multiast de terminaux en réception et attribue à chaque rapport reçu une information d'horodatage, contenant la date et l'heure de réception de ce rapport, dans une étape 5. Par"groupe multicast", on entend désigner l'ensemble des terminaux en réception d'une source multiast donnée. Dans une étape 6, à partir des rapports d'audience reçus, le serveur SC élabore un bilan statistique d'audience contenant un histogramme d'audience, sur lequel figure, en ordonnées, le nombre de terminaux en réception et, en abscisses, l'heure et la date de réception, ainsi que divers histogrammes concernant la langue préférée des terminaux, la qualité de la réception et la localisation des terminaux. Il transmet ensuite ce bilan au centre de programmation CP. Dans une étape 7, en tenant compte du bilan d'audience, le centre de programmation CP modifie la grille de programmation de la source S afin de l'adapter aux profils audiovisuels des terminaux récepteurs Ti. Ainsi, le centre CP peut changer les plages horaires de diffusion de certains contenus audiovisuels, par exemple de publicités, en ciblant de façon plus précise l'audience susceptible d'être intéressée par ces contenus. Dans une étape 8, afin de diminuer le nombre de rapports reçus, le serveur SC transmet aux terminaux Ti une commande de modification de la période d'envoi des rapports d'audience, avec l'indication d'une nouvelle période'supérieure à la période. Sur réception de cette commande, chaque terminal Ti remplace l'ancienne période T par la nouvelle période T'en mémoire. De la même manière, le serveur SC pourrait diminuer la période d'envoi des rapports d'audience afin de recueillir davantage de rapports. Le serveur de collecte SC peut être utilisé par une pluralité de sources de diffusion S. Dans ce cas, les différentes sources S diffusant des contenus vers différents groupes multiast de terminaux récepteurs respectivement, l'ensemble des terminaux récepteurs appartenant aux différents groupes multiast font remonter les rapports d'audience vers le même serveur collecte SC, lequel élabore un bilan d'audience pour chaque source S et le transmet au centre de programmation CP dont dépend la source S considérée. Dans la description qui précède, on insère les données descriptives associées à la source S dans un fichier SDP et les terminaux récepteurs Ti récupèrent ce fichier SDP par téléchargement depuis un site Web SW. Les terminaux pourraient récupérer les données descriptives associées à la source par tout autre moyen. On pourrait par exemple insérer ces données descriptives dans un courrier électronique, ou"mail", envoyé au terminal Ti. Dans une autre variante de réalisation de l'invention, on diffuse les caractéristiques du serveur de collecte à travers un canal de signalisation associé à la source. Dans ce cas, lorsqu'un terminal souhaite recevoir le contenu diffusé par la source de diffusion, il récupère au préalable les informations utiles pour recevoir le canal de signalisation associé à la source, par exemple par téléchargement depuis un site Web, puis se met en réception de ce canal de signalisation afin d'acquérir les données descriptives associées à la source, contenant des informations utiles pour se mettre en réception de cette source ainsi que les caractéristiques du serveur de collecte contenues dans le champ"q"précédemment décrit. Le fichier descriptif contenant toutes les informations requises pour se mettre en réception de la source pourrait avoir un format autre que le format SDP, par exemple le format XML. L'invention pourrait s'appliquer à la diffusion d'un contenu multimédia autre qu'audiovisuel, à travers un réseau informatique autre que l'Internet. Elle pourrait également s'appliquer à la diffusion en unicast. REVENDICATIONS 1. Procédé de diffusion en temps réel d'un contenu à partir d'une source (S) vers une pluralité de terminaux récepteurs (Ti), à travers un réseau informatique, dans lequel chaque terminal (Ti) récupère des données descriptives associées à la source (S), la source (S) diffuse le contenu à travers le réseau et les terminaux récepteurs (Ti) acquièrent le contenu diffusé, à partir desdites données descriptives, procédé caractérisé par le fait qu'on insère dans lesdites données descriptives une adresse d'un serveur de collecte (SC) et, à partir desdites données descriptives, chaque terminal (Ti) signale qu'il est en réception par l'envoi d'un rapport d'audience à ladite adresse. 2. Procédé selon la revendication 1, dans lequel on insère dans lesdites données descriptives une information de périodicité de façon à ce que chaque terminal récepteur (Ti) envoie périodiquement un rapport d'audience au serveur de collecte (SC). 3. Procédé selon l'une des revendications 1 et 2, dans lequel chaque terminal (Ti) insère dans le rapport d'audience au moins l'une des informations du groupe contenant une indication géographique de localisation, une langue préférée et une information de qualité de réception. 4. Procédé selon l'une des revendications 1 à 3, dans lequel le serveur de collecte (SC) attribue une information d'horodatage à chaque rapport d'audience reçu. 5. Procédé selon l'une des revendications 1 à 4, dans lequel le serveur de collecte (SC) élabore un bilan d'audience, à partir des rapports d'audience des terminaux (Ti). 6. Procédé selon l'une des revendications 1 à 5, dans lequel, une pluralité de sources diffusant des contenus vers une pluralité de groupes de terminaux récepteurs (Ti), l'ensemble des terminaux appartenant aux différents groupes envoient des rapports d'audience vers le même serveur de collecte (SC). 7. Procédé selon l'une des revendications 1 à 6, dans lequel on insère également dans lesdites données descriptives au moins l'une des informations du groupe contenant l'indication du réseau du serveur de collecte (SC), le type d'adresse du serveur de collecte (SC) et l'indication d'un port de réception des rapports. 8. Procédé selon l'une des revendications 1 à 7, dans lequel le serveur de collecte (SC) transmet aux terminaux récepteurs (Ti) une nouvelle information de périodicité afin de modifier la périodicité d'envoi des rapports d'audience. 9. Procédé selon l'une des revendications 1 à 8, dans lequel on insère les données descriptives associées à la source dans un fichier SDP. 10. Procédé selon l'une des revendications 1 à 9, dans lequel on diffuse l'adresse du serveur de collecte à travers un canal de signalisation associé à la source. 11. Serveur de collecte pour la mise en oeuvre du procédé de la revendication 1, comprenant des moyens (91) pour recevoir des rapports d'audience d'au moins une source de diffusion (S), des moyens (92) de traitement agencés pour élaborer un bilan d'audience à partir des rapports d'audience reçus et des moyens (93) pour émettre ledit bilan vers un centre de programmation (CP) associé à ladite source (S). 12. Serveur selon la revendication 11, dans lequel il est prévu des moyens (92) pour horodater les rapports. 13. Serveur selon l'une des revendications 11 et 12, dans lequel il est prévu des moyens (95) pour modifier la périodicité d'envoi des rapports d'audience.