FR 3124675 A1 20221230 FR 2106700 A 20210623 Gestion d’une audioconférence audio et/ou vidéo La présent invention vise un procédé mis en œuvre par un premier terminal client (T1) lors d’une conférence audio et/ou vidéo en coopération avec un serveur de conférence (SV1) gérant des échanges de flux de données audio (FX), le procédé comprenant : obtention d’un flux de données audio marquées par intégration d’un code de marquage numérique (WT1) par tatouage numérique; envoi du flux de données audio marquées au serveur de conférence (SV1) ; réception en provenance du serveur de médiation (SV1) de données de capacité audio (DTA) représentatives de si un deuxième terminal client (T2) a détecté le code de marquage numérique (WT1) dans un flux de données audio (FX) ; et déclenchement à partir des données de capacité audio (DTA) reçues d’au moins une action de gestion de la conférence audio et/ou vidéo, comprenant une restitution d’informations fonction des données de capacité audio reçues. Figure pour l’abrégé : Fig. 1. Gestion d’une audioconférence audio et/ou vidéo L'invention se rapporte au domaine de l’audioconférence et de la visioconférence, et concerne plus particulièrement la capacité d’un utilisateur à être entendu ou non par un autre utilisateur lors d’audioconférence ou visioconférence. Les systèmes de visioconférence ou audioconférence ont connu un essor important ces dernières années et cette tendance s’est encore amplifiée dans le contexte sanitaire actuel. De façon bien connue, une audioconférence (ou conférence audio) permet à des participants de communiquer par audio de façon instantanée tandis qu’une visioconférence (ou conférence vidéo) permet non seulement de communiquer par audio mais aussi par image de façon instantanée. Autrement dit, lors d’une visioconférence, des flux vidéo sont échangés entre les terminaux des participants afin que chacun puisse voir et entendre ses interlocuteurs. Lors d’une conférence audio, des flux audio sont échangés sans qu’il n’y ait de flux image. Les conférences de communication, de type audioconférence et vidéoconférence, sont des solutions permettant à plusieurs participants de communiquer ensemble de façon efficace au moyen de terminaux clients. Cependant, ces outils sont parfois délicats à utiliser pour les non-initiés et des problèmes techniques empêchent régulièrement les participants de profiter d’une bonne expérience utilisateur. En particulier, un problème récurrent se pose en ce qu’il n’est pas toujours possible pour un participant de savoir s’il est, ou va être, bien entendu par d’autres participants au cours d’une conférence audio ou vidéo. Cette incertitude pousse souvent les participants à demander auprès de leurs interlocuteurs s’ils sont bien entendu de tous, ce qui peut apporter de la confusion, une gêne pour les participants (perte de temps, etc.), et cette méthode n’apporte pas l’assurance que tous les participants entendent effectivement bien le locuteur en question, en particulier quand un nombre important d’utilisateurs participe à la conférence. Ces problèmes de bonne réception audio posent un défi dans la mesure où de nombreux problèmes techniques sont susceptibles d’empêcher un participant d’être bien entendu par ses interlocuteurs (problèmes de configuration, problèmes matériels, mauvaises utilisations des outils…). Les contraintes et limites techniques évoquées ci-dessus peuvent par conséquent dégrader l’expérience utilisateur et limiter l’intérêt de ces outils de communication pour certains utilisateurs ou dans certains contextes. A cet effet, la présente invention concerne un premier procédé mis en œuvre par un premier terminal client lors d’une session de communication en coopération avec un serveur de conférence audio et/ou vidéo gérant des échanges de flux de données audio entre le premier terminal client et au moins un deuxième terminal client au cours d’une conférence audio et/ou vidéo, le procédé comprenant : a) obtention d’un flux de données audio marquées par intégration d’un code de marquage numérique dans un premier flux de données audio par tatouage numérique; b) envoi du flux de données audio marquées au serveur de conférence audio et/ou vidéo ; c) réception, en provenance d’un serveur de médiation, de données de capacité audio représentatives de si ledit au moins un deuxième terminal client a détecté le code de marquage numérique dans un flux de données audio reçues du serveur de conférence audio et/ou vidéo ; et d) déclenchement d’au moins une action de gestion de la conférence audio et/ou vidéo à partir des données de capacité audio reçues, ladite au moins une action de gestion comprenant : restitution, par une interface utilisateur du premier terminal client, d’informations, fonction des données de capacité audio reçues, indiquant si ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio du premier terminal client. Comme déjà indiqué, il n’est pas toujours aisé pour un utilisateur participant à une conférence audio et/ou vidéo de savoir s’il est, ou s’il va être, bien entendu des autres participants lorsqu’il parle ou qu’il s’apprête à parler lors d’une conférence audio et/ vidéo. Divers problèmes matériels, logiciels ou autres sont susceptibles de faire obstacle à une bonne transmission d’un flux audio depuis le terminal client du locuteur considéré vers les terminaux clients d’autres participants. L’usage dans l’invention de la technique de marquage numérique (dit « watermarking ») permet de tester de façon fiable et robuste la capacité de terminaux clients à recevoir des flux de données audio en provenance d’un terminal client donné au cours d’une conférence audio et/ou vidéo. L’invention permet ainsi de limiter les risques qu’un utilisateur parle sans être entendu par un autre participant à la conférence audio et/ou vidéo. Selon un mode de réalisation particulier, l’obtention a) comprend : e) envoi à un serveur de médiation d’une requête de code de marquage numérique, ladite requête comprenant un identifiant du premier terminal client; f) réception, en réponse à ladite requête, du code de marquage numérique attribué au premier terminal client. Selon un mode de réalisation particulier, le premier procédé comprend : détermination, lors d’un établissement de la session de communication, d’un identifiant de la conférence audio et/ou vidéo ; et insertion dans la requête de code de marquage numérique de l’identifiant de la conférence audio avant envoi au serveur de médiation, de sorte à permettre audit serveur de médiation d’enregistrer le code de marquage numérique en association avec l’identifiant du premier terminal client et l’identifiant de la conférence audio et/ou vidéo. L’usage d’un identifiant de la conférence audio et/ou vidéo peut permettre notamment au serveur de médiation de reconnaître une requête associée à la conférence audio et/ou vidéo en cours, et ainsi d’obtenir ou générer un code de marquage numérique unique pour le premier terminal client. Le serveur de médiation peut en particulier superviser un test de réception de flux audio pour une pluralité de conférence audio et/ou vidéo distinctes, y compris lorsque le premier terminal client T1 participe à plusieurs conférences simultanément ou successivement sur une période donnée. Selon un mode de réalisation particulier, le premier flux de données audio est généré à partir de signaux acoustiques acquis par un premier microphone couplé au premier terminal client. Il est ainsi possible de réaliser un test audio tout en transmettant des sons depuis le premier terminal client vers le deuxième terminal client lors de la conférence audio et/ou vidéo. Selon un mode de réalisation particulier, les signaux acoustiques à partir desquels est généré le premier flux de données audio représentent un bruit de fond acquis par le premier microphone, l’intensité du bruit de fond étant inférieure à une première valeur d’intensité. Il est ainsi possible de réaliser un test audio alors que l’utilisateur du premier terminal client est silencieux (ne parle pas) pendant la conférence en cours. Selon un mode de réalisation particulier, l’envoi de la requête de code de marquage numérique est déclenché sur détection, au moyen du premier microphone du premier terminal client, d’une période de silence d’une durée au moins égale à une première durée, au cours de laquelle un bruit de fond d’une intensité inférieure à ladite première valeur d’intensité est détecté. Il est ainsi possible de déclencher automatiquement un test audio lorsque l’utilisateur du premier terminal client est silencieux (ne parle pas) lors de la conférence en cours. Selon un mode de réalisation particulier, l’envoi de la requête de code de marquage numérique est déclenché sur détection que le premier microphone est désactivé pendant au moins une deuxième durée. Selon un mode de réalisation particulier, le premier flux de données audio est généré par émulation d’un bruit aléatoire. Il est ainsi possible de réaliser un test audio de façon fiable et robuste, indépendamment de tout flux de données audio susceptibles d’être émis par le premier terminal client lors la conférence en cours. Selon un mode de réalisation particulier, aux moins certaines des étapes a)-d) sont réitérées pendant ladite session de communication, de façon à vérifier plusieurs fois (par exemple périodiquement) si ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio émises par le premier terminal client. Il est ainsi possible de vérifier sur une période donnée, de façon répétée (périodiquement ou régulièrement) ou continue, si le deuxième terminal client est apte à recevoir un flux de données audio émis par le premier terminal client lors de la conférence en cours. Selon un mode de réalisation particulier, si les données de capacité audio reçues représentent que ledit au moins un deuxième terminal client a détecté le code de marquage numérique dans un flux de données audio reçues en provenance du serveur d’audioconférence, alors les informations restituées par l’interface utilisateur indiquent que ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio émises par le premier terminal client. L’utilisateur du premier terminal client peut ainsi s’assurer qu’il est ou sera bien entendu lors de la conférence en cours. Selon un mode de réalisation particulier, le premier terminal client envoie au serveur de médiation une notification informant de l’envoi b) du flux de données marquées au serveur de conférence audio et/ou vidéo. Il est ainsi possible pour le serveur de médiation d’être informé lorsqu’un test audio est initié par le premier terminal client. A partir de cette notification, le serveur de médiation peut en particulier déterminer s’il reçoit une notification depuis le deuxième terminal client, indiquant que ce dernier a détecté le code de marquage numérique. Selon un mode de réalisation particulier, ladite au moins une action de gestion comprend : si les données de capacité audio reçues représentent que ledit au moins un deuxième terminal client n’a pas détecté le code de marquage numérique dans le flux de données audio mixées reçu en provenance du serveur d’audioconférence, changement d’une configuration audio du premier terminal client. Il est ainsi possible pour le premier terminal client d’adapter sa configuration lorsqu’un problème de réception de flux audio est détecté, et donc améliorer les chances que l’utilisateur du premier terminal client soit entendu par le deuxième terminal client lors de la conférence. Selon un mode de réalisation particulier, le premier procédé comprend, successivement pour chacune parmi une pluralité de configurations audio, tant qu’une première condition audio n’est pas satisfaite : configuration du premier terminal client selon ladite configuration audio; et réitération d’au moins certaines des étapes a)-d). Selon un mode de réalisation particulier, le premier procédé comprend, avant l’envoi b) du flux de données audio marquées au serveur conférence audio et/ou vidéo : activation du premier microphone du premier terminal client ; désactivation d’une fonction d’annulation d’écho de sorte à permettre une acquisition acoustique par le premier microphone du premier terminal client d’une émission acoustique d’un premier haut-parleur couplé audit au moins un premier terminal client ; génération d’un signal acoustique de test au moyen du premier haut-parleur ; acquisition acoustique, au moyen du premier microphone, du signal acoustique de test émis par le premier haut-parleur ; et détermination, à partir d’un résultat de ladite acquisition acoustique, de donnés de capacités acoustiques caractérisant des capacités acoustiques du premier microphone ; dans lequel les informations restituées en d) par l’interface utilisateur sont en outre représentatives des capacités acoustiques du premier microphone du premier terminal client. Il est ainsi possible de tester la chaîne de traitement acoustique au niveau du premier terminal client. Selon un mode de réalisation particulier, le premier procédé comprend en outre : réception, en provenance du serveur de médiation, de données de capacité acoustique représentatives de capacités acoustiques d’un deuxième haut-parleur couplé audit au moins un deuxième terminal client à produire une sortie acoustique ; les informations restituées en d) par l’interface utilisateur étant en outre représentatives des capacités acoustiques du deuxième haut-parleur du deuxième terminal client. L’utilisateur du premier terminal client peut ainsi être informé de la capacité de la chaîne de traitement acoustique du premier terminal client à produire une émission (sortie) acoustique. L’invention concerne également un deuxième procédé mis en œuvre par un deuxième terminal client lors d’une session de communication en coopération avec un serveur de conférence audio et/ou vidéo gérant des échanges de flux de données audio entre un premier terminal client et le deuxième terminal client au cours d’une conférence audio et/ou vidéo, le procédé comprenant : g) réception, en provenance du serveur de conférence audio et/ou vidéo, d’un flux de données audio marquées ; h) détection, dans le flux audio marquées, d’un code de marquage numérique intégré dans le flux de données audio marquées par tatouage numérique ; et i) envoi, à un serveur de médiation, d’une notification indiquant la détection du code de marquage numérique, ladite notification comprenant le code de marquage numérique en association avec un identifiant du deuxième terminal client. L’envoi au serveur de médiation de ladite notification permet audit serveur de générer des données de capacité audio indiquant si le deuxième terminal client a détecté le code de marquage numérique. Le serveur de médiation peut notamment transmettre ces données de capacité audio au premier terminal client afin de lui indiquer si le deuxième terminal client est apte ou non à recevoir un flux audio émis par le premier terminal client lors de la conférence. Selon un mode de réalisation particulier, le deuxième procédé comprend en outre, en réponse à la détection h) : activation d’un deuxième microphone couplé au deuxième terminal client ; désactivation d’une fonction d’annulation d’écho de sorte à permettre une acquisition acoustique par le deuxième microphone d’une émission acoustique d’un deuxième haut-parleur couplé audit deuxième terminal client ; génération d’un signal acoustique de test au moyen du deuxième haut-parleur ; acquisition acoustique, au moyen du deuxième microphone, du signal acoustique de test émis par le deuxième haut-parleur ; détermination, à partir d’un résultat de ladite acquisition acoustique, de capacités acoustiques du deuxième haut-parleur du deuxième terminal client à produire une émission acoustique ; et envoi au serveur de médiation des capacités acoustiques du deuxième haut-parleur. Il est ainsi possible de tester la chaîne de traitement acoustique au niveau du deuxième terminal client. L’invention vise également un troisième procédé mis en œuvre par un système, comprenant un premier terminal client et un deuxième terminal client exécutant respectivement les premier et deuxième procédés définis ci-avant et décrits dans des exemples particuliers ci-après. Plus particulièrement, l’invention vise un troisième procédé mis en œuvre par un système client, comprenant un premier terminal client et un deuxième terminal client, lors d’une session de communication en coopération avec un serveur de conférence audio et/ou vidéo gérant des échanges de flux de données audio entre le premier terminal client et le deuxième terminal client au cours d’une conférence audio et/ou vidéo, dans lequel le premier terminal exécute un premier procédé tel que défini ci-avant ; dans lequel le deuxième terminal exécute un deuxième procédé tel que défini ci-avant ; les informations restituées en d) par le premier terminal client indiquant que le deuxième terminal client est apte à recevoir un flux de données audio émis par le premier terminal client. Selon un mode de réalisation particulier, le troisième procédé comprend en outre (par exemple en réponse à la détection h), les étapes suivantes mises en œuvre par ledit deuxième terminal client : activation d’un deuxième microphone couplé au deuxième terminal client ; désactivation d’une fonction d’annulation d’écho de sorte à permettre une acquisition acoustique par le deuxième microphone d’une émission acoustique d’un deuxième haut-parleur couplé audit deuxième terminal client ; génération d’un signal acoustique de test au moyen du deuxième haut-parleur ; acquisition acoustique, au moyen du deuxième microphone, du signal acoustique de test émis par le deuxième haut-parleur ; détermination, à partir d’un résultat de ladite acquisition acoustique, de capacités acoustiques du deuxième haut-parleur du deuxième terminal client à produire une sortie acoustique ; et envoi au serveur de médiation des capacités acoustiques du deuxième haut-parleur ; le procédé comprenant en outre l’étape suivante mise en œuvre par le premier terminal client : réception, en provenance du serveur de médiation, de données de capacité acoustique représentatives desdites capacités acoustiques du deuxième haut-parleur du deuxième terminal client ; les informations restituées en d) par le premier terminal client étant en outre représentatives des capacités acoustiques du deuxième haut-parleur du deuxième terminal client. L’invention vise également un quatrième procédé mis en œuvre par un serveur de médiation en coopération avec une pluralité de terminaux clients (comprenant un premier terminal client et un deuxième terminal client) participant à une conférence audio et/ou vidéo au cours de laquelle des flux de données audio sont échangés via un serveur de conférence audio et/ou vidéo, le procédé comprenant : j) envoi à un premier terminal client d’un code de marquage numérique attribué au premier terminal client et enregistré, dans des données de marquage dudit serveur de médiation, en association avec un identifiant du premier terminal client ; k) détermination, à partir des données de marquage, de si une notification indiquant qu’un deuxième terminal client a détecté le code de marquage numérique est reçue en provenance dudit deuxième terminal client, ladite notification comprenant le code de marquage numérique en association avec un identifiant du deuxième terminal client ; l) détermination, à partir d’un résultat de la détermination k), de données de capacité audio indiquant si le deuxième terminal client est apte à recevoir un flux de données audio en provenance du premier terminal client ; et m) envoi au premier terminal client des données de capacité audio. Le serveur de médiation est ainsi capable de superviser le test audio initié par le premier terminal client pour évaluer si le deuxième terminal client est apte à recevoir un flux de données audio émis par le premier terminal client lors de la conférence. Selon un mode de réalisation particulier, il est déterminé en k) une absence de réception de ladite notification si aucune dite notification, indiquant que le deuxième terminal client a détecté le code de marquage numérique, n’est reçue dans un premier délai à compter d’un instant de référence. Le serveur de médiation est ainsi en mesure de déterminer que le deuxième terminal client n’a pas détecté le code de marquage numérique si ledit serveur de médiation ne reçoit pas de notification en ce sens du deuxième terminal client. Selon un mode de réalisation particulier, le serveur de médiation exécute les étapes j) à m) pour une pluralité de deuxièmes terminaux clients, de sorte à envoyer en m) au premier terminal client des données de capacité audio de chacun de la pluralité de deuxièmes terminaux clients. Le serveur de médiation peut ainsi superviser des tests audio initiés par le premier terminal client de sorte à évaluer si une pluralité de deuxièmes terminaux client participant à la conférence sont aptes à recevoir un flux de données audio émis par le premier terminal client. Selon un mode particulier de réalisation, les différentes étapes des premier, deuxième procédé, troisième et quatrième procédés tels que définis ci-avant, et tels décrits ci-après dans des exemples particuliers, sont déterminées par des instructions de programmes d’ordinateurs. En conséquence, l’invention vise aussi des programmes d’ordinateur sur des supports d’informations (ou support d’enregistrement), ces programme étant susceptibles d’être mis en œuvre dans des terminaux ou dans des serveurs, ou plus généralement dans des ordinateurs, ces programmes comportant des instructions adaptées à la mise en œuvre respectivement des étapes des premier, deuxième, troisième et quatrième procédés. Ainsi, chacun des procédés de l’invention peut être implémenté au moyen d’une mémoire non volatile stockant des instructions de programmes d’ordinateur et d’un processeur exécutant ces instructions. Selon un mode de réalisation, les différents procédés de l'invention sont mis en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel peut être exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. La présente invention vise également un premier terminal client (et respectivement un deuxième terminal client) configuré pour mettre en œuvre le premier procédé (et respectivement le deuxième procédé) de l’invention tel que défini ci-avant et décrit ci-après dans des exemples particuliers. La présente invention vise également un système comprenant les premier et deuxième terminaux clients de l’invention, configuré pour mettre en œuvre le troisième procédé de l’invention. La présente invention vise également un serveur de médiation configuré pour mettre en œuvre le quatrième procédé de l’invention tel que défini ci-avant et décrit ci-après dans des exemples particuliers. A noter que les différents modes de réalisation mentionnés ci-avant (ainsi que ceux décrits ci-après) en relation avec les différents procédés de l’invention ainsi que les avantages associés s’appliquent de façon analogue aux terminaux clients, système et serveur de médiation de l’invention. Pour chaque étape des procédés de l’invention, le dispositif associé de l’invention (terminal client ; système, serveur de médiation) peut comprendre un module correspondant configuré pour réaliser ladite étape. D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures: La représente schématiquement un environnement comprenant des terminaux clients et un serveur de médiation, selon un mode de réalisation particulier de l’invention ; La représente schématiquement un premier terminal client selon au moins un mode de réalisation de l’invention ; La représente schématiquement un deuxième terminal client selon au moins un mode de réalisation de l’invention ; La représente schématiquement un serveur de médiation selon au moins un mode de réalisation de l’invention ; La représente, sous forme d'un diagramme, les étapes de procédés mis en œuvre par des terminaux clients et par un serveur de médiation, selon certains modes de réalisation de l'invention ; La représente, sous forme d'un diagramme, les étapes de procédés mis en œuvre par des terminaux clients et par un serveur de médiation, selon certains modes de réalisation de l'invention ; La représente, sous forme d'un diagramme, les étapes d’un procédé mis en œuvre par un premier terminal client, selon au moins un mode de réalisation de l'invention ; et La représente, sous forme d'un diagramme, les étapes d’un procédé mis en œuvre par un deuxième terminal client, selon au moins un mode de réalisation de l'invention. Procédé mis en œuvre par un premier terminal client (T1) lors d’une session de communication en coopération avec un serveur de conférence audio et/ou vidéo (SV1) gérant des échanges de flux de données audio (FX) entre le premier terminal client et au moins un deuxième terminal client (T2-T4) au cours d’une conférence audio et/ou vidéo, le procédé comprenant : a) obtention (B4) d’un flux de données audio marquées par intégration d’un code de marquage numérique (WT1) dans un premier flux de données audio par tatouage numérique; b) envoi (B6) du flux de données audio (FX1) marquées au serveur de conférence audio et/ou vidéo ; c) réception (B8), en provenance d’un serveur de médiation (SV2), de données de capacité audio (DTA) représentatives de si ledit au moins un deuxième terminal client a détecté le code de marquage numérique dans un flux de données audio reçues du serveur de conférence audio et/ou vidéo ; et d) déclenchement (B22) d’au moins une action de gestion de la conférence audio et/ou vidéo à partir des données de capacité audio reçues, ladite au moins une action de gestion comprenant : restitution, par une interface utilisateur du premier terminal client, d’informations (IF1), fonction des données de capacité audio reçues, indiquant si ledit au moins un deuxième terminal client est apte à recevoir un flux de données audio du premier terminal client. Procédé selon la revendication 1, dans lequel l’obtention a) comprend : e) envoi (B42) à un serveur de médiation d’une requête (RQ1) de code de marquage numérique, ladite requête comprenant un identifiant du premier terminal client; f) réception (B46), en réponse à ladite requête, du code de marquage numérique (WT1) attribué au premier terminal client. Procédé selon la revendication 1 ou 2, dans lequel le premier flux de données audio est généré à partir de signaux acoustiques acquis par un premier microphone (MIC1) couplé au premier terminal client. Procédé selon la revendication 3, dans lequel les signaux acoustiques à partir desquels est généré le premier flux de données audio représentent un bruit de fond acquis par le premier microphone, l’intensité du bruit de fond étant inférieure à une première valeur d’intensité. Procédé selon la revendication 1 ou 2, dans lequel le premier flux de données audio est généré par émulation d’un bruit aléatoire. Procédé selon l’une quelconque des revendications 1 à 5, comprenant, avant l’envoi b) du flux de données audio marquées (FX1) au serveur conférence audio et/ou vidéo (SV1) : activation (B80) du premier microphone (MIC1) du premier terminal client ; désactivation (B82) d’une fonction d’annulation d’écho (F1) de sorte à permettre une acquisition acoustique par le premier microphone du premier terminal client d’une émission acoustique d’un premier haut-parleur couplé audit au moins un premier terminal client ; génération (B84) d’un signal acoustique de test (SA1) au moyen du premier haut-parleur (HP1) ; acquisition acoustique (B86), au moyen du premier microphone, du signal acoustique de test émis par le premier haut-parleur ; et détermination (B88), à partir d’un résultat de ladite acquisition acoustique, de donnés de capacités acoustiques (DTB1) caractérisant des capacités acoustiques du premier microphone ; dans lequel les informations (IF1) restituées en d) par l’interface utilisateur sont en outre représentatives des capacités acoustiques du premier microphone du premier terminal client. Procédé mis en œuvre par un deuxième terminal client (T2) lors d’une session de communication en coopération avec un serveur de conférence audio et/ou vidéo (SV1) gérant des échanges de flux de données audio (FX) entre un premier terminal client (T1) et le deuxième terminal client (T2) au cours d’une conférence audio et/ou vidéo, le procédé comprenant : g) réception (C8), en provenance du serveur de conférence audio et/ou vidéo, d’un flux de données audio marquées (FX2) ; h) détection (C10), dans le flux audio marquées, d’un code de marquage numérique (WT1) intégré dans le flux de données audio marquées par tatouage numérique ; et i) envoi (C12), à un serveur de médiation (SV2), d’une notification (NF1) indiquant la détection du code de marquage numérique, ladite notification comprenant le code de marquage numérique (WT1) en association avec un identifiant (ID2) du deuxième terminal client. Procédé selon la revendication 7, comprenant en outre, en réponse à la détection h) : activation (C100) d’un deuxième microphone (MIC2) couplé au deuxième terminal client ; désactivation (C102) d’une fonction d’annulation d’écho (F2) de sorte à permettre une acquisition acoustique par le deuxième microphone d’une émission acoustique d’un deuxième haut-parleur (HP2) couplé audit deuxième terminal client ; génération (C104) d’un signal acoustique de test (SA2) au moyen du deuxième haut-parleur ; acquisition acoustique (C106), au moyen du deuxième microphone, du signal acoustique de test émis par le deuxième haut-parleur ; détermination (C108), à partir d’un résultat de ladite acquisition acoustique, de capacités acoustiques (DTB2) du deuxième haut-parleur du deuxième terminal client à produire une émission acoustique ; et envoi au serveur de médiation (SV2) des capacités acoustiques du deuxième haut-parleur. Procédé de médiation mis en œuvre par un serveur de médiation (SV2) en coopération avec une pluralité de terminaux clients (T1-T4) participant à une conférence audio et/ou vidéo au cours de laquelle des flux de données audio (FX) sont échangés via un serveur de conférence audio et/ou vidéo (SV1), le procédé comprenant : j) envoi (D2) à un premier terminal client (T1) d’un code de marquage numérique (WT1) attribué au premier terminal client et enregistré, dans des données de marquage (DM) dudit serveur de médiation, en association avec un identifiant (ID1) du premier terminal client ; k) détermination (D14), à partir des données de marquage, de si une notification (NF1) indiquant qu’un deuxième terminal client (T2) a détecté le code de marquage numérique est reçue en provenance dudit deuxième terminal client, ladite notification comprenant le code de marquage numérique en association avec un identifiant (ID2) du deuxième terminal client ; l) détermination (D16), à partir d’un résultat de la détermination k), de données de capacité audio (DTA2) indiquant si le deuxième terminal client (T2) est apte à recevoir un flux de données audio en provenance du premier terminal client ; et m) envoi au premier terminal client (T1) des données de capacité audio (DTA2). Procédé selon la revendication 9, dans lequel il est déterminé (D14 ; D64) en k) une absence de réception de ladite notification (NF1) si aucune dite notification, indiquant que le deuxième terminal client (T2) a détecté le code de marquage numérique (WT1), n’est reçue dans un premier délai à compter d’un instant de référence.