FR 3145456 A1 20240802 FR 2300862 A 20230131 Procédé de gestion d’un test de la qualité d’une liaison de communication téléphonique L’invention se rapporte à un procédé de gestion d’un test (TST) de la qualité d’une liaison (L) de communication téléphonique entre un terminal (TER) et un serveur de test (SRV), la liaison (L) de communication téléphonique pouvant être ouverte ou fermée, le test (TST) étant réalisé lorsque la liaison (L) est ouverte, caractérisé en ce que, durant la réalisation du test (TST) de la qualité de la liaison (L), ladite liaison (L) est maintenue ouverte indépendamment de la réception d’une instruction (RAC) de fermeture de la liaison (L) par le terminal (TER) pendant une durée donnée au moins égale à la durée nécessaire à l’achèvement du test (TST) réalisé par le serveur de test (SRV). Figure 1 Procédé de gestion d’un test de la qualité d’une liaison de communication téléphonique Le domaine technique est celui de la téléphonie fixe et en particulier de la téléphonie IP, c’est-à-dire des liaisons téléphoniques fixes se faisant grâce au protocole IP (acronyme de l’anglais Internet Protocol ). Plus précisément, l’invention se rapporte à un procédé de gestion d’un test de la qualité d’une liaison de communication téléphonique. Le plus souvent, le procédé selon l’invention sera un procédé de gestion d’un test de la qualité d’une liaison de communication téléphonique IP. Les liaisons téléphoniques fixes se font dorénavant en général en utilisant des plates-formes de téléphonie utilisant le protocole IP pour transmettre le signal vocal entre postes téléphoniques. On parle alors de téléphonie sur IP, ou également de voix sur IP. Le terme de téléphonie VoIP (acronyme de l’anglais Voice over IP ) est également utilisé. Les anciens protocoles de téléphonie fixe, tels que le RTC (acronyme de Réseau Téléphonique Commuté ) ou le RNIS (acronyme de Réseau Numérique à Intégration de Services ) sont en cours d’abandon. En téléphonie, on appelle généralement terminal le téléphone qui est au point terminal de la liaison de communication téléphonique et qui va permettre aux utilisateurs de communiquer entre eux. Les postes téléphoniques permettant de communiquer en téléphonie sur IP sont des équipements dédiés appelés téléphones IP. Ces téléphones IP peuvent établir des sessions de communication IP avec d’autres téléphones IP en requêtant des plates-formes de téléphonie sur IP. Une fois la session établie entre deux téléphones IP, un canal de communication est établi et la voix est transmise entre les deux téléphones IP par le protocole IP. Parfois, le téléphone fixe ne se connecte pas directement au réseau IP, mais est présent dans un réseau local et se connecte à une passerelle domestique qui va établir la communication téléphonique IP. On parle en général de terminal IP pour recouvrir les deux cas distincts d’un téléphone pouvant utiliser directement le protocole IP et d’une passerelle domestique qui sert de relais à un téléphone présent dans son réseau local. La liaison entre la passerelle domestique qui sert de terminal IP et le téléphone fixe se fait en général avec une liaison DECT (acronyme de l’anglais Digital Enhanced Cordless Telecommunications ). L’établissement de la communication téléphonique IP se fait en général en utilisant le protocole SIP (acronyme de l’anglais Session Initiation Protocol ) qui est un protocole généraliste permettant d’établir des sessions de communication. Des versions précédentes de téléphonie sur IP utilisaient le protocole ad hoc H.323. Les plates-formes de téléphonie sur IP servent également de passerelles pour permettre aux téléphones IP et aux terminaux IP d’accéder à des terminaux appartenant à d’autres réseaux de téléphonie, en particulier les réseaux de téléphonie fixe traditionnels ou bien les réseaux de téléphonie mobiles. Etat de la technique Un des besoins des opérateurs de services de téléphonie est de pouvoir tester la qualité des lignes téléphoniques, et en particulier la partie des lignes téléphoniques qui se trouve entre les domiciles des clients et les premiers équipements du réseau de téléphonie. En effet, ces parties des lignes téléphoniques se trouvant en partie sur des terrains privés ne sont pas facilement accessibles aux employés des services de téléphonie. L’inspection de ces parties de lignes nécessite une prise de rendez-vous. Un client qui constate une mauvaise qualité de sa liaison téléphonique va donc contacter son opérateur de téléphonie qui va planifier une intervention avec un technicien qui procèdera aux tests de la liaison téléphonique et devra a priori se déplacer, ce qui entraîne un coût important ainsi que des délais avant de disposer du résultat des tests. Il existe donc un besoin de pouvoir tester à distance la qualité d’une telle ligne. Dans le cas des anciens réseaux de téléphonie fixe, tels que le RTC, il existe une technique bien connue de test à distance des lignes téléphoniques. Cette technique de test à distance s’appuie sur les propriétés de propagation des ondes électriques dans un support en cuivre, qui est le support le plus largement utilisé dans le réseau RTC. En exploitant notamment le phénomène d’écho bien connu des ondes électriques dans ce type de support, il est ainsi possible pour un opérateur téléphonique de tester à distance une ligne téléphonique du réseau RTC. Lorsqu’un client se plaint de la qualité de sa ligne téléphonique, un technicien de l’opérateur va pouvoir effectuer un test à distance pour mesurer cette qualité et détecter d’éventuels problèmes. Pour les services de téléphonie IP, de telles propriétés physiques de la ligne téléphonique ne peuvent pas être exploitées pour réaliser un test à distance. Cependant, le brevet français publié sous le numéro 3 063 407 le 31 août 2018 et délivré le 10 septembre 2021 présente un procédé de test à distance d’une telle liaison de communication et un serveur de test associé. Le serveur de test, présent dans le réseau de téléphonie IP émet une requête vers un terminal IP dont la liaison de communication doit être testée. Le serveur de test émet, après établissement de la communication, des paquets de données vers le terminal ce qui lui permet ensuite de calculer des résultats de test et de donner une indication quant à la qualité de la liaison de communication de téléphonie IP. La réalisation du test par le serveur implique que le terminal IP doit accepter l’établissement de la liaison, ce qui implique l’insertion par le serveur de test d’un paramètre spécifique dans la requête émise par le serveur à destination du terminal IP. Le calcul de test peut utiliser la norme G.107 qui fait partie des recommandations de l’UIT-T, c’est-à-dire des recommandations pour le secteur des télécommunications de l’Union Internationale des Télécommunications. Cependant, un tel test étant déclenché par un serveur de test dans le réseau, le procédé décrit ci-dessus implique qu’un client doive contacter le service après-vente de son opérateur téléphonique pour déclencher un test quand il constate un dysfonctionnement de sa ligne. Si le procédé introduit une possibilité de test à distance, il ne permet pas à un client de diagnostiquer l’état de sa ligne de téléphonie IP sans intervention du service après-vente de son opérateur téléphonique. Une telle intervention implique un délai avant d’obtenir une réponse quant à l’état de sa ligne pour le client du service de téléphonie IP et un coût important pour l’opérateur de service de téléphonie IP afin de répondre aux demandes de ses clients. Cet inconvénient dû à la réalisation d’un test à l’initiative d’un serveur présent dans le réseau existe également en téléphonie classique. D’autre part, la réalisation du test suivant la norme G.107 implique que le serveur de test doit disposer d’un certain temps avec la liaison ouverte vers le terminal pour effectuer des tests de qualité. Or, un utilisateur interagissant avec le terminal IP pourrait couper la liaison ouverte avec le serveur avant que le test soit terminé, par exemple en raccrochant un téléphone IP ou un téléphone DECT en lien avec la passerelle domestique qui sert de terminal IP. Cet inconvénient dû au temps pris pour réaliser un test existe également en téléphonie classique. Dans ce cas, si l’utilisateur raccroche le terminal, il peut couper la liaison ouverte avec le serveur avant que le test soit terminé. L’invention vient améliorer la situation. Selon un premier aspect fonctionnel, l’invention a trait à un procédé de gestion d’un test de la qualité d’une liaison de communication téléphonique entre un terminal et un serveur de test, la liaison de communication téléphonique pouvant être ouverte ou fermée, le test étant réalisé par le serveur de test lorsque la liaison est ouverte, caractérisé en ce que, durant la réalisation du test de la qualité de la liaison, ladite liaison est maintenue ouverte indépendamment de la réception d’une instruction de fermeture de la liaison par le terminal pendant une durée donnée au moins égale à la durée nécessaire à l’achèvement du test. Grâce à l’invention, le procédé de gestion de test assure que le test est réalisé complètement par le serveur de test. Un test ici est une session complète d’interaction entre le serveur et le terminal, qui comprend plusieurs étapes, et qui permet d’obtenir tout un ensemble d’informations quant à la qualité de la liaison de communication téléphonique. La réalisation complète d’un tel test s’étale donc sur une certaine durée. La complétion du test nécessite que le serveur réalise des calculs pendant un certain temps. Le maintien de la liaison de communication ouverte pendant une durée donnée permet d’assurer que le test est bien réalisé par le serveur de test. Cet avantage est particulièrement important à mettre en œuvre quand le test est réalisé à l’initiative du terminal. En effet, le test peut être réalisé alors en effectuant un appel vers un numéro dédié opéré par le serveur de test. Il est donc important dans ce cas de s’assurer que le terminal ne raccroche pas avant la complétion des tests. L’invention permet de s’assurer que, même si un utilisateur raccroche avant que les tests soient complets, le terminal maintiendra la liaison ouverte pour s’assurer de la complétion des étapes de test. Selon un premier mode de mise en œuvre particulier de l’invention, si une instruction de fermeture de la liaison est reçue pendant la durée donnée, l’exécution de ladite instruction est repoussée d’une autre durée donnée. Grâce à ce mode de mise en œuvre, l’instruction de fermeture de la liaison est repoussée pendant une durée donnée mais sera bien exécutée ultérieurement. Quand l’instruction de fermeture est une opération de raccrocher effectuée par un utilisateur du terminal, l’avantage de ce mode est que le test sera bien complété, mais l’instruction sera également bien effectuée, même si c’est de façon retardée. Pour peu que le délai nécessaire soit restreint, il est possible que l’utilisateur ne remarque pas le décalage d’exécution de l’instruction de fermeture. Dans un autre mode possible de mise en œuvre de l’invention, l’exécution de l’instruction est annulée. Ce mode a l’avantage de simplifier le traitement des instructions de fermeture reçues par le terminal. Selon un deuxième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent mode, la liaison est une liaison de communication téléphonique IP ouverte entre le terminal et le serveur de test, ladite liaison comprenant un canal de signalisation permettant au serveur de test d’obtenir des informations relatives à la signalisation et la réalisation, par le serveur de test, du test de la qualité de la liaison dépend des informations obtenues relatives à la signalisation. Une liaison de communication téléphonique IP comprend en général deux canaux, un canal permettant d’échanger les informations relatives à la signalisation, et donc à l’établissement de la communication, et un canal de transmission de données multimédia qui permet en particulier d’échanger le signal vocal entre les deux postes IP. C’est ce canal qui permet aux utilisateurs de se parler, leur parole étant transformée en paquets de données IP, et échangée dans les deux sens dans le canal de transmission de données présent dans la liaison de communication téléphonique ouverte. Grâce à ce mode de mise en œuvre, les étapes de test effectuées sont réparties en deux catégories : d’une part, des tests relatifs à la signalisation, et d’autre part des tests relatifs à la transmission des paquets de donnée. Comme le signal de parole est transmis par des paquets de données, le test de la qualité d’une liaison de communication téléphonique IP repose principalement sur les tests relatifs à la transmission de données. Cependant, les tests de signalisation sont également utiles. Un des avantages de ce mode est de pouvoir réaliser un test de qualité en dépendance des informations de signalisation obtenues. Par exemple, les informations de signalisation permettent de connaître le terminal IP à l’initiative du test. Le serveur de test peut alors différencier les tests suivant le terminal à l’origine de l’ouverture de la liaison qui sert au test. Un opérateur de télécommunications pourra par exemple refuser d’exécuter des tests issus de terminaux qui ne font pas partie de ses clients. Ou bien, un opérateur pourra effectuer des tests plus ou moins détaillés selon l’abonnement du client possédant le terminal à l’origine du test. Selon un troisième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, l’ouverture de la liaison est précédée d’une demande d’ouverture de la liaison issue du terminal. Grâce à ce mode de mise en œuvre de l’invention, il est possible de réaliser des tests de qualité de la liaison de communication à l’initiative des clients du service de téléphonie. Le serveur de test peut disposer d’un numéro de téléphone dédié qui sera appelé par un terminal à l’initiative d’un utilisateur, qui composera simplement le numéro. Cette action déclenchera l’ouverture de la liaison de communication entre le terminal et le serveur de test à la suite d’une demande émise par le terminal. L’ouverture de la liaison permettra au serveur de démarrer le test. L’avantage de ce mode est que le test est réalisé à l’initiative des clients, ce qui évite aux clients d’avoir à contacter le service après-vente de l’opérateur du service de téléphonie. Le test se réalise à distance et à l’initiative des clients, ce qui diminue au maximum le besoin de faire intervenir le service après-vente de l’opérateur téléphonique. Ce mode peut être mis en œuvre quand des utilisateurs du terminal appellent un numéro dédié opéré par le serveur de test ; dans ce cas, le terminal est à l’origine de l’ouverture de la liaison de communication, ce qui déclenche l’exécution du test par le serveur. Dans une variante, l’ouverture de la liaison de communication téléphonique se fait par le terminal sans intervention d’un utilisateur. Le terminal est programmé pour réaliser des ouvertures de la liaison vers le serveur de test sans intervention humaine. L’avantage de ce mode est de pouvoir réaliser des tests en préventif, et donc d’anticiper des problèmes éventuels en détectant des dégradations de la qualité de la liaison qui n’auraient pas forcément été détectées par un utilisateur. Dans cette variante, si la liaison est une liaison de communication téléphonique IP, le terminal IP peut être aussi bien un téléphone IP qu’une passerelle domestique. Selon un quatrième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec l’un des modes précédents, la liaison est une liaison de communication téléphonique IP et l’ouverture de la liaison est précédée d’une demande d’ouverture issue d’un téléphone distinct du terminal. Grâce à ce mode de réalisation, l’invention s’adapte au cas, présent en téléphonie IP, où le terminal IP est une passerelle domestique à laquelle des terminaux tels que des téléphones DECT sont rattachés. Dans ce cas, l’utilisateur du téléphone DECT, distinct du terminal IP, va appeler un numéro dédié au serveur de test, et donc créer une demande d’ouverture de la liaison de communication téléphonique. Cette demande sera ensuite issue du terminal IP (la passerelle domestique) vers le serveur IP de test. Le téléphone DECT, qui ne dispose pas d’interface IP, est quand même à l’origine de la demande d’ouverture de la liaison de communication téléphonique. Selon un cinquième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre cumulativement avec l’un des deux modes précédents, la liaison de communication étant une liaison de communication téléphonique IP ouverte entre le terminal et le serveur de test, ladite liaison comprend un canal de transmission de données multimédia et le terminal émet des paquets de données dans ledit canal de transmission de données indépendamment d’instructions reçues au travers d’une interface du terminal. Dans le cas de la téléphonie IP, pour qu’un test de la qualité de la liaison de communication téléphonique IP prenne place, il est nécessaire que des paquets de données soient échangés sur le canal ouvert de transmission de données multimédia. Les calculs nécessaires à la réalisation du test s’appliquent en effet sur l’ensemble des paquets transmis à travers la liaison de communication pendant la durée du test. Or, si le terminal IP est à l’origine de l’ouverture de la liaison, y compris sans intervention d’un utilisateur, il est nécessaire que le terminal IP émette des paquets de données dans le canal de transmission de données et ce même sans action de l’utilisateur aux interfaces du terminal ou, plus clairement, sans que l’utilisateur ne parle dans le téléphone. Ce mode de réalisation permet donc de s’assurer que le test va se dérouler dans de bonnes conditions même en l’absence de l’intervention d’un utilisateur. Selon un sixième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, le procédé de gestion comprend la réception par le terminal, pendant la durée donnée, d’un message issu du serveur de test destiné à être restitué par le terminal. Grâce à ce mode de réalisation, le serveur émet un message qui peut être par exemple un message vocal. Ce message sera restitué par le terminal, par exemple directement sur le haut-parleur du téléphone si le terminal est lui-même un téléphone ou bien, dans le cas d’une liaison de téléphonie IP où le terminal IP est une passerelle domestique, le message sera restitué par le terminal IP vers un téléphone DECT qui restituera ensuite le message vocal sur son propre haut-parleur. La restitution peut également prendre la forme d’une restitution sur un écran. L’avantage de ce mode de réalisation est de restituer un message pendant toute la durée de réalisation du test et donc d’inciter l’utilisateur à rester en ligne ce qui permet d’éviter une action de raccrocher de sa part. Selon un septième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre cumulativement avec le mode précédent, le message reçu par le terminal comprend des informations relatives au test réalisé par le serveur de test. Grâce à ce mode de réalisation, qui complète le mode précédent, le message reçu par le terminal comprend des éléments d’information sur les résultats des différentes étapes du test effectué par le serveur de test. L’avantage de ce mode est de fournir immédiatement des informations à l’utilisateur qui a procédé à l’appel d’un numéro dédié au serveur de test et qui a donc déclenché le test de qualité de sa liaison de communication. Là encore, un avantage est de limiter le recours au service après-vente de la part des utilisateurs puisqu’ils disposent d’un service de test en libre-service, qui va réaliser les étapes du test et leur fournir les résultats par l’intermédiaire du message émis par le serveur de test et restitué par le terminal. Selon un premier aspect matériel, l’invention a trait à une entité de gestion d’un test de la qualité d’une liaison de communication téléphonique entre un terminal et un serveur de test, la liaison de communication téléphonique pouvant être ouverte ou fermée, le test étant réalisé par le serveur de test lorsque la liaison est ouverte, caractérisée en ce que ladite entité de gestion comprend un processeur configuré pour assurer que, durant la réalisation du test de la qualité de la liaison, ladite liaison est maintenue ouverte par ladite entité de gestion, indépendamment de la réception d’une instruction de fermeture de la liaison par le terminal, pendant une durée donnée au moins égale à la durée nécessaire à l’achèvement du test. Selon un autre aspect matériel, l’invention a trait à un terminal comprenant une entité de gestion selon l’aspect précédent. Grâce à cet aspect matériel, il est possible de disposer de terminaux qui vont collaborer avec un serveur de test afin de s’assurer que, une fois qu’un test de qualité de la liaison de communication téléphonique est démarré, celui-ci ne sera pas interrompu, y compris en présence d’actions de l’utilisateur du terminal, comme une action de raccrochage. L’invention permet donc de disposer d’un système de test de la qualité d’une liaison de communication téléphonique accessible en libre-service pour un utilisateur et qui reste robuste face aux actions de l’utilisateur. En général, un tel terminal est un téléphone. Comme déjà expliqué, dans le cas de la téléphonie IP, un tel terminal IP peut être, entre autres, un téléphone IP ou une passerelle domestique. Il peut également s’agir d’un ordinateur, fixe ou portable, disposant de la capacité de réaliser des communications en téléphonie IP et attaché à un réseau téléphonique IP. Selon un autre aspect matériel, l’invention a trait à un programme d’ordinateur apte à être mis en œuvre par un terminal selon l’aspect précédent, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise le procédé de gestion selon l’invention. Les programmes d’ordinateur en question peuvent être rédigés dans tout langage de programmation. Ils peuvent être par exemple des langages compilés, ou bien interprétés, ou bien utiliser un mode de fonctionnement mixte utilisant une compilation vers un code à octet (de l’anglais bytecode ) qui sera ensuite interprété par une machine virtuelle. Les programmes peuvent s’exécuter sur des architectures matérielles, ou bien dans des machines virtuelles, ou bien dans des technologies proches comme des systèmes de conteneurs. Selon un autre aspect matériel, l’invention a trait à un support de données sur lequel est enregistré un programme d’ordinateur selon l’aspect précédent. Les supports de données peuvent être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique tel qu’un un disque dur. D'autre part, les supports peuvent être des supports transmissibles tels qu'un signal électrique ou optique, qui peuvent être acheminés via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des figures L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple, et faite en référence aux dessins annexées sur lesquels : représente un exemple d’étapes mises en œuvre dans le cadre d’un mode de réalisation de l’invention. représente un exemple de mise en œuvre de l’invention par un terminal IP et un serveur de test, le terminal IP étant une passerelle domestique distincte d’un téléphone. représente un exemple de mise en œuvre de l’invention par un téléphone IP et un serveur de test. Description détaillée La représente un exemple d’étapes mises en œuvre dans le cadre d’un mode de réalisation de l’invention. Les deux lignes verticales représentent l’évolution d’une part d’un terminal TER et d’autre part d’un serveur de test SRV lors de la mise en œuvre d’un procédé de gestion selon l’invention. De manière classique, l’évolution du temps est représentée par le passage du haut vers le bas le long des deux lignes verticales. Dans notre exemple de description détaillée, on se place dans le cadre de la téléphonie IP. Le test est un test de qualité d’une liaison de communication téléphonique IP, et le terminal TER est un terminal IP TER. Dans le mode de réalisation présenté ici, le terminal IP TER comprend une entité de gestion 100 selon l’invention, qui met en œuvre le procédé de gestion de test. Dans d’autres modes, l’entité de gestion 100 peut appartenir au serveur de test SRV ou bien appartenir à des plates-formes de service, non représentées sur les figures, qui mettent en œuvre le réseau de téléphonie IP entre le terminal IP TER et le serveur de test SRV. Cependant, le mode de réalisation dans lequel l’entité de gestion 100 est comprise dans le terminal IP TER est le mode préféré car l’entité de gestion 100 est chargée d’annuler l’effet d’actions à destination du terminal IP TER et une situation de l’entité de gestion 100 dans le terminal IP TER est la plus adaptée pour cela. L’entité de gestion 100 comprend un processeur et éventuellement une ou plusieurs mémoires (non représentés sur les figures) qui lui permettent d’exécuter des programmes. La présence de processeurs et de mémoires dans les terminaux téléphoniques, ou dans les passerelles domestiques qui servent de terminaux IP TER est classique de nos jours. Le processeur de l’entité de gestion 100 devra avoir accès aux interfaces réseau du terminal IP TER afin de pouvoir intercepter les instructions de fermeture de la liaison L durant l’exécution du test. Le programme du processeur devra également pouvoir détecter que la liaison L doit rester ouverte. Une manière de procéder peut être d’associer des numéros de téléphone dédiés aux tests de qualité, numéros qui seront mémorisés dans une mémoire de l’entité de gestion 100. Le programme mettant en œuvre le procédé selon l’invention ayant accès aux interfaces réseau du terminal IP TER détectera alors un appel vers un de ces numéros dédiés aux tests de qualité et commencera alors à exécuter le procédé. Une autre manière de procéder peut être, pour le serveur de test SRV, d’envoyer, au début d’un test de qualité de la liaison L, un message spécifique à destination de l’entité de gestion 100 lui demandant de mettre en œuvre le procédé selon l’invention et de maintenir ouverte la liaison L pendant une durée au moins égale à la durée nécessaire à l’exécution du test TST. Le terminal IP TER peut prendre plusieurs formes. Le terminal IP TER peut par exemple être une passerelle domestique qui offre l’accès au réseau Internet dans un domicile ou un petit local professionnel. Une telle passerelle domestique créera un réseau local et disposera de la possibilité de connecter un téléphone TEL à son réseau local par exemple en utilisant le protocole DECT. D’autre part, la passerelle domestique sera connectée à un réseau de téléphonie IP en tant que terminal IP TER et pourra établir des liaisons de communication téléphonique IP au bénéfice du téléphone TEL. Cette situation est représentée en , qu’on détaillera ultérieurement. Le terminal IP TER peut également être un téléphone capable de se rattacher directement au réseau de téléphonie IP. Cette situation est représentée en , qu’on détaillera ultérieurement. Le terminal IP TER peut également être un ordinateur, fixe ou portable, disposant de la capacité de réaliser des communications en téléphonie IP et attaché à un réseau téléphonique IP. Le serveur de test SRV, quant à lui, présente en général l’architecture matérielle d’un ordinateur conventionnel et comporte notamment un processeur, une mémoire vive de type RAM (pour l’anglais Read Access Memory ) et une mémoire morte telle qu’une mémoire de type Flash, ROM (pour l’anglais Read Only Memory ), ou autres, non représentés sur la figure, ainsi que des dispositifs d’entrée-sortie tels que claviers et/ou écrans (non représentés sur la figure). L’entité de gestion peut être un serveur matériel ou bien être déployée sur une architecture informatique en nuage (de l’anglais cloud computing ). L’entité de gestion dispose de liaisons de communication (non représentées sur la ) qui lui permettent de communiquer avec d’autres entités pour échanger des données ou des instructions. Le serveur de test SRV doit être capable d’être connecté à des liaisons de communication téléphonique IP afin de réaliser des tests de qualité d’une telle liaison. Le serveur de test SRV doit donc être relié par une liaison de communication non représentée au réseau de téléphonie IP et doit pouvoir interagir avec celui-ci, par exemple en disposant d’un ou plusieurs numéros de téléphone dédiés sur le réseau de téléphone IP et en étant capable de passer des instructions relatives à l’établissement des liaisons de communication téléphonique IP. Le serveur de test SRV dispose donc de possibilités de communication suivant les protocoles SIP ou H.323 ou d’autres selon les protocoles de téléphonie IP présents dans le réseau de téléphonie IP pour lequel le serveur de test SRV va réaliser des tests. Le procédé est mis en œuvre alors qu’une liaison L de communication téléphonique IP est ouverte entre le terminal IP TER et le serveur de test SRV. Une telle liaison L peut être ouverte à la suite de plusieurs événements. Dans un mode de réalisation le plus simple, un numéro de téléphone est dédié au serveur de test SRV et un utilisateur du terminal IP TER va composer ce numéro afin d’ouvrir la liaison L de communication téléphonique IP. Dans un autre mode de réalisation, le terminal IP TER va être capable d’initier l’ouverture de la liaison L sans initiative d’un utilisateur. Dans ce mode, le terminal IP TER dispose de capacités de programmation qui lui permettent de déclencher un appel téléphonique IP et donc l’ouverture d’une liaison L de communication téléphonique IP avec le serveur SRV, soit à des moments planifiés, soit en réponse à des instructions ne provenant pas d’un utilisateur mais d’autres machines. Le mode de réalisation dans lequel le terminal IP TER déclenche des appels vers le serveur de test SRV de façon planifiée permet de mettre en œuvre une maintenance préventive de la qualité de la liaison L de communication téléphonique IP, en réalisant des tests à intervalles réguliers. Dans un autre mode de réalisation, c’est le serveur de test SRV qui va déclencher un appel vers le terminal IP TER ce qui va ouvrir la liaison L de communication téléphonique IP. La liaison L de communication téléphonique IP comprend dans plusieurs modes de réalisation un canal de signalisation CS et un canal CD de transmission de données multimédia. Le canal de signalisation CS est utilisé pour transférer les informations et les instructions ayant trait à la signalisation téléphonique et par exemple à l’établissement des communications téléphoniques IP, au transfert de ces communications, à la fermeture des communications ou à toute autre opération de signalisation. Le canal CD de transmission de données multimédia sert quant à lui à transmettre des données multimédia sous forme de paquets de données. En particulier, le signal vocal entre les deux extrémités de la liaison L de communication téléphonique IP est transmis dans les deux sens sous forme de paquets de données encodant le signal vocal émis aux deux extrémités de la liaison L. Le protocole d’échange de tels paquets de données multimédia est le protocole RTP (acronyme de l’anglais Real-time Transport Protocol ). Ses notions sont bien connues par l’homme du métier dans le domaine de la téléphonie IP et ne sont pas davantage détaillées. Une fois la liaison L de communication téléphonique IP ouverte entre le terminal IP TER et le serveur de test SRV, ce dernier va procéder à un test TST de la qualité de la liaison L. Un tel test TST est une succession d’étapes qui va permettre d’obtenir tout un ensemble de résultats qualifiant la qualité de la liaison L avec le terminal IP TER. L’exécution de l’ensemble du test TST par le serveur de test SRV prend un temps significatif avant que ne soit obtenu les résultats des étapes du test TST réalisé par le serveur de test SRV. Ce temps occupe une période représentée dans la par un trait plus épais disposé sur la ligne représentant les actions du serveur de test SRV et du terminal IP TER. Certaines des étapes du test TST vont être exécutées de façon quasi-instantanée par le serveur de test SRV ce qui est représenté dans la par une flèche en boucle, arrivant un peu en-dessous de leur point de départ représentant que la fin de cette étape du test TST a lieu très peu de temps après son début. D’autres étapes du test TST vont au contraire prendre un temps significatif à être exécutées, ce qui est représenté par une flèche dont le point d’arrivée est significativement plus tardif que le point de départ. Ces différentes étapes du test TST sont dans tous les cas étiquetées TST dans la , la différenciation des différentes étapes du test TST n’ayant pas d’influence sur la réalisation du procédé de gestion selon l’invention. Dans tous les cas, c’est l’exécution de l’ensemble des étapes du test TST par le serveur de test SRV qui prend un temps significatif. Les étapes du test TST peuvent être de plusieurs natures. Le test TST peut d’abord concerner la signalisation téléphonique IP. Dans ce cas, le serveur récupère des données transmises à travers le canal CS de la liaison L de communication téléphonique IP établie entre le terminal IP TER et le serveur SRV. Pour réaliser un test TST relatif à la signalisation, le serveur SRV doit disposer des moyens d’interpréter les messages de signalisation qui vont en général utiliser le protocole SIP et éventuellement des protocoles dédiés à la téléphonie IP tel que H.323. Le serveur de test TST obtiendra ainsi un ensemble d’informations relatives à la signalisation, transmises par le canal de signalisation CS. Par exemple, dans le cas où la liaison L est ouverte à l’initiative du terminal IP TER en utilisant le protocole SIP, le serveur de test SRV pourra accéder au champ P-Asserted-Identity du message SIP-Invite . Ce champ permet au serveur de test SRV d’obtenir des informations sur le terminal IP TER et en particulier son numéro de téléphone et la plate-forme de téléphonie utilisée par le terminal IP TER pour placer son appel. Le serveur de test SRV peut ainsi déduire depuis quel réseau de téléphonie le terminal IP TER a placé son appel, ainsi que l’opérateur du service de téléphonie utilisé par le terminal IP TER et possiblement d’autres informations commerciales. Un autre exemple de test TST relatif à la signalisation consiste à accéder au champ SDP (acronyme de l’anglais Session Description Protocol ) présent dans le message SIP-Invite envoyé par un terminal IP TER. Ce champ permet au serveur de test SRV de connaître les capacités du réseau utilisé pour établir la liaison L de communication téléphonique IP entre le serveur de test SRV et le terminal IP TER. Le serveur de test TST peut ainsi déduire les codecs (programmes ou matériels utilisés pour encoder des signaux audios ou vidéos, acronyme de codeurs-décodeurs) qui sont utilisés par le terminal IP TER ou imposés par le réseau sous-jacent pour transmettre des données multimédia dans le canal CD de la liaison L. Un autre exemple de test TST relatif à la signalisation consiste à extraire le champ user-agent des messages SIP échangés entre le terminal IP TER et le serveur de test SRV. Le serveur de test SRV peut ainsi en déduire le modèle du terminal TER situé à l’extrémité de la liaison L de communication téléphonique IP. Les étapes du test TST peuvent ensuite concerner la qualité de la liaison L de communication téléphonique IP en ce qui concerne la transmission de données multimédia. Pour établir ces étapes du test TST, des données doivent être émises dans le canal CD de transmission de données multimédia de la liaison L de communication téléphonique IP. Ces données doivent en particulier être émises depuis le terminal IP TER vers le serveur de test SRV. Dans le cas où le terminal IP TER est à l’initiative de l’ouverture de la liaison L à la suite d’une action d’un utilisateur, c’est-à-dire quand l’utilisateur a utilisé le terminal IP TER pour appeler le numéro dédié du serveur de test SRV, le signal audio analogique enregistré par le microphone du téléphone TEL ou du terminal IP TER va être encodé en paquet de données grâce à un codec donné, puis les paquets vont être expédiés vers le serveur de test SRV grâce au protocole RTP. Le serveur de test SRV va ensuite effectuer un test de la qualité de la liaison L en s’appuyant sur les paquets de donnée reçus. Le serveur de test SRV doit donc disposer des moyens d’interpréter les paquets de données reçus selon le protocole RTP. Les étapes du test TST relatives à la transmission de données dans le canal CD vont s’appuyer sur la transmission d’un certain nombre de paquets de données et consister en calculs réalisés sur les paquets reçus. Par nature, ces étapes du test TST doivent donc prendre un certain temps afin d’être réalisées sur une quantité de paquets de données reçus suffisante afin que les résultats obtenus soient significatifs. De façon indicative, la durée nécessaire à la réalisation des étapes du test TST varie de quelques secondes à quelques dizaines de secondes. Pendant cette durée, la liaison L de communication téléphonique IP entre le terminal IP TER et le serveur de test SRV ne doit pas être interrompue. Les étapes du test TST relatives à la transmission des données vont par exemple consister en un calcul du rapport entre le nombre de paquets reçus par le serveur de test SRV et le nombre de paquets émis par le terminal IP TER. Le calcul du nombre de paquets perdus est également un résultat intéressant du test TST. Un autre exemple de test TST relatif à la transmission des données dans le canal CD consiste à calculer la gigue. La gigue est la variation de la latence au fil du temps. Un paquet émis par le terminal IP TER mettra un certain temps à être transmis au serveur de test SRV. Ce délai de transmission est la latence. Au fur et à mesure de la transmission, la latence peut diminuer (les paquets mettent moins de temps à être transmis) ou au contraire augmenter. La gigue mesure cette variation de la latence, et est par exemple définie dans le document RFC 3393 de l’IETF (acronyme de l’anglais Internet Engineering Task Force ). Plusieurs méthodes de calcul de la gigue peuvent être appliquées et donner différents résultats de test TST et ne sont pas détaillées plus avant. Un autre exemple de test TST relatif à la transmission des données consiste à réaliser les calculs définis dans la norme G.107 qui fait partie des recommandations de l’UIT-T, c’est-à-dire des recommandations pour le secteur des télécommunications de l’Union Internationale des Télécommunications. Dans certains modes de réalisation, la réalisation du test TST relatif à la transmission de données par le serveur de test SRV dépend des informations obtenues pendant le test TST relatives à la signalisation. Par exemple, l’opérateur de télécommunications qui déploie le serveur de test SRV peut vouloir réserver son utilisation uniquement à ses clients et va donc utiliser le résultat d’une étape du test TST identifiant le terminal IP TER qui appelle le serveur de test SRV et continuera le test TST uniquement si le terminal IP TER appartient bien aux clients de l’opérateur. Les étapes du test TST réalisées finalement peuvent également dépendre de l’abonnement auquel le terminal IP TER souscrit et seront par exemple plus détaillées pour un client entreprise que pour un particulier. Ou bien, le serveur de test SRV va pouvoir modifier le test TST réalisé en fonction des codecs utilisés par le terminal IP TER, ce qui est révélé par une étape du test TST initial relative à la signalisation. Ou bien encore, les étapes du test TST réalisé seront sélectionnées en fonction du modèle du terminal IP TER. Dans l’ensemble des modes de réalisation du procédé de gestion selon l’invention, la liaison L de communication est maintenue ouverte pendant la durée nécessaire à l’achèvement du test TST et ce indépendamment de la réception par le terminal IP TER d’une instruction RAC de fermeture de la liaison L. Une telle instruction RAC sera dans le cas le plus fréquent une opération de raccrochage initiée par l’utilisateur du terminal IP, comme représenté dans la . Pendant toute la durée de l’exécution des étapes du test TST, l’entité de gestion 100 fait en sorte que de telles instructions RAC sont ignorées par le terminal IP TER. De cette manière, la liaison L de communication téléphonique IP est maintenue ouverte et l’exécution du test TST par le serveur de test SRV peut se poursuivre. Lorsque l’entité de gestion 100 appartient au terminal IP TER, le maintien de la liaison L ouverte même en présence d’instructions RAC reçues par le terminal IP TER est rendu plus facile. L’entité de gestion 100 pourra en effet plus facilement intercepter les instructions RAC reçues par le terminal IP TER en étant incluse dans le terminal IP TER. Dans certains modes de réalisation, la durée nécessaire à l’achèvement du test TST par le serveur de test SRV est connue à l’avance de l’entité de gestion 100 qui met en œuvre le procédé de gestion. Dans d’autres modes de réalisation, le serveur de test SRV émet un message à destination de l’entité de gestion 100 lorsque l’ensemble des étapes du test TST ont été réalisées. De cette manière, l’entité de gestion 100 est informée qu’elle n’a plus à mettre en œuvre le procédé de gestion et à assurer que la liaison L reste ouverte même en présence d’instructions RAC. Dans certains modes de réalisation de l’invention, lorsqu’une instruction RAC de fermeture de la liaison L est reçue par le terminal IP TER pendant la durée donnée, l’exécution de ladite instruction RAC est repoussée d’une autre durée donnée. De cette manière, l’instruction RAC sera bien exécutée finalement par le terminal IP TER mais en dehors de la période pendant laquelle la liaison L de communication téléphonique IP doit être maintenue ouverte pour l’exécution du test TST. Dans d’autres modes de réalisation de l’invention, lorsqu’une instruction RAC de fermeture de la liaison L est reçue par le terminal IP TER pendant la durée donnée, l’exécution de ladite instruction RAC est annulée. L’entité de gestion 100 fait en sorte que l’instruction RAC ne soit pas reçue par le terminal IP TER. Dans certains modes de réalisation, la demande d’ouverture de la liaison L de communication téléphonique IP est issue d’une interface IP du terminal IP TER. Par exemple, dans un mode simple, un utilisateur du terminal IP TER déclenche un appel téléphonique vers un numéro dédié du serveur de test SRV ce qui envoie une demande d’ouverture de la liaison L de communication entre le terminal IP TER et le serveur de test SRV. Dans ce mode, le serveur de test SRV est en libre-service et va effectuer un test TST de la liaison L quand il est appelé par le terminal IP TER. Le procédé de gestion selon l’invention va alors permettre de s’assurer que la liaison L reste ouverte et donc que le serveur de test SRV dispose du temps nécessaire pour réaliser le test TST même en présence d’instructions RAC de fermeture de la liaison L. Ces instructions RAC sont typiquement des opérations de raccrochage de la part de l’utilisateur. Dans d’autres exemples, le terminal IP TER émet la demande d’ouverture de la liaison L sans intervention d’un utilisateur. L’ouverture de la liaison L et la réalisation du test TST est alors programmée et déclenchée par le terminal IP TER. Dans certains modes de réalisation, la demande d’ouverture de la liaison L est issue d’un téléphone TEL distinct du terminal IP TER. Il s’agit des modes dans lesquels le terminal IP TER n’est pas un téléphone mais par exemple une passerelle domestique à laquelle sont connectés un ou plusieurs téléphones dans son réseau local. L’utilisateur va alors utiliser le téléphone TEL pour appeler le numéro dédié du serveur de test SRV ; la demande d’ouverture de la liaison L est donc issue du téléphone TEL, distinct du terminal IP TER. Dans certains modes de réalisation, le terminal IP TER émet des paquets de données dans le canal CD de transmission de données multimédia indépendamment d’instructions reçues au travers d’une interface du terminal IP. Ces modes peuvent être utiles quand le terminal IP TER est à l’initiative de l’ouverture de la liaison L indépendamment d’une action d’un utilisateur. En effet, même en l’absence d’instructions reçues, comme des envois de signaux depuis les microphones, le terminal IP TER va émettre des paquets de données pour assurer que le serveur de test SRV puisse réaliser le test TST de qualité de la liaison L de communication téléphonique IP. L’entité de gestion 100 qui a la charge de réaliser le procédé de gestion et donc d’intercepter les instructions RAC de fermeture de la liaison va également assurer l’émission de ces paquets pendant la durée nécessaire au test TST. Dans des modes de réalisation de l’invention, le procédé de gestion comprend la réception par le terminal IP TER, pendant la durée donnée, d’un message issu du serveur de test SRV destiné à être restitué par le terminal IP TER. Ce message va être par exemple un message vocal, produit par un composant de synthèse de la parole, ou bien pré-enregistré, qui sera restitué par le haut-parleur du terminal IP TER, quand le terminal IP TER est un téléphone, ou envoyé par le terminal IP TER à un téléphone TEL qui le diffusera sur son haut-parleur. Le message peut aussi comprendre des éléments qui pourront être restitués sur un écran du terminal IP TER ou du téléphone TEL. Un des avantages de ce mode apparaît quand l’ouverture de la liaison L a été réalisée à la demande d’un utilisateur du terminal IP TER qui a composé le numéro de téléphone dédié du serveur de test SRV. Le message issu du serveur de test SRV et restitué par le terminal IP TER va permettre de communiquer des informations à l’utilisateur relatives au déroulement des étapes du test TST exécutées par le serveur de test SRV. Le message peut également donner des instructions à l’utilisateur pour aider à la réalisation du test TST. Par exemple, le message peut demander à l’utilisateur de presser une ou plusieurs touches du terminal IP TER ou du téléphone TEL. De cette manière, le serveur de test SRV sera capable de réaliser des étapes du test TST relatives au bon fonctionnement du DTMF (acronyme de l’anglais Dual-Tone Multi-Frequency ) le long de la liaison L de communication téléphonique IP. Dans certains modes de réalisation, le message peut demander à l’utilisateur de prononcer une phrase particulière. Un système de reconnaissance de la parole présent dans le serveur de test SRV va alors lui permettre de réaliser un test TST s’appuyant sur la qualité du signal de parole reçu qui peut être comparé au message demandé. Un avantage de l’émission d’un message par le serveur de test SRV est d’inciter l’utilisateur qui a initié le test TST en appelant le numéro dédié du serveur de test SRV à conserver ouverte la liaison L le temps nécessaire pour réaliser le test TST, autrement dit pour l’inciter à ne pas raccrocher RAC. De cette manière, l’ensemble des étapes du test TST pourra être réalisé par le serveur de test SRV même quand il s’agit de tester la qualité de la liaison L avec un terminal IP TER qui ne dispose pas de l’entité de gestion 100. Même en l’absence d’une entité de gestion 100 interceptant les instructions RAC de fermeture de la liaison L, ce mode de réalisation va permettre d’éviter la production de telles instructions RAC. Ce mode de réalisation permet donc de mettre à disposition en libre-service un serveur de test SRV qui pourra être appelé par tous types de terminaux IP TER et réalisera l’ensemble de tests TST. Le message émis par le serveur de test SRV conserve l’utilisateur qui a appelé le serveur de test SRV au bout du fil le temps nécessaire. Dans des modes de réalisation, le message émis pendant la durée de réalisation des étapes du test TST comprend des informations relatives au test TST réalisé par le serveur de test SRV. Ces informations peuvent être par exemple des indications de début et de fin de la réalisation des étapes du test TST au fur et à mesure de la réalisation de chacune d’entre elles. Ces informations peuvent comprendre également les résultats du test TST, y compris une indication globale sur la qualité de la liaison L de communication téléphonique IP entre le terminal IP TER et le serveur de test SRV. La présente la situation quand le terminal IP TER n’est pas un téléphone IP. Le terminal IP TER est par exemple une passerelle domestique et crée un réseau local DECT auquel se rattache un téléphone TEL. La liaison L de communication téléphonique IP est alors ouverte au sein d’un réseau IP entre le terminal IP TER et le serveur de test SRV. La liaison L de communication comprend un canal CS dédié à la transmission d’informations de signalisation et un canal CD dédié à la transmission de données multimédia, dont le signal vocal entre le terminal IP TER et le serveur de test SRV. Dans cette situation, une instruction RAC de fermeture de la liaison L peut être reçue par le terminal IP TER dans plusieurs situations, et en particulier quand l’utilisateur du téléphone TEL effectue une action de raccrochage RAC sur le téléphone TEL. Une telle action RAC est transmise par l’intermédiaire de la liaison DECT vers le terminal IP TER. La présence de l’entité de gestion 100 mettant en œuvre le procédé de gestion assure que l’instruction de fermeture RAC ne sera pas mise en œuvre pendant la durée nécessaire à la réalisation du test TST. La présente la situation quand le terminal IP TER est un téléphone IP. Le terminal IP TER est un téléphone capable de mettre en œuvre directement les protocoles nécessaires de téléphonie IP. La liaison L de communication téléphonique IP est ouverte entre le terminal IP TER et le serveur de test SRV, éventuellement au travers de plusieurs réseaux IP1, IP2 connectés par un ou plusieurs routeurs. La liaison L comprend un canal CS dédié à la transmission d’informations de signalisation et un canal CD dédié à la transmission de données multimédia. L’entité de gestion 100 présente dans le terminal IP TER permet d’assurer que la liaison L reste ouverte même en présence d’une instruction RAC de fermeture de la liaison L, en l’occurrence ici une instruction de raccrochage par l’utilisateur du terminal IP TER. Procédé de gestion d’un test (TST) de la qualité d’une liaison (L) de communication téléphonique entre un terminal (TER) et un serveur de test (SRV), la liaison (L) de communication téléphonique pouvant être ouverte ou fermée, le test (TST) étant réalisé par le serveur de test (SRV) lorsque la liaison (L) est ouverte, caractérisé en ce que, durant la réalisation du test (TST) de la qualité de la liaison (L), ladite liaison (L) est maintenue ouverte indépendamment de la réception d’une instruction (RAC) de fermeture de la liaison (L) par le terminal (TER) pendant une durée donnée au moins égale à la durée nécessaire à l’achèvement du test (TST) Procédé de gestion d’un test (TST) selon la revendication 1 caractérisé en ce que, si une instruction (RAC) de fermeture de la liaison (L) est reçue pendant la durée donnée, l’exécution de ladite instruction (RAC) est repoussée d’une autre durée donnée Procédé de gestion d’un test (TST) selon l’une des revendications 1 ou 2 caractérisé en ce que, la liaison (L) étant une liaison de communication téléphonique IP ouverte entre le terminal (TER) et le serveur de test (SRV), ladite liaison (L) comprend un canal de signalisation (CS) permettant au serveur de test (SRV) d’obtenir des informations relatives à la signalisation et en ce que la réalisation, par le serveur de test (SRV), du test (TST) de la qualité de la liaison (L) dépend des informations obtenues relatives à la signalisation Procédé de gestion d’un test (TST) selon l’une des revendications 1 à 3 caractérisé en ce que l’ouverture de la liaison (L) est précédée d’une demande d’ouverture de la liaison (L) issue du terminal (TER) Procédé de gestion d’un test (TST) selon la revendication 4, caractérisé en ce que la liaison (L) est une liaison de communication téléphonique IP et en ce que la demande d’ouverture de la liaison (L) issue du terminal (TER) est précédée d’une demande d’ouverture issue d’un téléphone (TEL) distinct du terminal (TER) Procédé de gestion d’un test (TST) selon l’une des revendications 4 ou 5, caractérisé en ce que, la liaison (L) étant une liaison de communication téléphonique IP ouverte entre le terminal (TER) et le serveur de test (SRV), ladite liaison comprend un canal (CD) de transmission de données multimédia et en ce que le terminal (TER) émet des paquets de données dans le canal (CD) indépendamment d’instructions reçues au travers d’une interface du terminal (TER) Procédé de gestion d’un test (TST) selon l’une des revendications 1 à 6 caractérisé en ce qu’il comprend la réception par le terminal (TER), pendant la durée donnée, d’un message issu du serveur de test (SRV) destiné à être restitué par le terminal (TER) Procédé de gestion d’un test (TST) selon la revendication 7 caractérisé en ce que le message reçu par le terminal (TER) comprend des informations relatives au test (TST) réalisé par le serveur de test (SRV) Entité de gestion (100) d’un test (TST) de la qualité d’une liaison (L) de communication téléphonique entre un terminal (TER) et un serveur de test (SRV), la liaison (L) de communication téléphonique pouvant être ouverte ou fermée, le test (TST) étant réalisé par le serveur de test (SRV) lorsque la liaison (L) est ouverte, caractérisée en ce que ladite entité de gestion comprend un processeur configuré pour assurer que, durant la réalisation du test (TST) de la qualité de la liaison (L), ladite liaison (L) est maintenue ouverte par ladite entité de gestion (100), indépendamment de la réception d’une instruction (RAC) de fermeture de la liaison (L) par le terminal (TER), pendant une durée donnée au moins égale à la durée nécessaire à l’achèvement du test (TST) Terminal (TER) comprenant une entité de gestion (100) selon la revendication 9 Programme d’ordinateur apte à être mis en œuvre par un terminal (TER) selon la revendication 10, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise le procédé de gestion selon la revendication 1 Support de données sur lequel est enregistré un programme d’ordinateur selon la revendication 11