Brevet FR2805107A1 — publié le 20010817

L'invention concerne un procédé de gestion de transmissions de données multimédias via un réseau de type Internet à l'aide de cartes à puce connectées à des terminaux munis d'un lecteur de carte à puce. L'invention concerne plus particulièrement la gestion de transmissions téléphoniques ou visiophoniques via un réseau de type Internet. L'invention concerne également une carte à puce pour la mise en oeuvre de ce procédé. Les transmissions précitées peuvent s'effectuer soit entièrement sur le réseau de type Internet, soit en partie sur ce réseau et en partie sur réseau téléphonique standard (par exemple de type commuté), via une passerelle matérielle et logique appropriée. Pour fixer les idées, et sans limiter en quoi que ce soit la portée de l'invention, on va décrire le procédé dans le cadre de l'application preférée, à savoir la téléphonie via un réseau Internet. Dans le cadre de l'invention, le terme "réseau Internet" doit être compris dans son sens le plus général. II concerne, outre le réseau Internet proprement dit, les réseaux privés d'entreprises. ou similaires, du type dit "intranet", et les réseaux les prolongeant vers l'extérieur, du type dit "extranet", et façon générale tout réseau dans lequel les échanges de données s'effectuent selon un protocole du type Internet. Dans ce qui suit un tel réseau sera appelé de façon générique "réseau Internet". De même, le terme "terminal" doit être compris dans un sens général. Le terminal précité peut être notamment constitué par un ordinateur personnel fonctionnant sous divers systèmes d'exploitation, tels WINDOWS ou UNIX (tous deux étant des marques déposées). II peut être aussi constitué par une station de travail, un ordinateur portable ou un terminal de carte dit dédié. Avec l'essor spectaculaire du réseau Internet ces dernieres cinq années, un nombre toujours croissant de terminaux sont connectés à réseau, notamment pour pouvoir être en liaison avec des serveurs éloignés, de type "WEB". II existe des limitations quant aux données transitant par les liaisons composant les mailles du réseau Internet. Cependant, ces limitations ne sont pas liées en premier lieu à la nature des données, mais surtout au débit permis par les liaisons. La mise en place récente de liaisons à haut débit (cable, liaison de type "ADSL", liaison par satellites, RNIS, etc.) permet désormais véhiculer des données de type multimédia et de les traiter en temps réel. Aussi, il est notamment intéressant de faire transiter réseau Internet des communications téléphoniques, voire de la visiophonie. Les transmissions des données elles-mêmes ne posent pas problèmes particuliers. Elles peuvent être traitées par les protocoles habituellement utilisés sur ce type réseau. Cependant, la gestion des communications pose des problèmes specifiques, notamment des problèmes liés à ce qui appelé en téléphonie classique la "signalisation". De façon générale, ce concept désigne des opérations telles que : appel d'un correspondant, acceptation appel, début et fin d'une conversation, sonnerie, décrochage du combiné, Dans années 90, un grand nombre de systèmes et logiciels ont été proposés pour pouvoir réaliser des appels téléphoniques via le réseau Internet. Le premier téléphone sur Internet, appelé "Internet Phone" (marque déposée) a " développé par la société Vocaltec en 1995. compte aujourd'hui dizaines de produits : "WebPhone", "NetMeeting" de société Microsoft (tous deux marques déposées), etc. L'état la technique qui en résulte se distingue donc par une grande diversité et manque de normes ou, pour le moins, de standards de fait. Il s'ensuit que produits ne sont pas inter-opérables. Cependant, on peut observer les tendances actuelles suivantes al utilisation d'un port de type "TCP" pour réaliser une pseudo signalisation (notification d'un appel, identification de l'appelant en vue de l'acceptation rejet de l'appel, etc.) ; bl compression du signal sonore, par exemple selon le procédé UIT-T G723 (Union Internationale des Télécommunications) de 5,3 Kbps à 6,3 Kbps ; cl diffusion du son en ayant recours au protocole "RTP" (pour "Real Time Protocol" conforme à la spécification RFC 1889), qui utilise lui-même le protocole de transmission "UDP" (pour "User Datagram Protocol"), des "PDUs" ("Protocol Data Unit") datées, et qui est associé à un protocole de contrôle "RTCP" (pour "Real Time Transport Control Protocol") ; et identification de l'appelé par son adresse "1P", de nombreux serveurs permettant d'associer à une adresse courrier fixe, une adresse "IF délivrée un serveur de type "PPP" d'un prestataire de service ou "provider" ("ISP" ou "Internet Service Provider", selon la terminologie anglo-saxonne, un serveur connu sous le sigle "ICQ" par exemple. Lorsque les communications doivent sortir du réseau Internet, des passerelles Internet téléphoniques dite "ITG" (pour "Internet Telephony Gateway") permettent de relier un réseau public de type commuté ("RTC"), connu genéralement sous le sigle anglo-saxon "PSTN" (pour "Public Switched Telephone Network") au réseau Internet. Le protocole "H323" qui définit le format paquets utilisés dans les réseaux locaux et sur un réseau "RNIS" ("Réseau Numérique à Intégration de Services" ou "ISDN" selon la terminologie anglo-saxonne) semble devenir le standard dominant protocoles d'appels dits "CCP" (pour "Call Control Protocol"). téléphonie sur Internet pose trois types de problemes principaux alla localisation de l'abonné dans le réseau, c'est à dire l'établissement d'une relation adresse "1P" (d'une machine informatique) abonne; b/ la gestion de la signalisation d'un appel télephonique (appel du correspondant, acceptation de l'appel, début de conversation, fin de conversation) : cette fonction est réalisée par un protocole dit "propriétaire" (généralement désigné sous le vocable "Protocole Propriétaire de Signalisation" ou "PSP") pour les appels de type "internetlinternet", ou par un protocole particulier qui tend à se standardiser (le protocole "CCP" précité) pour les appels de type "Internet/RTC", la signalisation étant réalisée au moyen d'un connexion "TCP" qui sera appelée ' après "Canal de Signalisation" ou "CS" ; et cl l'échange d'un flux de données multimédias : le protocole adopté est genéralement le protocole dit "RTP" (pour "Real Time Protocol", conforme à la spécification "rfc 1889" précitée), l'échange des données multimédias est réalisé à travers un canal de donnée, et les informations sont transportées par protocole "UDP" précité. Pour établir une conversation téléphonique sur Internet l'appelant et l'appelé doivent utiliser le même logiciel. La figure 1 illustre schématiquement les modules principaux composant un logiciel de téléphonie ("LT"), par exemple le logiciel "Netmeeting" précité. Schématiquement, un logiciel de téléphonie classique et l'architecture du système de transmission associée comportent sous ensembles suivants un profil d'abonné ("PA"), qui contient une suite d'informations permettent l'identification d'un abonné ; un protocole d'enregistrement ("PE") qui réalise l'enregistrement d'un abonné sur un serveur d'annuaire ("SA" - identifié par un numéro de "TCP" particulier, par exemple le port N 389) ; un protocole de localisation ("PL") qui réalise une fonction recherche d'un abonné à partir de son identifiant (généralement un e-mel), cette fonction etant mise en ceuvre au moyen d'une connexion au serveur d'annuaire ("SA"); un canal de signalisation ("CS"), qui met en oeuvre un protocole signalisation propriétaire ("PSP"), qui gère un appel téléphonique à travers une connexion TCP sur un port particulier (N 1503 pour Netmeeting) ; et un canal de données (CD) qui gère l'échange des données temps réels (le son et/ou l'image) à l'aide d'un protocole d'échange de données, tel que "RTP". De manière optionnelle, le logiciel de téléphonie sur Internet peut émettre un appel vers un abonné du réseau téléphonique standard, en utilisant un protocole de gestion d'appel ("CCP") au moyen d'un connexion "TCP" (sur port N 1 dans le cas du logiciel "Netmeeting") figure 1, annexée à la présente description, illustre schématiquement l'architecture d'un système de téléphonie 9 via le réseau Internet Ri, selon connu, mettant en ceuvre un logiciel de téléphonie du type qui vient d'être décrit. cette figure, on a représenté schématiquement deux terminaux, et 9b respectivement, réduits aux seuls logiciels de téléphonie les équipant, et 90b. Les composants de ces logiciels comprennent, pour chaque terminal, 9a ou 9b, un protocole d'enregistrement "PE", 900a ou 900b, associé à un profil d'abonne ("PA"), 903a ou 903b, et un protocole de localisation "PL", 901 a ou 901 b. profil d'abonné "PA" comprend un identifiant de base d'un abonné, Aa ou Ab, genéralement connu sous l'appellation "UserID", et diverses données qui seront précisées ci-après identifiant de façon plus complète abonné. protocole d'enregistrement "PE", 900a ou 900b, permet aux abonnées, Aa et Ab, associés aux terminaux, 9a ou 9b, de enregistrer dans un serveur d'annuaire 91 connecté au réseau Internet Ri. enregistrements s'effectuent en utilisant des données d'identification contenues dans les profils d'abonne "PA" précités, 903a ou 903b. Lorsque l'on désire établir une communication entre deux abonnées, il est nécessaire de procéder à une phase de localisation de l'abonné appelé. Par exemple, si le terminal 9a doit être mis en communication avec le terminal 9b, il est nécessaire de connaître l'adresse "1P" du terminal sur le réseau Internet soi, ces processus sont communs à la téléphonie classique sur un réseau commuté pur. II est attribué un numéro d'appel a chaque abonné, numéro repertorié dans un ou plusieurs annuaires. Cependant, le recours à un réseau Internet pour assurer les transmissions téléphoniques entre abonnés, ou ce qui revient au même entre terminaux, impose des contraintes spécifiques. apparaît tout d'abord utile de rappeler brièvement caractéristiques principales des protocoles de communication sur les réseaux. L'architecture des réseaux de communication est decrite par diverses couches. A titre d'exemple, le standard "0S1" ("Open System Interconnection"), défini l' "1S0", comporte sept couches qui vont des couches dites basses (par exemple la couche dite "physique" qui concerne le support de transmission physique) aux couches dites hautes (par exemple la couche dite "d'application"), en passant par des couches intermédiaires, notamment couche dite de "transport". Une couche donnée offre ses services à la couche qui lui est immédiatement supérieure et requiert de la couche qui immédiatement inférieure d'autres services, ' des interfaces appropriées. Les couches communiquent à l'aide de primitives. Elles peuvent également communiquer avec des couches de même niveau. Dans certaines architectures, plusieurs couches peuvent être inexistantes. Dans un environnement type Internet, les couches sont au nombre de cinq, et de façon plus précise, allant de la couche supérieure à la couche inférieure: la couche dite d'application ("HTTP", "FTP", "e-mail", etc.), la couche dite de transport ("TCP"), la couche dite d'adressage de réseau ("P"), la couche dite de liens de données ("PPP", "Slip", etc.) et la couche dite physique. Dans l'art connu, les abonnes, Aa et Ab, utilisent des terminaux Internet, 9a ou 9b, qui possèdent une adresse "1P" fixe, ou variable lorsque l'on a recours à un prestataire de service Internet, généralement connu sous le sigle anglo- saxon "ISP" (pour "Internet Service Provider"). Un premier inconvénient est constitué par le fait qu'une adresse "1P" n'est pas associée à un abonne, mais à un système informatique connecté au réseau Internet. Même dans le où le système informatique est doté d'une adresse fixe, il n'existe pas de correspondance a priori entre une adresse "1P" et une personne physique. De façon pratique, pour établir une telle relation l'abonné se connecte au serveur d'annuaire "SA" 91 (qui peut par exemple être du type dit "IRC", pour "Internet Relay Chat"). Ce serveur associe à l'identifiant de l'abonné, ou "UserID", adresse "1P". L'identifiant est généralement constitué par son adresse courrier e-mel, ou "e-mail" selon la terminologie anglo-saxonne, mais un pseudonyme quelconque peut également être utilisé. Cette association n'est géneralement pas authentifiée de telle sorte que le service (habituellement gratuit) puisse être utilisé de la manière la plus commode possible. Cette disposition n'est cependant pas exempte d'inconvénients, en particulier pour des applications dites "sensibles". Une des premières contraintes rencontrées est donc la localisation d'un abonné dans le réseau Internet Ri, c'est à dire l'établissement d'une correspondance entre un identifiant fixe et une adresse "1P". La localisation abonné sur le réseau Internet Ri, c'est-à-dire l'établissement de la correspondance précitée, présuppose que celui-ci ait été au préalable enregistré dans le serveur d'annuaire "SA". L'adresse d'un abonné dans le réseau Internet est donc constitué du couple : "Adresse SA" - "User Id". De façon usuelle, par "abonné", on entend une entité "physique". extension, il peut s'agir d'une "fonction". Cependant, ci-après, on donnera à abonné" son sens commun, sans que cela soit limitatif en quoi que ce soit de portée de l'invention. De façon pratique, un abonné indique sa localisation dans le réseau Internet RI par un acte volontaire en fournissant au serveur (annuaire) son adresse "1P" actuelle à l'aide du protocole d'enregistrement précité "PE". Cette opération implique que le terminal, 9a ou 9b, possède un logiciel spécifique (ou application) délivré par le fournisseur du service, en l'occurrence le logiciel "PE", 900a ou 900b, et personnalisé avec un profil d'abonné particulier "PA", 903a 903b. Comme il a éte indiqué, outre l'identifiant de base de l'abonné ("UserID"), le profil d'abonné "PA", 103a ou 103b, comprend un ensemble d'informations qui sont fournies au serveur d'annuaire "SA" 91 lors de l'enregistrement de l'abonné, et par exemple - l'adresse du "Serveur d'Annuaire" ("SA") ; - les abonnes (identifiés par leurs "UserID") avec lesquels l'utilisateur accepte d'entrer en communication ou auxquels il désire notifier sa localisation dans le réseau , et - les informations qu'il accepte de rendre publiques sur le serveur d'annuaire (par exemple : nom, nationalité, contacts recherchés, etc.). ; Pour joindre un correspondant à travers le réseau Internet RI, ce correspondant étant dument enregistré, il est nécessaire de connaître son adresse "1P". Cette information est obtenue à l'aide du serveur d'annuaire "SA" 91 et du protocole localisation "PL", 901 a ou 901 b, respectivement. On doit noter profil d'abonné "PA" est, par nature, spécifique à l'abonné, mais peut dépendre aussi des caractéristiques du serveur d'annuaire "SA", notamment du type et de la nature des informations qui doivent lui être fournies ou qu'il peut accepter. doit noter enfin que le protocole "PL", 901 a ou 901b, est, comme le protocole "PE", 900a ou 900b, de type dit propriétaire, puisqu'il adresse un serveur d'annuaire "SA" 91 a priori non standardisé ou ne répondant pas à des normes universellement reconnues. Les protocoles "PE" et "PL" des terminaux doivent etre compatibles avec les protocoles correspondants implantés dans le serveur d'annuaires "SA" 91, référencés 910 et 911, respectivement. deux caractéristiques constituent des inconvénients supplémentaires. résumé de ce qui vient d'être rappelé, pour qu'un abonne appelant puisse localiser un abonné appelé Ab et puisse être localisé celui-ci, nécessaire que le terminal qu'il utilise, par exemple 9a, stocke logiciels specifiques, 900a ou b, 901 a ou b, permettant de mettre en oeuvre protocoles "PE" et "PL". II peut également être nécessaire qu'il stocke données afférentes à son profil d'abonné "PA" 903a. Cette remarque s'applique de façon similaire aux terminaux des autres abonnés, par exemple terminal d'autres termes, le terminal, 9a ou 9b, utilisé par un abonne quelconque, Aa ou Ab, est également spécifique, en ce sens que, si cet abonne désire changer de terminal, il doit retrouver, sur le nouveau terminal utilisé, au moins les logiciels associés au protocole "PL", en admettant qu'il ait procède ' une phase préliminaire d'enregistrement sur le premier terminal, en faisant appel au protocole "PE" et en fournissant son profil "PA" au serveur d'annuaire "SA". En effet, la présence du protocole "PL" est nécessaire pour adresser le serveur d'annuaire "SA" 91 et avoir accès aux données enregistrées dans celui-ci, notamment les adresses "1P" des correspondants recherchés leurs profils "PA". Les terminaux, 9a ou 9b, doivent également être munis chacun de deux logiciels supplémentaires, également de type propriétaire : le protocole signalisation "PSP, 902a ou 902b, et le protocole d'échange de données "RTP" précité (ou un protocole similaire), 905a ou 905b. Les modules associés au protocole "PSP" correspondent entre eux par l'intermédiaire du canal de signalisation CS, au travers du réseau Internet Ri. De même, les modules associés au protocole "RTP" correspondent entre eux par l'intermédiaire du canal de données CD, au travers du réseau Internet Ri. Enfin, si les communications téléphoniques doivent sortir du réseau Internet R!, vers le réseau standard commuté 93, il est nécessaire de prévoir le protocole de gestion d'appel "CCP" précité (ou un protocole similaire), 904a ou 904b, également de type propriétaire, Il est également nécessaire de prévoir une ou plusieurs passerelles du type "ITG" précité, représentées sous référence unique 92, entre le module 904a, associé au protocole "CCP", et réseau "RTC" 92. Un poste téléphonique d'abonné 95 communique avec réseau "RTC" via un central "PBX" classique 94, ou tout système similaire. communications entre la passerelle "ITG" 92 et le terminal d'abonné, 9a dans l'exemple illustré sur la figure 1, mettent en ceuvre une connexion de type "TCP". communications sur la partie "réseau téléphonique commute" s'effectuent de façon classique et il est inutile de les décrire plus avant. serait donc intéressant d'utiliser des terminaux banalisés pour effectuer les phases d'enregistrement et, surtout, les phases de localisation d'abonnes sur le réseau Internet RI, de signalisation (appel de l'abonné localise, etc.) et d'échange de données, ce qui permettrait d'accéder de façon commode au concept appelé "nomadisme". serait également intéressant de pouvoir mettre en ceuvre, lors de phase signalisation, une procédure de simple ou mutuelle authentification sûre, entre l'appelé et l'appelant. Diverses négociations, telles que négociation de clés de chiffrage ou d'opérations dites de "réservation" chemins routage devraient également pouvoir être effectuées lors de cette phase signalisation. De même, lors de la phase d'échange de données, i serait interessant de pouvoir assurer un chiffrement/déchiffrement robuste informations, par exemple basé sur les clés de chiffrement précédemment négociées. Enfin, il serait intéressant de pouvoir mettre en ceuvre une tarification, basée sur la quantité (débit) de données échangées et/ou sur la qualité chemins de routage mis à disposition, ces chemins ayant été négociés, exemple, dans la phase précédente de signalisation. logiciels associés aux protocoles précités, "PE" "PL", ne nécessitent pas habituellement de disposer d'une grande quantité mémoire. II en est même des données de profil "PA". On pourrait donc penser les enregistrer, en tout ou partie, dans les circuits de mémoire d'une à puce, ce que permet la technologie actuelle. Cependant, on se heurte à une double difficulté technique, comme il va l'être montre ci-après, ce qui interdit toute communication directe entre réseau Internet une carte à puce. va tout d'abord rappeler brièvement l'architecture générale d'un système d'application à base de carte à puce, relié à un réseau Internet, par référence aux figures 2A et 2B. Un système d'application à base de carte à puce comporte généralement les éléments principaux suivants une carte à puce ; un système hôte constituant le terminal précité ; un réseau de communication, à savoir le réseau Internet dans l'application préférée ; et un serveur d'application connecté au réseau Internet. figure 2A illustre schématiquement un exemple d'architecture de ce type. terminal 1, par exemple un ordinateur individuel, comporte un lecteur 3 de carte à puce 2. Ce lecteur 3 peut être ou non physiquement integré dans le terminal 1. Dans le cadre de l'invention, le terminal 1 joue le rôle terminaux 9a ou du système de la figure 1. La carte à puce 2 comporte un circuit intégré dont des connexions d'entrées-sorties affleurent en surface de son support pour autoriser une alimentation en énergie électrique et des communications avec le terminal 1. Ce dernier comprend des circuits d'accès 11 au réseau Internet Ri. Ces circuits peuvent être constitués par modem pour se connecter à une ligne téléphonique commutée ou à voie de communication à plus haut débit : réseau numérique à intégration de services ("RNIS"), câble ou liaisons par satellite, etc. Les circuits 11 permettent de se connecter au réseau Internet RI, directement ou via un prestataire de services Internet ("Internet Service Provider" ou "ISP", selon terminologie anglo- saxonne). On peut également avoir recours à un système intermédiaire tel qu'un proxy" ou un système d'isolation dit "firewall" ("pare- ou encore appelé garde barrière"). Le terminal 1 comprend naturellement tous circuits et organes nécessaires à son bon fonctionnement, et qui n'ont pas éte représentés dans un de simplification du dessin : unité centrale, mémoires vive et fixe, mémoire masse à disque magnétique, lecteur de disquette et/ou CédéRom, etc. Habituellement, le terminal 1 est aussi relié a des périphériques classiques, intégrés ou non, tels un écran de visualisation 5, un clavier 6a et une souris 6b, etc. Le terminal 1 peut être mis en communication avec des serveurs ou tous systèmes informatiques connectés au réseau RI, dont un seul, 4, est illustré sur la figure 2A. Dans le cadre de l'invention, le serveur 4 est constitué par un serveur d'annuaire 91 (figure 1) et le terminal 1 par l'un des systèmes, 9a ou 9b, associé à un abonné, Aa ou Ab. Les circuits d'accès 11 mettent le terminal 1 en communication avec les serveurs 4 grâce à un logiciel particulier 10, appelé navigateur "WEB", ou "browser" selon la terminologie anglo-saxonne. Celui-ci permet d'accéder à diverses applications ou fichiers de données répartis sur l'ensemble du réseau RI, généralement selon un mode "client-serveur". Le protocole de communication sur le réseau Internet RI est choisi en fonction de l'application plus particulièrement visée : interrogation de pages "WEB", transferts de fichiers, courrier électronique (e-mel), forums ou "news", etc. L'architecture logique du système comprenant un terminal, un lecteur de carte à puce et une carte à puce, est représentée schématiquement par la figure 2B. Elle est décrite par la norme ISO 7816, qui elle-même comportent plusieurs sous-ensembles - ISO 7816-1 et 7816-2, en ce qui concerne les dimensions et le marquage des cartes ; - ISO 7816-3, en ce qui concerne le transfert de données entre le terminal et la carte à puce ; et - ISO 7816-4, en ce qui concerne la structure du jeu d'ordres le format des commandes. Sur la figure 2B, du côté terminal 1, on n'a représenté que les couches répondant à la norme ISO 7816-3, référencées 101, et un gestionnaire d'ordres "APDU" (norme ISO 7816-4), référencé 102. Du côté carte à puce 2, les couches répondant à la norme ISO 7816-3 sont référencées 200 et le gestionnaire d'ordres "ADPU" (norme ISO 7816-4) est référencé 201. Les applications sont référencées A1, ..., Ai, ..., An ; n étant le nombre maximum d'applications présentes sur la carte à puce 2. Une application, Ai, présente dans la carte à puce 2, dialogue avec le terminal 1 au moyen d'un jeu d'ordres. Ce jeu présente typiquement des ordres d'écriture et des ordres de lecture. Le format des ordres est connu sous l'abréviation anglo-saxonne de "APDU" (pour "Application Protocol Data Unit"). II est défini par la norme ISO 7816-4 précitée. Une "APDU" de commande est notée "APDU.commancf' et une "APDU" de réponse est notée "APDU.response". Les "APDU" sont échangées entre le lecteur de carte et la carte à puce au moyen d'un protocole spécifié par la norme ISO 7816-3 précitée (par exemple en mode caractère: T=0 ; ou en mode bloc.- T=1). Lorsque la carte à puce 2 inclut plusieurs applications distinctes, comme illustré sur la figure 2B, on parle de carte multi-applicative. Cependant, le terminal 1 ne dialogue qu'avec une seule application à la fois. La sélection d'une application particulière Al est obtenue à l'aide d'une "APDU" du type sélection ("SELECT"). Une fois ce choix effectué, les "APDU" qui le suivent sont acheminés vers cette application. Une "APDU SELECT" nouvelle a pour effet d'abandonner l'application en cours et d'en choisir une autre. Le sous-ensemble logiciel gestionnaire des "APDU" 201 permet de choisir une application particulière Ai dans la carte à puce 2, de mémoriser l'application ainsi choisie, et de transmettre et/ou recevoir des "APDU" vers et depuis cette application. En résumé de ce qui vient d'être décrit, la sélection d'une application Ai et le dialogue avec celle-ci s'effectuent par échanges d'ordres "APDU". suppose que les applications Ai sont des applications conventionnelles, que appellera ci-après "GCA" (pour "Generic Card Application" ou application carte génerique). rappels étant effectués, il est à noter que la carte à puce 2 ne peut communiquer directement avec les navigateurs standards du commerce 10, sauf à modifier code de ces derniers. outre, et surtout, les cartes à puce actuelles, qui par ailleurs sont conformes aux standards et normes rappelées ci-dessus, ont une configuration matérielle et logicielle qui ne permet pas non plus de communiquer directement avec réseau Internet Ri. En particulier, elles ne peuvent recevoir transmettre des paquets de données, selon l'un ou l'autre des protocoles utilises sur ce type de réseau. Il est donc nécessaire de prévoir une pièce de logiciel additionnelle, implantée dans le terminal 1, généralement sous la forme de ce qui appelé un "plug-in", selon la terminologie anglo-saxonne. Cette pièce logiciel, porte la référence 12 sur la figure 2A, effectue l'interface entre navigateur 10 et la carte 2, plus précisément les circuits électroniques 20 cette carte L'invention vise à pallier les inconvénients des procédés et dispositifs l'art connu, et dont certains viennent d'être rappelés, tout en répondant aux besoins se font sentir. Selon l'invention, les applications nécessaires à la mise en ceuvre protocoles d'enregistrement "PE" et de localisation "PL", ainsi que les donnees caractérisant le profil d'abonné "PA", sont des fichiers qui sont de préférence stockés, tout ou partie, dans des mémoires d'une carte à puce, les fichiers de type exécutable étant des applications standards du type "GCA" précité. Selon l'invention, la carte à puce se comporte comme un serveur/client de type "WEB" pour le terminal qui lui est associé. Pour ce faire, on prévoit une couche de logiciel de communication spécifique dans la carte à puce et son pendant dans le terminal. Le terme "spécifique" doit être entendu comme spécifique au procédé de l'invention. En effet, ces couches de communication, dites spécifiques, sont banalisées quelle que soit l'application considérée. En particulier, elles sont indépendantes des applications necessaires à la mise en oeuvre des différents protocoles précités. Elles n'interviennent que dans le processus d'échanges de donnees bidirectionnels entre la carte à puce et le terminal, d'une part, et la carte à puce et le réseau, d'autre part. Les couches logicielles de communication spécifiques comprennent notamment composants logiciels, dits "agents intelligents", permettant en particulier conversions de protocoles. Les agents intelligents seront appelés ci-après plus simplement "agents". II existe des agents appareillés dans couches communication spécifiques respectives associées au terminal et à carte à puce. Selon le procédé de l'invention, il s'établit des sessions entre agents appareillés. notera que le procédé de l'invention rend possible l'activation d'applications de type conventionnel, c'est-à-dire du type "GCA" précite, localisées dans une carte à puce, sans devoir les modifier en quoi que ce soit. Pour ce faire, on prévoit un ou plusieurs agents intelligents particuliers dits traducteurs de script, qui reçoivent des requêtes d'un navigateur et traduisent en ordres "APDU" compréhensibles par l'application de type "GCA". De ce fait, on implante dans la carte à puce une fonction similaire à celle connue ailleurs sous la dénomination "CGI" dans les serveurs "WEB" classiques. Cette fonction permet de mettre en oeuvre une application dans carte à puce un protocole Internet de type "HTTP". Ces diverses dispositions permettent à la carte à puce, et plus précisément aux applications présentes dans celle-ci, de communiquer directement avec un serveur éloigné connecté au réseau Internet par la mise en oeuvre de protocoles de type Internet. La fonctionnalité "CGI" offerte par la carte à puce permet pour sa part l'accession aux applications associées aux protocoles d'enregistrement "PE" et de localisation "PL" et leur exécution, sans nécessiter la presence d'applications de type propriétaire dans le terminal. Seul un navigateur, avantageusement de type standard du commerce, est nécessaire. Selon une caractéristique avantageuse de l'invention, on implante dans la carte à puce une application particulière, que l'on appellera "filtre" dans ce qui suit. s'agit d'une entité logicielle qui joue un rôle analogue à celui "proxy". Pour faire, on fait appel aux dispositions précitées mettant oeuvre des agents. Cette disposition permet à la carte à puce de se comporter comme un "proxy" type "TCP") de protocole de signalisation et/ou un "proxy" (de type "UDP") protocole d'échange de données. L'intérêt d'un proxy de signalisation est de pouvoir mettre ceuvre une procedure de simple ou mutuelle authentification entre l'appelant et l'appelé qui peut être utile par exemple pour l'acceptation des communications. II permet également la négociation de clés de chiffrage. II permet aussi de négocier a priori un chemin de routage optimisé, par exemple en garantissant une qualité de transmission donnée ou une bande passante élevée. L'intérêt principal d'un proxy d'échange de données est de pouvoir mettre en aeuvre une procédure robuste de chiffrement/déchiffrement des informations. Un proxy permet également de mettre en oeuvre une procédure de tarification, basée par exemple sur le débit ou sur le type de chemin précedemment négocié. Ces caractéristiques répondent donc bien à des besoins qui se font sentir et qui ont été précédemment évoqués. L'invention a donc pour objet principal un procédé de gestion de transmissions de données multimédias via un réseau de type Internet entre un premier système d'abonné et un second système d'abonné comprenant au moins une phase d'échange de données dites de signalisation, via un canal dit de signalisation, à l'aide d'un protocole de signalisation déterminé, et une phase d'échange desdites données multimédias, via un canal dit de données, à l'aide d'un protocole de communication déterminé, caractérisé en ce que, au moins ledit premier système d'abonné comportant un terminal muni d'un navigateur de type "WEB" et d'un lecteur de carte à puce coopérant avec une carte à puce, ladite carte à puce comportant une première pièce de logiciel, formant une couche protocolaire de communication spécifique et ledit terminal comportant une seconde pièce de logiciel, formant une couche protocolaire de communication spécifique et formant interface avec au moins ledit navigateur de type "WEB" ;lesdites première et seconde pièces de logiciel comprennent chacune en outre au moins une première entité logicielle autonome, de type dit client, et une deuxième entité logicielle autonome, de type dit serveur, lesdites entités coopérant de manière à permettre l'établissement de sessions d'echanges de données bidirectionnels entre ledit terminal et ladite carte ' puce et à ce que ladite carte à puce offre la fonctionnalité d'un client/serveur de type "WEB", et à permettre l'établissement d'une session d'échanges de données bidirectionnels entre le terminal dudit premier système d'abonné et ledit second système d'abonné via ledit reseau de type Internet, lesdites unités logicielles autonomes communiquant au moyen d'unités de données de protocole prédéterminées ; - en ce qu'il comprend la réalisation, dans ladite carte à puce, d'une pièce de logiciel applicative de caractéristiques fonctionnelles déterminées, dite filtre, recevant et/ou émettant des unites de données de protocole vers lesdites et/ou à partir desdites première et deuxième entités logicielles autonomes, de types respectifs client et serveur, comprises dans ladite seconde pièce de logiciel spécifique ; la réalisation de ladite pièce applicative étant sous le contrôle de ladite entité logicielle autonome de type serveur ; et - en ce que ledit filtre coopère avec lesdites entités logicielles autonomes de ladite seconde pièce de logiciel spécifique pour ouvrir une session avec lesdites entités logicielles autonomes de ladite première pièce de logiciel spécifique pour former une fonction dite de "proxy " et contrôler des caractéristiques prédéterminées des échanges de données transitant entre ledit premier système d'abonné et ledit second système d'abonné, via au moins l'un desdits canaux de signalisation et/ou de données, pendant lesdites phases d'échanges de données de signalisation et/ou de données multimédias. L'invention a encore pour objet une carte à puce pour la mise en oeuvre de ce procède. Un mode préféré, mais non limitatif, de réalisation de l'invention va maintenant être décrit de façon plus détaillée en se référant aux dessins annexés, parmi lesquels - figure 1 illustre schématiquement les modules principaux composant un logiciel de téléphonie selon l'art connu ; - figures 2A et 2B illustrent les architectures matérielle logique, respectivement, d'un exemple de système d'application à base de carte à puce connecté à un réseau Internet selon l'art connu ; - figure 3 illustre schématiquement un exemple de système d'application à base de carte à puce selon l'invention, cette dernière agissant en tant que client/serveur "WEB", selon un aspect l'invention ; - figure 4 est un diagramme d'états d'une session entre entités logicielles dites agents intelligents, selon un aspect l'invention ; - figure 5 illustre de façon simplifiée l'architecture logique système selon l'invention dans lequel la carte à puce comprend agents intelligents ; - figure 6 illustre de façon simplifiée l'architecture logique système selon un autre aspect de l'invention selon lequel la carte a puce comprend des agents intelligents traducteurs de scripts, maniere à implanter une fonction dite "CGI" ; - figure 7A illustre schématiquement une première étape de phase d'enregistrement d'un abonné sur un serveur d'annuaire ; - figures 7B et 7C illustrent des exemples de formulaires "HTLM" utilisables pour cette phase d'enregistrement ; - la figure 7D illustre schématiquement les principales étapes de phase d'enregistrement d'un abonné sur un serveur d'annuaire ; - figure 8 illustre schématiquement les principales etapes de la phase de localisation d'un abonné sur le réseau Internet par interrogation d'un serveur d'annuaire ; - figure 9 illustre schématiquement un "proxy" selon connu ; - figure 10 illustre de façon simplifiée l'architecture logique d'un système selon l'invention conforme à celui de la figure 4, dans lequel un filtre "proxy" est réalisé sur la carte à puce ; - figure 11 A illustre schématiquement l'architecture système de telephonie selon l'invention mettant en oeuvre la fonctionnalité "proxy pour le canal de signalisation, du côté abonné appelant et du côté abonné appelé ; - figure 11 B illustre schématiquement l'architecture système de telephonie selon l'invention mettant en ceuvre la fonctionnalité "proxy pour le canal de données, du côté abonné appelant du côté abonne appelé ; et - figure 12 illustre schématiquement l'architecture génerale d'un système de gestion de transmission de données téléphoniques, selon un mode de réalisation préféré de l'invention, entre un système appelant comprenant un terminal et une carte à puce, et un système appelé. Dans qui suit, sans en limiter en quoi que ce soit la portee, on se placera ci-apres dans le cadre de l'application préférée de l'invention, sauf mention contraire, c'est-à-dire dans le cas de transmissions téléphoniques via le réseau Internet. La figure 3 illustre schématiquement un exemple système d'application base de carte à puce selon un premier aspect l'invention, permettant à cette dernière d'agir en tant que client/serveur "WEB. A l'exception de couches logicielles de protocole de communication spécifiques, référencées 13 et 23a, respectivement implantees dans le terminal 1 et carte à puce 2a, les autres éléments, matériels ou logiciels, sont communs à connu, notamment à ce qui a été décrit en regard des figures 2A et et il n'y a pas lieu de les re-décrire de façon détaillée. Le terminal 1 comprend des circuits 11 d'accès au réseau Ri, constitues exemple d'un modem. Ces circuits regroupent les couches logicielles inférieures, C1 et C2, qui correspondent aux couches "physique" et de "lien données". On a également représenté les couches supérieures, C3 et C4, correspondent aux couches "d'adressage de réseau" ("F", dans le d'Internet) et de "transport" ("TCP"). La couche supérieure d'application ("HTTP", "FTP", "e-mail", etc.) n'a pas été représentée. L'interface entre les couches inférieures, C1 et C2, et les couches supérieures, C3 et C4, est constituée par une couche logicielle généralement appelée "driver couches basses". Les couches supérieures, C3 et s'appuient sur cette interface et sont mises en oeuvre par l'intermédiaire de bibliothèques de fonctions spécifiques ou bibliothèques réseau 14, avec lesquelles elles correspondent. Dans le cas du réseau Internet, "TCPIIP" est mis en ceuvre au moyen de bibliothèques dites de "sockets". Cette organisation permet à un navigateur 10 de poser des requêtes vers un serveur 4, pour la consultation de pages "WEB" (protocole "HTTP"), pour le transfert de fichiers (protocole "FTP") ou l'envoi de courrier électronique (protocole "e-mail"), ce de façon tout à fait classique en soi. Le terminal 1 comprend également un lecteur de carte 3, intégré ou non. Pour communiquer avec la carte à puce 2a, le lecteur de carte 30 englobe également deux couches basses, CC1 (couche physique) et CC2 (couche de lien de données), jouant un rôle similaire aux couches C1 et C2. Les interfaces logicielles avec les couches CC1 et CC2 sont décrites, par exemple, par la spécification "PC/SC" ("part 6, service provider"). Les couches elles-mêmes, et CC2, sont notamment décrites par les normes ISO 7816-1 à7816-4, comme il a été rappelé. Une couche logicielle supplémentaire 16 forme interface entre couches. applicatives (non représentées) et les couches inférieures, CC1 CC2. La fonction principale dévolue à cette couche 16 est une fonction de multiplexageldémultiplexage. Les communications avec la carte à puce 2a effectuent selon un paradigme similaire à celui utilisé pour la manipulation fichiers dans un système d'exploitation du type "UNIX" (marque déposée) : OUVRIR ("OPEN"), LIRE ("READ"), ECRIRE ("WRITE"), FERMER ("CLOSE"), Du côté de la carte à puce 2a, on retrouve une organisation similaire, à savoir la présence de deux couches basses, référencees CCa1 (couche physique) CCa2 (couche de lien de données), ainsi qu'une couche d'interface , tout à fait similaire à la couche 16. Selon l'invention, on prévoit, de part et d'autre, c'est-à-dire dans le terminal 1 dans la carte à puce 2a, deux couches de protocoles spécifiques 13 et 23a, respectivement. Dans le terminal 1, la couche spécifique 13 s'interface aux "drivers couches basses" 15, aux bibliothèques 14 des couches réseau, C3 et C4, et aux couches protocolaires du lecteur de carte 3, c'est-à-dire les couches inférieures, CC1 et via la couche de multiplexage 16. La couche spécifique 13 permet le transfert de paquets réseaux de et vers la carte à puce 2a. En outre, elle adapte les applications existantes telles le navigateur Internet 10, le courrier électronique, etc., pour des utilisations mettant en oeuvre la carte à puce 2a. Du côté de la carte à puce 2a, on retrouve une organisation tout à fait similaire constituée par une instance supplémentaire de la couche spécifique, référencée 23a, pendant de la couche 13. De façon plus précise, les couches spécifiques, 13 et 23a, sont subdivisées trois éléments logiciels principaux - module, 130 ou 230a, de transfert de blocs d'informations entre les couches 13 et 23a, via les couches conventionnelles CC1, CC2, CCal et CCa2 ; - une ou plusieurs pièces de logiciel, dites "agents intelligents", 132 ou 232a, qui réalisent, par exemple, des fonctions de conversion de protocoles ; - et un module de gestion de la configuration spécifique, 131 et 231a, respectivement ; module qui peut être assimilé à un agent intelligent particulier. Pour simplifier, on appellera ci-après les agents intelligents, "agents", comme il a été précédemment indiqué. On retrouve donc, dans le terminal 1 et la carte à puce 2a, une pile protocolaire de communication entre les deux entités. Les couches de niveau deux (couches de lien de données), CC2 et CCa2, assurent l'échange entre la carte à puce 2a et le terminal 1. Ces couches sont responsables de la détection et l'éventuelle correction d'erreurs de transmission. Différents protocoles sont utilisables, et à titre d'exemples non exhaustifs suivants recommandation ETSI GSM 11.11 ; protocole défini par la norme ISO 7816-3, en mode caractère T=0 ; protocole défini par la norme ISO 7816-3, en mode bloc T=1 ; ou le protocole défini par la norme ISO 3309, en mode trame "HDLC" (pour "High-Level Data Link Control procedure" ou procédure commande de liaison à haut niveau). Dans le cadre de l'invention, on utilisera de préférence le protocole ISO 7816- en mode bloc. façon connue en soi, à chaque couche de protocole, il est associe un certain nombre de primitives qui permettent les échanges de données entre couches même niveau et d'une couche à l'autre. A titre d'exemple, primitives associées à la couche de niveau deux sont du type "demande données" ("Data. requesP') et "envoi de données" par la carte ("Data. response"), ainsi que "confirmation de données" ("Data. confirm"), etc. De façon plus spécifique, les couches 13 et 23a sont chargées du dialogue entre la carte à puce 2a et l'hôte, c'est-à-dire le terminal 1. Ces couches permettent l'échange d'informations entre un utilisateur (non représenté) du terminal 1 et la carte à puce 2a, par exemple via des menus déroulants sous la forme d'hypertexte au format "HTML". Elles permettent aussi la mise en place d'une configuration adaptée pour l'émission et/ou la réception de paquets de données. Comme il a été indiqué ci-dessus, les couches comprennent trois entités distinctes. La première couche, 130 ou 230a, est essentiellement constituée un multiplexeur logiciel. Elle permet l'échange d'informations entre la carte ' puce 2a et le terminal hôte 1, sous la forme d'unités de données de protocole. Elle joue un rôle similaire à celui d'un commutateur de paquets de données. Ces unités sont émises ou reçues via la couche de niveau deux (couche de liens de données). Ce protocole particulier de communication permet de mettre en communications au moins une paire d'agents. Le premier agent de chaque paire, 132, est situé dans la couche 13, côté terminal 1, le second, 232a, est situé dans la couche 23a, côté carte à puce 2a. Une liaison entre deux "agents" est associée à une session, que l'on pourra appeler "S-Agent'. Une session est un échange de données bidirectionnel entre ces deux agents. Si l'une l'autre des couches, 13 et 23a, comporte plusieurs agents, les agents d'une même couche peuvent aussi établir de sessions entre eux et/ou avec les modules 131 et 231 a, qui constituent des agents particuliers. De façon plus précise, un agent est une entité logicielle autonome qui peut réaliser tout ou partie de fonctions des couches de niveau trois et quatre, en fonction de la configuration mise en ceuvre par le terminal 1. Les agents sont associés à des propriétés ou attributs particuliers. Pour fixer les idées, et à titre d'exemple non limitatif, les six propriétés suivantes sont associées aux agents - "hôte" : agent localisé dans le terminal ; - "carte" : agent localisé dans la carte à puce ; - "local": agent ne communiquant pas avec le réseau ; - "réseau" : agent communiquant avec le réseau (côté terminal) ; - "client" : agent qui initialise une session ; - "serveur" : agent qui reçoit une demande de session. Un agent particulier est identifié par une référence, par exemple un nombre entier de 16 bits (c'est-à-dire compris entre 0 et 65535). Le bit de poids fort (b15 = 1) indique si la référence est locale (communications locales à la carte à puce ou au terminal) ou distante (b15 = 0). II existe deux grandes catégories d'agents : les agents de type "serveur", qui sont identifiés par une référence fixe, et les agents de type "client", qui sont identifiés par une référence variable, que l'on peut qualifier d'éphémère, délivrée par le module de gestion de configuration, 131 ou 231 a. Les agents communiquent entre eux à l'aide d'entité dites "unités de donnée de protocole" ou "pdu" (pour "protocol data unit", selon terminologie anglo-saxonne) constituant une référence de destination et référence de source. On pourrait également appeler cette "pdu" particulière "SmartTP pdu", en référence au terme anglais "Smart Card" (carte à puce) couramment utilisé. Les "pdu" utilisent notamment les références définies ci-dessus. Une "SmartTP pdu", ou plus simplement "pdu" ci-apres, comporte une référence source, une référence de destination, un ensemble de bits constituant des drapeaux ou "flags" qui précisent la nature de la "pdu", et des données optionnelles - le drapeau "OPEN" (ouvert) est positionné pour indiquer l'ouverture d'une session ; - le drapeau "CLOSE' (fermé) indique la fermeture d'une session ; et - Le drapeau "BLOCK" (verrouillé) indique que l'agent est en attente d'une réponse de son correspondant et suspend toute activité. On appellera jeton une "pdu" qui ne comporte pas de données. L'entité "SmaftTP" contrôle l'existence de l'agent destinataire et réalise la commutation d'un paquet vers ce dernier. Une session agent "S-Agent' possède trois états remarquables, à savoir - un état déconnecté : aucune session n'est ouverte avec un autre agent - un état connecté : une session est ouverte avec un autre agent, une session "S-Agent' étant identifiée par une paire de références ; - un état bloqué, l'agent étant connecté et attendant réponse de son correspondant. Le mécanisme d'établissement d'une session "S-Agent" est le suivant - une nouvelle instance d'un agent client est créée (côté carte à puce ou terminal), cet agent étant identifié par une référence éphémère pseudo- unique ; - l'agent client émet une "pdu" à destination d'un agent serveur (dont la référence est connue ailleurs) avec le drapeau "OPEN' positionné et l'agent client passe à l'état connecté ou bloqué selon la valeur du drapeau "BLOCK'; et - l'agent serveur reçoit la "pdu" avec le drapeau "OPEN' et passe à l'état connecté Une fois une session ouverte, deux agents échangent des données via des "pdu". Le mécanisme de fermeture d'une session est le suivant - un agent émet une avec le drapeau "CLOSE' positionné (et qui comporte éventuellement données ; et - l'autre agent reçoit une " avec le drapeau "CLOSE" positionné (et qui comporte éventuellement données) et la session "S-Agent' passe à l'état déconnecté. La figure 4 illustre façon schématique le diagramme d'états des sessions "S-Agent', telles elles viennent d'être rappelées. Les couches 130 230a gèrent des tables (non représentées) qui contiennent la liste des agents présents, côté terminal hôte 1 et carte à puce 2a. De façon pratique, agents permettent d'échanger des données (de l'hypertexte, par exemple), mais également de déclencher des transactions réseau, autorisant des communications entre la carte à puce 2a et un serveur éloigné 4 (figure 3). Les modules de gestion de configuration, 131 et 231 a, respectivement, sont assimilables à des agents particuliers. Par exemple, le module 131, côté terminal hôte 1, gère notamment des informations relatives à la configuration de ce terminal (modes de fonctionnement), liste des autres agents présents, etc. Le module 231 a, côté carte à puce 2a, a des fonctions analogues. Ces deux agents peuvent être mis en communication l'un avec l'autre pour établir une session. De façon pratique, la carte à puce 2a est avantageusement "adressée" par utilisation d'une adresse "URL" (pour "Universal Resource Locator") définissant rebouclage sur le terminal 1 lui-même, et non un pointage un serveur externe. A titre d'exemple, la structure de cette "URL" est habituellement la suivante http:ll127.0.0.1:8080 (1), dans laquelle 127.0.0.1 est l'adresse "IP" de rebouclage et 8080 le numéro de La figure 5 illustre de façon simplifiée l'architecture logique d'un systeme selon l'invention du type représenté sur la figure 3, mais décrite de façon plus détaillée. carte à puce 2a comprend plusieurs agents, dont deux seulement ont été representés : un agent de type non précisément défini 232a1 et un agent 232a2, de type dit "WEB". La pile logique comprend, les couches de protocole inférieures, référencées 200a, répondant aux normes ISO 7816-3 (figure 2 CCal et CCa2), le gestionnaire de commandes "APDU" 201a1, et le multiplexeur de paquets 230a, ce dernier étant interfacé aux agents, notamment l'agent "WEB" 231 a2. Du coté terminal 1, il existe deux piles, l'une communiquant avec le réseau Internet Ri, l'autre avec la carte à puce 2a. La première pile comprend les organes 1 (figure 2 : C1 et C2) d'accès au réseau (normes OSI 1 et 2) et les couches de protocole "TCPIIP" (figure 3 : C3 et C4), référencées 100. Ces dernières couches sont interfacées avec le navigateur "WEB" 10. L'autre pile comprend couches de protocole inférieures, référencées 101, répondant aux normes 7816-3 (figure 3 : C1 et C2), le gestionnaire 102 d'ordres "APDU" et le multiplexeur de paquets 130, ce dernier étant interfacé avec des agents, dont un seul 1 est représenté. Ce dernier, que l'on supposera de "type réseau", peut en outre communiquer, d'une part avec le navigateur 10, via les couches "TCPIIP" , d'autre part avec le réseau Internet RI, via ces mêmes couches "TCPIIP" et l'organe 11, d'accès au réseau RI. gestionnaire d'ordres "APDU" 201 a est également interfacé avec une ou plusieurs couches de niveau applications, que l'on appellera simplement applications. Ces applications, A,, ... , A;, ..., A, sont, comme il été indiqué, des applications de type conventionnel. En résumé, la fonction client/serveur "WEB", fournie par la carte à puce 2a, peut être réalisée par l'association de l'agent "WEB" 232a1 dans la carte à puce et de l'agent réseau 132 dans le terminal 1, et la mise en oeuvre sessions entre agents, comme il a été décrit. carte à puce 2a présente donc bien la fonctionnalite client/serveur "WEB". outre, selon l'invention, n'importe quelle application conventionnelle, A1 à du type "CGA" précité, peut être activée au travers de client/serveur "WEB", soit par le navigateur "WEB" 10 présent dans le terminal 1, soit par un navigateur éloigné 4, localisé en un point quelconque du réseau Internet RI, par la mise oeuvre de sessions entre agents. Selon le procédé l'invention, les applications, A1 à An, ne nécessitent pas d'être réécrites sont mises en oeuvre telles quelles. Dans le cadre de l'invention, tout ou partie des applications A1 à An peut être constitué par des applications associées à un ou plusieurs des protocoles précités "PE", "PL", etc., et chargé dans une mémoire de la carte à puce Des données représentant un ou plusieurs profils "PA" peuvent également être stockées dans la carte à puce 2a. fonctionnalité client/serveur "WEB" offerte par la carte à puce 2a n'est suffisante pour qu'une application puisse s'exécuter. II est nécessaire de lui adjoindre une fonctionnalité supplémentaire. effet, selon un autre aspect de l'invention, la fonction client/serveur "WEB" offerte par la carte à puce 2a inclut un mécanisme similaire à la fonction dite "CGI" (pour "Common Gateway Interface" ou "interface de passerelle") implantée dans les serveurs "WEB" classique. Avant de décrire un exemple d'architecture conforme à l'invention, permettant de réaliser une fonction de ce type, au sein même d'une carte à puce, il est utile de rappeler les principales caractéristiques d'un mode de fonctionnement "CGI". Le "CGI" est une spécification de mise en oeuvre, depuis un serveur "WEB", d'applications écrites pour les systèmes d'exploitation "UNIX" (marque deposée), "DOS", ou "WINDOWS" (marque déposée). A titre d'exemple, pour système d'exploitation "UNIX", la spécification est "CGI 1.1" et pour le système d'exploitation "WINDOWS 95", la spécification est "CGI 1.3". Toujours à titre d'exemple, une requête "HTTP" pour une adresse "URL", du type "http://www.host.com/cgi-binlxxx.cgi" (2), dans laquelle "host" se réfère à un système hôte (généralement éloigné), interprétée par un serveur "WEB" comme l'exécution d'un script de commande, type "CGI" nommé "xxx" et présent dans le répertoire "cgi-bin" de ce système hote. Bien que le nom du répertoire puisse être a priori quelconque, convention, c'est le nom donné au répertoire stockant les scripts de type "CGI". script est une suite d'instructions du système d'exploitation du système Note dont le résultat final est transmis au navigateur "WEB" émetteur de la requete precitée. Différents langages peuvent être utilisés pour écrire ce script, exemple le langage "PERL" (marque déposée). De façon pratique, la requête est habituellement affichée sur un écran informatique sous la forme d'un formulaire compris dans une page "HTLM". langage "HTLM" permet de traduire un formulaire en une adresse "URL". formulaire comporte un ou plusieurs champs, obligatoires ou non, qui sont remplis par un utilisateur à l'aide des moyens de saisie habituels : clavier pour le texte, souris pour les cases à cocher ou les boutons dits "radio", etc. contenu du formulaire (ainsi qu'éventuellement des informations et instructions dites "cachées") est émis à destination du serveur "WEB". Le code "HTLM" de la page décrit la structure matérielle du formulaire (cadre, graphisme, couleur, et tout autre attribut), ainsi que la structure des champs de données à saisir (nom, longueur, type de données, etc.). La transmission peut s'effectuer selon deux types de formats principaux. Un premier format utilise la méthode dite "POST" et un second la méthode dite "GET". Une information de type de format est présente dans le code de la page formulaire. Ce mécanisme n'est cependant pas directement transposable à une carte à puce, même si celle-ci offre la fonctionnalité client/serveur "WEB" conformément à l'une des caractéristiques de l'invention. On va maintenant décrire un exemple d'architecture permettant d'activer une application quelconque, de type conventionnel, via un serveur "WEB" sur la carte à puce, par référence à la figure 6. Parmi les agents intelligents, prévus conformément ' l'un des aspects de l'invention, on prévoit des agents intelligents particuliers, que l'on appellera ci-après "Agents traducteurs de script" ou de façon abrégée "ATS". Le script est alors interprété par un de ces agents "ATS". Cette traduction peut être réalisée de différentes manières a/par l'agent "WEB" 232a1 lui-même, qui est doté dans ce cas d'une double capacité ; b/par un agent script unique capable de traduire l'ensemble des scripts présents dans la carte à puce 2a ; c/par un agent de script dédié que l'on appellera "ATSD" ci-après (un agent par script) ; ou d/par un agent "APDU" 2010a du gestionnaire d'ordres "APDU" 201 a, qui est doté, dans ce cas, d'une double capacité. L'agent "APDU" 2010a est une composante de la couche gestionnaire d'ordres "APDU" 201a. Cette dernière est une couche capable de centraliser tous les ordres "APDU" émis et/ou reçus par le système, sélectionner des applications, parmi Ai à An, mais également d'offrir une interface de type agent intelligent. Elle est donc capable, selon l'une des caractéristiques de l'invention de communiquer avec tous les agents intelligents (via sessions), que ces agents soient localisés dans le terminal 1 ou la carte à puce 2a. Dans le cas G ci-dessus, une session est ouverte entre l'agent "WEB" 232a1 et l'un des agents "ATSD". La figure 6 illustre un exemple d'architecture pour laquelle les agents traducteurs sont du type "ATSD". Ils sont référencés à ATSn et associés aux applications Ai à An. L'application sélectionnée étant supposée être l'application Agi, la session s'établit entre l'agent "WEB" 232al et l'agent ATS;. Un agent traducteur de script génère une suite d'ordres "APDU". Une session est ouverte entre l'agent traducteur, par exemple l'agent ATS;, et l'agent "APDU" 2101 Les ordres sont alors émis vers l'agent "APDU" 2101 a. gestionnaire d'ordres "APDU" 210a sélectionne l'application "CGA" A; et transmet les ordres "APDU", ordres traduits et donc conventionnels, qu'elle est en mesure comprendre. Cette application est donc correctement activée, sans avoir à modifier ou à la réécrire. Les reponses de l'application Ai sont transmises au gestionnaire d'ordres "APDU" 210a, à l'agent "APDU" 2010a, puis de nouveau à l'agent ATS; (et de façon plus générale à l'agent traducteur de script). Les différents cheminements sont représentés symboliquement sur figure 6 par des traits pleins reliant les blocs fonctionnels, ou en pointillés l'intérieur de ces blocs. Pour effectuer les opérations d'enregistrement d'un abonné sur un plusieurs serveurs d'annuaires etlou la localisation d'abonnés appelés, procédé selon l'invention utilise les deux caractéristiques qui viennent d'être rappelées, à savoir le fonctionnement de la carte à puce en tant serveurlclient "WEB", incluant une fonction "CGI". Selon une forme préférée de réalisation de l'invention, les applications associées aux protocoles d'enregistrement d'abonné "PE" et/ou de localisation d'abonné "PL", ainsi qu'éventuellement un ou plusieurs profil(s) d'abonné sont enregistrées dans la carte à puce 2a. On va maintenant décrire de façon détaillée les différentes phases étapes du procédé selon l'invention pour l'enregistrement d'un abonné et/ou localisation d'un abonné appelé, par référence aux figures 7A à 9. La première phase concerne l'enregistrement d'un profil d'abonné dans un serveur d'annuaire particulier que l'on référencera SA; ci-après. Cet annuaire est un annuaire conforme à l'art connu (par exemple fig. 1 : 91), le procède selon l'invention restant tout à fait compatible avec l'existant. Dans une première étape, illustrée par la figure 7A, la carte à puce est adressée par le navigateur 10 du terminal 1, via les couches 13 et 23a. On récupère, par une commande de type "GET" par exemple, un formulaire de chargement à partir de la carte à puce 2a, formulaire en langage "HTML" que l'on appellera arbitrairement "download.html". Cette récupération est effectuée en consultant une page correspondante dont l'URL est typiquement de la forme suivante http:ll127.0.01:80801download. html (3), dans laquelle http:11127.0.0.1:8080 est l'adresse URL de rebouclage proprement dite, telle qu'elle a été définie par la relation (1), et "download.html" page "HTML" à obtenir. Cette requête met en ceuvre une session entre 'agents apparies comme il a été décrit en regard des figures 2 à 4, selon un premier aspect de l'invention. La carte à puce 2a envoie le formulaire "download.html" lors d'une deuxième étape, toujours par ouvertures de sessions entre agents intelligents apparies, selon le procédé de l'invention. Le formulaire obtenu peut être affiché sur un écran 5a par l'intermédiaire du navigateur 10 et est référencé sur la figure qui illustre schématiquement ce processus. Ce formulaire constitue une page d'accueil pour l'abonné désirant s'enregistrer sur un serveur d'annuaire SA;. La carte à puce 2a se comporte alors comme un serveur "WEB". page P peut comporter, de façon usuelle, différents éléments type graphique et/ou de type texte, ainsi que des éléments interactifs de commande (bouton type dit "radio", cases à cocher, zones d'entrées de données, ). va supposer, dans un premier temps, que la carte à puce 2a offre, à son porteur (non représenté), la possibilité de s'enregistrer sur un serveur d'annuaire unique, que l'on peut appeler SA", et selon un profil unique d'abonne, que l'on peut appeler PA,,. On suppose également que profil unique PA, est enregistré dans la carte à puce 2a. Dans cette hypothèse, le formulaire P (c'est-à-dire la page d'accueil) affiché sur l'écran 5a, peut se réduire à une présentation minimale, dont la figure 7B illustre un exemple possible: formulaire P,. Le formulaire P, comprend diverses zones de textes, sous la reférence unique Zr. Ces zones affichent typiquement le nom "xxx" du serveur d'annuaire (SA" ), l'action proposée "enregistrement' et diverses aides (par exemple "cliquer ici"). Puisque l'on a supposé que les données du profil d'abonné étaient enregistrées dans la carte à puce 2a, il suffit de prévoir un bouton d'envoi BS. Le fait pour l'abonné de cliquer sur ce bouton à l'aide d'une souris (figure 2A: 6b) ou d'appuyer sur la touche "entree" d'un clavier (figure 2A : 6a) déclenche l'envoi du formulaire vers la carte à puce 2a. Dans une autre variante procédé selon l'invention, les données afférentes au profil de l'abonné sont saisies directement par celui-ci. Dans cette hypothèse, le formulaire est plus complexe. La figure 7C illustre un exemple possible de formulaire, référencé II comprend une première zone de texte fixe Zt ,, similaire à celle de la figure 7B (Zt) et une ou plusieurs zone(s) de saisie de données, sous la réference unique Zt 2. On prévoit comme précédemment un bouton d'envoi mais aussi avantageusement un bouton B,e, de ré-initialisation du formulaire qui permet d'effacer les données saisies en cas d'erreur. La ou les zones saisies de données Zt 2 peu(ven)t être du type dit "TEXTAREA" en langage "HTML" et présenter une facilité dite d' "ascenseur" pour l'affichage déroulant de textes longs. Le code "HTML" nécessaire pour programmer un tel formulaire est bien connu en soi et est à 1a portée de l'homme de métier. II n'est pas nécessaire de le détailler plus avant. On peut cependant indiquer qu'il contient notamment une ligne de code en langage "HTML" se présente typiquement sous la forme (4) dans laquelle http:11127.0.01:8080 l'URL de rebouclage de la relation (1), le cgi-smart" le répertoire "CGI" précite contenant un script "pe" associé à une des applications stockées dans la carte à puce 2a, référencée par exemple Ae. Cette application permet l'enregistrement de l'abonné sur l'annuaire SA,, avec le profil PA". Cette action s'effectue de la manière décrite en regard des figures 5 et 6, par mise en ceuvre des fonctionnalités offertes par la carte à puce 2a, "CGI", d'une part, et client/serveur, d'autre part. L'application Ae se comporte comme un client. Dans le premier cas (figure 7B), il n'est pas nécessaire de passer des paramètres à la carte à puce 2a. effet, les données de profil d'abonné PA" sont uniques et enregistrées dans carte à puce 2a. Dans second cas (figure 7C), les données saisies sont passées en tant que parametres à la carte à puce 2a, sous la forme d'une requête "HTTP". La figure 7D illustre schématiquement le processus global de phase d'enregistrement d'un abonné sur un serveur d'annuaire SA", via réseau Internet RI. La réference unique SwEB regroupe différents modules ont été explicités en regard des figures 5 et 6, modules permettant à la carte a puce 2a d'offrir les fonctionnalités combinées de client/serveur WEB et de passerelle "CGI". On a egalement supposé que l'application AB permettant la mise en ceuvre du protocole d'enregistrement "PE" était associée à un agent traducteur de script dédie Ate. II s'agit d'une configuration conforme à celle illustrée par la figure 6. Cependant, comme il a été indiqué, la traduction des scripts peut s'effectuer d'autres manières (par l'agent "WEB" 232a,), etc. L'envoi du formulaire, ouverture de sessions entre agents appariés, va permettre d'activer l'application Ae, par l'intermédiaire de l'agent traducteur de script Ate. Lors d'une étape ultérieure, l'application Ae pose une requête "HTTP" par ouverture sessions entre paires d'agents, notamment impliquant un agent de type "réseau" (figure 6 : 132). La requête est transmise à un serveur d'annuaîre SA;, avec passage de paramètres. Les paramètres sont constitués notamment des données de profil abonné, de façon à permettre son enregistrement dans l'annuaire. L'adresse "URL" du serveur d'annuaire est obtenue à partir d'un profil d'abonné enregistré dans la carte à puce 2a ou à partir de donnees saisies dans le formulaire P2 (figure 7C). A priori, le processus d'enregistrement est terminé à ce stade. II peut cependant comprendre une ou plusieurs étapes supplémentaires. de ces étapes peut consister en l'envoi par l'annuaire d'un accusé de réception, sous la forme d'une requête "HTTP" adressant la carte à puce 2a. L'accusé de reception peut comprendre une information indiquant que l'inscription s'est déroulée de façon satisfaisante, ou au contraire un code d'erreur. Dans ce dernier cas, le processus d'enregistrement doit être répété. Le serveur peut requérir l'envoi de données manquantes ou la ré-émission de données incorrectes ou corrompues. La demande d'enregistrement peut également être rejetée, notamment si la limite de validité de l'abonnement est dépassée. Dans une variante préférée du procédé selon l'invention, il possible, pour un abonné, de s'enregistrer sur plusieurs annuaires différents. Dans cette variante de réalisation, il est en général nécessaire de disposer également de plusieurs protocoles d'enregistrement. Pour ce faire, plusieurs applications associées à ces protocoles sont stockées dans la carte à puce 2a, l'on peut référencer Aa,, ..., A & , ... A,,, en admettant que le nombre maximum de protocoles distincts est n. Comme précédemment, les données associées aux profils d'abonné, que l'on référencera PA,, ..., PA;, ..., PA, peuvent être stockées dans la carte à puce 2a, ou au contraire fournis, au coup par coup, par l'abonne Ion une méthode similaire à ce qui à été décrit en regard de la figure 7C, isie dans un formulaire approprié. q est le nombre maximum de profils d'abonné disponibles. On notera que q n'est pas forcément égal à n. En effet un serveur d'annuaire donné, que l'on référencera arbitrairement SA;, peut accepter plusieurs occurrences distinctes d'un même abonné, d'une D'autre part, plusieurs serveurs d'abonné, bien que distincts, peuvent accepter un même profil d'abonné et éventuellement partager un protocole d'enregistrement commun. Quelle que soit la méthode utilisée pour effectuer la selection tout ou partie des serveurs d'annuaires, les paramètres passés à carte a puce 2a doivent permettre de sélectionner un ou plusieurs profils d'abonné, à PAD, et en " iver une ou plusieurs adresses "URL". Les actions demandees, par les parametres passés à la carte à puce 2a, sont typiquement du type ?sai=enr+pai (5), avec " le nom du serveur d'annuaire d'indice arbitraire i parmi les n possibles, "enr" l'action requise d'enregistrement proprement dit et ." le profil d'abonne à utiliser parmi les q possibles. ou plusieurs requêtes "HTTP" sont posées et transmises aux serveurs d'annuaires concernés, que l'on référencera SAA à SA", 'il existe n serveurs d'annuaire sélectionnables. Le choix présenté sur la page d'accueil P est naturellement fonction la carte à puce 2a insérée dans le lecteur 3. Les choix présentés dépendent droits qui sont accordés à l'abonné possesseur de la carte à puce notamment des abonnements souscrits à des services donnés et de leurs périodes de validité. Une deuxième phase du procédé selon l'invention, c'est-à-dire localisation, sur le réseau Internet, d'un abonné associé à un identifiant quelconque peut se dérouler de façon très similaire à la phase d'enregistrement. Pour ce faire, il est nécessaire d'interroger un ou plusieurs serveur(s) d'annuaire(s). II est nécessaire aussi de disposer d'au moins un protocole "PL" spécifique localisation de cet abonné. Enfin, s'il existe plusieurs serveurs d'annuaires interrogeables, SA, à SA,, il est généralement nécessaire également, comme dans le cas de l'enregistrement, de disposer de plusieurs protocoles localisation distincts. protocoles de localisation peuvent être mis en #uvre à l'aide d'applications stockées dans la carte à puce 2a. processus de localisation se déroule de façon tout à fait similaire à celui l'enregistrement de l'abonné sur un ou plusieurs serveurs d'annuaire La seule exception notable est qu'un profil d'abonné PAJ n' plus explicitement requis. II suffit de fournir à la carte à puce 2a l'identifiant l'abonne recherché et l'adresse du serveur d'annuaire SA;, ou pour le moins des paramètres permettant à l'application associée à l'un des protocoles de localisation déterminer cette adresse "URL". Un profil d'abonné PA; peut toutefois être utilisé pour en dériver automatiquement l'adresse "URL" du serveur d'annuaire SA; à l'aide duquel lequel un abonné appelant désire localiser un abonné appelé. Comme il a été indiqué, l'identifiant de l'abonne recherché peut être son adresse e-mel, adresse qui se présente typiquement sous la forme suivante pseudo@fournisseur. com (6), avec "pseudo" le nom d'utilisateur de messagerie de l'abonné ou plus généralement un pseudonyme, et "fournisseur. com" le nom et le suffixe prestataire service Internet ".com" pouvant être remplace selon les cas par divers suffixes : ".fr", ".net", etc.). La figure 8 illustre les principales étapes de la phase de localisation d'un abonne avec lequel on veut établir une communication téléphonique par interrogation d'un annuaire SA Dans une première étape, la carte à puce 2a adressée par le navigateur du terminal 1, via les couches 13 et 23a. récupère, par une commande type "GET" par exemple, un formulaire de chargement à partir de la carte à puce 2a sous la forme d'une page d'accueil réferencée P'. Cette page d'accueil peut prendre différents aspects, similaires notamment à ceux décrits en regard la figure 7C. Selon qu'il y ait un ou plusieurs choix possibles, l'abonné selectionne un ou plusieurs serveurs d'annuaires et fournit des données d'identification de l'abonné recherché. Sur la figure 8, on a supposé qu'un seul serveur d'annuaire SA; était interrogeable. La page est transmise sous forme d'une requête "HTTP" à la carte à puce 2a et interprétée par un agent traducteur de script Atf associé à une application de mise en oeuvre du protocole "PL". Par double mécanisme client/serveur "WEB" et "CGI" (module référencé comme précédemment), une requête du type http 27.0.0.1I? sa,--loc+pseudo@fournisseur (7), est interpretee par la carte à puce 2a comme une demande de localisation de l'abonné dont l'identifiant est (6) sur le serveur d'annuaire SA;. requête "HTTP" est transmise à ce serveur qui renvoie les informations demandées, dans la mesure où elles sont disponibles. II recherche dans sa base de données une adresse "IF correspondant aux données d'identification reçues. En cas de succès, c'est-à-dire si l'abonné demandeur est effectivement enregistré, si cet abonné a le droit d'obtenir cette adresse et si les données reçues sont correctes, les données retransmises comprennent l'adresse "1P" de l'abonné recherché, ce qui permet de le localiser. Ces différentes étapes mettent en ceuvre des sessions entre agents appariés, selon un des aspects de l'invention. On peut également stocker dans la carte à puce 2a plusieurs applications, chacune étant destinée à la mise en oeuvre d'un protocole de localisation distinct, a priori associé à un serveur d'annuaire également distinct. Dans une variante préférée du procédé selon l'invention, on stocke dans la carte à puce 2a des applications permettant la mise en oeuvre plusieurs protocoles d'enregistrement, plusieurs protocoles de localisation et fichiers de données pour l'enregistrement de plusieurs profils d'abonne. Cette disposition avantageuse permet de transformer la carte à puce 2a en base de données portable multi-annuaire. Dans une autre variante encore du procédé selon l'invention l'utilisation d'une carte à puce 2a permet une authentification robuste de son possesseur, lors de la phase d'enregistrement et/ou de la phase de localisation. effet, il est possible stocker des données de sécurité dans la carte à puce reste propriété son possesseur. De telles donnés de sécurité peuvent être constituées des clés de chiffrage. Du fait que, selon l'un des aspects avantageux du procède selon l'invention, carte à puce 2a peut communiquer directement avec le réseau Internet, par mise en oeuvre de sessions entre agents, ces données ont pas à être transmises à un dispositif externe, serait-ce le terminal 1. Les traitements touchant à sécurité sont effectués directement par la carte à puce Cette façon de procéder offre donc un degré de sécurité beaucoup plus eleve que la simple utilisation de couches logicielles dites sécurisées des navigateurs "WEB" récents, connues sous l'abréviation anglo-saxonne "SSL" (pour "Secure Socket Layer"). L'authentification proprement dite peut s'effectuer en ayant recours à la technique dite de certificat, en association avec les clés de chiffrage précitées, stockées dans la carte à puce 2a. Cette procédure peut nécessiter des transactions supplémentaires entre la carte à puce 2a et le ou les serveur(s) d'annuaire concerné(s), à l'aide de requêtes "HTTP" transitant par le réseau Internet Ri. En fonction du résultat, positif ou négatif, de l'authentification, l'abonné est autorisé ou non à effectuer les traitements, enregistrements ou localisations qu'il désire réaliser. Selon un autre aspect de l'invention, en ayant recours de nouveau à agents intelligents, on implante directement sur la carte à puce 2a une fonction dite de "proxy TCPIIP". Cette fonction est réalisée par une application logicielle particulière que l'on appellera "filtre "ci-après. La fonctionnalité "proxy" est bien connue dans le domaine applications Internet, mais ne peut être implantée dans les cartes à puce systèmes selon l'art connu. Avant de décrire une architecture conforme à l'invention, on va tout d'abord rappeler brièvement les caractéristiques d'un "proxy" classique selon l'art connu, par référence à la figure 9. Dans la technologie "TCPIIP", on nomme "proxy" une entité logicielle qui réalise, d'une part, un serveur "TCPIIP" Sv et, d'autre part, un client "TCP/IP" Cl. L'entité logicielle Py réalise une connexion entre une client local un autre serveur TCPIIP distant. Un proxy Py réalise usuellement des fonctions de filtre et/ou de sécurite. Par exemple, un proxy "HTTP" assure généralement la connexion navigateur, par exemple le navigateur 10 du terminal 1, à un serveur "WEB" dans une entreprise (ce qui est connu sous la dénomination "firewall" ou "pare- feu"). II peut s'agir également d'un proxy dit "SSL", que l'on peut définir comme étant un "proxy" local au terminal, qui réalise des opérations de sécurite nécessaires (authentification - confidentialité - intégrité) à l'établissement tunnel sécurise au travers du réseau Internet Ri. On va maintenant décrire une architecture logique intégrant la fonction "proxy " directement dans une carte à puce, selon un aspect supplémentaire l'invention, référence à la figure 10. Les eléments communs aux figures précédentes portent les mêmes références ne seront re-décrits qu'en tant que de besoin. Pour simplifier description, agents, côté terminal 1 sont regroupés sous la référence unique 132, côté carte à puce 2a, sous la référence unique 232a. Ils seront différenciés dans ce qui suit par la lettre "T", pour "terminal", et "S" pour "Smart Card" (carte à puce), lettres associées à des chiffres en indice. Le "proxy" réalisé sur la carte à puce 2a sera appelé "Smart Proxy' dans ce qui suit. Le "Smart Proxy' est réalisé par l'association de quatre agents, deux, côté terminal 1 : T, et et deux, côté carte à puce 2a, : S, et S2, et d'une fonction filtre 28, comme décrit ci-après - un agent "Terminal/Client/Réseau" T, réalise un serveur TCPIIP (par exemple sur le 8080) ; - un agent "Carte/Serveur/local" S, est associé par une session à l'agent T,, cet agent realisant typiquement les fonctions d'un serveur "WEB" ; - une fonction filtre 28 qui est déterminée en fonction d'informations en provenance de l'agent T,, cette dernière fonction étant en mesure d'émettre ou de recevoir "pdu" vers/depuis les agents S, et S2; - un agent "Carte/Client/Local", une instance de cet agent étant créée de manière dynamique par la fonction filtre 27 et S2 ouvrant une session avec l'agent "reseau" T2, auquel il indiquera l'adresse du serveur distant Internet 4 auquel veut être relié ; et - un agent "Terminal/Serveur/Réseau" réalise la fonction d'un client "TCPIIP", qui connecté à un serveur Internet 4. Le mécanisme creation du "Smart Proxy" 27 est décrit ci-dessous. Un client "TCP", l'on appellera ci-après "cTCP", typiquement le navigateur "WEB" 10, ouvre une connexion avec l'agent "réseau" T,. Une session T,-S, est ensuite créee. Par exemple l'URL suivante http:11127.0.0.1:80801?des1=xxx.com:80hyyylcontent.html (8) provoque l'ouverture d'une session entre les agents T, et S,. A partir des données échangées par T, et S,, l'application associée à l'agent S, (un serveur WEB) détermine quelle fonction filtre 28 doit être utilisée. Ainsi "des1" est le nom d'un filtre particulier, "xxx.com" est le nom arbitraire d'un serveur Internet, par exemple du serveur 4, "80" un numéro de port et "hyyylcontent.html" est le arbitraire d'un fichier sur ce serveur, constitué dans l'exemple par une page en langage "HTML". Dans l'exemple, le filtre "des1" est un filtre permettant de réaliser une opération de déchiffrage et/ou de chiffrage selon un algorithme de type "DES" ("Data Encryption System"). Dans le cadre de l'invention, le serveur 4 est constitué par un serveur d'annuaire (par exemple figures 7D et 8 : SA;). En d'autres termes, l'URL "carte", défini la relation 2, encapsule un autre URL destinée au monde extérieur, la premiere partie de cette URL étant constituée par l'URL de rebouclage tel que définit la relation (1). Le filtre 28 "des1" crée une instance client S2, une session est ouverte entre les agents S2 et T2 Les données inserées dans la première "pdu" ("pdu OPEN') précisent le nom du serveur Internet ("xxx.com") et son numéro de port associé (80). L'agent T2 ouvre une connexion de type "TCP" avec le serveur distant "sTCP" (" zzz.com"). Une fois que cette dernière établie, un jeton est émis à destination de S2. Au terme de ces échanges un "Smart Proxy" 27 a été crée, une fonction filtre 28 qui réside dans la carte à puce 2a est mesure de traiter les données (en provenance du réseau Internet RI) reçues les agents "réseau". Le filtre 28 contrôle les données émises par les agents "réseau", T, et T2, de manière logique. II se comporte comme un "proxy qui contrôle les données échangées entre le client "cTCP" et le serveur "sTCP". Pour fixer les idées, on a représenté figure 10 des numéros de référence arbitraires des différents agents : fixes "2" et "5", pour les agents de type "serveur", respectivement T2 et S,, et variables ou éphémères, "15360" et "2559", pour les agents de type "client", respectivement T, et S2, D'autres types de filtres peuvent être implantés dans la carte à puce 2a. Ces filtres peuvent alors être utilisés pour la mise en ceuvre des négociations d'échange de clés de chiffrement ou de négociations de réservation d'un chemin de routage de caractéristiques particulières. A titre d'exemple; l'abonné appelant désirant transmettre un fichier multimédia à débit élevé ou une grande quantité de données, il souhaite obtenir une garantie de bande passante minimale et/ou de non-encombrement du trafic, fusse à titre onéreux. Précisément, un autre type de filtre sur carte à puce 2a peut réaliser une fonction de tarification, basée classiquement sur le débit ou la quantité de données échangées, mais aussi sur le type chemin négocié avec un prestataire de service pendant la phase de signalisation. Pour ce faire, comme il est bien connu en soi, on utilise essentiellement compteurs. fois un abonné localisé, la fonction "proxy", implantée directement sur la ' puce 2a, est utilisée pour les étapes correspondant aux opérations de signalisation et/ou d'échanges de données proprement dites entre un abonné appelant abonné localisé et appelé. On doit bien comprendre que le procédé selon l'invention, utilisé par un abonné appelant, n'exige pas que l'abonné appelé mette en oeuvre également ce même procédé. En effet, et c'est un avantage supplémentaire de l'invention, l'un des abonnés, par exemple l'abonné appelé, peut utiliser un terminal standard, conforme à l'art connu (figure 1 : 9b). II n'est pas nécessaire notamment que ce terminal soit muni d'un lecteur de carte à puce. En d'autres termes, au moins en ce qui concerne l'une des installations associées à l'un abonnés, appelant ou appelé, le procédé selon l'invention est entièrement compatible avec l'existant, matériel et logiciel de téléphonie, l'autre installation ne nécessitant que peu de modifications pour devenir conforme au procédé l'invention. Cependant, on va supposer que, dans une variante préférée l'invention, l'abonné appelant et l'abonné appelé, utilisent tous deux un terminal mettant en oeuvre le procédé selon l'invention. Ci-après, le côté "appelant" sera repéré arbitrairement par la lettre de référence "a" et le côté "appelé" par lettre de référence "b". La figure 11A illustre schématiquement l'architecture d'un système téléphonie mettant en oeuvre la fonctionnalité "proxy" pour le canal signalisation CS, du côté abonné appelant Aa et du côté abonné appelé Ab. cette figure, les terminaux appelants 1 a et 1 b sont réduits, pour I commodite de la description, aux seules pièces de logiciel associées protocoles de signalisation "PSP", 902a et 902b, respectivement. En soi, pièces logiciel sont, a priori, conformes aux pièces de logiciel correspondantes de l'art connu (voir figure 1). Cependant, la fonctionnalité "proxy" peut nécessiter leur adaptation pour pouvoir supporter des cartes à puces Internet mettant en oeuvre le procède selon l'invention. Pour le moins, comme il va l'être montré, elles doivent pouvoir être paramétrées de manière à modifier le numéro de port (de type "TCP") signalisation. Certains logiciels de téléphonie, en version standard du commerce, ne permettent pas ce paramétrage. On peut citer, à titre d'exemple non limitatif le logiciel "Netmeeting", alors que le logiciel "Webphone" le permet, logiciels tous deux cités dans le préambule de la présente demande de brevet. Cependant, l'intérêt d'utiliser un "proxy" de signalisation est de pouvoir mettre en oeuvre une procédure de simple ou mutuelle authentification entre l'abonne appelant Aa et l'abonné appelé Ab qui peut être utile, par exemple, pour l'acceptation des communications. carte à puce 2a de l'abonné appelant Aa est associée à un serveur, constitue, selon l'invention, par un agent réseau serveur "TCP", que appellera de signalisation, sur un port "TCP". Ce port sera appelé "PSCS" pour "Port Signalisation Carte Source". La carte à puce 2a de l'abonné appelant se connecte au port de signalisation correspondant de la carte à puce 2b l'abonné appelé Ab. Ce port sera appelé "PSCD" pour "Port Signalisation Carte Destination". II est localisé à une adresse "IF que l'on appellera arbitrairement "@i p". carte de l'appelé 2b réalise un "proxy" de signalisation entre le "TCP" "PSCD" et le port "PSLT" ou "Port de Signalisation du Logiciel Téléphonie" du terminal 1 b de l'abonné appelé Ab. Ces transactions nécessitent l'établissement de sessions entre agents appariés, selon l'une des caractéristiques du procédé de l'invention qui a explicitée en regard des figures 3 à 5, et la mise en ceuvre de la fonctionnalite "proxy", selon une autre caractéristique du procédé de l'invention qui a explicitee en regard de la figure 10. Sur la figure 11 A, les "proxys" des cartes à puce 2a et 2b sont représentés schématiquement par les références 27a et 27b. Ils comprennent en réalité les différents éléments représentés sur la figure 10 : agents S, et et filtre Pour fixer les idées, on va maintenant décrire, dans un exemple réalisation pratique, les principales étapes de la phase de signalisation. Pour fixer idées, on suppose que l'adresse "URL" de rebouclage de carte est celle donnee par la relation (1), soit 127.0.0.1 et le numéro de port arbitraire 1731. numéro de port des logiciels de téléphonie est généralement 1503. L'adresse l'abonne appelé Ab, telle qu'elle a été déterminée lors la phase de localisation, est @ip. Du côté abonné appelant Aa I étape de préparation : configuration du "proxy" de manière à opérer la translation 127.0.0.1:1731à @ip:1503 ; étapes d'appel gal "PSP" appelant 902a appelle 127.0.0.1:1 ; 2b/ la carte à puce appelante 2a appelle @ip:1 ; et 2c! la carte à puce appelée 2b appelle @ip:1 Du côté abonné appelé Ab étape de préparation préalable : modification numéro de port de signalisation de "PSP" (appelé) de 1503 à 1502 ; étape de communication entre la carte à puce 2b et le terminal 1 b mise en oeuvre d'un agent de type réseau "TCP" le port 1503 et fonctionnalité "proxy" 27b entre les ports 1503, entrée de carte, 502 en sortie. Naturellement, si seul le système d'abonné appelant, la-2a, est du type conforme à l'invention, la carte à puce 2a appelle directement le système d'abonné appelé à l'adresse "URL" @ip:1502. De manière optionnelle, une paire de clés de chiffrement peut être négociee au cours de la procédure de signalisation. Les échanges des données correspondantes s'effectuent également par l'établissement de sessions entre agents appariés. La carte à puce conforme au procédé de l'invention peut également se comporter comme un "proxy" (de type "UDP") de protocole d'échange de données, sur le canal de données CD. Comme précedemment, cette fonctionnalité peut nécessiter l'adaptation des logiciels téléphonie de manière à supporter des cartes à puce conformes au procédé l'invention. Cependant, là aussi, la mise en oeuvre d'un "proxy d'échange de données présente un intérêt certain. Celui-ci réside dans le fait de pouvoir mettre couvre une procédure chiffrement/déchiffrement des informations. La norme G723, par exemple, qui compresse le son avec des débits compris entre 5,3 Kbps et 6,3 Kbps, est compatible avec les débits des cartes a puce actuelles, débits typiquement compris entre 9600 bps et 105900 bps. Comme il a été décrit, en regard de la figure 10, le filtre du "proxy" peut être notamment un filtre permettant de réaliser une opération de déchiffrage et/ou de chiffrage selon un algorithme de type "DES". La figure 11B illustre schématiquement l'architecture d'un système de téléphonie mettant en oeuvre la fonctionnalité "proxy", pour le canal de données CD, du côté abonné appelant Aa et du côté abonné appelé Ab. Sur la figure 11 B, les "proxys" des cartes à puce 2a et 2b sont représentés schématiquement par les références 27a et 27b. Ils comprennent en réalité, comme précédemment, les différents éléments représentés sur la figure 10 agents S, et S2, et filtre 28. La carte à puce 2a de l'abonné appelant Aa est associée à un serveur constitué par un agent réseau serveur de type "UDP" d'échange de donnees sur un port "UDP", que l'on appellera "PDCS" pour "Port Données Carte Source". La carte à puce 2a de l'abonné appelant Aa se connecte au port d'échange de données de la carte à puce 2b de l'abonné appelé Ab, que l'on appellera "PDCD" pour "Port Données Carte Destination", carte localisée à une adresse "1P" arbitraire "@ip". La carte à puce 2b de l'abonné appelé Ab réalise un "proxy" d'échange de données entre le port "UDP" "PDCD" et le port "PDLT" ou "Port de Données du Logiciel de Téléphonie" du terminal lb. Il est nécessaire dans ce cas de mettre en oeuvre deux "proxy" d'échanges de données : le "proxy" 27a de l'abonné Aa appelant vers l'abonné appelé Ab, et l'autre de l'abonné appelé Ab vers l'abonné appelant Aa. Comme précédemment, si seul le système d'abonné appelant, a-2a, est du type conforme à l'invention, la carte à puce 2a appelle directement le système d'abonné appelé. La figure 12, synthèse des figures 11 A et 11 B, illustre schématiquement l'architecture générale d'un système de gestion de transmission de données téléphoniques SGDT (et, de façon plus générale, de données multimedias) entre un abonné appelant Aa et un abonné appelé Ab, plus précisément entre un système appelant comprenant le terminal appelant 1 a coopérant avec la à puce 2a, et un système appelé dit serveur, référencé globalement 1'b. Le systeme appelé 1'b peut présenter indifféremment une configuration similaire au systeme appelant, c'est-à-dire conforme à l'invention : terminal 1 a coopérant avec une carte à puce 2a (tel que décrit sur la figure 11A et/ou la figure 11 B), ou configuration d'un système de l'art connu (voir figure 1 : 9b). Les éléments communs aux figures précédentes portent les mêmes références et ne seront redécrits qu'en tant que de besoin. La figure 12 illustre les différentes interactions entre composants elémentaires du système de gestion de transmission de données téléphoniques selon l'invention, tels qu'elles ont été explicitées en regard notamment figures 3 à 8, et 10 à 11 B. De façon plus précise encore, la carte à puce illustre un mode de réalisation préféré de l'invention pour lequel les applications associées aux protocoles d'enregistrement "PE" 900a et au protocole localisation "PL" 901 a, ainsi qu'un profil d'abonné "PA" 903a sont enregistres dans des mémoires de cette carte à puce 2a (comme explicité par les figures 8). De même, on a supposé que la carte à puce 2a présente la fonctionnalite proxy" 27a, aussi bien pour le canal de signalisation CS et que pour le canal données CD (figure 11A et 11 B). Comme il a été précédemment décrit, le proxy est sous le contrôle du clientlserveur SWE8 de la carte à puce 2a. Enfin, bien qu'un seul serveur d'annuaire SA; ait été représenté sur figure 12, dans un mode de réalisation préféré encore, on stocke dans la carte a puce 2a des applications permettant la mise en oeuvre de plusieurs protocoles d'enregistrement, plusieurs protocoles de localisation et des fichiers de données pour l'enregistrement de plusieurs profils d'abonné. Cette disposition avantageuse permet de transformer la carte à puce 2a en base de donnees portable multi-annuaire. En soi, le(s) serveur(s) est(sont) tout à fait similaires serveurs de l'art connu, par exemple au serveur 91 de la figure 1. comporte des protocoles d'enregistrement "PE" 910 et de localisation "PL" d'abonnés. A la lecture de ce qui précède, on constate aisément que le procède l'invention atteint bien les buts qu'elle s'est fixés. La fonctionnalité dite de "proxy" directement implantée dans carte à puce, en coopération avec la fonctionnalité de client/serveur "WEB" offerte par celle-ci, permet d'utiliser une carte à puce comme "proxy" de protocole de signalisation et/ou d'échange de données. Si la carte à puce est utilisée comme "proxy" de protocole de signalisation, il est notamment possible de mettre en ceuvre une procédure de simple ou mutuelle authentification entre un abonné appelant et un abonné appelé. II est également possible de négocier des clés de chiffrement et/ou de réserver un chemin de routage offrant des caractéristiques de transmission pré établies. Si la carte à puce est utilisée comme "proxy" de protocole de communication, il est notamment possible de mettre en ceuvre une procédure de chiffrement/déchiffrement. Il est aussi possible d'effectuer des opérations de tarification, par exemple basées sur le débit ou la quantité de données échangées, ou encore en tenant compte de la réservation précédemment effectuée. Le procédé selon l'invention permet également à un abonné, par exemple appelant,. de s'enregistrer sur un ou plusieurs serveurs d'annuaires et/ou de localiser un autre abonné, dit appelé, sur le réseau Internet, également par l'intermédiaire de un ou plusieurs annuaires. La carte à puce présentant les fonctionnalités combinées d'un client/serveur "WEB" et d'une passerelle "CGI", cette disposition permet des communications directes entre la carte à puce et le ou les serveurs d'annuaire. Elle autorise de ce fait le stockage des logiciels spécifiques nécessaires à la mise en oeuvre des protocoles d'enregistrement et/ou de localisation, ce qui permet une grande mobilité. Un ou plusieurs profils d'abonné peuvent également être stockés dans la carte à puce. L'abonné n'est plus astreint à l'utilisation de terminaux configurés spécifiquement pour les protocoles précités. Le procédé selon l'invention est tout à fait compatible avec l'existant. II n'est pas requis que l'abonné, appelant ou appelé, se soit enregistré sur un ou plusieurs serveurs d'annuaires en faisant usage du procédé selon l'invention, ni qu'il soit doté d'un terminal muni d'un lecteur de carte à puce selon l'invention. Les transmissions sur le réseau Internet s'effectuent selon les protocoles en vigueur et les communications entre le terminal de l'abonné mettant en oeuvre procédé selon l'invention et sa carte à puce font appel au protocole normalise "1S0" précité. On peut donc mettre en oeuvre un lecteur de carte à puce standard. Seule la présence d'une couche logicielle spécifique dans le terminal est nécessaire, ce qui ne nécessite que peu de modifications et peut être réalise une fois pour toutes, quel que soit le nombre de protocoles d'enregistrement, localisation et/ou de profils d'abonné portés par la carte à puce, et quelle soient leurs natures. II en est de même des filtres de "proxy" implantés dans carte à puce. Enfin, l'utilisation d'une carte à puce permet une sécurisation transactions notamment, une authentification "robuste". Elle permet également la negociation de chemin de routage et/ou la tarification des donnees échangées. II doit etre clair cependant que l'invention n'est pas limitée aux seuls exemples de realisations explicitement décrits, notamment en relation avec figures 3 à 8, d'une part, et 10 à 12, d'autre part. En particulier, il n'est pas nécessaire que les deux séries de logiciels propriétaires, "PE" et "PL" soient stockées dans la carte à puce, bien que cette disposition soit particulièrement avantageuse. A titre d'exemple non limitatif, (les) phase(s) d'enregistrement, dans un ou plusieurs serveurs d'annuaire(s), pouvant être réalisée(s) une fois pour toutes, ou pour le moins étant a priori moins fréquente(s) que les phases de localisation, on pourrait se contenter ne stocker dans la carte à puce que les applications spécifiques associées cette dernière opération. De même, comme il a été indiqué, il est possible de pas enregistrer dans la carte à puce les profils d'abonné "PA" (les données pouvant être fournies en temps réel au moment de l'enregistrement de l'abonne dans un serveur d'annuaire particulier). Il est encore possible de n'enregistrer qu'une partie des profils d'abonné, profils qui pourront être fournis de façon automatique. Enfin, comme il a été indiqué, l'invention n'est pas limitée à la gestion des seules données de type téléphonique. Elle permet plus généralement gestion d'autres types de données multimédias, notamment de données visiophoniques. REVENDICATIONS 1. Procédé de gestion de transmissions de données multimédias via un réseau de type Internet entre un premier système d'abonné un second système d'abonné comprenant au moins une phase d'échange de données dites de signalisation, via un canal dit de signalisation, à l'aide d'un protocole de signalisation déterminé, et une phase d'échange desdites données multimédias, via un canal dit de données, à l'aide protocole de communication déterminé, caractérisé en ce que, au moins ledit premier système d'abonné comportant un terminal muni navigateur de type "WEB" et d'un lecteur de carte à puce coopérant avec une carte à puce, ladite carte à puce (2a) comportant une premiere piece de logiciel (23a), formant une couche protocolaire de communication spécifique et ledit terminal (l a) comportant une seconde piece de logiciel (13), formant une couche protocolaire de communication spécifique et formant interface avec au moins it navigateur de type "WEB" (10) ; lesdites première et seconde pièces logiciel (13, 23a) comprennent chacune en outre au moins une première entité logicielle autonome (T2, S,), de type dit client, et une deuxième entité logicielle autonome (T,, S2), de type dit serveur, lesdites entites S2, T,, SZ) coopérant de manière à permettre l'établissement sessions d'échanges de données bidirectionnels entre ledit terminal (1 et ladite carte à puce (2a) et à ce que ladite carte à puce (2a) offre fonctionnalité d'un client/serveur de type "WEB", et à permettre l'établissement d'une session d'échanges de données bidirectionnels entre le terminal (1a) dudit premier système d'abonné et ledit second système d'abonné (1'b) via ledit réseau de type Internet (RI), lesdites entités logicielles autonomes communiquant au moyen d'unités données de protocole prédéterminées ; - en ce qu'il comprend la réalisation, dans ladite carte à puce (2a), d'une pièce de logiciel applicative de caractéristiques fonctionnelles déterminées, dite filtre (28), recevant et/ou émettant des unités données de protocole vers lesdites et/ou à partir desdites première deuxième entités logicielles autonomes (S2, S,), de types respectifs client et serveur, comprises dans ladite seconde pièce de logiciel spécifique (23a) ; la réalisation de ladite pièce applicative étant sous contrôle de ladite entité logicielle autonome de type serveur (S,) ; et - en ce que ledit filtre (28) coopère avec lesdites entités logicielles autonomes (S2, S,) de ladite seconde pièce de logiciel spécifique (23a) pour ouvrir une session avec lesdites entités logicielles autonomes (T2, T,) ladite première pièce de logiciel spécifique pour former une fonction dite "proxy " (27a) et contrôler des caractéristiques prédéterminées des échanges de données transitant entre ledit premier système d'abonné (la, 2a) et ledit second système d'abonné (1'b), via au moins l'un desdits canaux signalisation (CS) et/ou de données (CD), pendant lesdites phases d'échanges de données de signalisation et/ou de données multimédias. 2. Procédé selon la revendication 1, caractérisé en ce que lesdites entités logicielles autonomes sont constituées par des agents intelligents (T2, T,, S2. S,). 3. Procédé selon la revendication 2, caractérisé en ce que chacun desdits agents intelligents (T2, T,, S2, S,) est associés à au moins l'une six propriétés suivantes "hôte" : agent intelligent localisé dans ledit terminal (1) ; "carte" : agent intelligent localisé dans ladite carte à puce (2a) ; "local" : agent intelligent ne communiquant pas avec ledit réseau (RI) ; "réseau" : agent intelligent communiquant avec ledit réseau (RI) "client" : agent intelligent qui initialise une desdites sessions ; et "serveur" : agent intelligent qui reçoit une demande pour une desdites sessions. 4. Procédé selon la revendication 3, caractérisé ce que ladite première pièce de logiciel spécifique comprend un premier agent intelligent (T,) associé auxdites propriétés "terminal", "serveur" "local", dit T,, réalisant la fonction d'un serveur de type "TCPIIP", en ce ladite seconde pièce de logiciel spécifique comprend un premier agent intelligent (S,) associé auxdites propriétés "carte", "serveur" et "local", S,, cet agent S, étant associé par une session audit premier agent intelligent T,, en ce que lesdites caractéristiques fonctionnelles déterminées dudit filtre (28) sont fonctions d'informations en provenance dudit premier agent intelligent T,, en ce que ladite première pièce de logiciel spécifique comprend un deuxième agent intelligent (T2) associé auxdites propriétés "terminal", "serveur" et "réseau", dit T2, réalisant la fonction d'un serveur type "TCPIIP" ou "UDPIIP", pour être connecté audit second système d'abonné (1'b) via ledit réseau de type Internet (RI), et en ce que ladite seconde pièce de logiciel spécifique (23a) comprend un deuxième agent intelligent (S2) associé auxdites propriétés "carte", "client" et "local", dit S2, une instance de cet agent intelligent S2 étant créée à chacune des dites sessions de manière dynamique par ledit filtre (28) et cet agent S2 ouvrant des sessions avec ledit deuxième agent intelligent T2 et lui indiquant une adresse permettant de se connecter audit second système d'abonné (1'b), de manière à ce que lesdits agents intelligents (T2, Ti, S2, S,) et ledit filtre (28) coopèrent pour former ladite fonction de "proxy TCP" (27a) et contrôlent lesdites caractéristiques des échanges de données entre ledit premier système d'abonné (Aa) et ledit second système d'abonné (Ab), via lesdits canaux de signalisation (CS) et/ou de données (CD). 5. Procédé selon la revendication 1, caractérisé en ce que ladite fonction "proxy" contrôle lesdites caractéristiques desdites données de signalisation transitant sur ledit canal de signalisation, en ce que le terminal (la) dudit premier système d'abonné et ledit second système d'abonné (1'b) comprenant une pièce de logiciel spécifique (902a, 902b), dite de signalisation, associée à un port de type "TCP", dit de signalisation, désigné un numéro de port prédéterminé, il comprend au moins les étapes suivantes - établissement d'un session d'échange bidirectionnels entre le terminal dudit premier système d'abonné, dit appelant, et ladite carte à puce (2a) lui est associée, par mise en ceuvre d'un serveur de type "TCP", de manière à appeler ladite carte à puce (2a) sur une adresse de type "URL" dite rebouclage ; - appel dudit second système d'abonné (1'b), dit appelé, ladite carte a puce (2a), via ledit réseau Internet (RI), sur une adresse type "URL" constituée d'une adresse de type "1P" désignant ledit abonne appelé (Ab), determinée pendant la dite phase de localisation, et dudit numéro de port de signalisation; - et transmission desdites données de signalisation ledit canal de signalisation (CS) au travers dudit "proxy" (27a) et via ledit reseau Internet (RI). 6. Procédé selon la revendication 5, caractérisé en ce ledit système d'abonné appelé comportant un terminal (1b) dans lequel est implanté ladite seconde pièce de logiciel et coopérant avec une carte à puce (26) dans laquelle est implantée ladite seconde pièce de logiciel et ladite pièce de logiciel applicative pour former ledit "proxy" (27b), il comprend les étapes supplémentaires suivantes - appel de la carte à puce (2b) dudit système d'abonné appelé par la carte à puce (2a) dudit système appelant; et - communication entre la carte à puce (2b) du terminal (1b) dudit système appelé et ce terminal, au travers dudit "proxy" associé à cette carte à puce. 7. Procédé selon la revendication 5, caractérisé en ce que ledit contrôle caractéristiques prédéterminées des échanges desdites données de signalisation comprend une étape de simple ou de mutuelle authentification entre lesdits abonnés appelant (Aa) et appelé (Ab) effectuée par lesdits "proxys" (27a, 27b). 8. Procédé selon la revendication 5, caractérisé en ce que ledit contrôle de caractéristiques prédéterminées des échanges desdites données de signalisation comprend une étape de négociation de réservation d'un chemin de routage à emprunter par lesdites données pendant la dite phase d'échange de données, effectuée par lesdits "proxys" (27a, 27b). 9. Procédé selon la revendication 1, caractérisé en ce que, ladite fonction "proxy" (27a) contrôle lesdites données multimédias transitant sur ledit canal de donnés (CD), en ce que le terminal (1a) dudit premier systeme d'abonné et ledit second système d'abonné (1'b) comprenant une pièce de logiciel spécifique (905a, 905b), dite de d'échange de données, associee à port de type "UDP", dit de données, désigné par un numéro de prédéterminé, il comprend au moins les étapes suivantes - établissement d'un session d'échange bidirectionnels entre le terminal dudit premier système d'abonné, dit appelant, et ladite carte à puce (2a) lui est associé, par mise en ceuvre d'un serveur de type "UDP", manière à appeler ladite carte à puce (2a) sur une adresse de type "URL" dite rebouclage ; - appel dudit second système d'abonné (1'b), dit appelé, par ladite puce (2a), via ledit réseau Internet (RI), sur une adresse de type "URL" constituée d'une adresse de type "1P" désignant ledit abonné appelé (Ab), déterminée pendant la dite phase de localisation, et dudit numéro de port signalisation ; - et transmission desdites données multimédias sur ledit canal données (CD) au travers dudit "proxy" (27a) et via ledit réseau Internet (RI). 10. Procédé selon la revendication 9, caractérisé en ce que ledit système d'abonné appelé comportant un terminal (1b) dans lequel est implanté ladite seconde pièce logiciel et coopérant avec une carte à puce (2b) dans laquelle est implantee ladite seconde pièce de logiciel et ladite pièce de logiciel applicative pour former ledit "proxy" (27b), il comprend les étapes supplémentaires suivantes - appel de la carte à puce (2b) dudit système d'abonné appelé par la carte à puce (2a) dudit système appelant; et - communication entre la carte à puce (2b) du terminal (1b) dudit système appelé et ce terminal, au travers dudit "proxy" (27b) associé à cette carte à puce (2b). 11. Procédé selon la revendication 10, caractérisé en ce que ledit contrôle de caractéristiques predéterminées des échanges desdites données multimédias comprend une operation de chiffrement et/ou déchiffrement des données multimédias transitant dans ledit canal de données (CD) effectuée par lesdits "proxys" (27a, 27b). 12. Procédé selon la revendication 10, caractérisé en ce que ledit contrôle de caractéristiques predéterminées des échanges desdites données multimédias comprend une operation de tarification des données multimédias transitant dans ledit canal de données (CD) effectuée par lesdits "proxys" (27a, 27b). 13. Procédé selon la revendication 1, caractérisé en ce que lesdites données multimédias sont des données téléphoniques. 14. procédé selon la revendication 1, caractérisé en ce que lesdites données multimédias sont des données visiophoniques. 15. Procédé selon revendication 5, caractérisé en ce qu'il comprend en outre une phase d'enregistrement desdits abonnés dans au moins un serveur d'annuaire (SA;), à l'aide d'un protocole d'enregistrement déterminé (900a) et de donnees dites de profil d'abonné (903a) décrivant lesdits abonnés, une phase de localisation dudit abonné appelé par interrogation d'au moins un desdits serveurs d'annuaire (SA;), à l'aide d'un protocole de localisation déterminé (901a), lesdits protocoles déterminés d'enregistrement et de localisation étant associés à des pièces de logiciel (AB, A,), au moins l'une desdites pièces de logiciel est stockee dans au moins la carte à puce (2a) dudit premier système d'abonné, en que ladite carte à puce (2a) comprend au moins une deuxième entité logicielle (ATB, AT,), apte à interpreter une suite d'instructions et à la traduire en une suite d'ordres, de manière ' coopérer avec ladite seconde pièce de logiciel spécifique (23a) pour que ladite carte à puce offre une fonctionnalité d'interface passerelle dite "CGI", la dite carte à puce comprenant au moins une desdites suites d'instructions associée à au moins une pièce de logiciel propriétaire ; et en ce 'il comprend au moins les étapes suivantes 1l ouverture d'une première séquence d'échanges de données entre au moins ledit terminal (1) et ladite carte à puce (2a), pour la transmission d'une requête pour que ledit navigateur "WEB" (10) récupère des données permettant de sélectionner et d'activer une desdites pièces de logiciel (Ae, A,), en vue de la sélection d'un desdits serveurs d'annuaire (SA;) ; 21 ouverture d'une deuxième séquence d'échanges de données entre ladite carte à puce (2a) et ledit terminal (1) pour lui transmettre lesdites données 2I ouverture d'une troisième séquence d'échanges de données entre ledit terminal (1) et ladite carte à puce (2a) pour transmettre des données de sélection et des paramètres optionnels, lesdites données et lesdits paramètres optionnels comportant une référence à une desdites suites d'instructions associées à ladite pièce de logiciel propriétaire ; 4l interprétation de cette dite suite d'instructions, par mise en oeuvre de ladite fonctionnalité "CGI" et exécution de ladite pièce de logiciel propriétaire (AB, A,) ; et 5l en résultat de ladite exécution, ouverture d'une quatrième séquence d'échanges de données entre ladite carte à puce (2a) et un desdits serveurs d'annuaire (SA;), sélectionné lesdites données de sélection, de manière à transmettre une requête pour la réalisation d'une opération déterminée d'enregistrement ou de localisation. 16. Procédé selon la revendication 13, caractérisé en ce que ladite suite d'instructions à interpréter associée à chacune desdites pièces de logiciel propriétaire est constituée par un script et en ce que ladite deuxième entité logicielle est constituée par un module logiciel agent intelligent traducteur de script (ATe, AT,) fournissant des ordres compréhensibles par lesdites pièces de logiciel (Ae, A,),. 17. Procédé selon la revendication 15, caractérise en ce que ladite étape 1l comprend l'émission d'une requête de type dit "HTTP" selon un protocole de type Internet par adressage d'une page déterminée (P,, P2) en langage "HTML" contenant lesdites données de sélection des paramètres optionnels, ladite adresse étant une adresse de type "URL" de rebouclage sur ladite carte à puce (2a). 8. Procédé selon la revendication 17, caractérisé en ce que ladite étape 21 comprend l'envoi par ladite carte à puce (2a) d'un formulaire en langage "HTML" (P,, P2) et en ce que ledit formulaire comprend au moins une adresse de type dit "URL" de rebouclage sur ladite carte ' puce (2a) et un chemin menant à un répertoire déterminé contenant ledit script associé à l'une desdites pièces de logiciel propriétaire (Ae, A,), à lui transmettre lesdits paramètres optionnels et à occasionner son exécution après ladite interprétation. 9. Procédé selon la revendication 18, caractérise en ce que ladite étape 31 comprend l'envoi d'une requête de type dit "HTTP" à ladite adresse "URL" désignant ledit répertoire contenant ledit script associé à ladite pièce de logiciel propriétaire (AB, A,), ladite requête comprenant lesdites données de sélection et lesdits paramètres optionnels. Procédé selon la revendication 15, caractérisé en ce qu'une pièce logiciel dite d'un premier type (AB) est associée au dit protocole permettant l'enregistrement d'un des dits abonnés (Aa, Ab) sur un serveur d'annuaire determiné (SA;), en ce que lesdits paramètres optionnels sont constitués des données définissant un profil dit d'abonné, comprenant au moins des données dites d'identification dudit abonné à enregistrer (Aa, Ab), et en ce ladite requête "HTTP" de ladite étape 3J comprend premières données indiquant que l'opération demandée est ledit enregistrement et des deuxièmes données permettant d'élaborer, par ladite pièce de logiciel de premier type (AB), une adresse de type "U caractéristique dudit serveur d'annuaire déterminé (SA;), et en ce que données associées au dit profil d'abonné sont transmises, pendant ladite étape 4l, a ce serveur d'annuaire (SA;), de manière à réaliser ledit enregistrement dudit abonné (Aa, Ab), ledit enregistrement comprenant détermination d'une adresse de type IF par association de ladite adresse serveur d'annuaire (SA;) et desdites données d'identification de cet abonne (Aa, Ab). 21. Procédé selon la revendication 20, caractérisé en ce que ledit profil d'abonnée est stocké dans ladite carte à puce (2a). 22. Procédé selon la revendication 21, caractérisé en ce que plusieurs profils d'abonnés sont stockés dans la dite carte à puce (2a) et en ce que ladite requête "HTTP" de ladite étape 31 comprend des données permettant de sélectionner un desdits profils d'abonné. 23. Procédé selon la revendication 20, caractérisé en ce que ledit profil d'abonné est saisi par un opérateur sur des moyens d'entrée de données (6a) et transmis à ladite carte à puce (2a) comme paramètres pendant ladite étape 31. 24. Procédé selon la revendication 20, caractérisé en ce que plusieurs pièces distinctes de logiciel propriétaire d'un premier type (Ae) sont stockées dans ladite carte à puce (2a), associée chacune à un protocole d'enregistrement déterminé, de manière à permettre ledit enregistrement d'abonné (Aa, Ab) sur plusieurs serveurs d'annuaire de caractéristiques déterminées (SA,-SA"). 25. Procédé selon la revendication 15, caractérisé en ce qu'une pièce de logiciel dite d'un second type (A,) est associée au dit protocole permettant la localisation d'un abonné (Ab) dit appelé sur ledit reseau de type Internet (RI), ledit abonné appelé (Ab) étant enregistré sur un serveur d'annuaire déterminé (SA;), en ce que ce dit enregistrement comprend au moins des données dites d'identification dudit abonné appelé, en ce que ladite requête "HTTP" de ladite étape 3/ comprend des premieres données indiquant que l'opération demandée est ladite localisation, deuxièmes données identifiant ledit abonné appelé (Ab) à localiser et troisièmes données permettant d'élaborer, par ladite pièce de logiciel propriétaire de second type (A,), une adresse de type "URL" caractéristique dudit serveur d'annuaire déterminé (SA;), et en ce que des données identifiant ledit abonné appelé sont transmises, pendant ladite étape 4/ à ce serveur d'annuaire (SA,), de manière à réaliser ladite phase de localisation dudit abonne appelé, par la recherche d'une adresse de type "1P", en associant lesdites données d'identification de ce abonné appelé, reçues par ledit serveur d'annuaire (SA;), à des données d'enregistrement stockées dans celui-ci, et la retransmission de ladite adresse de type "1P" à ladite carte a puce (2a), de manière à permettre ladite localisation. 26. Procédé selon la revendication 25, caractérisé en ce que plusieurs pièces distinctes de logiciel propriétaire d'un second type (A,) sont stockées dans ladite carte à puce (2a), associé chacun à un protocole de localisation déterminé (PLy), de manière à permettre chacune ladite localisation d'un desdits abonnés appelés (Ab) sur ledit réseau de type Internet (RI), par sélection, parmi plusieurs (SA,-SA"), d'un serveur d'annuaire (SA,) de caractéristiques déterminées. 27. Carte à puce destinée à coopérer avec un terminal muni d'un lecteur de carte à puce, de manière à former un premier système d'abonné pour la gestion transmissions de données multimédias via un réseau de type Internet entre ledit premier système d'abonné et un second système d'abonne, ladite gestion comprenant au moins une phase d'échange de donnees dites de signalisation, via un canal dit de signalisation, à l'aide protocole de signalisation déterminé, et une phase d'échange desdites données multimédias, via un canal dit de données, à l'aide protocole de communication déterminé, caractérisé en ce ladite carte à puce (2a) comporte une pièce de logiciel (23a), formant couche protocolaire de communication spécifique, comprenant outre au moins une première entité logicielle autonome (S,), type dit client, et une deuxième entité logicielle autonome (S2), type serveur, lesdites entités (S2, S2) coopérant de manière à ce ladite carte à puce (2a) offre la fonctionnalité d'un client/serveur type "WEB" et à permettre l'établissement des échanges de données entre le terminal (la) dudit premier système d'abonné et ledit second système d'abonné (1'b) via ledit réseau de type Internet (RI) ; en ce ladite carte à puce (2a) comprend en outre une pièce logiciel applicative de caractéristiques fonctionnelles déterminées, dite filtre (28), recevant et/ou émettant des unités de données de protocole vers lesdites et/ou à partir desdites première et deuxième entités logicielles autonomes (S2, S,), de types respectifs client et serveur, comprises dans ladite pièce de logiciel spécifique (23a) ; ladite pièce applicative étant réalisée sous le contrôle de ladite entité logicielle autonome type serveur (S,) ; et en ce que ledit filtre (28) coopère avec lesdites entités logicielles autonomes (S2, S,) de ladite seconde pièce logiciel spécifique (23a) pour permettre l'ouverture de session avec lesdites entités logicielles autonomes (T2, Ti) de ladite première piece de logiciel spécifique pour former une fonction dite de "proxy " (27a) et contrôler des caractéristiques prédéterminées des échanges de données transitant entre ledit premier système d'abonné (1a, et ledit second système d'abonné (1'b), via au moins l'un desdits canaux de signalisation (CS) et/ou de données (CD), pendant lesdites phases d'échanges de données de signalisation et/ou données multimédias. 28. Carte à puce selon la revendication 27, caracterisé en ce que, ladite gestion de transmissions de données multimédias comprenant en outre une phase d'enregistrement desdits abonnés dans au moins un serveur d'annuaire (SA;), à l'aide d'un protocole d'enregistrement déterminé (900a) et de données dites de profil d'abonné (903a) décrivant lesdits abonnés, une phase de localisation dudit abonné appelé par interrogation d'au moins un desdits serveurs d'annuaire (SA;), à l'aide d'un protocole de localisation déterminé (901a), ladite carte à puce (2a) stocke au moins une pièce de logiciel A,) associée aux dits protocoles déterminés d'enregistrement et de localisation, et en ce que ladite carte à puce (2a) comprend au moins une deuxième entité logicielle (ATe, ATr) coopérant avec ladite pièce de logiciel spécifique (23a) pour que ladite carte à puce (2a) offre fonctionnalité d'interface passerelle dite "CGI",.de manière à activer lesdites pièces de logiciel A,) associées aux dits protocoles d'enregistrement ou de localisation. 29. Carte à puce selon la revendication 28, caracterisé en ce que ladite carte à puce (2a) stocke en outre au moins l'un desdits profils d'abonnés.