FR 3014277 A1 20150605 FR 1361893 A 20131129 L'invention se situe dans le domaine des réseaux de communication de type IP (Internet Protocol) et concerne plus particulièrement une technique de restauration d'un service pour un utilisateur dans un réseau de type IMS (IP Multimedia System). Une architecture de réseau IMS telle que définie par le groupe de normalisation 3GPP (pour 3rd Generation Partnership Project) permet l'établissement et le contrôle de sessions multimédia entre deux équipements utilisateur ainsi que la réservation de ressources pour les flux multimédias au niveau du réseau de transport. Grâce à cette architecture, les opérateurs de réseaux peuvent commodément contrôler la qualité de service offerte. L'architecture IMS permet actuellement d'offrir des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée et gère également l'interaction de ces services. Elle met généralement en oeuvre le protocole SIP (pour Session Initiation Protocol), tel que défini par l'IETF (Internet Engineering Task Force) dans le document RFC 3261 en tant que protocole de gestion de sessions, lequel permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Une telle architecture de réseau IMS comprend notamment : - un ou plusieurs serveurs d' abonnés, ou serveurs HSS (pour Home Subscriber Server), contenant chacun une base de données utilisateurs. Chaque serveur d' abonnés contient le « profil » d'un certain nombre d'équipements utilisateur du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services souscrits ; - un ou plusieurs serveurs d'enregistrement, appelés « S-CSCF » (pour Serving-Call Server Control Function) permettant notamment de gérer la procédure d'enregistrement des équipements utilisateur connectés au réseau ; - un ou plusieurs serveurs d'interrogation, appelés « I-CSCF » (pour Interrogating-Call Server Control Function), permettant d'interroger un serveur d'abonnés au moment de l'enregistrement d'un équipement utilisateur, afin de d'obtenir un identifiant d'un serveur d'enregistrement disposant des caractéristiques requises pour atteindre le niveau de service souscrit par l'utilisateur, un tel serveur est appelé par la suite « serveur d'enregistrement nominal » ; - un ou plusieurs serveurs mandataires (aussi appelés serveurs « proxy »), désignés par « P-CSCF » (pour Proxy-Call Server Control Function), servant d'entité de raccordement entre le coeur de réseau IMS et le réseau d'accès utilisé par les équipements utilisateur, aptes à retransmettre tous les messages de signalisation entre les équipements utilisateur d'une part et les serveurs SCSCF ou I-CSCF d'autre part. Afin d'assurer une continuité de service dans un réseau IMS, le groupe de normalisation 3GPP a défini dans un document de spécifications techniques TS 23.380 version 11.1.0, intitulé « IMS Restoration Procedures », des procédures relatives à la restauration de service au sein d'un réseau IMS lorsqu'un serveur d'enregistrement nominal est injoignable (e.g., panne réseau, ou panne du serveur d'enregistrement lui-même). Deux procédures de restauration sont en particulier décrites, la première intervenant lors de l'enregistrement d'un équipement utilisateur sur le réseau IMS (TS 23.380, §4.2.2), et la seconde lors de la fin d'une session avec un équipement utilisateur (TS 23.380, §4.3.3). Ces deux procédures prévoient un envoi d'un message de demande de capacités par un serveur d'interrogation I-CSCF à un serveur d'abonnés HSS, afin que le serveur d'interrogation I-CSCF puisse sélectionner un serveur d'enregistrement S-CSCF de remplacement. Ces « capacités » sont définies dans le Chapitre 6.7 des spécifications techniques 3GPP TS 29.228. Ceci permet d'assurer une continuité de service dans le réseau IMS transparente pour l'utilisateur. Un inconvénient des procédures de restauration de service telles que spécifiées dans le document de spécification TS 23.380, est le coût en termes de ressources du réseau et de charge processeur associé au basculement vers le serveur d'enregistrement de remplacement. Ce basculement s'accompagne notamment d'une migration des informations associées à un utilisateur enregistré auprès du serveur d'enregistrement nominal vers le serveur d'enregistrement de remplacement, provoquant une augmentation des opérations mémoire et des échanges entre serveurs du réseau. Il existe donc un besoin d'améliorer les procédures de restauration de service dans un réseau IMS. Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations. Selon un premier aspect l'invention concerne un procédé de traitement d'une requête de service relative à un utilisateur dans un réseau de communication, mis en oeuvre par un serveur d'abonnés et comprenant les étapes suivantes : - réception depuis un serveur d'interrogation d'une requête d'obtention d'un identifiant d'un serveur d'enregistrement nominal, suivie d'une réception d'une requête de capacités qu'un serveur d'enregistrement de remplacement doit disposer pour pouvoir fournir des services autorisés pour l'utilisateur ; - détection qu'une procédure de recherche d'un serveur d'enregistrement de remplacement est en cours d'exécution par le serveur d'interrogation, suite à une détection que ledit serveur d'enregistrement nominal n'est pas joignable par le serveur d'interrogation ; - vérification que le serveur d'enregistrement nominal est actif ; - envoi d'une commande au serveur d'interrogation, cette commande permettant de déclencher l'interruption de la procédure de recherche et une sélection d'un serveur d'interrogation de remplacement pour traiter la requête de service. Les procédures de restauration de service telles que décrites dans la spécification TS 23.380 ne distinguent pas une panne d'un serveur d'enregistrement nominal d'une panne intervenant sur un chemin réseau entre un serveur d'interrogation et un serveur d'enregistrement nominal En particulier, ces procédures proposent dans tous les cas de sélectionner un serveur d'enregistrement de remplacement en exécutant une procédure de recherche d'un tel serveur dès lors que le serveur d'enregistrement nominal est réputé injoignable. Le basculement vers un nouveau serveur d'enregistrement est cependant particulièrement couteux en termes de ressources du réseau. Grâce au procédé de traitement d'une requête de service, ce basculement peut être évité lorsque le serveur d'enregistrement est injoignable en raison d'une panne ou d'un incident réseau intervenant entre le serveur d'interrogation et le serveur d'enregistrement nominal. L'étape de vérification d'une activité du serveur d'enregistrement nominal permet au serveur d'abonnés de vérifier que le serveur d'enregistrement nominal est joignable par un chemin réseau distinct de celui passant par le serveur d'interrogation. Le procédé permet ainsi de différencier les cas de pannes propres au serveur d'enregistrement nominal de ceux intervenant sur le chemin réseau permettant de l'atteindre à partir du serveur d'interrogation. La procédure de restauration peut alors être adaptée en fonction du type de panne constatée. Lorsqu'un type de panne correspondant à une panne intervenant sur le chemin réseau permettant d'atteindre le serveur d'enregistrement nominal est identifié, le procédé permet de commander au serveur d'interrogation d'interrompre la procédure de recherche d'un serveur d'enregistrement de remplacement. Il permet également de sélectionner un serveur d'interrogation de remplacement conformément à la procédure de resélection décrite dans la spécification 3GPP TS 24.229 version 12.2.0. Une allocation d'un serveur d'enregistrement de remplacement pour l'utilisateur concerné peut ainsi être évitée. Les opérations, notamment de récupération de contextes associés à la migration des informations relatives à l'utilisateur et les échanges protocolaires qui en résultent, sont également évités. Il est en particulier possible de s'affranchir des échanges associés à l'authentification de l'utilisateur (e.g. messages MAR/MAA, pour Multimedia Authentication Request/Multimedia Authentication Answer), ainsi que des échanges pour l'assignation d'un serveur d'enregistrement à l'utilisateur (e.g. messages SAR/SAA, pour Server Assignment Request/Server Assignment Answer). Le procédé permet d'économiser les ressources du réseau et d'optimiser le traitement des requêtes de service relatives à un utilisateur. La continuité de service est renforcée, ce qui contribue à améliorer la qualité de service perçue par l'utilisateur. Selon une caractéristique particulière le procédé de traitement comprend en outre lorsqu'une interruption de la procédure de recherche a été déclenchée pour un nombre de serveurs d'interrogation supérieur à un seuil, sur réception en provenance d'au moins un autre serveur d'interrogation, d'une nouvelle requête d'obtention d'un identifiant de serveur d'enregistrement, suivie d'une réception d'une nouvelle requête de capacités, l'identifiant correspondant à l'identifiant du serveur d'enregistrement nominal, une étape d'envoi des capacités. Lorsque des requêtes de capacités sont reçues de plusieurs serveurs d'interrogation distincts pour le même serveur d'enregistrement nominal, une défaillance de ce dernier serveur peut-être supposée. Ceci se produit par exemple lorsqu'un serveur d'interrogation de remplacement a été sélectionné, mais qu'il ne parvient pas à son tour à joindre le serveur d'enregistrement nominal La reprise de l'exécution de la procédure de recherche d'un serveur d'enregistrement telle que décrite par exemple dans la spécification TS 23.380, au bout d'un certain nombre de tentatives par plusieurs serveurs d'interrogation distincts pour joindre le serveur d'enregistrement nominal est alors préférable à la sélection d'un serveur d'interrogation de remplacement. Elle présente en particulier l'avantage de permettre un traitement d'une nouvelle requête de service en recherchant un serveur d'enregistrement de remplacement. Selon une caractéristique particulière l'activité du serveur d'enregistrement nominal est vérifiée à partir d'informations relatives à des échanges dans le réseau du serveur d'abonnés avec le serveur d'enregistrement nominal. Le serveur d'abonnés mémorise de nombreuses informations relatives à l'activité du serveur d'enregistrement nominal telles que des indicateurs d'état du lien avec le serveur d'enregistrement nominal ou des indicateurs d'état du trafic entre les deux serveurs. Ces informations sont faciles d'accès pour le serveur d'abonnés et constituent un moyen simple de détection de l'activité du serveur d'enregistrement nominal Les indicateurs d'état du trafic sont par exemple des compteurs associés à chaque type de messages échangés (MAR/MAA, SAR/SAA ou encore DWR/DWA pour Device-Watchdog-Request/Device-Watchdog-Answer). Ces derniers messages sont plus particulièrement définis dans les documents de l'IETF RFC 3588 et RFC 4740. Un indicateur de l'état du lien est par exemple un code indiquant un statut de la connexion Diameter. L'activité du serveur d'enregistrement nominal est typiquement vérifiée à l'aide de requêtes DWR de surveillance utilisées pour surveiller les échanges entre le serveur d'abonnés et le serveur d'enregistrement nominal. Il est à noter que pour contrôler l'activité du serveur d'enregistrement nominal, les différents indicateurs mentionnés ne nécessitent pas la création de trafic supplémentaire au sein du réseau. Le procédé de traitement peut notamment être mis en oeuvre sans obtention de données autres que celles déjà connues du serveur d'abonnés. Le déploiement du procédé au sein d'une architecture réseau existante est facilité. En outre ces informations permettent de mettre en oeuvre le procédé pour certains types d'activité définis par exemple par un opérateur de réseau. Il suffit à l'opérateur de réseau de sélectionner uniquement des informations relatives à certains types d'activité du serveur d'enregistrement, tels que l'authentification de l'utilisateur, ou encore l'affectation du serveur d'enregistrement à l'utilisateur. Différentes politiques de restauration de services peuvent ainsi être définies. Selon une caractéristique particulière, l'activité du serveur d'enregistrement nominal est vérifiée par une mise à jour réussie du profil de l'utilisateur auprès du serveur d'enregistrement nominal Une mise à jour réussie du profil utilisateur à la demande du serveur d'abonnés permet de garantir l'activité du serveur d'enregistrement nominal tant au niveau matériel qu'au niveau applicatif. La couche applicative du serveur d'enregistrement nominal étant interrogée lors de la mise à jour du profil utilisateur, une réponse réussie de ce dernier permet notamment de se prémunir de faux positifs relatifs à l' activité du serveur. Selon un deuxième aspect l'invention concerne un procédé de traitement d'une requête de service relative à un utilisateur, mis en oeuvre par un serveur d'interrogation et comprenant les étapes suivantes : - réception de la requête de service relative à un utilisateur en provenance d'un serveur mandataire ; - envoi à un serveur d'abonnés d'une requête d'obtention d'un identifiant d'un serveur d'enregistrement nominal, détection que le serveur d'enregistrement nominal est injoignable et déclenchement d'une procédure de recherche d'un serveur d'enregistrement de remplacement, envoi d'une requête de capacités qu'un serveur d'enregistrement de remplacement doit disposer pour pouvoir fournir des services autorisés pour ledit utilisateur ; - réception depuis le serveur d'abonnés d'une commande demandant une interruption de la procédure de recherche et une sélection d'un serveur d'interrogation de remplacement pour traiter la requête de service, le serveur d'abonnés ayant vérifié que le serveur d'enregistrement nominal est actif ; - envoi au serveur mandataire d'une commande de redirection de la requête de service vers un serveur d'interrogation de remplacement pour traiter la requête de service. Les avantages énoncés pour le procédé de traitement selon le premier aspect sont directement transposables au procédé de traitement selon le deuxième aspect. En outre la réception d'une commande demandant d'interrompre la procédure de recherche d'un serveur d'enregistrement de remplacement permet au serveur d'interrogation d'être informé que le serveur d'enregistrement nominal fonctionne et peut être joint par un chemin réseau alternatif. Le procédé permet à cette fin l'envoi d'une commande de redirection vers le serveur mandataire émetteur de la requête de service relative à l'utilisateur. Cette dernière commande de redirection permet au serveur d'interrogation d'initier la sélection d'un serveur d'interrogation de remplacement pour joindre le serveur d'enregistrement nominal Le chemin réseau alternatif correspond ainsi à un chemin réseau permettant de joindre le serveur d'enregistrement nominal et passant par le serveur d'interrogation de remplacement sélectionné. Selon une caractéristique particulière, le serveur d'interrogation sélectionne le serveur d'interrogation de remplacement et la commande de redirection comprend une adresse du serveur d'interrogation de remplacement. Selon une caractéristique particulière, la commande de redirection comprend une indication que le serveur d'enregistrement nominal n'est pas joignable par le serveur d'interrogation, permettant au serveur mandataire de déclencher une obtention d'une adresse du serveur d'interrogation de remplacement. Selon une caractéristique particulière, la commande de redirection comprend une liste d'adresses de serveurs d'interrogation du réseau, le serveur d'interrogation de remplacement étant sélectionné dans la liste par le serveur mandataire. En fonction de la topologie du réseau, il peut être avantageux de sélectionner un serveur d'interrogation de remplacement plutôt qu'un autre. En particulier, selon qu'il est sélectionné par le serveur d'interrogation ou par le serveur mandataire, le serveur d'interrogation de remplacement choisi peut différer. En outre lorsque cette sélection est mise en oeuvre par un serveur mandataire, il est également possible d'associer des critères de priorités aux serveurs d'interrogation du réseau (e.g. poids associé à un serveur). Différentes stratégies de sélection du serveur d'interrogation de remplacement peuvent ainsi être adoptées par un opérateur de réseau. Selon un troisième aspect, l'invention concerne un serveur d'abonnés agencé pour traiter une requête de service relative à un utilisateur, comprenant : - un module de réception, agencé pour recevoir depuis un serveur d'interrogation, une requête d'obtention d'un identifiant d'un serveur d'enregistrement nominal, suivie d'une réception d'une requête de capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir des services autorisés pour ledit utilisateur ; - un premier module de contrôle, agencé pour détecter qu'une procédure de recherche d'un serveur d'enregistrement de remplacement est en cours d'exécution par le serveur d'interrogation suite à une détection que le serveur d'enregistrement nominal n'est pas joignable par le serveur d' interrogation ; - un deuxième module de contrôle, agencé pour vérifier que le serveur d'enregistrement nominal est actif ; - un module d'envoi, agencé pour envoyer au serveur d'interrogation une commande permettant de déclencher l'interruption de la procédure de recherche et une sélection d'un serveur d'interrogation de remplacement pour traiter la requête de service. Les avantages présentés selon le premier aspect sont directement transposables au serveur d'abonnés selon le troisième aspect. Selon une caractéristique particulière, le serveur d'abonnés comprend en outre un module de commande agencé pour commander lorsqu'une interruption de la procédure de recherche a été déclenchée pour un nombre de serveurs d'interrogation supérieur à un seuil, sur réception en provenance d'au moins un autre serveur d'interrogation, d'une nouvelle requête d'obtention d'un identifiant de serveur d'enregistrement, suivie d'une réception d'une nouvelle requête de capacités, l'identifiant correspondant à l'identifiant du serveur d'enregistrement nominal, une étape d'envoi des capacités. Selon un quatrième aspect, l'invention concerne un serveur d'interrogation, agencé pour traiter une requête de service relative à un utilisateur, comprenant : - un premier module de réception, agencé pour recevoir la requête de service relative à un utilisateur en provenance d'un serveur mandataire ; - un premier module d'envoi, agencé pour envoyer à un serveur d'abonnés une requête d'obtention d'un identifiant d'un serveur d'enregistrement nominal, suivie d'une requête de capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir des services autorisés pour l'utilisateur ; - un module de détection, agencé pour détecter que le serveur d'enregistrement nominal est injoignable ; - un module de commande, agencé pour commander le déclenchement et l'interruption d'une procédure de recherche d'un serveur d'enregistrement de remplacement ; - un deuxième module de réception, agencé pour recevoir depuis le serveur d'abonnés une commande demandant une interruption de la procédure de recherche et une sélection d'un serveur d'interrogation de remplacement pour traiter la requête de service, le serveur d'abonnés ayant vérifié que le serveur d'enregistrement nominal est actif ; - un deuxième module d'envoi, agencé pour envoyer au serveur mandataire une commande de redirection de la requête de service vers un serveur d'interrogation de remplacement pour traiter la requête de service. Les avantages présentés pour l'une quelconque des caractéristiques particulières du procédé selon le deuxième aspect sont directement transposables au serveur d'interrogation selon le quatrième aspect. Selon un cinquième aspect, l'invention a pour objet un système de traitement d'une requête de service dans un réseau de communication comprenant : - un serveur d'abonnés selon l'une quelconque des caractéristiques selon le troisième aspect ; - au moins un serveur d'interrogation selon le quatrième aspect ; - un serveur d'enregistrement agencé pour traiter une requête de service relative à un utilisateur. Selon une caractéristique particulière, le système comprend en outre un serveur mandataire ayant reçu la requête de service, et agencé pour sélectionner un serveur d'interrogation de remplacement sur réception d'une commande de redirection depuis un serveur d'interrogation. Selon un sixième aspect, l'invention concerne également un programme pour un serveur d'abonnés, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé précédemment décrit, lorsque ledit programme est exécuté par ledit serveur et un support d'enregistrement lisible par un serveur d'abonnés sur lequel est enregistré un programme pour un serveur d'abonnés. De même, l'invention concerne également un programme pour un serveur d'interrogation, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé précédemment décrit, lorsque ledit programme est exécuté par ledit serveur et un support d'enregistrement lisible par un serveur d'interrogation sur lequel est enregistré un programme pour un serveur d'interrogation. L'invention sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers, en référence aux dessins annexés sur lesquels : - la figure 1 représente un système de traitement d'une requête de service relative à un utilisateur dans un réseau de communication ; - la figure 2 représente des étapes d'un procédé de traitement d'une requête de service relative à un utilisateur selon un mode particulier de réalisation ; - la figure 3 représente un serveur d'interrogation selon un mode particulier de réalisation ; - la figure 4 représente un serveur d'abonnés selon un mode particulier de réalisation. La figure 1 représente un système 2 de traitement d'une requête de service dans un réseau de communication 1. Les services multimédia offerts par ce réseau 1 peuvent comprendre des services de téléphonie, de vidéo-téléphonie, de partage de contenu, de présence, de messagerie instantanée, ou de télévision. Le système 2 permet de transférer une demande d'enregistrement reçue d'un serveur mandataire 10 vers un serveur d'enregistrement 40, et de bénéficier des services offerts par ce réseau. Plus précisément le serveur mandataire 10 relaie une demande d'enregistrement d'un équipement utilisateur (User Equipment, ou UE en anglais) 50 vers un serveur d'interrogation 20. L'équipement utilisateur 50 est par exemple un terminal fixe ou mobile, ou une passerelle domestique ou d'entreprise. Le système 2 comprend au moins un serveur d'interrogation 20-21, un serveur d'abonnés 30 et le serveur d'enregistrement 40. Le serveur d'abonné 30 communique avec les serveurs d'interrogation 20-21 ainsi qu'avec le serveur d'enregistrement 40. Le serveur mandataire 10 communique avec les serveurs d'interrogation 20- 21. Il est par ailleurs à noter que la figure 1 est une représentation simplifiée du système 2 dans le réseau de communication 1 afin d'en faciliter la compréhension. Aucune limitation n'est attachée au nombre de serveurs d'abonnés, de serveurs d'enregistrement, de serveurs d'interrogation appartenant au réseau de communication. De même, aucune limitation n'est attachée au nombre d'équipements utilisateur. Dans le cas particulier où le réseau de communication 1 présente une architecture de type IMS, les serveurs d'interrogation 20-21 sont des serveurs I-CSCF, le serveur d'enregistrement 40 est un serveur S-CSCF, le serveur d'abonnés 30 est un serveur HSS, le serveur mandataire 10 est un serveur P-CSCF, certains de ces différents serveurs pouvant être rassemblés au sein d'une même entité, le cas échéant. Dans le cas d'une telle architecture IMS, le protocole de signalisation SIP est utilisé pour les échanges avec l'équipement utilisateur 50, ainsi qu'entre les serveurs mandataire 10, d'interrogation 20 et d'enregistrement 40. Les échanges entre le serveur d' abonnés 30 d'une part et le serveur d'interrogation 20 et d'enregistrement 40 d'autre part, sont quant à eux supportés par le protocole Diameter tel que défini dans le document de l'IETF RFC 4740. Il est également à noter que dans un mode particulier de réalisation le système 2 comprend également le serveur mandataire 10. La figure 2 décrit les étapes du procédé de traitement d'une requête de service relative à un utilisateur selon un mode particulier de réalisation. Dans une étape Dl, le serveur d'interrogation 20 reçoit une requête de service Ml relative à un utilisateur en provenance d'un serveur mandataire 10. La requête de service M1 est par exemple une requête SIP REGISTER d'enregistrement auprès d'un serveur d'enregistrement. Le serveur d'interrogation 20 interroge dans une étape D2 le serveur d'abonnés 30 afin d'obtenir un identifiant du serveur d'enregistrement nominal 40 possédant les caractéristiques requises pour atteindre le niveau de service souscrit par l'utilisateur. Cette interrogation est plus particulièrement réalisée par l'envoi d'un message UAR (pour User-Authorization-Request) M2 selon le protocole Diameter tel que défini dans la RFC 4740 et conformément aux spécifications 3GPP TS 24.229 et TS 29.228. Dans une étape El, le serveur d'abonnés 30 reçoit le message UAR M2 et transmet un message UAA M3. Lors d'une étape D3, le serveur d'interrogation 20 reçoit du serveur d'abonnés 30 en réponse à la requête UAR M2, le message UAA (pour User-Authorization-Answer) M3 lui indiquant un identifiant Ids cscF du serveur d'enregistrement nominal 40 auprès duquel l'utilisateur est enregistré. Cet identifiant est par exemple un identifiant uniforme de ressource (Uniform Resource Identifier ou URI en anglais) tel que défini par le document de l'IETF RFC 3986. Le serveur d'interrogation 20 transfere ensuite lors d'une étape D4 la requête SIP REGISTER (message M4) vers le serveur d'enregistrement nominal 40 identifié à l'étape D3. A l'étape D5, une absence de réponse à la requête SIP REGISTER est constatée par le serveur d'interrogation 20. Le protocole SIP prévoit un mécanisme de réémission de messages, à l'issue duquel après plusieurs tentatives d'envoi sans réponse, l'absence de réponse est considérée comme étant identique à un code de réponse 408 Request Timeout, indiquant qu'aucune réponse du serveur d'enregistrement nominal 40 n'a été reçue dans le temps imparti pour le traitement du message. L'absence de réponse du serveur d'enregistrement nominal 40 résulte par exemple d'une panne de ce dernier, d'un trafic réseau perturbé, ou de toute autre cause ne permettant pas de le joindre ou ne permettant pas à ce dernier de répondre à une requête reçue. Dans une étape D6, conformément aux procédures de restauration du service IMS telles que définies dans la spécification technique 3GPP TS 23.380, le serveur d'interrogation 20 initie ne procédure de recherche d'un serveur d'enregistrement de remplacement. Pour cela le serveur d'interrogation 20 envoie au serveur d'abonnés 30 un nouveau message UAR M5 comportant une demande de capacités. La demande de capacités est construite en renseignant le champ UserAuthorization-type du message UAR M5 par la valeur REGISTRATION_AND_CAPABILITIES. Le serveur d'abonnés 30 reçoit la demande de capacités contenue dans le message UAR M5 lors d'une étape E2. La réception de ce message permet au serveur d'abonnés 30 de détecter qu'une procédure de recherche d'un serveur d'enregistrement de remplacement a été initiée par le serveur d'interrogation 20. La détection qu'une procédure de recherche d'un serveur d'enregistrement de remplacement est en cours, est plus précisément obtenue par la réception (étape El) d'un premier message UAR, suivi d'un deuxième message UAR comportant une demande de capacités. Cette séquence de messages UAR indique en effet au serveur d'abonnés 30 que le serveur d'interrogation 20 n'est pas parvenu à joindre le serveur d'enregistrement nominal 40, et qu'une recherche d'un serveur d'enregistrement de remplacement est en cours. Dans une étape E3a, le serveur d'abonnés 30 demande une mise à jour du profil de l'utilisateur au serveur d'enregistrement 40. Cette demande de mise à jour se fait à titre non limitatif par l'envoi d'une requête PPR (Push Profile Request) M6, telle que décrite dans la RFC 4740. L'activité du serveur d'enregistrement 40 est confirmée par la réception (étape E3b) d'une réponse PPA (Push Profile Answer) M7 indiquant que la mise à jour du profil de l'utilisateur a réussi. Le traitement de la réponse à une demande de mise à jour étant par ailleurs de niveau applicatif, une mise à jour réussie permet de s'assurer que le serveur d'enregistrement nominal 40 est joignable au niveau couche applicative. Lorsque l'activité du serveur d'enregistrement nominal 40 est vérifiée (étapes E3a-E3b), le serveur d'abonnés 30 répond (étape E4) au message UAR M2 du serveur d'interrogation 30 en lui envoyant un message UAA M8 comprenant une commande demandant de déclencher d'une part l'interruption de la procédure de recherche d'un serveur d'enregistrement de remplacement et d'autre part la sélection d'un serveur d'interrogation de remplacement pour traiter la requête de service. Le serveur d'interrogation 20 reçoit le message M8 dans une étape D7, et interrompt la procédure de recherche d'un serveur d'enregistrement de remplacement. Dans une étape D8, le serveur d'interrogation 20 obtient l'adresse d'un serveur d'interrogation de remplacement 21 permettant de joindre le serveur d'enregistrement nominal 40. L'adresse du serveur d'interrogation de remplacement 21 est à titre d'exemple obtenue par une interrogation DNS (Domain Name System). Lors d'une étape D9, le serveur d'interrogation 20 envoie au serveur mandataire 10 un message de redirection M9 comprenant l'adresse du serveur d'interrogation de remplacement 21 obtenue à l'étape précédente. Le message de redirection est en particulier un message « SIP (Session Initiation Protocol) 305 ». Le serveur mandataire 10 redirige (étape Hl) la requête de service SIP REGISTER M10 vers le serveur d'interrogation de remplacement 21, ce qui met fin au procédé de traitement de la requête de service. Cette redirection vers le serveur d'interrogation de remplacement est conforme au mécanisme de resélection d'un serveur d'enregistrement décrit en section 5.2.2.1 de la spécification technique 3GPP 24.229, version 12.2.0. Lorsque l'activité du serveur d'enregistrement nominal 40 n'a pu être vérifiée lors des étapes E3a-E3b, le serveur d'abonnés 30 envoie à l'étape E4 une réponse UAA comprenant des capacités qu'un serveur d'enregistrement de remplacement doit disposer pour pouvoir fournir des services autorisés pour l'utilisateur. Le serveur d'interrogation 20 peut alors transférer la requête de service vers un serveur d'enregistrement de remplacement tel que spécifié par exemple par les procédures de restauration de service de la spécification technique TS 23.380. Dans un mode de réalisation particulier, le serveur d'abonnés 30 envoie à l'étape E4 une réponse UAA comprenant des capacités lorsque la procédure de recherche d'un serveur d'interrogation de remplacement 21 a été déclenchée pour un nombre de serveurs d'interrogation supérieur à un seuil. Il s'agit alors d'un retour à une procédure de restauration, permettant une sélection d'un nouveau serveur d'enregistrement. Plus précisément, une liste L des serveurs d'interrogations, pour lesquels une commande permettant de déclencher une sélection d'un serveur d'interrogation de remplacement 21 a été envoyée par le serveur d'abonnés 30, est mémorisée par ce dernier. Lors de l'étape El, le serveur d'abonnés 30 vérifie si le serveur d'interrogation 20 appartient à la liste L. Si tel est le cas, une temporisation T est initialisée. A l'expiration de cette temporisation, le serveur d'interrogation 20 est retiré de la liste L. Dans le cas contraire, c'est-à- dire lorsque le serveur d'interrogation n'appartient pas à la liste, ou lorsque la liste L est vide, les étapes E2 à E4 sont exécutées telles que décrites précédemment en relation avec le premier mode de réalisation. Lors de l'étape E2, le serveur d'abonnés 30 vérifie que le serveur d'interrogation 20 appartient à la liste L. Si le serveur d'interrogation 20 appartient à la liste L, une commande permettant la sélection d'un serveur d'interrogation de remplacement 21 lui a déjà été envoyée, la temporisation T est alors arrêtée. Dans le cas contraire, le serveur d'interrogation 20 est ajouté à la liste L. Lorsque le nombre de serveurs d'interrogation 20-21 de la liste L atteint un seuil S, le serveur d'abonnés envoie à l'étape E4 une réponse UAA comportant les capacités. Le seuil S est paramétré par l'opérateur du réseau avec une valeur inférieure ou égale au nombre de serveurs d'interrogation 20-21 du réseau et peut par exemple prendre la valeur de deux. Le serveur d'enregistrement nominal 40 étant estimé injoignable depuis un nombre trop important de serveurs d'interrogation 20-21, l'envoi des capacités permet alors la sélection d'un serveur d'enregistrement de remplacement, selon la procédure classique de restauration. Si en revanche le nombre de serveurs d'interrogation 20-21 de la liste L est en dessous du seuil S, le serveur d'abonnés continue de répondre avec l'envoi d'un message M8. A l'expiration de la temporisation T, le serveur d'interrogation auquel cette temporisation est associée est en outre retiré de la liste L. Ceci permet de prendre en compte lors de l'envoi d'un prochain message UAR par ce dernier serveur d'interrogation pour le même serveur d'enregistrement nominal 40, le fait que le chemin réseau entre les deux serveurs est de nouveau valide. Cela permet également au serveur d'abonnés 30 de répondre à une prochaine demande de capacités de ce dernier serveur d'interrogation pour le même serveur d'enregistrement nominal par un message M8 tel que décrit précédemment, lorsque la difficulté à joindre le serveur d'enregistrement nominal 40 ne s'est pas manifestée de nouveau pendant une période d'observation. En outre le serveur d'interrogation ainsi retiré de la liste L fourni un chemin réseau permettant d'atteindre le serveur d'enregistrement nominal 40 (i.e. chemin réseau entre le serveur d'interrogation retiré de la liste L et le serveur d'enregistrement nominal 40). Dans un autre mode de réalisation, le serveur d'abonnés 30 mémorise une table construite à partir de l'ensemble des combinaisons de serveurs d'interrogation 20-21 et des serveurs d'enregistrement du réseau. Chaque ligne i de cette table comprend un couple (SIJ ; SEk) formé d'un serveur d'interrogation SIS et d'un serveur d'enregistrement SEk , auquel est associé un compteur C. La table comprend ainsi n * m lignes, avec n le nombre de serveurs d'interrogation du réseau et m le nombre de serveurs d'enregistrement du réseau. Les compteurs sont incrémentés à chaque réception d'un message UAR comprenant une demande de capacités pour le couple (SIS ; SEk) concerné. Les compteurs rendent ainsi compte du nombre de tentatives en échec pour joindre un serveur d'enregistrement SEk donné par un serveur d'interrogation SIS donné. La table permet notamment d'avoir une vision d'ensemble des serveurs d'interrogation et d'enregistrement du réseau. Lorsqu'à l'étape E2 un message UAR comportant une demande de capacités est reçu pour un couple (SIS ; SEk) donné, le serveur d'abonnés 30 consulte sa table et vérifie si un compteur a été incrémenté pour au moins un couple (SI/ ; SEk)1 j. Si seul le compteur Ci a été incrémenté, le serveur d'enregistrement SEk est réputé injoignable en raison d'une panne ou d'un incident intervenu sur le chemin réseau entre le serveur d'interrogation SIS et le serveur d'enregistrement SEk . Le serveur d'abonnés met alors en oeuvre les étapes E3a, E3b et E4 précédemment décrites, avec l'envoi d'un message M8 lorsque l'activité du serveur d'enregistrement nominal est confirmée. Lorsqu'au contraire plusieurs compteurs distincts de Ci pour un même serveur d'enregistrement SEk ont été incrémentés, la panne ou l'incident réseau n'est plus isolé à un chemin réseau entre un serveur d'interrogation et un serveur d'enregistrement particulier. Si le compteur Ci atteint un seuil S1, le serveur d'enregistrement SEk est alors réputé injoignable en raison d'un incident survenu directement sur ce dernier serveur. Cette condition de détermination que le serveur d'enregistrement SEk est injoignable peut également être adaptée pour prendre en compte l'ensemble des compteurs associés au serveur d'enregistrement SEk , en vérifiant par exemple que la somme des compteurs qui lui sont associés est supérieure à un seuil S2. Le serveur d'abonnés renverra alors directement un message UAA comportant les capacités en réponse à un prochain message UAR pour un utilisateur enregistré auprès de SEk. Les compteurs sont régulièrement remis à zéro à l'expiration d'une temporisation. Il est également souligné qu'aucune limitation n'est attachée au mode de vérification de l'activité du serveur d'enregistrement nominal 40. Dans un mode particulier de réalisation, le serveur d'abonnés 30 vérifie que le serveur d'enregistrement nominal est actif, en contrôlant par exemple dans une base de données qui lui est locale si des échanges avec le serveur d'enregistrement nominal 40 associés à une requête de service distincte de celle en cours de traitement ont eu lieu. Ces échanges sont par exemple des messages MAR/MAA (Multimedia Authentication Request / Multimedia Authentication Answer) pour authentifier un utilisateur, ou encore des messages SAR/SAA (Server Assignment Request / Server Assignment Answer) pour l'assignation du serveur d'enregistrement à un utilisateur. L'activité du serveur d'enregistrement nominal 40 peut également être vérifiée par des échanges de messages de surveillance du trafic réseau entre le serveur d'enregistrement 40 et le serveur d'abonnés 30, tels que des messages DWR (Device-Watchdog-Request) et DWA (Device-Watchdog-Answer). Ce mode de réalisation peut en particulier être mis en oeuvre en combinaison avec les étapes E3a et E3b. Il permet alors d'assurer une double vérification de l'activité du serveur d'enregistrement nominal 40, aux niveaux interface et applicatif. Il peut également être mis en oeuvre seul en remplacement des étapes E3a et E3b afin de minimiser les échanges entre serveur d'abonnés 30 et serveur d'enregistrement 40. Dans un mode particulier de réalisation, lors de l'étape D9 le serveur d'interrogation 20 renvoie au serveur mandataire 10 la réponse d'une interrogation DNS obtenue à l'étape D8, dans un message de réponse de type « SIP 3xx » tel que défini dans la RFC 3261. Les messages de réponse de ce type ont vocation à fournir une ou plusieurs adresses auprès de desquelles un appelé, dans le présent mode de réalisation un serveur d'interrogation de remplacement, peut être joint. A cette fin un message de réponse « SIP 311 » est par exemple spécifiquement créé pour le type de redirection décrit. Ce message comprend typiquement une liste constituée de l'ensemble ou d'un sous-ensemble des serveurs d'interrogation du réseau 1 à l'exception du serveur d'interrogation 20 ayant initialement reçu la requête de service. Le serveur mandataire 10 choisit ensuite le serveur d'interrogation de remplacement 21 vers lequel rediriger la requête de service, en fonction par exemple de poids ou de priorités associés par le serveur mandataire 10 à chaque serveur d'interrogation du réseau 1. Dans un mode particulier de réalisation, l'étape D8 d'obtention d'une adresse d'un serveur d'interrogation de remplacement n'est pas mise en oeuvre. Le serveur d'interrogation 20 envoie à l'étape D9 un message de réponse de type « SIP 3xx » indiquant au serveur mandataire 10 que le serveur d'enregistrement nominal 40 est actif mais non joignable par le serveur d'interrogation 20. Par exemple, il s'agit d'un message « SIP 310 » spécifiquement créé à cet effet. A réception de ce message « SIP 310 » le serveur mandataire 10 effectue une interrogation DNS, et sélectionne ensuite le serveur d'interrogation de remplacement 21 vers lequel rediriger la requête de service, en fonction par exemple de poids ou de priorités associés par le serveur mandataire 10 à chaque serveur d'interrogation du réseau 1. Les précédents modes de réalisation ont été décrits pour le traitement d'une requête de service SIP REGISTER. Il n'existe cependant pas de limitations quant aux types de requête de service traités. Le procédé de traitement mis en oeuvre par exemple pour une requête SIP INVITE est équivalent à celui mis en oeuvre pour traiter une requête SIP REGISTER, seuls l'entité émettrice de la requête de service et les types de messages échangés entre le serveur d'interrogation 20 et le serveur d'abonnés 30 diffèrent. L'entité émettrice ne correspond plus à un serveur mandataire 10 mais par d'autres entités telles que des entités IBCF (Interconnection Border Control Function) du réseau nominal de l'utilisateur ou d'un réseau visité, des MGCF (Media Gateway Controller Function), ou encore des AS (Application Server). De même, au lieu des messages UAR et UAA, les serveurs s'échangent respectivement des messages LIR (pour Location Info Request) et LIA (pour Location Info Answer). La figure 3 représente un serveur d'interrogation 20 agencé pour traiter une requête de service relative à un utilisateur. Il comprend notamment : - un premier module de réception 200, agencé pour recevoir la requête de service relative à un utilisateur en provenance d'un serveur mandataire ; - un premier module d'envoi 202, agencé pour envoyer à un serveur d'abonnés 30 une requête d'obtention d'un identifiant d'un serveur d'enregistrement nominal 40, suivie d'une requête de capacités qu'un serveur d'enregistrement 40 doit posséder pour pouvoir fournir des services autorisés pour l'utilisateur ; - un module de détection 204, agencé pour détecter que le serveur d'enregistrement nominal est injoignable ; - un module de commande 208, agencé pour commander le déclenchement et l'interruption d'une procédure de recherche d'un serveur d'enregistrement de remplacement ; - un deuxième module de réception 206, agencé pour recevoir depuis le serveur d'abonnés 30 une commande demandant une interruption de la procédure de recherche et une sélection d'un serveur d'interrogation de remplacement pour traiter la requête de service ; - un deuxième module d'envoi 210, agencé pour envoyer au serveur mandataire 10 une commande de redirection de la requête de service vers un serveur d'interrogation de remplacement 21 pour traiter la requête de service. Dans un mode de réalisation particulier, le serveur d'interrogation comprend également un module de sélection 212 agencé pour obtenir une liste d'adresses de serveurs d'interrogation du réseau et pour sélectionner dans cette liste un serveur d'interrogation de remplacement, le deuxième module d'envoi étant en outre agencé pour envoyer une commande de redirection comprenant une adresse du serveur d'interrogation de remplacement. Dans un autre mode de réalisation, le module de sélection précédemment décrit permet seulement d'obtenir une liste d'adresses de serveurs d'interrogation du réseau. Le deuxième module d'envoi est alors agencé pour transférer la liste au serveur mandataire. Dans un autre mode de réalisation particulier, le deuxième module d'envoi est en outre agencé pour envoyer une commande de redirection comprenant une indication que le serveur d'enregistrement nominal n'est pas joignable par le serveur d'interrogation, permettant au serveur mandataire de déclencher une obtention d'une adresse du serveur d'interrogation de remplacement. La figure 4 représente un serveur d' abonnés 30 agencé pour traiter une requête de service relative à un utilisateur. Il comprend notamment : - un module de réception 300, agencé pour recevoir depuis un serveur d'interrogation 20, une requête d'obtention d'un identifiant d'un serveur d'enregistrement nominal 40, suivie d'une réception d'une requête de capacités qu'un serveur d'enregistrement 40 doit posséder pour pouvoir fournir des services autorisés pour l'utilisateur ; - un premier module de contrôle 302, agencé pour détecter qu'une procédure de recherche d'un serveur d'enregistrement de remplacement est en cours d'exécution par le serveur d'interrogation suite à une détection que le serveur d'enregistrement nominal n'est pas joignable par le serveur d' interrogation ; - un second module de contrôle 304, agencé pour vérifier que le serveur d'enregistrement nominal est actif ; - un module d'envoi 306, agencé pour envoyer au serveur d'interrogation une commande permettant de déclencher une interruption de la procédure de recherche et une sélection d'un serveur d'interrogation de remplacement pour traiter la requête de service. Dans un mode de réalisation particulier, le serveur d'abonnés comprend également un module de commande agencé pour commander lorsqu'une interruption de la procédure de recherche a été déclenchée pour un nombre de serveurs d'interrogation supérieur à un seuil, sur réception en provenance d' au moins un autre serveur d'interrogation, d'une nouvelle requête d'obtention d'un identifiant de serveur d'enregistrement, suivie d'une réception d'une nouvelle requête de capacités, l'identifiant correspondant à l'identifiant du serveur d'enregistrement nominal, une étape d'envoi des capacités. L'invention est mise en oeuvre 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/ou logiciels, apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit précédemment pour le module concerné. 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. Un tel composant logiciel est stocké en mémoire puis chargé et exécuté par un processeur de données d'une entité physique 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). Il peut s'agir d'un composant matériel programmable ou non, avec ou sans processeur intégré pour l'exécution de logiciel. Il s'agit par exemple d'un circuit intégré, d'une carte à puce, d'une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. Dans un mode de réalisation particulier, les modules 200, 202, 204, 206, 208 et 210 sont agencés pour mettre en oeuvre le procédé de traitement précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé de traitement précédemment décrit, mises en oeuvre par un serveur d'interrogation. L'invention concerne donc aussi : - un programme pour un serveur d'interrogation, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de traitement précédemment décrit, lorsque ledit programme est exécuté par ledit serveur d'interrogation ; - un support d'enregistrement lisible par un serveur d'interrogation sur lequel est enregistré le programme pour un serveur d'interrogation. De même, les modules 300, 302, 304 et 306 sont agencés pour mettre en oeuvre le procédé de traitement précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé de traitement précédemment décrit, mises en oeuvre par un serveur d'abonnés. L'invention concerne donc aussi : - un programme pour un serveur d'abonnés, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de traitement précédemment décrit, lorsque ledit programme est exécuté par ledit serveur d'abonnés ; - un support d'enregistrement lisible par un serveur d'abonnés sur lequel est enregistré le programme pour un serveur d'abonnés. Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication. REVENDICATIONS1. Procédé de traitement d'une requête de service relative à un utilisateur dans un réseau de communication (1), mis en oeuvre par un serveur d'abonnés (30) et comprenant les étapes suivantes : - réception (El) depuis un serveur d'interrogation (20) d'une requête d'obtention d'un identifiant d'un serveur d'enregistrement nominal (40), suivie d'une réception (E2) d'une requête de capacités qu'un serveur d'enregistrement de remplacement doit disposer pour pouvoir fournir des services autorisés pour ledit utilisateur ; - détection qu'une procédure de recherche d'un serveur d'enregistrement de remplacement est en cours d'exécution par le serveur d'interrogation, suite à une détection que ledit serveur d'enregistrement nominal n'est pas joignable par ledit serveur d'interrogation ; - vérification (E3a-E3b) que ledit serveur d'enregistrement nominal est actif ; - envoi (E4) d'une commande au serveur d'interrogation, ladite commande permettant de déclencher l'interruption de la procédure de recherche et une sélection d'un serveur d'interrogation de remplacement pour traiter ladite requête de service. 2. Procédé de traitement selon la revendication 1, comprenant en outre lorsqu'une interruption de la procédure de recherche a été déclenchée pour un nombre de serveurs d'interrogation supérieur à un seuil, sur réception en provenance d'au moins un autre serveur d'interrogation, d'une nouvelle requête d'obtention d'un identifiant de serveur d'enregistrement, suivie d'une réception d'une nouvelle requête de capacités, ledit identifiant correspondant à l'identifiant dudit serveur d'enregistrement nominal, une étape d'envoi desdites capacités. 3. Procédé de traitement d'une requête de service relative à un utilisateur, mis en oeuvre par un serveur d'interrogation (20) et comprenant les étapes suivantes : - réception (Dl) de ladite requête de service relative à un utilisateur en provenance d'un serveur mandataire ; - envoi (D2) à un serveur d'abonnés (30) d'une requête d'obtention d'un identifiant d'un serveur d'enregistrement nominal (40), détection que le serveur d'enregistrement nominal est injoignable et déclenchement d'une procédure de recherche d'un serveur d'enregistrement de remplacement, envoi d'une requête (D6) de capacités qu'un serveur d'enregistrement de remplacement doit disposer pour pouvoir fournir des services autorisés pour ledit utilisateur ; - réception (D7) depuis le serveur d'abonnés (30) d'une commande demandant une interruption de la procédure de recherche et une sélection d'un serveur d'interrogation de remplacement pour traiter ladite requête de service, le serveur d'abonnés ayant vérifié que le serveur d'enregistrement nominal est actif ;- envoi (D9) au serveur mandataire (10) d'une commande de redirection de ladite requête de service vers un serveur d'interrogation de remplacement (21) pour traiter ladite requête de service. 4. Procédé de traitement selon la revendication 3, dans lequel ledit serveur d'interrogation sélectionne le serveur d'interrogation de remplacement et la commande de redirection comprend une adresse du serveur d'interrogation de remplacement. 5. Procédé de traitement selon la revendication 3, dans lequel la commande de redirection comprend une indication que le serveur d'enregistrement nominal n'est pas joignable par le serveur d'interrogation, permettant au serveur mandataire de déclencher une obtention d'une adresse du serveur d'interrogation de remplacement. 6. Procédé de traitement selon la revendication 3, dans lequel la commande de redirection comprend une liste d'adresses de serveurs d'interrogation dudit réseau, le serveur d'interrogation de remplacement étant sélectionné par ledit serveur mandataire dans ladite liste. 7. Serveur d'abonnés (30), agencé pour traiter une requête de service relative à un utilisateur, comprenant : - un module de réception (300), agencé pour recevoir depuis un serveur d'interrogation (20), une requête d'obtention d'un identifiant d'un serveur d'enregistrement nominal (40), suivie d'une réception d'une requête de capacités qu'un serveur d'enregistrement (40) doit posséder pour pouvoir fournir des services autorisés pour ledit utilisateur ; - un premier module de contrôle (302), agencé pour détecter qu'une procédure de recherche d'un serveur d'enregistrement de remplacement est en cours d'exécution par le serveur d'interrogation suite à une détection que ledit serveur d'enregistrement nominal n'est pas joignable par ledit serveur d'interrogation ; - un deuxième module de contrôle (304), agencé pour vérifier que ledit serveur d'enregistrement nominal est actif ; - un module d'envoi (306), agencé pour envoyer au serveur d'interrogation une commande permettant de déclencher l'interruption de la procédure de recherche et une sélection d'un serveur d'interrogation de remplacement pour traiter ladite requête de service. 8. Serveur d'abonnés selon la revendication 7, comprenant en outre un module de commande agencé pour commander lorsqu'une interruption de ladite procédure de recherche a été déclenchée pour un nombre de serveurs d'interrogation supérieur à un seuil, sur réception en provenance d'au moins un autre serveur d'interrogation, d'une nouvelle requête d'obtention d'un identifiant de serveur d'enregistrement, suivie d'une réception d'une nouvelle requête de capacités, leditidentifiant correspondant à l'identifiant du serveur d'enregistrement nominal, une étape d'envoi desdites capacités. 9. Serveur d'interrogation (20), agencé pour traiter une requête de service relative à un utilisateur, comprenant : - un premier module de réception (200), agencé pour recevoir ladite requête de service relative à un utilisateur en provenance d'un serveur mandataire ; - un premier module d'envoi (202), agencé pour envoyer à un serveur d'abonnés (30) une requête d'obtention d'un identifiant d'un serveur d'enregistrement nominal (40), suivie d'une requête de capacités qu'un serveur d'enregistrement (40) doit posséder pour pouvoir fournir des services autorisés pour ledit utilisateur ; - un module de détection (204), agencé pour détecter que le serveur d'enregistrement nominal est injoignable ; - un module de commande (208), agencé pour commander le déclenchement et l'interruption d'une procédure de recherche d'un serveur d'enregistrement de remplacement ; - un deuxième module de réception (206), agencé pour recevoir depuis le serveur d'abonnés (30) une commande demandant une interruption de la procédure de recherche et une sélection d'un serveur d'interrogation de remplacement pour traiter ladite requête de service, le serveur d'abonnés ayant vérifié que le serveur d'enregistrement nominal est actif ; - un deuxième module d'envoi (210), agencé pour envoyer au serveur mandataire (10) une commande de redirection de ladite requête de service vers un serveur d'interrogation de remplacement (21) pour traiter ladite requête de service. 10. Système de traitement d'une requête de service dans un réseau de communication (1), ledit système comprenant : - un serveur d'abonnés (30) selon l'une des revendications 7 à 8 ; - au moins un serveur d'interrogation (20-21) selon la revendication 9 ; - un serveur d'enregistrement (40) agencé pour traiter une requête de service relative à un utilisateur. 30 11. Système selon la revendication 10, comprenant en outre un serveur mandataire (10), ledit serveur mandataire ayant reçu ladite requête de service, agencé pour sélectionner un serveur d'interrogation de remplacement (21) sur réception d'une commande de redirection depuis un serveur d'interrogation (20). 35 12. Programme pour un serveur d'abonnés (30), comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé selon l'une des revendications 1 à 2, lorsque ledit programme est exécuté par ledit serveur. 13. Programme pour un serveur d'interrogation (20), comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé selon l'une des revendications 3 à 6, lorsque ledit programme est exécuté par ledit serveur.