FR 2841072 A1 20031219 FR 0207510 A 20020614 La présente invention concerne un système de consultation et /ou mise à jour de serveurs DNS (Domain Name System) et/ou d'annuaires LDAP (Lightweight Directory Access Protocol) à partir d'un terminal. La présente invention permet notamment à un abonné, à partir d'un terminal quelconque, de consulter et de mettre à jour un enregistrement de ressources de télécommunication stocké dans un serveur DNS ou LDAP. Les serveurs DNS (et LDAP) sont utilisés dans le monde informatique pour nommer des machines (par exemple : associationd'une URL web à une adresse IP correspondant au serveur web hébergeant ce site web). Ces serveurs sont habituellement consultés par des machines informatiques au moyen d'un logiciel communément appelé RESOLVER, disponible dans la plupart des terminaux ou serveurs informatiques. Ce logiciel permet d'extraire une information d'un serveur DNS en réponse à la requête d'un client. Cette information peut être disponible directement auprès du premier serveur DNS consulté ou bien auprès d'un serveur DNS référencé par le premier, et ainsi de suite si nécessaire par indirections successives. Les contenus des serveurs DNS sont mis à jour par des spécialistes "administrateur" et de manière peu fréquente (mise à jour de fichiers à plat sous plateforme UNIX ou application dédiée via IHM sous les plate-formes serveurs Windows). Le format des contenus des serveurs et des requêtes sont définis dans un protocole, dit protocole DNS décrit dans les documents RFC 1034 et RFC 1035, disponibles sur le site web de l'IETF (www.ietforg). D'autre part, les serveurs DNS sont désormais appelés à jouer un rôle dans le cadre du service ENUM visant à offrir aux abonnés une portabilité généralisée de numéro de téléphone. Ce service ENUM utilise le système de numérotation téléphonique international défini par FUIT sous la recommandation E.164. Plus précisément, le service ENUM permet à tout abonné disposant d'une numéro téléphonique unique E.164 (numéro de téléphone de type +33296053859) d'être joint par différents moyens en fonction de ses préférences configurées dans un profil hébergé dans le réseau par un serveur DNS. Par exemple, le numéro de téléphone unique E.164 de l'abonné ENUM peut être associé à un numéro de téléphone mobile (+33686166924), à un numéro de téléphone fixe (+33296916404), à une adresse eMail (bertrand dupont@rd francetelecom com), à une URL de site web (http //www bertrand dupent com), à un numéro de téléphone VoIP (sip:bertrand.dupont@sip.francetelecom.com), à un numéro de fax, etc. L'ensemble de ces informations peuvent être stockées dans un serveur DNS standard et accédées selon le modèle de délégation hiérarchique représenté en Fig. 1. L'accès se fait par un serveur DNS racine (E164. ARPA). Chaque pays dispose ensuite d'un code téléphonique unique (33 pour la France) et un serveur DNS est géré au niveau 1 par chaque pays (3.3.E164.ARPA pour la France). Des opérateurs de télécommunications ou des fournisseurs de services ENUM gèrent enfin des serveurs DNS (indiqué en Fig. 1 par DNS 1 à DNS 6) en fonction des ressources téléphoniques (tranche de numéros téléphoniques E. 164) qui leur sont attribuées. Le modèle retenu est un découpage par tranches : tranches de numéros de téléphone fixes RTC avec des préfixes allant de 1 à 5 et une tranche de numéros de téléphone mobile identifiée par le préfixe 6. A un numéro de téléphone au format E. 164, est associé un chemin dans l'arborescence des serveurs DNS. Plus précisément, chaque numéro de téléphone au format international E. 164 est inversé, le code "+" est supprimé, un point est ajouté entre chaque chiffre et le résultat obtenu est accolé au domaine el64.arpa de manière à transformer le numéro de téléphone en un nom de domaine Internet unique. Par exemple, le numéro de téléphone +33686166924 donne après transformation, le nom de domaine Internet 4.2.9.6.6.1.6.8.6.3.3.el64.arpa. D'autre part, à chaque numéro de téléphone au format E. 164 est associé un enregistrement comprenant un ou des enregistrements de ressources (Resource Record ou RR), stockés dans le serveur de niveau 2 correspondant, chaque enregistrement de ressource pouvant comprendre un ou plusieurs champs. Par exemple, à un numéro de téléphone au format E. 164 peuvent être associés des enregistrements de ressource NAPTR (Naming Authority PoinTeR), tels que définis dans les documents RFC 2915 et RFC 2916, disponibles sur le site de l'IETF. De manière schématique, un enregistrement de ressource NAPTR indique un service de télécommunication (n de tel, fax, adresse eMail, site web etc. ) associé à un niveau de priorité. On appellera par la suite enregistrement ENUM (ou profil ENUM) un ensemble d'enregistrements NAPTR associés à un nom de domaine Internet. Par exemple, si le profil ENUM suivant est stocké dans un serveur DNS de niveau 2 : $ORIGIN9.5.8.3.5.0.6.9.2.3.3.el64.arpa. IN NAPTR 100 10 "u" "tel+E2U" "!^.*@!tel+33296053859!" IN NAPTR 100 11 "u" "tel+E2U" "!^.*@tel:+33296916404!" IN NAPTR 100 12 "u" "tel+E2U" "!^.*@!tel:+33686166924! IN NAPTR 100 13 "u" "sip+E2U" "!^.*@!sip:bdupont@sip.ftrd.fr!" IN NAPTR 120 10 "u" "mailto+E2U" "!^.*@!mail2:bdupont@rd.ftrd.fr!" IN NAPTR 130 10 "u" "http+E2U" "!^.*@!http://www.bdupont.fr!" La ligne d'en-tête indique un nom de domaine Internet correspondant au numéro de téléphone E.164. Le logiciel RESOLVER permet à partir du nom de domaine d'accéder à l'enregistrement. A chaque enregistrement NAPTR de l'exemple cidessus correspond une ressource ou service de télécommunication. Deux champs numériques suivent le terme NAPTR , il s'agit respectivement des priorités de service : "Ordre" et "Préférence". Plus la valeur du champ "Ordre" est faible, plus le service est prioritaire et si plusieurs services ont un niveau d'ordre identique, plus la valeur de Préférence associée est faible, plus le service est prioritaire. Ainsi, les lignes de l'enregistrement ci-dessus correspondent à des priorités décroissantes. La 1ère ligne correspond au service téléphonique fixe 0296053859 avec un ordre=100 et une préférence =10. La 2ème ligne correspond au service téléphonique fixe 0296916404 avec un ordre=100 et une préférence=11 . La 3ème ligne correspond au service téléphonique mobile 0686166924 avec un ordre=100 et une préférence=12 . La 4ème ligne correspond au service téléphonique IP via SIP vers l'adresse SIP bdupont@sip.ftrd fr avec un ordre=100 et une préférence=13 . La 5ème ligne correspond au service de courrier électronique eMail dont l'adresse de destination est bdupont@rd.ftrd.fr avec un ordre=120 et une préférence=10 . Enfin, la 6ème ligne correspond au service web dont l'URL d'accès est http //www bdupont fr avec un ordre=130 et une préférence=10 . La signification de cet enregistrement est la suivante. Si l'on cherche à joindre le numéro de téléphone E. 164 (+33296053859), le logiciel RESOLVER transmet une requête au serveur DNS niveau 2 avec le nom de domaine Internet correspondant (9.5.8.3.5.0.6.9.2.3.3.el64.arpa). En retour, le serveur DNS niveau 2 (DNS2) fournira dans la réponse la liste des ressources de télécommunication (également dénommés ci-après services) associés au numéro de téléphone +33296053859, telle que donné par l'enregistrement. Le logiciel RESOLVER et le service ENUM pourront alors exploiter tout ou partie de ces ressources en mode séquentiel (le système tentera de joindre le service le plus prioritaire puis, en l'absence de réponse ou en cas d'occupation, le système essaiera de joindre le service de moindre priorité, etc. ) ou en mode diffusion (le service ENUM tentera alors de joindre simultanément l'ensemble des services). La modification des profils ENUM dans un serveur DNS s'accommode mal du procédé de mise à jour par administrateur tel que connu de l'état de la technique. En effet, au contraire des noms de domaines Internet, les services classiques de télécommunication tels que le téléphone ou la télécopie sont susceptibles de modification fréquente. Qui plus est, il est quelquefois nécessaire de programmer ces modifications de manière automatique sur une base quotidienne voire horaire. Il est alors extrêmement difficile pour des raisons de disponibilité et de flexibilité de faire supporter la modification de configuration d'un profil ENUM à son propre opérateur de télécommunications ou à son fournisseur de service ENUM. Un problème particulier à la base de l'invention est de permettre à un abonné une consultation et/ou une modification simple et rapide de son profil ENUM stocké dans un serveur DNS ou un annuaire LDAP. De manière plus générale, le problème à la base de l'invention est de permettre une consultation et/ou modification simple et rapide d'un ou de plusieurs enregistrement (s) de ressource stocké (s) un serveur DNS ou LDAP et ce, à partir d'un terminal conventionnel quelconque. Le problème à la base de l'invention est résolu par un système de consultation et/ou de mise à jour d'un enregistrement stocké dans une première base de données, ledit enregistrement comprenant un ou une pluralité d'enregistrements de ressources, ladite première base de données étant hébergée par un serveur de noms de domaine, dit serveur DNS, ou un serveur d'annuaire, dit serveur LDAP, pouvant être accédé par indirection à partir d'un serveur DNS, ledit système comprenant: - des moyens de communication permettant audit système de recevoir d'un terminal de télécommunication une demande de consultation et/ou de modification dudit enregistrement ou une programmation d'une telle demande ; - des moyens de contrôle adaptés à déterminer à partir de ladite demande de consultation et/ou de modification transmise au dit système ou préalablement programmée dans ledit système, un nom de domaine et une opération à effectuer sur ledit enregistrement ; - des moyens de gestion de protocole adaptés à rechercher à partir dudit nom de domaine, l'adresse IP dudit serveur hébergeant ladite première base de données et, en fonction de ladite opération, à transmettre au dit serveur une requête de lecture ou de mise à jour dudit enregistrement. Avantageusement, ledit système comprend des moyens d'authentification adaptés à authentifier au niveau applicatif l'émetteur de ladite demande à partir d'informations d'authentification stockées dans une seconde base de données locale ou distante. Lorsque l'émetteur de ladite demande a été authentifié, lesdits moyens de gestion de protocole permettent de transmettre une requête en consultation selon le protocole DNS (DNS Query) audit serveur DNS, la requête ayant pour argument ledit nom de domaine, et à recevoir une première réponse dudit serveur. Selon un mode de réalisation, les moyens de contrôle sont adaptés à déterminer ledit nom de domaine à partir d'un identifiant d'abonné qui pourra être le numéro téléphonique E.164 dudit abonné. Les moyens de contrôle sont alors adaptés à extraire des informations et à déterminer en fonction de ladite demande une opération à effectuer sur un enregistrement de ressource de type NAPTR. Selon d'autres modes de réalisation les moyens de contrôle sont adaptés à extraire des informations et à déterminer en fonction de ladite demande une opération à effectuer sur un ou plusieurs enregistrements de ressource de type A, NS, MD, MF, CNAME, SOA, MB, MG, MR, NULL, WKS, PTR, HINFO, MINFO,MX, TXT. Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : la Fig. 1 illustre schématiquement le modèle de délégation utilisé dans le service ENUM ; la Fig. 2A illustre schématiquement un exemple d'environnement du système selon l'invention; la Fig. 2B illustre schématiquement l'environnement de la Fig. 2A dans le contexte du service ENUM ; la Fig. 3A représente le schéma de principe du système de consultation/ mise à jour selon l'invention ; la Fig. 3B représente un exemple de système de consultation/ mise à jour selon l'invention ; la Fig. 4 représente schématiquement une procédure de consultation et mise à jour manuelle d'un profil ENUM avec accès en mode vocal ; la Fig. 5 représente schématiquement une procédure de consultation et mise à jour manuelle d'un profil ENUM par envoi de messages SMS ; la Fig. 6 représente schématiquement une procédure de consultation et mise à jour manuelle d'un profil ENUM par le Web ; la Fig. 7 représente schématiquement une procédure de consultation et mise à jour manuelle d'un profil ENUM à partir d'un Minitel; la Fig. 8 représente schématiquement une procédure de consultation et mise à jour manuelle d'un profil ENUM par eMail; la Fig. 9 représente schématiquement une procédure de consultation et mise à jour manuelle d'un profil ENUM par IUU à partir d'un terminal RNIS ; la Fig. 10 représente schématiquement une procédure de programmation de mise automatique de profil ENUM ; la Fig. 11 représente schématiquement une procédure de mise à jour automatique de profil ENUM ; la Fig. 12 représente schématiquement une procédure de consultation de profil ENUM lorsque ce dernier est stocké dans un annuaire LDAP ; la Fig. 13 représente schématiquement une procédure de mise à jour de profil ENUM lorsque ce dernier est stocké dans un annuaire LDAP. La Figure 2A illustre un exemple d'environnement du système selon l'invention. Des fournisseurs de service de gestion de ressources de télécommunication, ciaprès dénommés fournisseurs de service, ont été schématiquement représentés en 301,..,30N. Chaque fournisseur de service dispose d'un serveur DNS (31,) ou LDAP (34,) hébergeant une base de données et plus généralement de plusieurs serveurs redondants de manière à augmenter la fiabilité de l'accès au service. La base de données contient un enregistrement des ressources de télécommunication pour tous les abonnés du fournisseur de service en question. Le système (50) selon l'invention peut être connecté d'une part au réseau téléphonique public via une interface standard de type analogique ou numérique TO ou T2 et, d'autre part, au réseau IP via une interface standard de type Ethernet. Plus précisément, le système (50) est connecté au réseau Internet si la présente invention est accessible à tout abonné, quel que soit son fournisseur de service, et pourra être connecté à un réseau Intranet si la présente invention est accessible aux seuls abonnés d'un fournisseur de service. Le système (50) pourra être accédé par un terminal téléphonique RNIS (2) connecté soit directement soit a travers un PABX (3) au réseau RNIS (10). On rappelle que le réseau RNIS est interconnecté nativement au réseau RTC. Le système (50) pourra aussi être accédé par un terminal téléphonique classique (4) ou un terminal Minitel (5) connecté au réseau RTC (11). Le système (50) pourra encore être accédé par un terminal mobile GSM (6) ou encore un terminal UMTS non représenté (les réseaux GSM et UTRAN sont interconnectés nativement au réseau RTC). Le système (50) pourra être accédé au moyen d'un terminal téléphonique IP (7) connecté au réseau IP (13). Le système (50) pourra enfin être accédé au moyen d'un micro-ordinateur (8) relié au réseau IP soit au travers une interface Ethernet (réseau local d'entreprise) soit par modem (RTC/RNIS/ADSL/câble/satellite etc. ) L'abonné pourra en outre recevoir des notifications du système (50) grâce à l'un des terminaux envisagés ci-dessus ou bien encore à l'aide d'un terminal fax (9). La Figure 2B illustre un exemple d'environnement du système selon l'invention, dans le contexte d'un service ENUM. Les éléments portant les mêmes numéros de référence sont identiques à ceux de la Fig. 2A. On a indiqué en 40 le serveur DNS ENUM de niveau 0 (racine). Ce serveur dispose de l'ensemble des adresses IP référençant l'ensemble des serveurs DNS ENUM de niveau 1, correspondant aux codes des différents pays (33 pour la France, 34 pour l'Espagne, 44 pour l'Angleterre, etc. ). Par exemple, on a fait figurer en 41 le serveur DNS ENUM de niveau 1 correspondant à la France. Chaque opérateur ou fournisseur de service ENUM dispose d'au moins un premier serveur DNS ENUM de niveau 2 (31,), dit serveur primaire, redondé par au moins un second serveur DNS ENUM de niveau 2 (31',), dit serveur secondaire, ce afin d'assurer une bonne fiabilité de service. Le serveur primaire (resp. secondaire) héberge une base de données 33, (resp. 33',). Dans chaque serveur de niveau 2, est stocké, pour chaque numéro de téléphone E.164 d'abonné au service ENUM, un profil composé des différentes ressources de télécommunication de l'abonné, chaque ressource correspondant à un moyen d'accès (par ex. téléphone fixe bureau, téléphone fixe domicile, téléphone mobile, téléphone IP, adresse eMail du bureau, adresse eMail du mobile, N de fax professionnel, etc. ) ainsi que les priorités afférentes à chacun de ces moyens d'accès. Chaque ressource de télécommunication est déclarée au moyen d'un enregistrement de ressource NAPTR comme on l'a vu plus haut. La priorité d'une ressource est déterminée par le contenu des champs Ordre et Préférence de l'enregistrement de ressource NAPTR, tels que définis dans le document RFC 2915 de l'IETF et exemplifiés dans la partie introductive. Un fournisseur A de service ENUM (30,) peut également disposer d'un serveur LDAP (34,) hébergeant un annuaire dynamique LDAP (36,) tel que défini dans le document RFC 1959 de l'IETF. L'intérêt de cette configuration est de permettre de gérer les profils ENUM par indirection non plus dans le DNS ENUM niveau 2 mais dans l'annuaire dynamique LDAP. L'avantage procuré consiste à ne plus modifier le profil du client ENUM au niveau du serveur DNS ENUM niveau 2 mais directement dans l'annuaire LDAP qui, lui, est conçu pour stocker des profils dynamiques. Dans ce cas, le DNS ENUM niveau 2 (31,) contient par exemple le profil suivant pour l'ensemble des numéros de téléphone E.164 commençant par le préfixe "+332": $ORIGIN 2.3.3.el64.arpa. IN NAPTR 100 10 "u" "ldap+E2U" " !^.+332(.*)@!]dap://ldap.fournisseurA.fr/cn=01!" L'annuaire LDAP (36,) est accédé par indirection à partir du serveur DNS ENUM de niveau 2 et contient les enregistrements de ressource pour les différents abonnés du fournisseur A. Un serveur ou une passerelle ENUM (80) peut consulter un fournisseur de service ENUM (30,) pour connaître la liste des ressources de télécommunication d'un abonné ENUM. Pour ce faire, le logiciel RESOLVER transforme le numéro unique E.164 de l'abonné en nom de domaine comme on l'a vu plus haut et accède par indirections successives au serveur DNS ENUM niveau 2 (31,) et, le cas échéant, après indirection supplémentaire au serveur LDAP (34j). Le fournisseur de service retourne la liste des ressources de l'abonné en question avec les priorités associées. Le serveur ou la passerelle ENUM (80) peut alors, selon le cas, tenter de joindre l'abonné en utilisant successivement les ressources, par ordre décroissant de priorité ou joindre l'abonné au moyen de l'ensemble de ses ressources. La Fig. 3A représente le schéma de principe du système (50) de mise à jour selon l'invention. Le système comprend des moyens de communication (1150) permettant à un abonné de dialoguer avec ledit système et notamment : de transmettre à l'abonné une requête en authentification ; de recevoir dudit abonné des informations permettant son authentification ; de recevoir dudit abonné une demande de modification d'un enregistrement (dite demande manuelle) ou une demande de modification automatique (dite demande programmée) en fonction d'un critère temporel ou géographique ; - de transmettre le contenu d'un enregistrement préalablement ou postérieurement à la demande de modification ; - de transmettre au dit abonné une notification de confirmation de mise à jour lorsque la modification demandée a bien été effectuée et d'infirmation de mise àjour lorsque cette dernière n'a pu être effectuée; de transmettre au dit abonné, à fin de consultation ou révision, une demande de modification automatique préalablement enregistrée dans ledit système ; de transmettre au dit abonné un historique des modifications effectuées. Le système comprend également des moyens d'interface (1160) permettant de connecter lesdits moyens de communication au réseau RTC/RNIS et/ou à un réseau IP (Internet ou Intranet). Le système comprend encore des moyens d'authentification (1173) coopérant avec les moyens de communication pour authentifier au niveau applicatif un émetteur de demande de consultation et/ou mise à jour. L'authentification au niveau applicatif présente l'avantage de permettre à un abonné d'opérer à partir de n'importe quel terminal. Les moyens d'authentification utilisent pour ce faire des informations d'authentification stockées dans une base de données (1170) locale ou distante . Outre les informations susmentionnées, la base de données (1170) peut notamment contenir des programmes de modification automatique relatifs à différents abonnés, les adresses IP des serveurs des différents fournisseurs de gestion de ressources de télécommunication, les historiques de modifications manuelles ou automatiques des enregistrements, les adresses auxquelles les notifications de confirmation/infirmation de mise à jour doivent être transmises. Le système (50) comprend encore des moyens de gestion de protocole (1162) assurant entres autres la fonction RESOLVER. En particulier les moyens de gestion de protocole sont adaptés à rechercher, le cas échéant par indirections successives, le contenu d'un enregistrement de ressource (RR) à l'aide d'un nom de domaine. Les moyens de gestion de protocole peuvent transmettre à cette fin des requêtes de consultation selon le protocole DNS (DNS Query). En outre, les moyens de gestion de protocole peuvent mettre à jour des enregistrements de ressources à partir de requêtes de mise à jour (DNS Update). Selon un mode de réalisation, si des enregistrements de ressources sont stockées dans un annuaire LDAP, les moyens de gestion de protocole permettront également la consultation d'un enregistrement dans un annuaire LDAP (émission d'une requête LDAP Search) ainsi que la mise à jour de cet enregistrement (émission d'une requête LDAP Modify). Lorsque la mise à jour a été réalisée, les moyens de protocole reçoivent un acquittement du serveur du fournisseur de gestion de ressources de télécommunication. Les moyens de contrôle 1175coordonnent les moyens précités et notamment : ordonnent aux moyens de communication la transmission d'une requête en authentification ; après authentification de l'abonné par les moyens d'authentification (1173) demandent aux moyens de protocole (1162) de transmettre une requête en consultation, formatent la réponse et la retransmettent sous forme intelligible à l'abonné via les moyens de communication; à partir d'une demande en modification d'un enregistrement de ressource par un abonné, déterminent une opération à effectuer sur ledit enregistrement et un identifant de l'abonné sur réception de confirmation/infirmation de mise à jour par les moyens de protocole, notifient la confirmation/infirmation à l'abonné via les moyens de communication. La Fig. 3B illustre un exemple de réalisation de l'invention dans le contexte d'un service ENUM. Les éléments portant les mêmes numéros de référence sont identiques à ceux de la Fig. 2A. En particulier, l'abonné pourra contacter le système de mise à jour (50) au moyen de l'un des terminaux envisagés plus haut. En (30) a été représenté un fournisseur de service de gestion de ressources de télécommunication comprenant un serveur DNS de niveau 2 (31), dit serveur primaire, redondé par un serveur secondaire (non représenté). Le serveur (31) comporte une base de données (33) et une pile de protocole DNS (32) intégrant les protocoles DNS décrits dans les documents RFC 1034 et RFC 1035. La pile de protocole intègre également les protocoles DNS décrits dans les documents RFC 2136 et RFC 2137 destinés à permettre la mise à jour (DNS Update) d'un enregistrement de ressource (RR). De manière optionelle, le fournisseur de service de gestion de ressources comprend aussi un serveur d'annuaire LDAP (34) hébergeant une base de données (36). Le serveur d'annuaire LDAP comporte une pile de protocole LDAP (35). Les moyens de communication du système (50) sont constitués des modules suivants : o un module ayant en charge le traitement des appels téléphoniques entrants et sortants (52). Ce module gère l'établissement et la libération de la communication ; o un module (53) de gestion d'Information d'Usager à Usager (IUU) permettant d'extraire et de transmettre des informations IUU ; o un module (54) de traitement des codes DTMF. Ce module a en charge la récupération des DTMF saisis par l'abonné ; o un module (55) de synthèse vocale ; o un module (56) de diffusion de fichiers vocaux pré-enregistrés et concaténés pour former des phrases ; o un serveur videotex (57) ; o un module de réception et d'envoi de SMS (58) ; o un module d'envoi de fax (59) ; o un serveur SMTP (61) permettant l'émission et la réception d'eMail ; o un serveur Web dynamique (63). Il convient de noter que le système peut comprendre également un module de reconnaissance vocale (non représenté) adapté à reconnaître une information prononcée par l'abonné. Les moyens de communication sont reliés à l'extérieur au moyen d'une interface RTC et/ou RNIS (51) et une interface IP (60). La première est basée soit sur une carte analogique RTC multi-port soit sur une carte RNIS TO (2 canaux) ou T2 (30 canaux). La seconde est une interface Ethernet. La passerelle indiquée par (14) rappelle que les réseaux RTC/RNIS et IP sont nativement interconnectés en protocole VOIP (H323/SIP). Le système (50) comporte, comme précédemment, des moyens d'authentification (73) autorisant l'authentification applicative des abonnés du service à partir d'informations d'authentification, par exemple des couples de pseudonymes (Login~Id) et de mots de passe stockés dans une base de données (70) locale ou distante. En outre, la base de données comprend les identifiants des différents fournisseurs de service ENUM (tel que 30), les adresses IP ou les noms de machine des DNS tiers 2, des demandes de modification automatique de profil ENUM, les historiques de modification manuelle ou automatique de profils ENUM, les adresses de notification de modification du profil ENUM (N de fax, SMS, eMail). Le système comprend encore un module de gestion de protocole DNS (62), de préférence dans sa forme sécurisée (DNSSec). Ce module joue en particulier le rôle de RESOLVER pour la lecture des enregistrements de ressource. Le cas échéant, un module de gestion de protocole LDAP (64) y est adjoint pour permettre la lecture et la modification d'enregistrements dans un annuaire LDAP. Le système comprend également un module (72) permettant la configuration des adresses des serveurs DNS de niveau 2 ainsi qu'un module (71) chargé de tenir à jour les modifications manuelles ou automatiques des profils ENUM et d'élaborer, le cas échéant, des statistiques pour l'exploitant du système. Les moyens de contrôle sont constitués, d'une part, d'un module (74) chargé de la configuration automatique de profils ENUM à partir de demandes de modification automatique programmées par des abonnés et stockées dans la base de données (70) et, d'autre part, d'un module (75) chargé de la configuration manuelle des profils ENUM. Ce dernier gère des scripts ENUM, notamment un script de lecture de profil ENUM (on rappelle qu'un profil ENUM est constitué d'une liste d'enregistrements de ressource NAPTR), des scripts de modification des champs des enregistrements de ressource NAPTR et notamment des champs ordre, préférence, service (adresse eMail, numéro de téléphone, adresse eMail etc. ). Si l'on souhaite prévoir la consultation et/ou la mise à jour d'enregistrements de ressource DNS autres que NAPTR, des scripts supplémentaires doivent être prévus pour leur modification. La Fig. 4 illustre schématiquement une procédure de consultation et de modification manuelle d'un profil ENUM en mode vocal via un téléphone fixe ou mobile de type RTC, RNIS, GSM ou IP. L'abonné ENUM émet à l'étape 100 un appel téléphonique gratuit (type numéro vert) ou payant selon un mode de rémunération géographique ou forfaitaire de type audiotel ou numéros colorés depuis un terminal fixe RTC (4) ou RNIS (2) connecté sur le réseau public ou derrière un PABX (3) ou un terminal mobile (6) de type GSM, ou depuis un terminal IP (7) à destination de l'interface RTC/RNIS (51) du système (50). L'automate de traitement d'appel (52) accepte automatiquement l'appel entrant à l'étape 101. Le module script ENUM (75) donne à l'étape 102 l'ordre au module de synthèse vocale (55) ou au module de diffusion de fichiers vocaux (56) de diffuser à l'étape 103 vers l'abonné ENUM une annonce vocale invitant l'abonné ENUM à saisir son numéro ENUM E. 164 ainsi que son pseudonyme et son mot de passe . L'abonné ENUM saisit à l'étape 104 via son clavier ces informations qui sont véhiculées dans la bande sous forme de DTMF et qui sont interceptées par le module de traitement des DTMF (54). Ces informations sont fournies à l'étape 105 au module d'authentification (73) qui interroge la base de données locale ou distante (via par exemple une interface de type ODBC (pour Open DataBase Connectivity)) en opérant une recherche sur le Numéro ENUM E. 164. Celle-ci fournit à l'étape 107 les informations d'authentification correspondantes au module d'authentification (73). Ce dernier compare le pseudonyme et le mot de passe saisis par le client ENUM avec les informations d'authentification contenues dans la base de données (70). En cas de concordance, le module d'authentification (73) ordonne à l'étape 108 au module de synthèse vocale (55) ou au module de diffusion de fichiers vocaux de diffuser à l'étape 109 vers l'abonné ENUM une annonce du type "Pour consulter votre profil ENUM taper sur la touche 1, pour modifier les attributs de votre profil taper sur 2, pour configurer de manière automatique votre profil tapez sur 3, pour modifier votre pseudonyme-mot de passe tapez sur 4, pour accéder à votre journal de modification de votre profil tapez 5, etc. Si l'abonné ENUM tape sur la touche 1 de son clavier téléphonique à l'étape 110, le code DTMF correpondant est intercepté par le module de traitement des DTMF (54) et est retransmis à l'étape 111 vers le module script ENUM (75). Le script ENUM (75) détecte alors qu'il s'agit d'une commande de lecture du profil ENUM. Le script ENUM (75) émet alors à l'étape 112 une demande d'interrogation au module protocole DNS (62) en fournissant en argument l'adresse E. 164 de l'abonné ENUM mise sous forme de domaine (transformation du numéro de téléphone E. 164 de type 33296053859 en (9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62) qui joue le rôle classique d'un RESOLVER peut d'abord vérifier si les informations ne sont pas présentes dans son cache suite à une consultation précédente ou interroger (à l'étape 113) selon le protocole standard DNS (requête DNS Query) successivement le serveur DNS de niveau 0, le serveur de DNS de niveau 1, puis le serveur DNS de niveau 2 par la pile de protocole DNS (32). Pour gagner en efficacité, les données d'un enregistrement NAPTR sont chargées dans la mémoire vive du serveur DNS (31). Si l'abonné ENUM est effectivement enregistré dans le serveur DNS (31) du fournisseur de service ENUM (30) alors la pile de protocole DNS (32) retourne (à l'étape 114) au module protocole DNS (62) la liste des enregistrements NAPTR correspondants. Le module de protocole DNS (62) se charge ensuite de les retransmettre vers le module Script ENUM (75) à l'étape 115. Le module (75) analyse et interprète les enregistrements NAPTR et génère un texte compréhensible par l'abonné ENUM du type "Service N 1 : téléphone vers le 0296053859, service N 2: téléphone vers le 0686166924, service N 3: eMail vers bertrand.dupont@rd.francetelecom corn, etc.). Ce texte est envoyé vers le module de synthèse vocale (55) à l'étape 116 qui se charge de diffuser cette information à l'abonné ENUM à l'étape 117. Dans le cas ou le module de diffusion de fichiers vocaux (56) est utilisé, le module (75) génère l'enchaînement des fichiers vocaux à jouer. Après diffusion de cette information, le module de synthèse vocale (55) ou le module de diffusion de fichiers vocaux (56) diffuse à nouveau à l'étape 118 la liste des opérations d'administration possibles sur le profil ENUM "Pour consulter votre profil ENUM taper sur la touche 1, pour modifier les attributs de votre profil taper sur 2, pour configurer de manière automatique votre profil tapez sur 3, pour modifier votre pseudonyme-mot de passe, tapez sur 4, pour accéder à votre journal de modification de votre profil tapez sur 5, etc.). Si l'abonné ENUM choisit la modification de son profil ENUM à l'étape 150, cette commande est interceptée par le module script ENUM (75) à l'étape 151, suite à la détection du code DTMF par le module de traitement DTMF (54). Le système (50) entre alors dans un dialogue itératif basé sur la diffusion de messages vocaux vers l'abonné ENUM à partir d'un texte généré par le module script ENUM (75) (à l'étape 152) en fonction du contexte et diffusés (à l'étape 153) sous forme vocale par le module de synthèse vocale (55) ou par le module de diffusion de fichiers vocaux concaténés (56). Ce dernier valide les choix proposés en utilisant son clavier DTMF à l'étape 154 et les commandes sont transmises à l'étape 155 vers le script ENUM (75). Par exemple, le dialogue vocal peut être le suivant: # # pour modifier l'ordre/préférence de vos services tapez sur 1, pour modifier les attributs d'un service tapez 2, pour ajouter un service tapez 3, pour supprimer un service tapez 4,etc. o # 4 # # pour supprimer le numéro de téléphone 0296053859 tapez 1, pour supprimer le numéro de téléphone 0686166924 tapez 2, pour supprimer l'adresse eMail bertrand dupont(Srd francetelecom com tapez 3,etc o 2 o Pour valider votre choix tapez 1, sinon tapez 2 # # 1 o - Pour supprimer un service tapez 1, pour enregistrer vos modifications tapez 2, pour revenir au menu principal tapez sur 0 o # 2 Lorsque l'abonné ENUM demande la prise en compte des modifications du profil ENUM, le module script ENUM (75) émet une requête de demande de modification à l'étape 156 vers le module protocole DNS (62). Ce dernier émet une commande DNS UPDATE à l'étape 157 à destination du module protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). Il est rappelé que l'adresse IP de ce dernier est stockée dans la base de données (70) et qu'elle est retrouvée à partir du numéro E. 164 de l'abonné ENUM. Le module protocole DNS (32) met à jour l'information dans la mémoire vive du serveur (31) et demande la mise à jour de la base de données (33) qui est généralement un fichier texte à plat. Le protocole DNS gère le numéro de modification dans ce fichier de manière à ce que le/les DNS secondaire (s) recharger lui/eux-même (s) modification à des intervalles de temps prédéfinis. La base de données (33) confirme la mise à jour à l'étape 159, ce qui se traduit par une réponse à la requête de demande de l'étape 160. Le script ENUM (75) intercepte à l'étape 161 le code retour de cette réponse puis génère à l'étape 162 le message de confirmation/infirmation de prise en compte de la modification. Le module de synthèse vocale (55) ou le module de diffusion de fichiers vocaux diffuse cette information vers l'abonné ENUM à l'étape 163. Ce dernier peut alors libérer la communication. Selon une variante de cette procédure, en réponse aux messages vocaux, l'abonné peut fournir directement une réponse de manière vocale. C'est alors le module de reconnaissance vocale qui détermine le choix ou l'information contenue dans la réponse. La Fig. 5 illustre schématiquement la procédure de consultation et de modification manuelle d'un profil ENUM via l'envoi de SMS depuis des terminaux téléphoniques mobile ou fixe de type GSM, RTC, RNIS ou IP. L'abonné ENUM émet à l'étape 200 un SMS formaté (ex: N E.164 + pseudonyme + mot de passe + requête) comme spécifié par le fournisseur de service ENUM (30) depuis un terminal fixe RTC (4) ou RNIS (2) connecté sur le réseau public ou derrière le PABX (3) ou un terminal mobile (6) de type GSM, ou depuis un terminal IP (7), à destination du module SMS (58) de la présente invention. Ce dernier transmet le SMS à l'étape 201 vers le module script ENUM (75). Ces informations sont fournies à l'étape 202 au module d'authentification (73) qui interroge à l'étape 203 la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E.164. Celle-ci fournit à l'étape 204 les informations correspondantes au module d'authentification (73) qui se charge de comparer le pseudonyme et le mot de passe saisis par le client ENUM dans le SMS avec les informations d'authentification contenues dans la base de données. En cas de concordance, le module d'authentification (73) ordonne à l'étape 205 au module script ENUM (75) de traiter la requête contenue dans le SMS. Le script ENUM (75) détecte qu'il s'agit d'une commande de lecture du profil ENUM. Par conséquent, le script ENUM (75) émet une demande d'interrogation à l'étape 206 au module de gestion protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonné ENUM transformée sous forme de domaine (transformation du numéro de téléphone E.164 de type 33296053859 en (9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion protocole DNS (62) qui joue le rôle classique d'un RESOLVER interroge (étape 207) à l'aide d'une requête (DNS Query) le serveur DNS de niveau 0, puis le serveur DNS de niveau 1, à moins que les informations ne soient déjà dans son cache suite à une consultation précédente de ces serveurs. Pour gagner en efficacité, les données d'un serveur DNS sont chargées dans la mémoire vive du serveur (31). Si l'abonné ENUM est effectivement enregistré dans le serveur DNS (31) du fournisseur de service ENUM (30) alors le module protocole DNS (32) retourne à l'étape 208 les enregistrements NAPTR correspondants. Le module de gestion de protocole DNS (62) se charge ensuite de les retransmettre vers le module script ENUM (75) à l'étape 209. Ce dernier analyse et interprète les enregistrements NAPTR et génère un texte relativement synthétique et compréhensible par l'abonné ENUM du type "P1: Tel= 0296053859, P2: Tel=0686166924, P3 : eMail= bertrand dupont@rd francetelecom com, P4: url=www.bertranddupont.fr, etc. ). Ce texte est envoyé à l'étape 210 vers le module d'envoi de SMS (58) qui envoie le SMS (à l'étape 211) vers le terminal téléphonique à l'origine de la requête (utilisation du Numéro de l'appelant). L'abonné ENUM émet à l'étape 250 un message SMS formaté (ex: N E. 164 + pseudonyme + mot de passe + type de requête= ECR : Pl:tel=0686166924, P2:email=bertrand.dupont@rd.francetelecom.com) comme spécifié par le fournisseur de service ENUM (30) depuis un terminal fixe RTC (4) ou RNIS (2) connecté sur le réseau public ou derrière le PABX (3) ou un terminal mobile (6) de type GSM, ou depuis un terminal IP (7) à destination du module SMS (58) de la présente invention. Ce dernier transmet le message SMS à l'étape 251 vers le module script ENUM (75). Ces informations sont fournies à l'étape 252 au module d'authentification (73) qui interroge à l'étape 253 la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E.164. Celle-ci fournit à l'étape 254 les informations correspondantes au module d'authentification (73) qui se charge de comparer le pseudonyme et le mot de passe saisis par le client ENUM dans le message SMS avec les informations d'authentification contenues dans la base de données. En cas de concordance, le module d'authentification (73) en avertit le module script ENUM (75) qui traite alors la requête contenue dans le SMS. Le script ENUM (75) détecte qu'il s'agit d'une commande de mise à jour du profil ENUM avec des arguments. Le script ENUM (75) vérifie la syntaxe de la commande et, si elle est correcte, émet une demande de mise à jour à l'étape 256 au module de gestion de protocole DNS (62). Ce dernier émet une commande DNS UPDATE à l'étape 257 à destination du module protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). Il est rappelé que l'adresse IP de ce dernier est stockée dans la base de données (70) et qu'elle est retrouvée à partir du numéro E. 164 de l'abonné ENUM. Le module protocole DNS (32) met à jour l'information dans la mémoire vive du serveur (31) et demande la mise à jour de la base de données (33) qui est généralement un fichier texte à plat. Le protocole DNS gère le numéro de modification dans ce fichier de manière à ce que le/les serveur(s) DNS secondaire(s) puisse (nt) recharger lui/eux-même(s) cette modification à des intervalles de temps prédéfinis. Le serveur (31) confirme la mise à jour à l'étape 259, ce qui se traduit par une réponse à la requête de demande de mise à jour à l'étape 260. Le script ENUM (75) intercepte à l'étape 261 le code retour de cette réponse puis génère à l'étape 262 le message de confirmation/infirmation de prise en compte de la modification avant de l'envoyer au module d'envoi de SMS (58) qui se charge d'envoyer le SMS à l'étape 263 vers le terminal téléphonique à l'origine de la requête (utilisation du numéro de l'appelant). La Fig. 6 illustre schématiquement la procédure de consultation et de modification manuelle d'un profil ENUM par le web à partir d'un terminal disposant d'un navigateur web (8). L'abonné ENUM demande à l'étape 300 le téléchargement de la page web d'accueil du service de gestion du profil ENUM. Celle-ci est retournée à l'étape 301 par le serveur web (63) de la présente invention. Cette page web affiche un formulaire d'authentification à l'abonné ENUM. Celui ci saisit son numéro E. 164 puis son pseudonyme et son mot de passe. Ces informations sont transmises à l'étape 302 au serveur web (63) qui lui même les transmet à l'étape 303 au module d'authentification (73). Le module d'authentification (73) interroge à l'étape 304 la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E. 164. Celle-ci fournit à l'étape 305 les informations correspondantes au module d'authentification (73) qui se charge de comparer le pseudonyme et le mot de passe saisis par le client ENUM dans le formulaire web et les informations d'authentification contenues dans la base de données. En cas de concordance, le module d'authentification (73) notifie à l'étape 306 le module serveur web (63) que l'authentification est réussie. Celui-ci émet à l'étape 307, à destination du module script ENUM (75), une requête de lecture du profil ENUM. Par conséquent, le script ENUM (75) émet une demande d'interrogation à l'étape 308 au module protocole DNS (62) en fournissant en argument l'adresse E. 164 de l'abonné ENUM transformée sous forme de domaine (transformation du numéro de téléphone E. 164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module protocole DNS (62) qui joue le rôle classique d'un RESOLVER interroge (à l'étape 309) après avoir vérifié si les informations ne sont pas présentes dans son cache suite à une consultation précédente, à l'aide du protocole standard DNS (requête DNS Query) successivement le serveur DNS de niveau 0, le serveur de DNS de niveau 1, puis le serveur DNS de niveau 2. Pour gagner en efficacité, les données d'un DNS sont chargées dans la mémoire vive du serveur DNS (31). Si l'abonné ENUM est effectivement enregistré dans le DNS (31) du fournisseur de service ENUM (30), le module protocole DNS (32) retourne à l'étape 310 les enregistrements NAPTR correspondants au module protocole DNS (62). Ce dernier les retransmet vers le module script ENUM (75) à l'étape 311 qui interprète les enregistrements NAPTR et génère un texte relativement synthétique et compréhensible par l'abonné ENUM du type : Service de priorité 1 Tel : Service de priorité 2 Tel : Service de priorité 3 Mail : bdupont@rd ft com Service de priorité 4 Web : w-ww bertranddupont fr, Ce texte est envoyé à l'étape 312 vers le module serveur web (63) qui télécharge une page web munie de ces informations à l'étape 313 vers le terminal Web (8) de l'abonné ENUM. La page web présentée à l'abonné ENUM permet via une interface graphique adaptée d'opérer des modifications de profil ENUM courant : des priorités, ajout de service, suppression de service, modification des attributs d'un service, etc. La demande en modification est émise à l'étape 350 à destination du serveur web (63). Ce dernier transmet à l'étape 351 la requête vers le module script ENUM (75) qui se charge de formater la requête conformément aux entrées NAPTR décrites par le protocole ENUM. Le script ENUM (75) émet alors une demande de mise à jour à l'étape 352 au module protocole DNS (62). Ce dernier émet une commande DNS UPDATE à l'étape 353 à destination du module protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). Il est rappelé que l'adresse IP de ce dernier est stockée dans la base de données (70) et qu'elle est retrouvée à partir du numéro E. 164 de l'abonné ENUM. Le module protocole DNS (32) met à jour l'information dans la mémoire vive du serveur (31) et demande la mise à jour de la base de données (33) qui est généralement un fichier texte à plat. Le protocole DNS gère le numéro de modification dans ce fichier de manière à ce que le/les serveur (s) DNS secondaire (s) recharger lui/eux-même(s) cette modification à des intervalles de temps prédéfinis. La base de données (33) confirme la mise à jour à l'étape 355, ce qui se traduit par une réponse à la requête de demande de mise à jour à l'étape 356. Le script ENUM (75) intercepte à l'étape 357 le code retour de cette réponse puis génère à l'étape 358 le message de confirmation/infirmation de prise en compte de la modification avant de l'envoyer au serveur web (63) qui se charge de formater la page web de résultat avant de la télécharger à l'étape 359 vers le terminal web (8). La Fig. 7 illustre schématiquement la procédure de consultation et de modification manuelle d'un profil ENUM à partir d'un Minitel. L'abonné ENUM se connecte au service Minitel en utilisant la fonction PAVI (Point d'Accès Vidéotex) du réseau de France Telecom (appel par exemple du 3615 code ENUM-FT). Le terminal minitel (5) entre alors en session avec le serveur minitel (57) à l'étape 400. Ce dernier active à l'étape 401 le module script ENUM (75) de la présente invention qui génère alors la page d'accueil du service à l'étape 402 et qui est téléchargée à l'étape 403 sur le terminal Minitel (5) de l'abonné ENUM . Cette page Minitel affiche un formulaire d'authentification à l'abonné ENUM. Celui-ci saisit son numéro ENUM E. 164 puis son pseudonyme et son mot de passe. Ces informations sont transmises à l'étape 404 au serveur Minitel (57) qui lui même les transmet à l'étape 405 au module script ENUM (75). Ce dernier redirige la requête à l'étape 406 vers le module d'authentification (73). Le module d'authentification (73) interroge à l'étape 407 la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E. 164. A l'étape 408 les informations d'authentification de la base de données sont transmises au module d'authentification (73) qui les compare avec le pseudonyme et le mot de passe saisis dans le formulaire Minitel. En cas de concordance, le module d'authentification (73) notifie à l'étape 409 le module script ENUM (75) que l'authentification est réussie. Le module script ENUM (75) émet alors une demande d'interrogation à l'étape 410 au module protocole DNS (62) en fournissant en argument l'adresse E. 164 de l'abonné ENUM transformée sous forme de domaine (transformation du numéro de téléphone E. 164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module protocole DNS (62) qui joue le rôle classique d'un RESOLVER interroge (étape 411), après avoir vérifié si les informations ne sont pas présentes dans son cache suite à une consultation précédente, à l'aide du protocole standard DNS (requête DNS Query) successivement le serveur DNS de niveau 0, le serveur de DNS de niveau 1, puis le serveur DNS de niveau 2. De préférence, pour gagner en efficacité, les données d'un DNS sont chargées dans la mémoire vive du serveur DNS (31). Si l'abonné ENUM est effectivement enregistré dans le serveur DNS (31) du fournisseur de service ENUM (30), le module protocole DNS (32) retourne (à l'étape 412) les enregistrements NAPTR correspondants. Le module de protocole DNS (62) se charge de les retransmettre vers le module script ENUM (75) à l'étape 413. Ce dernier analyse et interprète les enregistrements NAPTR et génère un texte relativement synthétique et compréhensible par l'abonné ENUM du type: Service de priorité 1 Tel : Service de priorité 2 Tel: 0686166924 Service de priorité 3 Mail: b dupont@rd ft com Service de priorité 4 Web www.bertranddupont fr, Ce texte est envoyé à l'étape 414 vers le module serveur videotex (57) qui se charge de télécharger à l'étape 415 vers le terminal Minitel (5) de l'abonné ENUM . La page videotex présentée à l'abonné ENUM permet via une interface adaptée d'opérer des modifications sur le profil ENUM courant : des priorités, ajout de service, suppression de service, modification des attributs d'un service, etc. La requête de mise à jour du profil ENUM est émise à l'étape 450 à destination du serveur videotex (57). Ce dernier transmet à l'étape 451 la requête vers le module script ENUM (75) qui se charge de formater la requête conformément aux entrées NAPTR décrites par le protocole ENUM. Le script ENUM (75) émet alors une demande de mise à jour à l'étape 452 au module protocole DNS (62). Ce dernier émet une commande DNS UPDATE à l'étape 453 à destination du module protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). Il est rappelé que l'adresse IP de ce dernier est stockée dans la base de données (70) et qu'elle est retrouvée à partir du numéro E.164 de l'abonné ENUM. Le module protocole DNS (32) met à jour l'information dans la mémoire vive du serveur (31) et demande la mise à jour de la base de données (33) qui est généralement un fichier texte à plat. Le protocole DNS gère le numéro de modification dans ce fichier de manière à ce que le/les serveurs DNS secondaire (s) recharger lui/eux-même(s) cette modification à des intervalles de temps prédéfinis. La base de données (33) confirme la mise à jour à l'étape 455, ce qui se traduit par une réponse à la requête de demande de mise à jour à l'étape 456. Le script ENUM (75) intercepte à l'étape 457 le code retour de cette réponse puis génère à l'étape 458 le message de confirmation/infirmation de prise en compte de la modification avant de l'envoyer au serveur vidéotex (57) qui se charge de formater la page videotex de résultat avant de la télécharger à l'étape 459 vers le terminal Minitel (5). La Fig. 8 illustre schématiquement la procédure de consultation et de modification manuelle d'un profil ENUM par eMail à partir d'un terminal disposant d'un client eMail (8). L'abonné ENUM émet un eMail formaté à l'étape 500 à destination du serveur eMail (61). La commande ENUM est par exemple passée dans l'adresse eMail destinataire : e 164-3 3296053 859-login-dupont-password-1234-requete lire@gestion.enum.francetelecom.com Le module script ENUM (75) dispose d'un client eMail qui vient régulièrement scruter le serveur eMail (61). Lorsque le module script ENUM (75) reçoit à l'étape 501 un eMail comme indiqué ci-dessus, il récupère, soit dans l'entête, soit dans le corps de l'eMail, les arguments fournis puis les transmet à l'étape 502 vers le module d'authentification (73). Le module d'authentification (73) interroge à l'étape 503 la base de données locale ou distante (via une interface ODBC par exemple) en effectuant une recherche sur le numéro ENUM E. 164. Celle-ci fournit à l'étape 504 les informations d'authentification correspondantes au module d'authentification (73) qui les compare au pseudonyme (login~id) et au mot de passe (password) fournis par le client ENUM dans l'eMail. En cas de concordance, le module d'authentification (73) en avertit le module script ENUM (75) à l'étape 505. Par conséquent, le script ENUM (75) émet une demande d'interrogation à l'étape 506 au module de gestion de protocole DNS (62) en fournissant en argument l'adresse E. 164 de l'abonné ENUM transformée en nom de domaine (transformation du numéro de téléphone E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62) qui joue le rôle classique d'un RESOLVER interroge (étape 507), si toutefois les informations ne sont pas déjà présentes dans son cache suite à une consultation précédente, selon le protocole standard DNS (requête DNS Query) successivement le serveur DNS de niveau 0, le serveur de DNS de niveau 1, puis le serveur DNS de niveau 2 par la pile de protocole DNS (32). De préférence, pour gagner en efficacité, les données d'un DNS sont chargées dans la mémoire vive du serveur DNS (31). Si l'abonné ENUM est effectivement enregistré dans le DNS (31) du fournisseur de service ENUM (30) alors le module de gestion de protocole DNS (32) retourne à l'étape 508 les enregistrements NAPTR correspondants. Le module de gestion de protocole DNS (62) se charge de les retransmettre vers le module script ENUM (75) à l'étape 509. Ce dernier analyse et interprète les enregistrements NAPTR et génère un texte relativement synthétique et compréhensible par l'abonné ENUM du type: Service de priorité 1 Tel : Service de priorité 2 Tel: 0686166924 Service de priorité 3 Mail : bdupont@rd ft com Service de priorité 4 Web www bertranddupont fr, Ce texte est expédié (étape 510) sous forme d'eMail par le logiciel client eMail intégré dans le module script ENUM vers le module serveur eMail (61) qui se charge de l'envoyer vers l'abonné ENUM. L'abonné ENUM qui souhaite modifier son Profil ENUM envoie un eMail formaté à l'étape 550 à destination du serveur eMail (61). La commande ENUM est par exemple passée dans l'adresse eMail destinataire, par exemple: e 164-33296053859-login-dupont-password-1234-requete-ecrire-P 1-tel-0296053 859- P2-tel-0686166924-P3-fax-0296050242@gestion.enum.francetelecom.com Le client eMail du module script ENUM scrute le serveur eMail (61). Lorsque le module script ENUM reçoit (en 551) un eMail comme indiqué ci-dessus, il récupère, soit dans l'entête, soit dans le corps de l'eMail, les arguments fournis puis les transmet à l'étape 552 vers le module d'authentification (73). Le module d'authentification (73) interroge à l'étape 553 la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E.164. Celle-ci fournit à l'étape 554 les informations d'authentification correspondantes et le module d'authentification (73) les compare au pseudonyme et au mot de passe fournis dans l'eMail. En cas de concordance, le module d'authentification (73) en avertit le module script ENUM (75) à l'étape 555. Ce dernier formate la requête conformément aux entrées NAPTR décrites par le protocole ENUM. Le script ENUM (75) transmet alors une demande de mise à jour à l'étape 556 au module de gestion de protocole DNS (62) qui émet une commande DNS UPDATE à l'étape 557 à destination du module protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). Il est rappelé que l'adresse IP de ce dernier est stockée dans la base de données (70) et qu'elle est retrouvée à partir du numéro E. 164 de l'abonné ENUM. Le module protocole DNS (32) met à jour l'information dans la mémoire vive du serveur (31) et demande la mise à jour de la base de données (33) qui est généralement un fichier texte à plat. Le protocole DNS gère le numéro de modification dans ce fichier de manière à ce que le/les serveur (s) DNS secondaire (s) recharger lui/eux- même (s) cette modification à des intervalles de temps prédéfinis. La base de données (33) confirme la mise à jour à l'étape 559, ce qui se traduit par une réponse à la requête de demande de mise à jour à l'étape 560. Le module script ENUM (75) intercepte à l'étape 561 le code retour de cette réponse puis génère le message de confirmation/infirmation de prise en compte de la modification. Ce message est expédié (à l'étape 562) sous forme d'eMail par le logiciel client intégré dans le module script ENUM au serveur eMail (61). Ce dernier envoie à l'étape 563 l'eMail en question à l'abonné ENUM qui peut le consulter sur son terminal (8). La Fig. 9 illustre schématiquement la procédure de consultation et de modification manuelle d'un profil ENUM par IUU (Information d'Usager à Usager) à partir d'un terminal RNIS (2). L'abonné ENUM émet à l'étape 600 depuis son terminal RNIS (2) un appel téléphonique contenant l'élément d'information IUU vers l'interface RNIS (51). Il faut rappeler que le champ IUU est actuellement limité à une taille de 32 caractères. La commande ENUM qui est insérée dans le champ IUU ne pourra donc agir que sur un service ENUM à la fois. Par exemple : cette requête permet de récupérer les attributs du service ENUM de priorité 1. L'automate d'appel (52) transmet à l'étape 601 le message de demande d'établissement d'appel au module IUU (53) qui va extraire la commande IUU. L'automate d'appel (52) émet à l'étape 652 le message Alerte à destination de l'abonné ENUM de manière à s'autoriser un minimum de temps (temporisation du protocole RNIS avant d'envoyer un message de déconnexion). Le module IUU (53) transmet la commande ENUM à l'étape 603 vers le module script ENUM (75). Ce dernier récupère les arguments ENUM fournis puis les transmet à l'étape 604 vers le module d'authentification (73). Le module d'authentification (73) interroge à l'étape 605 la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E.164. Celle-ci fournit à l'étape 606 les informations d'authentification correspondantes au module d'authentification (73) qui les compare avec le pseudonyme et le mot de passe fournis par le client ENUM dans l'IUU. En cas de concordance, le module d'authentification (73) en avertit le module script ENUM (75) à l'étape 607. Par suite, le module script ENUM (75) émet une demande d'interrogation à l'étape 608 au module de gestion de protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonné ENUM transformée sous forme de domaine (transformation du numéro de téléphone E. 164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.e164.arpa). Le module de gestion de protocole DNS (62) quijoue le rôle classique d'un RESOLVER peut interroger (à l'étape 609), après avoir vérifié si les informations ne sont pas déjà dans son cache suite à une consultation précédente, à l'aide du protocole standard DNS (requête DNS Query) le DNS niveau 0 puis le DNS niveau 1, puis le DNS niveau 2 via son module de protocole DNS (32). De préférence, pour gagner en efficacité, les données d'un serveur DNS sont chargées dans la mémoire vive du serveur (31). Si l'abonné ENUM est effectivement enregistré dans le DNS (31) du fournisseur de service ENUM (30), la pile de protocole DNS (32) retourne à l'étape 610 les enregistrements NAPTR correspondants au module de gestion protocole DNS (62) qui se charge de les retransmettre vers le module script ENUM (75) à l'étape 611. Ce dernier analyse et interprète les enregistrements NAPTR et en fonction du service demandé dans la commande IUU génère un texte relativement synthétique et compréhensible par l'abonné ENUM du type: Service PI: Tel:0296053859 Ce texte est envoyé à l'étape 612 vers le module IUU (53) qui se charge de formater un message de déconnexion avant de l'envoyer à l'étape 613 au module automate d'appel (52). Ce dernier génère le message de déconnexion RNIS qui contient l'élément d'information IUU et qui est donc transmis à l'étape 614 via le réseau RNIS au terminal (2) de l'abonné ENUM. Ce dernier peut visualiser l'IUU sur l'afficheur de son terminal RNIS (2). L'abonné ENUM qui souhaite modifier son profil ENUM émet à l'étape 650 depuis son terminal RNIS (2) un appel téléphonique contenant l'élément d'information IUU vers l'interface RNIS (51). Par exemple: DelP3-33296053859*dupont#123456: cette requête permet de supprimer le service ENUM de priorité 3. L'automate d'appel (52) transmet à l'étape 651 un message de demande d'établissement d'appel au module IUU (53) qui extrait la commande IUU. L'automate d'appel (52) émet à l'étape 652 le message Alerte à destination de l'abonné ENUM de manière à s'autoriser un minimum de temps (temporisation du protocole RNIS avant d'envoyer un message de déconnexion). Le module IUU (53) transmet la commande ENUM à l'étape 653 vers le module script ENUM (75). Ce dernier récupère les arguments fournis puis les transmet à l'étape 654 vers le module d'authentification (73). Le module d'authentification (73) interroge à l'étape 655 la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E. 164. Celle-ci fournit à l'étape 656 les informations d'authentification correspondantes au module d'authentification (73) qui les compare au pseudonyme et au mot de passe fournis par le client ENUM dans l'IUU. En cas de concordance, le module d'authentification (73) en avertit le module script ENUM (75) à l'étape 657. Etant donné que la modification ne porte pas sur l'ensemble du profil, le script ENUM (75) émet d'abord une demande d'interrogation (à l'étape 658) au module de gestion de protocole DNS (62) en fournissant en argument l'adresse E. 164 de l'abonné ENUM transformée sous forme de domaine (transformation du numéro de téléphone E. 164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62), qui joue le rôle de RESOLVER, peut interroger (à l'étape 659), après avoir vérifié si les informations ne sont pas déjà dans son cache suite à une consultation précédente, à l'aide du protocole standard DNS (requête DNS Query) le DNS niveau 0, le DNS niveau 1 puis le DNS niveau 2 via son module de protocole DNS (32). Pour gagner en efficacité, les données d'un DNS sont chargées dans la mémoire vive du serveur (31). Si l'abonné ENUM est effectivement enregistré dans le DNS (31) du fournisseur de service ENUM (30), le module protocole DNS (32) retourne à l'étape 660 les enregistrements NAPTR correspondants au module de gestion de protocole DNS (62). Ce dernier se charge de les retransmettre vers le module script ENUM (75) à l'étape 661. Le script ENUM (75) émet alors une demande de mise à jour en tenant compte de la modification demandée dans le champ IUU à l'étape 662 au module protocole DNS (62). Ce dernier émet une commande DNS UPDATE à l'étape 663 à destination du module protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). Il est rappelé que l'adresse IP de ce dernier est stockée dans la base de données (70) et qu'elle est retrouvée à partir du numéro E. 164 de l'abonné ENUM. Le module protocole DNS (32) met à jour l'information dans la mémoire vive du serveur (31) et demande la mise à jour de la base de données (33) qui est généralement un fichier texte à plat. Le protocole DNS gère le numéro de modification dans ce fichier de manière à ce que le/les serveurs DNS secondaire(s) puisse(nt) recharger lui/eux-même(s) cette modification à des intervalles de temps prédéfinis. La base de données (33) confirme la mise à jour à l'étape 665, ce qui se traduit par une réponse à la requête de demande de mise à jour à l'étape 666. Le script ENUM (75) intercepte à l'étape 667 le code retour de cette réponse puis génère à l'étape 668 le message de confirmation/infirmation de prise en compte de la modification. Ce message est envoyé à l'étape 668 vers le module IUU (53) qui se charge de formater un message de déconnexion avant de l'envoyer à l'étape 669 au module automate d'appel (52). Ce dernier génère à l'étape 670 le message de déconnexion RNIS qui contient l'élément d'information IUU et qui est donc transmis via le réseau RNIS vers le terminal (2) de l'abonné ENUM. Ce dernier peut visualiser l'IUU sur l'afficheur de son terminal RNIS (2). La Fig. 10 illustre schématiquement la procédure d'accès au service de consultation et de modification automatique d'un profil ENUM à partir d'une session web. La tâche consistant à modifier manuellement un profil ENUM peut vite devenir délicate et répétitive. Un automate (dit automate de configuration) est alors utilisé pour effectuer une modification automatique du profil ENUM en fonction du temps et/ou d'autres paramètres. Parmi ces autres paramètres, la localisation de l'abonné peut être retenue si elle est connue du système (50). L'abonné ENUM demande à l'étape 700 le téléchargement de la page web d'accueil du service de gestion du profil ENUM. Celle-ci est retournée à l'étape 701 par le serveur web (63) de la présente invention. Cette page web affiche un formulaire d'authentification à l'abonné ENUM. Celui-ci saisit son numéro ENUM E. 164 puis son login et mot de passe. Ces informations sont transmises à l'étape 702 au serveur web (63) qui lui même les transmet (à l'étape 703) au module d'authentification (73). Le module d'authentification (73) interroge (à l'étape 704) la base de données locale ou distante (70) (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E.164. Celle-ci fournit à l'étape 705 les informations d'authentification correspondantes au module d'authentification (73) qui les compare avec le pseudonyme et le mot de passe saisis par le client ENUM dans le formulaire web. En cas de concordance, le module d'authentification (73) notifie à l'étape 706 le module serveur web (63) que l'authentification est réussie. Celui-ci émet à l'étape 707 à destination du module script ENUM (75) une requête en lecture de la configuration automatique pour ce profil ENUM. Le module script ENUM (75) interroge à l'étape 708 la base de données (70) en fournissant en arguments le numéro E.164 de l'abonné ENUM. La base de données (70) retourne à l'étape 709 le programme de gestion automatique du profil au module script ENUM (75). dernier met en forme les informations, par exemple: Lundi au Vendredi : de08:30 à 19:00 P1 Tel 0296053859 P2 Tel 0686166924 P3 eMail bertrand.dupont@rd.francetelecom.com P4 fax 0296050242 Lundi au Vendredi : 19 :00 08:30 P1 Tel 0296916404 P2 eMail bertrand.dupont@rd.francetelecom.com Samedi et Dimanche : 00 :00 23:59 P1 Tel 0296916404 P2 Tel 0686166924 P3 eMail b dupont@wanadoo.fr Le module script ENUM (75) transmet les informations formatées à l'étape 710 au serveur web (63) qui se charge de télécharger la page web contenant les informations en clair du programme de configuration du profil ENUM sur le terminal web (8) de l'abonné ENUM. Cette page web permet la modification du programme de configuration automatique du profil ENUM : des horaires, gestion des jours fériés, ajout-suppression de service, modifications des attributs des services, etc. L'abonné ENUM valide la modification du programme à l'étape 750. Le serveur Web (63) transmet ces informations à l'étape 751 vers le module script ENUM (75). Ce dernier extrait les informations, les met en forme selon un format défini avant de les écrire dans la base de données (70), à l'étape 752. Celle-ci prend en compte l'enregistrement du programme et le confirme à l'étape 753 au module script ENUM (75). Ce dernier notifie au serveur web (63) à l'étape 754 la prise en compte de la modification de l'automate de configuration du profil ENUM. Le serveur télécharge à l'étape 755 la page web de confirmation de la modification sur le terminal web (8) de l'abonné ENUM. La Fig. 11illustre la procédure de mise à jour automatique par l'automate de configuration des profils ENUM ainsi que la procédure optionnelle de notification de changement de profil vers l'abonné ENUM. L'automate de configuration (74) scrute régulièrement à l'étape 800 la base de données (70) pour vérifier s'il y a une modification programmée à réaliser (en fonction du jour et de l'heure courants). Si une modification est programmée alors les paramètres de configuration sont retournés à l'étape 801. L'automate de configuration (74) émet une demande d'interrogation à l'étape 802 au module de gestion de protocole DNS (62) en fournissant en argument l'adresse E. 164 de l'abonné ENUM dont le profil est à modifier, transformée sous forme de nom de domaine (transformation du numéro de téléphone E. 164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62) qui joue le rôle d'un RESOLVER peut interroger (à l'étape 803), si toutefois les informations ne sont pas déjà dans son cache suite à une consultation précédente, à l'aide du protocole standard DNS (requête DNS Query), le serveur DNS niveau 0, le serveur DNS niveau 1, puis le serveur DNS niveau 2 via son module de protocole DNS (32). De préférence, pour gagner en efficacité, les données d'un DNS sont chargées dans la mémoire vive du serveur DNS (31). Si l'abonné ENUM est effectivement enregistré dans le DNS (31) du fournisseur de service ENUM (30) alors le module protocole DNS (32) retourne à l'étape 804 les enregistrements NAPTR correspondants au module protocole DNS (62). Ce dernier les retransmet vers l'automate de configuration (74) qui consulte alors (étape 806) la base de données (70) afin de récupérer les modifications à opérer sur le profil ENUM. La base de données retourne (étape 807) le profil à appliquer au module automate de configuration (74). Si une modification est effectivement nécessaire (le profil a pu entre temps être modifié manuellement), l'automate de configuration détermine les modifications à apporter aux enregistrements NAPTR et émet une demande de mise à jour à l'étape 808 au module de gestion de protocole DNS (62). Ce dernier émet une commande DNS UPDATE à l'étape 809 à destination du module protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). Il est rappelé que l'adresse IP de ce dernier est stockée dans la base de données (70) et qu'elle est retrouvée à partir du numéro E. 164 de l'abonné ENUM. Le module protocole DNS (32) met à jour l'information dans la mémoire vive du serveur (31) et demande la mise à jour de la base de données (33) qui est généralement un fichier texte à plat. Le protocole DNS gère le numéro de modification dans ce fichier de manière à ce que le/les serveurs DNS secondaire (s) recharger lui/eux -même(s) cette modification à des intervalles de temps prédéfinis. La base de données (33) confirme la mise à jour à l'étape 811, ce qui se traduit par une réponse à la requête de demande de mise à jour à l'étape 812. Le module automate de configuration (74) intercepte à l'étape 813 le code retour de cette réponse puis génère à l'étape 814 une demande d'écriture dans la base de données (70) pour alimenter le journal des modifications. La base de données (70) confirme l'écriture de l'événement de modification automatique du profil à l'étape 815. Si le service de mise à jour automatique a été configuré pour notifier les modifications automatiques de profil ENUM, l'automate de configuration notifie la mise à jour selon un ou plusieurs des modes suivants : o dans le cas ou la notification est en mode vocal, l'automate de configuration (74) notifie l'automate d'appel (52) à l'étape 820, ce qui se traduit par un appel téléphonique vers un téléphone fixe RTC (4), ou RNIS (2), ou IP (7) ou vers un téléphone mobile (6). Les informations et adresses de notification sont stockées dans la base de données (70). L'abonné ENUM répond à cet appel téléphonique à l'étape 822 ou l'appel est aiguillé vers sa messagerie vocale. Le module de synthèse vocale (55) ou le module de diffusion de fichiers vocaux (56) diffuse à l'étape 823 la notification de la modification de profil ENUM, par exemple : votre profil ENUM 33296053859 a été mis à jour aujourd'hui à 19 :00 suit : téléphonique vers 0296053859 puis service téléphonique vers 0686166924 puis service eMail vers bertrand dupont@wanadoo fr"; o dans le cas ou la notification est en mode SMS, l'automate de configuration (74) avertit le module SMS (58) à l'étape 830 en fournissant le texte du SMS par exemple du type : de votre profil ENUM 33296053859 le 21/03/2002 à 09:00: tél:0296053859, tél:0686166924,fax:0296050242". Le module SMS (58) transmet à l'étape 840 ce message SMS à destination du terminal téléphonique mobile ou fixe, tel que configuré dans la base de données (70) ; o dans le cas ou la notification est en mode eMail, l'automate de configuration (74) notifie la mise à jour au serveur eMail (61) (étape 850) à l'aide d'un eMail contenant un texte du type : de votre profil ENUM 33296053859 le 21/03/2002 à 09:00: tél:0296053859, tél:0686166924, fax:0296050242". A cette fin, l'automate de configuration dispose d'un client eMail. Le serveur eMail (61) transmet ensuite à l'étape 860 l' eMail en question à l'adresse eMail stockée dans la base de données (70) ; o dans le cas ou la notification est en mode fax, l'automate de configuration (74) notifie au module fax (59) à l'étape 870 en fournissant le texte du fax qui pourrait être de type: "Modification de votre profil ENUM 33296053859 le 21/03/2002 à 09:00: tél:0296053859, tél:0686166924,fax:0296050242". Le module fax (59) transmet à l'étape 880 ce fax à destination du terminal fax (9) configuré dans la base de données (70). La Fig. 12 illustre un exemple de procédure de consultation de profil ENUM lorsque ce dernier est stocké dans un annuaire LDAP. L'exemple donné en Fig. 12 illustre une consultation via un ordinateur individuel mais il est clair que la consultation peut être réalisée au moyen des autres types de terminaux précédemment envisagés. Ce type de service pourrait notamment être proposé par des entreprises qui souhaiteraient offrir l'accès à un service ENUM à toute ou partie de leurs employés. L'abonné ENUM demande à l'étape 900 le téléchargement de la page web d'accueil du service de gestion du profil ENUM. Celle-ci est retournée à l'étape 901 par le serveur web (63) du système (50). Cette page web affiche un formulaire d'authentification à l'abonné ENUM. Celui-ci saisit son numéro ENUM E. 164 puis son pseudonyme et son mot de passe. Ces informations sont transmises à l'étape 902 au serveur web (63) qui lui même les transmet (étape 903) au module d'authentification (73). Le module d'authentification (73) interroge (étape 904) la base de données locale ou distante (via une interface ODBC par exemple) en opérant une recherche sur le numéro ENUM E. 164. Celle-ci fournit à l'étape 905 les informations d'authentification correspondantes au module d'authentification (73) qui se charge de les comparer avec le pseudonyme et mot de passe saisis par le client ENUM. En cas de concordance, le module d'authentification (73) notifie à l'étape 906 le module serveur web (63) que l'authentification est réussie. Celui-ci émet à l'étape 907 à destination du module script ENUM (75) une requête de lecture du profil ENUM. Le script ENUM (75) émet une demande d'interrogation à l'étape 908 au module de gestion de protocole DNS (62) en fournissant en argument l'adresse E. 164 de l'abonné ENUM transformée sous forme de domaine (transformation du numéro de téléphone E. 164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62) qui joue le rôle d'un RESOLVER interroge (étape 909), si les informations ne sont pas déjà dans son cache suite à une consultation précédente, à l'aide du protocole standard DNS (requête DNS Query), le serveur DNS de niveau 0, le serveur DNS de niveau 1, puis le serveur DNS de niveau 2 via son module de protocole DNS (32). De préférence, pour gagner en efficacité, les données d'un DNS sont chargées dans la mémoire vive du serveur (31). Si l'abonné ENUM est effectivement enregistré dans le serveur DNS (31) du fournisseur de service ENUM (30), le module de gestion de protocole DNS (32) retourne à l'étape 910 le/les enregistrement (s) NAPTR correspondant(s) . Le module de gestion de protocole DNS (62) se charge de les retransmettre vers le module script ENUM (75) à l'étape 911. Ce dernier analyse et interprète le/les enregistrement(s) NAPTR, par exemple: $ORIGIN 9.5.8.3.5.0.6.9.2.3.3.e164.arpa. IN NAPTR 100 10 "u" "ldap+E2U""!A.+33296053859$!ldap://ldap.fournisseurA.fr/cn=33296053859!" Le script ENUM détecte qu'il s'agit d'un service LDAP. Par conséquent, le module script ENUM (75) émet à l'étape 912 à destination du module de gestion protocole LDAP (64) une requête LDAP de demande de connexion vers le serveur LDAP référencé par l'URI "ldap://ldap.fournisseurA.fr". Ce dernier émet à l'étape 913 une requête "Bind" à destination du module protocole LDAP (35) du serveur annuaire LDAP (34) du fournisseur ENUM A (30). Le module protocole LDAP (35) la connexion à l'étape 914. Le module de gestion de protocole LDAP (64) émet alors à l'étape 915 à destination du module protocole LDAP (35) la requête LDAP "Search" en fournissant le numéro E.164 de l'abonné ENUM en argument. Le module protocole LDAP (35) interroge la base de données LDAP (36) à l'étape 916 puis retourne (à l'étape 917) l'ensemble des informations concernant l'abonné ENUM au module protocole LDAP (35) qui lui-même les retourne (étape 918) au module de gestion de protocole LDAP (64). Ce dernier retourne les informations à l'étape 919 au script ENUM (75) qui se charge de les mettre sous une forme compréhensible pour l'abonné ENUM avant de les transmettre (à l'étape 922) vers le serveur web (63). Le serveur télécharge ensuite la page web générée dynamiquement à l'étape 923 sur le terminal web (8) de l'abonné ENUM. En parallèle, le module de gestion de protocole LDAP (64) envoie à l'étape 920 une demande de déconnexion au serveur LDAP (34) via une requête "Unbind". Le module de protocole LDAP (35) confirme la déconnexion à l'étape 921. La Fig. 13 décrit la procédure de modification manuelle de profil ENUM lorsque ce dernier est stocké dans un annuaire LDAP. Là encore, une modification de profil ENUM par un terminal autre qu'un PC peut bien entendu être envisagée. L'abonné ENUM ayant précédemment consulté le contenu de son profil ENUM au moyen de la procédure décrite ci-dessus, peut décider de le modifier. Pour ce faire, il modifie localement dans la page web affichée sur son terminal web (8) les attributs de ses services ENUM, les priorités, ajoute des services ou en supprime. Il valide ses modifications de profil à l'étape 1000 et les informations sont fournies au serveur web (63). Ce dernier transmet l'ensemble de ces informations à l'étape 1001 au module script ENUM (75). Ce dernier émet une demande d'interrogation à l'étape 1002 au module protocole DNS (62) en fournissant en argument l'adresse E. 164 de l'abonné ENUM transformée sous forme de domaine (transformation du numéro de téléphone E. 164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62) qui joue le rôle d'un RESOLVER peut interroger, si les informations ne sont pas déjà dans son cache suite à une consultation précédente (à l'étape 1003) avec le protocole standard DNS (requête DNS Query) le DNS niveau 0, puis le DNS niveau 1, avant d'interroger le DNS niveau 2 via son module de protocole DNS (32). Pour gagner en efficacité, les données d'un DNS sont chargées dans la mémoire vive du serveur DNS (31). Si l'abonné ENUM est effectivement enregistré dans le DNS (31) du fournisseur de service ENUM (30) le module protocole DNS (32) retourne à l'étape 1004 le/les enregistrements NAPTR correspondant(s). Le module de gestion de protocole DNS (62) les retransmet alors vers le module script ENUM (75) à l'étape 1005. Ce dernier analyse et interprète le/les enregistrement(s) NAPTR, par exemple : $ORIGIN9.5.8.3.5.0.6.9.2.3.3.el64.arpa. IN NAPTR 100 10 "u" "ldap+E2U""!^.+33296053859$!ldap://ldap.fournisseurA.fr/cn=33296053859!" Le module script ENUM (75) détecte qu'il s'agit d'un service LDAP. Le module script ENUM (75) émet alors (étape 1006) à destination du module protocole LDAP (64) une requête LDAP de demande de connexion au serveur LDAP référencé par l'URI "ldap://ldap.fournisseurA.fr". Ce dernier émet à l'étape 1007 une requête "Bind" à destination du module protocole LDAP (35) du serveur annuaire LDAP (34) du fournisseur ENUM A (30). Le module protocole LDAP (35) la connexion à l'étape 1008. Le module protocole LDAP (64) alors à l'étape 1009 à destination du module protocole LDAP (35) une requête LDAP "Search" en fournissant le numéro E. 164 de l'abonné ENUM en argument. Le module protocole LDAP (35) interroge la base de données LDAP (36) à l'étape 1010 puis retourne à l'étape 1011 l'ensemble des informations concernant l'abonné ENUM au module de gestion de protocole LDAP (35). Ce dernier les retourne à l'étape 1012 vers le module de gestion de protocole LDAP (64) qui lui-même les retourne (étape 1013) au module de script ENUM (75). Celui-ci les compare avec les informations fournies via le web par l'abonné ENUM et détermine l'opération à effectuer au format LDAP et transmet une demande de modification à l'étape 1014 à destination du module de gestion de protocole LDAP (64). Ce dernier envoie une requête LDAP "Modify" à l'étape 1015 à destination du module protocole LDAP (35) qui lui-même émet à l'étape 1016 une demande d'écriture dans la base de données (36). Celle-ci accepte la mise à jour et la confirme (étape 1017) au module protocole LDAP (35). Ce dernier transmet (étape 1018) la confirmation/infirmation de mise à jour au module de gestion de protocole LDAP (64) qui la retourne (étape 1019) au module script ENUM (75). Celui-ci génère alors la page web de confirmation de modification avant de la transmettre au serveur web (63). Le serveur télécharge cette page (étape 1023) au terminal web (8) de l'abonné ENUM. En parallèle, le module protocole LDAP (64) envoie (étape 1020) une demande de déconnexion au serveur LDAP (34) via une requête "Unbind". Le module de protocole LDAP (35) confirme la déconnexion à l'étape 1021. Bien que la procédure de mise à jour d'annuaire LDAP ait été illustrée pour une procédure manuelle , il va de soi qu'une mise à jour automatique de l'annuaire LDAP au moyen de l'automate de configuration (74) peut également être envisagée. Bien que l'invention ait été essentiellement décrite dans le cadre de l'application ENUM et de la mise à jour d'un profil ENUM , il est clair pour l'homme du métier qu'elle peut s'étendre à la mise à jour d'un ou plusieurs enregistrement(s) de ressource(s) (RR) dans un serveur DNS (ou LDAP), tels que définis au paragraphe 3. 2.2 du document RFC 1035 précité et repris dans la table ci-après : Type de RR Valeur Signification A 1 Addresse IP d'une machine NS 2 Nom de serveur géré par une autorité administrative MD 3 Serveur Mail de destination MF 4 Serveur Mail de reroutage CNAME 5 Nom canonique pour un alias SOA 6 Marque le début d'une zone d'autorité MB 7 Nom de domaine d'une boîte eMail MG 8 Membre de groupe de mail MR 9 Nom de domaine de renommage d'un mail NULL 10 Resource record NULL WKS 11 Description de service bien connu PTR 12 Pointeur sur un nom de domaine HINFO 13 Information sur une machine informatique MINFO 14 Information sur une boite mail MX 15 Echange de mail TXT 16 Chaines de caractères Pour un enregistrement de ressource donné, la mise à jour pourra porter sur un ou plusieurs champs de cet enregistrement, tels que définis dans le document RFC 1035 précité. Il faut noter que si la mise à jour d'enregistrement(s) de ressources autre(s) que NAPTR est envisagée, de nouveaux modules similaires au module Script ENUM (75) et automate de configuration ENUM (74) doivent être ajoutés pour traiter chacun de ces enregistrements. REVENDICATIONS 1) Système de consultation et/ou de mise à jour d'un enregistrement stocké dans une première base de données (33,36), ledit enregistrement comprenant un ou une pluralité d'enregistrements de ressources (RR), ladite première base de données étant hébergée par un serveur de noms de domaine, dit serveur DNS, ou un serveur d'annuaire, dit serveur LDAP, pouvant être accédé par indirection à partir d'un serveur DNS, caractérisé en ce qu'il comprend : - des moyens de communication (1150,53-59, 61,63) permettant audit système de recevoir d'un terminal de télécommunication une demande de consultation et/ou de modification dudit enregistrement ou une programmation d'une telle demande ; - des moyens de contrôle (1175,74, 75) adaptés à déterminer à partir de ladite demande de consultation et/ou de modification transmise au dit système ou préalablement programmée dans ledit système, un nom de domaine et une opération à effectuer sur ledit enregistrement ; - des moyens de gestion de protocole (1162, 62,64) adaptés à rechercher à partir dudit nom de domaine, l'adresse IP dudit serveur hébergeant ladite première base de données et, en fonction de ladite opération, à transmettre au dit serveur une requête de lecture ou de mise àjour dudit enregistrement. 2) Système selon la revendication 1, caractérisé en ce qu'il comprend des moyens d'authentification (1173,73) adaptés à authentifier au niveau applicatif l'émetteur de ladite demande à partir d'informations d'authentification stockées dans une seconde base de données (1170,70) locale ou distante. 3) Système selon la revendication 2, caractérisé en ce que, l'émetteur de ladite demande ayant été authentifié, lesdits moyens de gestion de protocole sont adaptés à transmettre une requête en consultation selon le protocole DNS (DNS Query) audit serveur DNS, la requête ayant pour argument ledit nom de domaine, et à recevoir une première réponse dudit serveur. 4) Système selon la revendication 3, caractérisé en ce que la première base de données étant hébergée par ledit serveur DNS, les moyens de contrôle sont adaptés à extraire de ladite première réponse une information contenue dans ledit enregistrement et à la formater pour la transmettre au dit terminal via lesdits moyens de communication. 5) Système selon la revendication 3, caractérisé en ce que, la première base de données étant hébergée par ledit serveur LDAP, les moyens de contrôle sont adaptés à extraire de ladite première réponse l'adresse du serveur LDAP. 6) Système selon la revendication 5, caractérisé en ce que, lesdits moyens de gestion de protocole sont adaptés à transmettre une requête en consultation selon le protocole LDAP (LDAP Search) audit serveur LDAP et à recevoir de celui-ci une seconde réponse. 7) Système selon la revendication 6, caractérisé en ce que les moyens de contrôle sont adaptés à extraire de ladite seconde réponse une information contenue dans ledit enregistrement et à la formater pour la transmettre au dit terminal via lesdits moyens de communication. 8) Système selon la revendication 4, caractérisé en ce que, les moyens de contrôle ayant déterminé une opération de mise à jour, les moyens de gestion de protocole sont adaptés, sur instruction desdits moyens de contrôle, à transmettre une requête en mise à jour selon le protocole DNS (DNS Update). 9) Système selon la revendication 8, caractérisé en ce que les moyens de gestion de protocole sont adaptés à recevoir une réponse de confirmation/infirmation de mise à jour du serveur DNS et les moyens de contrôle sont adaptés à formater cette réponse de confirmation/infirmation avant d'en ordonner la transmission au dit terminal via lesdits moyens de communication. 10) Système selon la revendication 7, les moyens de contrôle ayant déterminé une opération de mise à jour, les moyens de gestion de protocole sont adaptés, sur instruction desdits moyens de contrôle, à transmettre une requête en mise à jour selon le protocole LDAP (LDAP Modify). 11) Système selon la revendication 10, caractérisé en ce que les moyens de gestion de protocole sont adaptés à recevoir une réponse de confirmation/infirmation de mise à jour du serveur LDAP et les moyens de contrôle sont adaptés à formater cette réponse de confirmation/infirmation avant d'en ordonner la transmission au dit terminal via lesdits moyens de communication . 12) Système selon la revendication 2, caractérisé en ce que les moyens de contrôle sont adaptés à stocker dans la seconde base de données un profil de configuration transmis via lesdits moyens de communication, ledit profil étant constitué d'une ou plusieurs demandes de modification programmée, chaque demande de modification programmée étant associée à au moins une plage temporelle et/ou une zone géographique. 13) Système selon la revendication 12, caractérisé en ce que lesdits moyens de contrôle comprennent un automate de configuration (74) adapté à scruter ladite seconde base de données et à tester si une mesure de temps appartient à ladite plage et/ou une localisation du terminal appartient à ladite zone, et en cas de résultat positif, à extraire la demande de modification programmée associée et à transmettre aux dits moyens de gestion de protocole une demande de consultation de la première base de données. 14) Système selon la revendication 13, caractérisé en ce que lesdits moyens de gestion de protocole sont adaptés à formuler ladite requête en consultation selon le protocole DNS (DNS Query) ou LDAP (LDAP Search) et à recevoir, du serveur hébergeant la base de données, le contenu dudit enregistrement. 15) Système selon la revendication 14, caractérisé en ce que si le contenu dudit enregistrement n'est pas conforme à ladite demande de modification programmée, lesdits moyens de contrôle déterminent une opération à effectuer sur ledit enregistrement pour le rendre conforme à ladite demande de modification programmée et lesdits moyens de gestion de protocole formulent, en fonction de ladite opération, une requête de mise à jour de ladite première base de données selon le protocole DNS ou LDAP et l'acheminent vers le serveur hébergeant ladite première base de données. 16) Système selon la revendication 15, caractérisé en ce que lesdits moyens de gestion de protocole sont adaptés à recevoir une réponse de confirmation/infirmation de mise à jour du serveur hébergeant la première base de données et que les moyens de contrôle sont adaptés à détecter ladite réponse de confirmation/infirmation et à la stocker sous forme d'historique dans la seconde base de données. 17) Système selon la revendication 16, caractérisé en ce que lesdits moyens de contrôle sont adaptés à recevoir une demande de lecture dudit historique, et après authentification de l'émetteur de ladite demande par lesdits moyens d'authentification, à lui transmettre le contenu dudit historique via lesdits moyens de communication. 18) Système selon la revendication 17, caractérisé en ce que lesdits moyens de gestion de protocole sont adaptés à recevoir une réponse de confirmation/infirmation de mise à jour du serveur hébergeant la première base de données et que les moyens de contrôle sont adaptés à détecter ladite réponse de confirmation/infirmation et à transmettre un compte-rendu de ladite opération à un terminal de notification. 19) Système selon l'une des revendications précédentes, caractérisé en ce que lesdits moyens de gestion de protocole sont adaptés à utiliser un protocole DNS de type sécurisé (DNSSec). 20) Système selon l'une des revendications précédentes, caractérisé en ce qu'il comprend une interface RTC et/ou RNIS (51) connectant lesdits moyens de communication au réseau RTC/ RNIS. 21) Système selon la revendication 20, caractérisé en ce que lesdits moyens de communication comprennent un module de synthèse vocale (55) ou un module de reproduction de fichiers vocaux (56) permettant de générer un menu vocal, de reproduire une ou des informations dudit enregistrement sous forme vocale, ainsi qu'un module de reconnaissance de signaux DTMF (54) et/ou un module de reconnaissance vocale permettant de reconnaître un choix dans ledit menu vocal. 22) Système selon la revendication 20, caractérisé en ce que lesdits moyens de communication comprennent un serveur vidéotex (57) permettant de générer un menu, de saisir une demande de consultation ou de modification dudit enregistrement et de reproduire une ou des informations dudit enregistrement ou une réponse de confirmation/infirmation de mise à jour sous forme de séquences vidéotex. 23) Système selon la revendication 20, caractérisé en ce que lesdits moyens de communication comprennent un module d'émission/réception de messages SMS (58) permettant de recevoir sous forme de message une demande en consultation ou de modification dudit enregistrement et de transmettre sous forme de message une ou des informations dudit enregistrement ou une réponse de confirmation/infirmation de mise àjour. 24) Système selon la revendication 20 comportant une interface RNIS (51), caractérisé en ce que les moyens de communication comprennent un module d'émission/ réception (53) d'information usager à usager IUU, permettant de recevoir sous forme d'une dite information IUU, une demande en consultation ou de modification dudit enregistrement et de transmettre sous forme d'une dite information IUU une ou des informations dudit enregistrement ou une réponse de confirmation/infirmation de mise à jour. 25) Système selon la revendication 20, caractérisé en ce qu'il comprend un module fax (59) permettant de transmettre une ou des informations dudit enregistrement ou une réponse de confirmation/infirmation de mise àjour. 26) Système selon l'une des revendications 1 à 19, caractérisé en ce qu'il comprend une interface IP (60). 27) Système selon la revendication 26, caractérisé en ce que les moyens de communication comprennent un serveur Web adapté à transmettre un formulaire d'authentification, un formulaire de saisie d'une demande de consultation ou de modification dudit enregistrement, de présenter une ou des informations dudit enregistrement ou une réponse de confirmation/infirmation de mise à jour sous forme de pages Web. 28) Système selon la revendication 26, caractérisé en ce que les moyens de communication comprennent un serveur SMTP adapté à recevoir sous forme d'emails une demande de consultation ou de modification dudit enregistrement et de transmettre sous forme d'emails une ou des informations dudit enregistrement ou une réponse de confirmation/infirmation de mise àjour. 29) Système selon l'une des revendications précédentes, caractérisé en ce que les moyens de contrôle sont adaptés à déterminer ledit nom de domaine à partir d'un identifiant d'abonné. 30) Système selon la revendication 29, caractérisé en ce que ledit identifiant d'abonné est le numéro téléphonique E.164 dudit abonné. 31) Système selon la revendication 29 ou 30, caractérisé en ce que lesdits moyens de contrôle sont adaptés à extraire des informations et à déterminer en fonction de ladite demande une opération à effectuer sur un enregistrement de ressource de type NAPTR. 32) Système selon l'une des revendications précédentes caractérisé en ce que lesdits moyens de contrôle sont adaptés à extraire des informations et à déterminer en fonction de ladite demande une opération à effectuer sur un ou plusieurs enregistrements de ressource de type A, NS, MD, MF, CNAME, SOA, MB, MG, MR, NULL, WKS, PTR, HINFO, MINFO,MX, TXT.