FR 2871009 A1 20051202 FR 0405752 A 20040527 L'invention concerne un procédé de traitement d'un message d'origine contenant au moins un objet multimédia, ledit message d'origine étant généré par un terminal de télécommunication expéditeur pour être envoyé à un terminal de télécommunication récepteur par un réseau de communication, ledit terminal récepteur étant identifié par au moins une donnée d'identification. L'invention concerne également un système de traitement d'un tel message ainsi qu'un terminal de télécommunication associé. Dans le domaine des télécommunications, les opérateurs proposent à leurs abonnés des services de messagerie multimédia. Un service multimédia est assuré par un serveur de messagerie multimédia qui permet l'envoi et la réception de messages multimédias depuis tout dispositif comportant une interface de communication avec ce serveur et un moyen de composition, de lecture, de modification, d'envoi et de réception des messages multimédias appelé client multimédia MMS. Il peut être déployé sur un réseau mobile, par exemple GSM, GPRS, UMTS, sur un réseau fixe filaire ou non, ou sur un réseau local filaire ou non. Un message multimédia est généralement composé d'éléments ou d'objets multimédias de type texte, image, audio ou vidéo. Cependant, des objets du type applicatif, logiciel exécutable, chemin d'accès pointant vers des fichiers stockés soit sur un serveur d'un réseau de communication, soit en local dans une mémoire d'un terminal de télécommunication pourraient également constituer des objets multimédias. Les terminaux de télécommunication de différentes marques ou de différents types ont des configurations et caractéristiques techniques différentes. En conséquence, certains objets multimédias contenus dans un message généré par un terminal d'un utilisateur expéditeur ne sont pas toujours visualisés, joués ou exécutés par un terminal récepteur en raison de la non _ compatibilité des unités de traitement et d'affichage de ces terminaux. Un but de l'invention est de pallier cet inconvénient. A cet effet, l'invention a pour objet un procédé du type précité caractérisé en ce qu'il comprend les étapes suivantes: - constitution d'une base de stockage contenant au moins une information de configuration du terminal récepteur; - recherche à partir de ladite ou desdites données d'identification du terminal récepteur, de ladite ou desdites informations de configuration du terminal récepteur dans ladite base de stockage de données du terminal expéditeur; - traitement du ou des objets multimédias contenus dans le message pour le ou les adapter aux caractéristiques des unités de traitement et d'affichage du terminal récepteur à partir de ladite ou desdites informations de configuration; et - génération d'un message de substitution comportant les objets multimédias traités. Ainsi, un message multimédia envoyé peut toujours être lu, joué, affiché et exécuté par le terminal qui le réceptionne, car les objets multimédias qu'il contient sont adaptés à la configuration du terminal récepteur auquel ils sont destinés par exemple, par changement de format des objets multimédias, réduction de la taille, etc... De plus, lorsque le terminal récepteur du message offre des services de qualité inférieure aux services du terminal expéditeur, il est particulièrement intéressant de réduire la taille des objets multimédias avant l'émission du message. Dans ce cas, le message contenant des objets multimédias adaptés aux unités de traitement et d'affichage du terminal récepteur, présente une taille réduite pour sa transmission du terminal expéditeur vers le serveur de messagerie multimédia puis, du serveur de messagerie multimédia vers le terminal récepteur, lorsque l'expéditeur et le récepteur sont abonnés auprès du même opérateur ou du terminal expéditeur vers un premier puis un second serveurs multimédias et du second serveur vers le terminal récepteur, lorsque l'expéditeur et le récepteur sont abonnés auprès d'opérateurs différents. L'invention permet ainsi de réduire la taille des objets multimédias contenus dans un message pour les adapter à la configuration du terminal récepteur de ce message. En conséquence, l'utilisation du réseau de télécommunication et les coûts liés à l'utilisation de celui-ci sont réduits pour l'opérateur. Suivant des modes particuliers de réalisation, le procédé comporte l'une ou plusieurs des caractéristiques suivantes: - l'étape de constitution comprend au moins une étape d'établissement d'un fichier de renseignements dans la base de stockage, ledit fichier de renseignements étant associé audit terminal récepteur, l'étape d'établissement comportant en outre les étapes suivantes: - enregistrement de chaque donnée d'identification du terminal récepteur dans ledit fichier de renseignements par le terminal expéditeur; - transmission dudit fichier de renseignements du terminal expéditeur vers un serveur répertoire d'un réseau de communication, le serveur répertoire comportant au moins un espace répertoire associé audit terminal expéditeur; - enregistrement du fichier de renseignements dans ledit espace répertoire, réalisé par le serveur répertoire; - mise à jour dudit fichier de renseignements enregistré dans l'espace répertoire; et mise à jour dudit fichier de renseignements enregistré dans la base de stockage du terminal expéditeur; - l'étape de mise à jour dudit fichier de renseignements de l'espace 20 répertoire comprend les étapes suivantes: recherche d'au moins une information de configuration du terminal récepteur à partir de la ou des données d'identification du terminal récepteur, réalisée par le serveur répertoire; et - enregistrement de chaque information de configuration recherchée dans le fichier de renseignements de l'espace répertoire associé au terminal expéditeur pour créer un fichier de renseignements enrichi, réalisé par le serveur répertoire; - l'étape de recherche des informations de configuration du terminal récepteur comprend une étape de transmission d'une requête, par le serveur répertoire, vers un serveur d'un réseau de commutation par paquets, ladite requête comportant au moins un chemin d'accès pointant vers les informations de configuration du terminal récepteur; ladite étape de transmission étant réalisée sur enregistrement ou modification dudit chemin d'accès; - l'étape de recherche des informations de configuration du terminal récepteur comprend une étape de transmission d'une requête de recherche dudit chemin d'accès par le serveur répertoire vers une base de données opérateur du réseau de communication, ladite requête comportant au moins une donnée d'identification du terminal récepteur; - l'étape de mise à jour du fichier de renseignements de la base de stockage comprend les étapes suivantes: - transmission dudit fichier de renseignements du serveur répertoire vers le terminal expéditeur; et - enregistrement dudit fichier de renseignements dans la base de stockage du terminal expéditeur, réalisée par le terminal expéditeur; - il comprend une étape d'actualisation périodique de ladite base de stockage réalisée à une périodicité prédéfinie, ladite étape comprenant: - ladite ou lesdites étapes de mise à jour du fichier de renseignements de l'espace répertoire; et - ladite ou lesdites étapes de mise à jour du fichier de renseignements de ladite base de stockage; - il comporte en outre une étape de prévisualisation du message de substitution. L'invention a également pour objet un terminal de télécommunication caractérisé en ce que ledit terminal comporte: - une base de stockage d'au moins un fichier de renseignements associé audit terminal récepteur, ledit fichier de renseignements comportant au moins une information de configuration du terminal récepteur et la ou les données d'identification du terminal récepteur, - des moyens de traitement du ou des objets multimédias propres à modifier le ou les objets multimédias à partir de la ou des informations de configuration pour le ou les adapter aux caractéristiques du ou des modules de traitement ou d'affichage du terminal récepteur. Enfin, l'invention a pour objet un système de traitement d'un message contenant au moins un objet multimédia caractérisé en ce que qu'il comporte un serveur répertoire comportant un module de pilotage apte à transmettre une requête de recherche d'au moins une information de configuration dudit terminal récepteur sur un réseau de commutation par paquets à partir d'une ou des données d'identification d'un terminal récepteur; ledit module de pilotage étant apte à transmettre au terminal expéditeur la ou les informations de configuration du terminal récepteur. Suivant des modes particuliers de réalisation, le système comporte l'une ou plusieurs des caractéristiques suivantes: - ledit serveur répertoire comporte des moyens de stockage de données comprenant au moins un espace répertoire associé audit terminal expéditeur et le module de pilotage est propre à enregistrer la ou les informations de configuration du terminal récepteur dans un fichier de renseignements de l'espace répertoire associé audit terminal expéditeur; - il comporte un terminal expéditeur selon la revendication 9; - le terminal expéditeur comprend un module client de synchronisation et le serveur répertoire est un serveur de synchronisation, le module client de synchronisation et le serveur de synchronisation sont aptes à échanger des données pour synchroniser entre elles les informations contenues d'une part dans les fichiers de renseignements enregistrés dans l'espace répertoire du serveur de synchronisation et d'autre part les fichiers de renseignements enregistrés dans la base de stockage du terminal expéditeur. L'invention sera mieux comprise à la lecture de la description qui va suivre donnée uniquement à titre d'exemple et faite en se référant aux dessins sur lesquels: - la figure 1 est une vue schématique d'un système de traitement d'un message multimédia selon l'invention; - la figure 2 est un diagramme illustrant le procédé de traitement d'un message selon l'invention; - la figure 3 est une vue schématique du système de traitement selon l'invention pendant une phase de constitution du module carnet d'adresses ou pendant une phase de mise à jour de celui-ci; - la figure 4 est un diagramme illustrant la phase de constitution et la phase de mise à jour du module carnet d'adresses d'un terminal selon l'invention; et - la figure 5 est un diagramme illustrant la phase de mise à jour du module carnet d'adresses d'un terminal lorsqu'un correspondant récepteur a changé de marque ou de type de terminal. Un exemple de structure d'un système de traitement d'un message multimédia selon l'invention est illustré schématiquement sur la figure 1. Dans cet exemple, le correspondant envoyant un message multimédia et le correspondant destinataire du message sont abonnés auprès du même opérateur. Ce système comporte un serveur de messagerie multimédia 2, un terminal 4 de télécommunication d'un correspondant expéditeur d'un message et un terminal de télécommunication 6 d'un correspondant récepteur du message envoyé par le terminal 4. Le serveur de messagerie multimédia 2 est connu en soi et ne sera pas décrit de manière détaillée. Il comprend notamment une interface 3 de communication avec les terminaux 4 et 6, par exemple de type MM1. Le terminal 4 comprend notamment un module client multimédia MMS 10, une unité éditeur SMIL 11, une interface homme-machine 14, des afficheurs/joueurs 18 et 20, une interface de communication 22 avec le serveur multimédia 2, un module carnet d'adresses 24, des moyens de comparaison 28, des moyens 30, 32, 34 de traitement d'objets multimédias et un module de synchronisation 35. Le module client multimédia MMS 10 est raccordé à l'interface hommemachine 14, à l'interface de communication 22, pour composer, présenter, envoyer et réceptionner des messages multimédias MMS. Le module client MMS 10 est raccordé à l'unité éditeur SMIL 11 pour générer un code de synchronisation et d'affichage des objets multimédias intégrés dans un message selon le langage SMIL (Synchronized Multimedia Integration Language). Une description du langage SMIL est disponible à l'adresse suivante: http://www.w3c.orq/TR/smil20/. L'interface homme-machine 14 comprend notamment un récepteur, un microphone, un clavier et un écran d'affichage d'images, par exemple à cristaux liquides. Les afficheurs/joueurs 18, 20 sont connectés à l'interface homme-machine 14. Ils sont propres à afficher, jouer, éditer des objets multimédias et à exécuter des logiciels exécutables ou des applicatifs. Ils comprennent par exemple un lecteur audio, un lecteur vidéo, un afficheur d'images, un logiciel de gestion d'application JAVA. Ils sont chacun compatibles avec certains formats de fichiers multimédias. Les formats des fichiers multimédias sont soit de type propriétaire par exemple flash, soit standards et normalisés par les groupes de normalisation 3 GPP, IETF, W3C et OMA au sein du groupe définissant les différents codecs utilisés pour les services mobiles. L'interface de communication 22 est raccordée au module client MMS 10 et au module de synchronisation 35 pour dialoguer avec le serveur multimédia 2 et avec un serveur répertoire, comme cela sera explicité dans la suite de la description. Le module carnet d'adresses 24 est connecté au module client MMS 10, à l'interface homme-machine 14, à des moyens de stockage de données 36 et aux moyens de comparaison 28. Les moyens 36 de stockage de données sont constitués par une mémoire non volatile de type ROM (Read Only Memory), une mémoire flash EEPROM (Electrically Erasable Programmable Read-Only Memory) ou équivalent. Ils sont implantés dans le terminal 4 ou sont constitués d'une mémoire externe comme par exemple une carte SIM\USIM connectée au carnet d'adresses 24 du terminal. Les moyens 36 de stockage comportent une base de données 38 qui contient une ou plusieurs informations 39 d'identification du terminal expéditeur 4 et des fiches de renseignements 40 contenant chacune des informations relatives à un correspondant destinataire de messages aussi appelé correspondant récepteur. Les fichiers de renseignements 40 peuvent avantageusement utiliser la technologie des cartes de visite électroniques appelée vCard. Cette technologie offre la possibilité d'avoir d'une part, des champs 42, 43 dédiés à des informations qui sont classiquement enregistrées dans des cartes de visite et d'autre part des champs libres 44. La technologie des cartes de visite vCard est décrite en version 3.0 dans le site web suivant: http:l/www.imc.orq/pdi/ et spécifiée dans les normes RFC 2425 et RFC 2436. Le champ 42 des fichiers de renseignements 40 comprend par exemple le nom et le prénom du correspondant récepteur, son adresse personnelle et professionnelle, son ou ses numéros de téléphone fixe personnel et/ou professionnel, son ou ses adresses courriels et éventuellement une photo de celui-ci. Le champ 43 des fichiers 40 comprend une donnée d'identification du terminal du correspondant récepteur constitué par exemple par son numéro 10 de téléphone mobile ou MSISDN. Selon l'invention, des informations de configuration du terminal récepteur 6 sont enregistrées dans les champs libres 44. Ces données comprennent notamment des informations concernant les capacités des modules d'affichage, d'édition et d'exécution implantés dans le terminal du correspondant récepteur 6, les unités de traitement disponibles comme par exemple le client MMS, le navigateur WAP, etc..., et les formats supportés GIF, JPEG, utilisés par le terminal du correspondant récepteur. Le carnet d'adresses 24 est propre à créer, modifier et gérer les cartes de visite vCard 40 associées aux terminaux des correspondants 20 récepteurs de messages. Le module de comparaison 28 est connecté au module client MMS 10. Il comporte un fichier descriptif 46 contenant les informations de configuration du terminal expéditeur 4. Ces informations sont de même type que les informations de configuration enregistrées dans les champs 44 des cartes de visite 40. H est adapté pour comparer les informations enregistrées dans le fichier 46 aux informations de configuration d'un terminal récepteur enregistrées dans une carte de visite vCard 40 du carnet d'adresses 24 et pour informer le module client MMS 10 des différences de configuration entre ces terminaux. Les moyens de traitement 30, 32, 34 sont connectés au module client MMS 10 pour recevoir les objets multimédias à traiter et les informations de configuration du terminal récepteur 6 correspondant à ces objets. Ils sont aptes à modifier les objets multimédias pour les adapter à la configuration des afficheurs/joueurs implantés dans le terminal récepteur 6 et à envoyer au module client MMS 10 des objets multimédias traités. Ils comprennent par exemple des moyens de traitement du son 30, des images 32 et de vidéo 34. Le moyen 30 de traitement du son est notamment apte à transformer un son stéréo en son mono, à comprimer un fichier son ou à changer le format de celui-ci, par exemple pour passer d'un format MP3 à un format MIDI (Musical Instrument Digital Interface). Le moyen 32 de traitement d'images est notamment adapté pour modifier la définition ou la résolution d'une image, pour transformer son échelle de gris, par exemple pour passer d'une image en couleurs à une image noir et blanc, pour comprimer une image, pour changer le format de celle-ci, par exemple d'un format GIF (Graphic Interchange Format) à un format PNG (Portable Network Graphics) ou à un format JPEG. Le moyen 34 de traitement vidéo est notamment apte à comprimer une vidéo ou à générer un GIF animé à partir de celle-ci. Le GIF animé comprend plusieurs images de la vidéo défilant à une fréquence prédéterminée. La constitution d'un GIF animé permet de réduire considérablement la taille d'un objet multimédia de type vidéo. Le module de synchronisation 35 est raccordé à l'interface 22, au module client MMS 10 ainsi qu'au carnet d'adresses 24. Il est apte à transmettre un fichier contenant les dernières modifications réalisées sur la base de données 38 du carnet d'adresses et à recevoir de façon similaire un fichier contenant des modifications réalisées par un autre terminal ou serveur et à enregistrer ces modifications sur la base de données 38 tel que cela sera décrit dans la suite de la description. Le module client MMS 10, l'éditeur SMIL 11, les afficheurs-joueurs 18 et 20, le carnet d'adresses 24, les moyens de comparaison 28, les moyens de traitement 30, 32, 34 et le module de synchronisation 35 peuvent être implémentés sous forme matérielle sur un micro-contrôleur ou sous forme logicielle sur un support de logiciel ou un composant programmé exécuté par un micro processeur à partir d'une mémoire non volatile. Le terminal récepteur 6 comprend notamment un module client MMS 45, une interface homme-machine 46, un module 47 de traitement, un module d'affichage 48 et une interface 49 de communication avec le serveur 2. Il ne sera pas décrit de manière détaillée. Le procédé de traitement d'un message multimédia objet de l'invention est illustré par un diagramme représenté sur la figure 2. Il comprend une étape préalable 50 de constitution d'une base de stockage 36, 38 comprenant des fichiers de renseignement 40 comme cela sera explicité dans la suite de la description en liaison avec la figure 4. Il comprend une étape 51 de composition d'un message d'origine contenant des objets multimédias de type audio, vidéo, texte ou image. Ce message est adressé à un terminal destinataire ou récepteur 6 identifié par un numéro d'identification tel que son numéro de téléphone ou son MSISDN. Pendant une étape 53, le module carnet d'adresses 24, commandé par le module client MMS 10, recherche dans la base de données 38, la carte de visite 40 associée au terminal récepteur 6 destinataire du message composé lors de l'étape 51. Ce fichier est identifiable à partir du MSISDN du terminal récepteur 6 contenu dans le champ 43 de la carte 40. Si le MSISDN du terminal récepteur 6 n'est pas enregistré dans une 20 carte 40 de la base de données ou si aucune information de configuration n'est présente dans la carte 40, les objets multimédias contenus dans le message ne sont pas traités et le message d'origine est transmis sans modification, au serveur multimédia 2 au cours d'une étape 72. Si, par contre, des informations de configuration associées au terminal récepteur 6 sont enregistrées dans une carte de visite 40, le carnet d'adresses 24 les recherche dans les champs 44 au cours d'une étape 55. Puis, pendant une étape 57, le carnet d'adresses 24 transmet ses informations aux moyens de comparaison 28. Au cours d'une étape 59, les moyens de comparaison 28 comparent les informations envoyées par le carnet d'adresses 24 aux informations de configuration du terminal 4 enregistrées dans le fichier descriptif 46. Lorsque ces informations sont identiques et que, par conséquent, le terminal expéditeur 4 est du même modèle et comprend les mêmes options que le terminal récepteur 6, le message multimédia d'origine est transmis sans modification au serveur multimédia 2 au cours d'une étape 72. Lorsque, par contre, certaines informations de configuration sont différentes, les moyens de comparaison 28 transmettent les informations de configuration pour lesquelles il y a discordance au module client MMS 10 au cours d'une étape 61. Par exemple, un utilisateur possédant le terminal expéditeur 4 a généré un message multimédia qu'il souhaite envoyer au terminal récepteur 6. Ce message est un message multimédia avec une image, du texte et du son. L'image est au format JPEG, elle est en couleurs et a une définition de 840 x 480 pixels. La taille de l'image est de 40 Ko. Le son est stéréo, dure 10 secondes, et sa taille est de 10 Ko. Le fichier texte a une taille de 0,5 Ko. Les champs 44 de la carte de visite 40 associée au terminal récepteur 6 indiquent que ce terminal possède un écran noir et blanc, d'une définition de 128 x 128 pixels et un écouteur mono et que ce terminal est apte à visualiser uniquement des fichiers au format GIF. Alors, les moyens de comparaison 28 comparent ses informations de configuration pendant l'étape 59 et transmettent les informations concernant l'objet image et l'objet son au module client MMS 10 pendant l'étape 61. Ces informations sont les suivantes: écran noir et blanc d'une définition 128x128 pixels, au format GIF et écouteur mono. Pendant une étape 63, le module client MMS 10 indique à l'utilisateur du terminal 4 par un message d'affichage que le terminal récepteur 6 a une configuration différente de la sienne et lui demande si les objets multimédias pour lesquels cette configuration est différente, doivent être traités pour être adaptés à la configuration du terminal récepteur 6. Si l'utilisateur du terminal expéditeur 4 ne souhaite pas réaliser cette adaptation, il l'indique au module client MMS 10 par l'intermédiaire de l'interface homme-machine 14. Le module client MMS 10 transmet alors le message d'origine sans traitement au serveur multimédia 2, via l'interface 22, au cours d'une étape 72. Si, par contre, l'utilisateur du terminal 4 souhaite réaliser cette adaptation, il l'indique au module client MMS 10, par l'intermédiaire de l'interface homme-machine 14. Alors, pendant une étape 65, le module client MMS 10 transmet aux moyens 30, 32, 34 de traitement, les objets multimédias et les informations de configuration associées à ces objets multimédias. Pendant une étape 67, les moyens 30, 32 et 34 modifient les objets multimédias en fonction des informations de configuration du terminal récepteur 6. Ainsi, dans l'exemple décrit précédemment, le moyen 30 de traitement du son transforme le fichier son stéréo en fichier son mono. Le moyen 32 de traitement d'images modifie le format, la résolution et la couleur de l'objet image envoyé par le module client MMS 10. Après traitement, les objets multimédias traités sont envoyés au module client MMS 10, pendant une étape 68. Au cours d'une étape 69, le module client MMS 10 et l'éditeur SMIL 11 génèrent un nouveau code de synchronisation et d'affichage des objets multimédias traités et l'insère, ainsi que les objets traités, dans un message multimédia de substitution. Au cours d'une étape 70, le module client MMS 10 transmet à l'utilisateur du terminal expéditeur 4 une information de confirmation de la fin du traitement du message d'origine ainsi qu'une demande de prévisualisation du message multimédia de substitution tel que traité, via l'interface homme-machine 14. Si l'utilisateur ne souhaite pas prévisualiser le message tel que traité avant son envoi, le module client MMS 10 transmet le message multimédia de substitution au serveur multimédia 2, via l'interface 22, au cours d'une étape 72. Si l'utilisateur souhaite prévisualiser le message de substitution, le module client MMS 10 transmet ce dernier à l'afficheur/joueur 18 ou 20. Pendant une étape 71, l'afficheur/joueur exécute ou affiche le message de substitution contenant les objets multimédias traités. Au cours d'une étape 72, le message multimédia de substitution est envoyé via, l'interface 22, au serveur multimédia 2. L'étape 63 de demande à l'utilisateur de confirmation du traitement des objets multimédias, ainsi que les étapes 70 et 71 de demande à l'utilisateur d'une prévisualisation du message de substitution, sont des étapes optionnelles. Le procédé de traitement selon l'invention peut être réalisé sans ces étapes. La figure 3 illustre le système de traitement d'un message multimédia pendant la constitution et la mise à jour de la base de données 38 du terminal expéditeur 4. Ce système comporte, outre les terminaux expéditeur 4 et récepteur 6, un serveur répertoire 73 et un serveur de registre 74 localisés sur un même réseau de communication 75, ainsi qu'un serveur 76 localisé sur un réseau 78 de commutation par paquets usuellement appelé réseau Internet. Les terminaux 4 et 6 sont identiques aux terminaux illustrés sur la figure 1. Ils ont déjà été décrits précédemment et ne seront plus décrits de 15 manière détaillée. Le serveur répertoire 73 est un serveur de synchronisation propre à mettre à jour des données avec tout type de terminal comportant un module client de synchronisation, tel que par exemple un ordinateur, un téléphone mobile ou fixe ou un assistant numérique personnel PDA et de mettre à jour tout type de données comme par exemple des courriels, des calendriers, des bases de données ou des carnets d'adresses. Il comprend une base de données 80, un module de pilotage 82 et deux interfaces de communication 84 et 85. La base de données 80 est divisée en plusieurs espaces répertoires 86. Chaque espace 86 est associé à un terminal expéditeur 4 abonné au service d'adaptation d'un message multimédia selon l'invention. Une copie de la base de données 38 du terminal expéditeur 4 est enregistrée dans l'espace répertoire 86 identifié par exemple par le MSISDN de ce terminal expéditeur 4. Le module de pilotage 82 est apte à transmettre, via l'interface 84, une requête, selon un protocole http, vers le serveur de registre 74 et à recevoir une réponse de celui-ci. Il est également apte à envoyer une requête, via l'interface 85, au serveur 76 localisé sur le réseau 78. Le serveur de registre 74 comprend une base de données opérateur 87 répertoriant, pour chaque MSISDN 88 d'un terminal récepteur 6, un chemin d'accès 89 sous forme d'une adresse web ou URL. Ce chemin d'accès 89 pointe vers un fichier contenant des informations de configuration du terminal de ce correspondant récepteur. Ce chemin d'accès 89 est usuellement appelé I'UAProf d'un terminal donné. La base de données 87 comporte de plus, une liste 90 récapitulant les MSISDN des terminaux expéditeurs 4 ayant interrogé le serveur 74 pour connaître l'UAProf d'un correspondant récepteur 6 et ayant par conséquent une carte de visite associée à ce correspondant récepteur dans leur carnet d'adresses 24. Le serveur 76 comporte des fichiers 92, 93 de type xml. Chaque fichier 92 comporte des informations de configuration d'un terminal d'une marque et d'un type donné. Avantageusement, il est possible d'utiliser des fichiers 92, 93 existants, accessibles à partir de leur chemin d'accès UAProf. De tels fichiers 92, 93 sont générés par les constructeurs de terminaux mobiles pour tous les terminaux existants sur le marché. Ils comprennent des informations de configuration décrites précédemment lors de la description du contenu des champs 44 des cartes de visite. Le procédé de traitement d'un message comporte une étape 50 de constitution de la base de données 38 du carnet d'adresses. Cette étape 50 comprend une étape d'établissement des fichiers de renseignement 40 contenus dans cette base de données et de mise à jour de celles-ci. Ces étapes sont illustrées sur la figure 4. Lors d'une étape 100, l'utilisateur du terminal expéditeur 4 enregistre des données d'identification d'un nouveau contact telles que son nom, son prénom et son adresse dans le champ 42, ainsi que le numéro de téléphone ou MSISDN du terminal 6 récepteur de ce nouveau contact dans le champ 43 d'une carte de visite 40, à l'aide de l'interface homme-machine 14. Simultanément ou alternativement, pendant une étape 102, l'utilisateur du terminal 4 modifie une ou plusieurs données d'une carte de visite 40. De telles modifications sont par exemple réalisées lorsqu'un correspondant change d'adresse, de numéro de téléphone ou de nom. Lorsqu'une carte de visite 40 a été créée ou modifiée, une mise à jour de l'espace répertoire 86 du serveur répertoire est effectuée par l'intermédiaire du module de synchronisation 35 et du serveur répertoire 73. Cette mise à jour peut être effectuée à une période prédéfinie ou être déclenchée par un évènement prédéfini tel que par exemple la mise en veille du terminal 4 ou la création ou la modification d'une carte de visite 40. Pendant une étape 104, le module de synchronisation 35 transmet au serveur répertoire 73 un fichier contenant la carte de visite 40 générée pendant l'étape 100 ou la carte de visite 40 modifiée pendant l'étape 102. Lors d'une étape 106, le serveur répertoire 73 enregistre la carte de visite 40 qu'il vient de réceptionner dans la base de données 80 et plus précisément dans l'espace répertoire 86 associé au terminal expéditeur 4 et identifié par le MISDN de celui-ci. La base de données 80 contient alors une réplique exacte du carnet d'adresses 24 du terminal expéditeur 4. Lors d'une étape 108, le serveur répertoire 73 détecte l'enregistrement effectué au cours de l'étape 106. Alors, le module de pilotage 82 transmet au serveur de registre 74 une requête, dans un protocole http, de demande du chemin d'accès UAProf vers le fichier 92 contenant des informations de configuration du terminal du nouveau contact enregistré dans la carte de visite 40 ou du contact dont la carte de visite 40 a été modifiée. Si la base de données opérateur 87 du serveur de registre ne comprend pas soit la donnée d'identification MSISDN du terminal du nouveau contact ou soit l'UAProf du terminal de ce contact, le serveur de registre 74 envoie cette information au module de pilotage 82 du serveur répertoire et le procédé de traitement d'un message s'arrête. Si, par contre, la base de données 87 comprend la donnée d'identification MSISDN du terminal récepteur du contact enregistré dans la carte de visite 40 et l'UAProf qui lui est associé, le serveur de registre 74 transmet l'UAProf au module de pilotage 82 au cours d'une étape 110. Au cours d'une étape 112, le serveur de registre 74 enregistre le MSISDN du terminal expéditeur 4 dans la liste 90. Cette liste constitue un historique de l'ensemble des terminaux expéditeurs ayant demandé I'UAProf associé à un MSISDN d'un terminal récepteur donné. L'utilisation de cette liste 90 sera ultérieurement explicitée en liaison avec la figure 5. Lorsqu'un utilisateur d'un terminal expéditeur efface une carte de visite 40 de son carnet d'adresses 24, l'étape 112 d'enregistrement du MSISDN du terminal expéditeur dans la liste 90 est remplacée par une étape d'effacement de celui-ci. Au cours d'une étape 114, le module de pilotage 82 transmet une requête de recherche sur le réseau 78, du fichier 92 stocké à l'UAProf envoyé par le serveur de registre 74 et contenant les informations de configuration du terminal récepteur du contact. Au cours d'une étape 116, le serveur 76 communique le fichier 92 au module de pilotage 82 du serveur répertoire 73, par l'interface 85. Ensuite, pendant une étape 118, le module de pilotage 82 enregistre les informations de configuration dans la carte de visite 40 de l'espace 15 répertoire 86 associé au terminal expéditeur 4. La carte de visite 40 est associée au terminal récepteur 6 du contact. Pendant une étape 120, le serveur répertoire 73 transmet la carte de visite 40 au terminal expéditeur 4. Au cours d'une étape 122, le module de synchronisation 35 du terminal 4 met à jour la carte de visite 40 enregistrée pendant l'étape 100 ou 102 dans le carnet d'adresses 24. La correspondance entre la carte de visite 40 réceptionnée et la carte de visite préalablement enregistrée dans le carnet d'adresses est réalisée à partir des MSISDN enregistrés dans le champ 43 de chaque carte. Ainsi se termine le procédé d'établissement ou de mise à jour du carnet d'adresses du terminal expéditeur 4 utilisé pour le procédé de traitement d'un message multimédia selon l'invention. La figure 5 illustre le procédé de mise à jour de la base de données 38 du carnet d'adresses 24 lorsque un contact a changé de type ou de marque 30 de terminal de télécommunication. Dans ce cas, au cours d'une étape 130, l'opérateur propriétaire du serveur de registre 74 modifie l'UAProf associé au MSISDN du contact. Pendant une étape 132, le serveur de registre 74 émet une requête auprès du serveur répertoire 73 afin de mettre à jour l'ensemble des espaces répertoires 86 identifiés par un MSISDN contenu dans la liste 90. Pour cela, il transmet au serveur 73 le nouvel UAProf ainsi que la liste 90 des MSISDN 88 des terminaux expéditeurs 4 ayant préalablement demandé cet UAProf. Au cours d'une étape 134, le module de pilotage 82 transmet alors au serveur 76 du réseau 78 une requête de recherche des informations de configuration correspondant au nouvel UAProf. Les nouvelles informations de configuration sont envoyées au 10 module de pilotage 82, au cours d'une étape 138 et sont enregistrées dans les cartes de visite 40 de l'ensemble des espaces répertoires 86 identifiés par les MSISDN 88 contenus dans la liste 90. Au cours d'une étape 140, le serveur répertoire 73 transmet les cartes de visite 40 à l'ensemble des terminaux expéditeurs 4 identifiés par leurs MSISDN 88 dans la liste 90 et contenant une carte de visite 40 pour ce contact ayant changé de terminal de télécommunication. Le module de synchronisation 35 de chacun de ces terminaux 4 réalise la mise à jour de leur base de données 38 au cours d'une étape 142. Selon un mode de réalisation alternatif du procédé de traitement d'un 20 message multimédia, les étapes 130 à 142 représentées sur la figure 5 et illustrant le mode de fonctionnement lors d'un changement de modèle d'un terminal d'un contact sont remplacées par les étapes suivantes. Le serveur répertoire 73 interroge à intervalles réguliers la base de données 87 du serveur de registre 74 afin de vérifier pour chaque contact des espaces répertoires 86 que la correspondance MSISDN-UAProf n'a pas été modifiée. Lorsqu'un UAProf a été modifié pour un contact donné, les étapes de mise à jour 134 à 142 des cartes de visite 40 du carnet d'adresses 24 du terminal ainsi que des espaces répertoires 86 du serveur répertoire 73 sont réalisées tel que décrit précédemment. Dans ce mode de réalisation alternatif, le serveur de registre 74 ne comprend pas de liste 90 listant les MSISDN des terminaux expéditeurs ayant demandé I'UAProf d'un contact donné. Le serveur répertoire 73 contient uniquement une base de données dans laquelle la correspondance entre les MSISDN des contacts et les UAProf des terminaux récepteurs 6 est enregistrée. Alternativement, le serveur répertoire 73 n'est pas un serveur de synchronisation et le terminal expéditeur 4 ne comporte pas de module 35 de 5 synchronisation. Dans ce cas, les bases de données 38 et 80 ne sont mises à jour que sur demande explicite de l'utilisateur du terminal expéditeur 4 ou lors de la création d'une carte de visite 40. Selon une variante de réalisation de l'invention non représentée, la base de données opérateur 87 est localisée dans le serveur répertoire 73. Selon une autre variante de réalisation de l'invention non représentée, le terminal récepteur 6 comporte de plus des moyens de stockage de données dans lesquels sont stockés un fichier descriptif de sa configuration et de ses caractéristiques techniques. Avant chaque émission d'un message multimédia, le module client MMS 10 du terminal expéditeur transmet une requête de demande d'information de configuration au terminal récepteur 6, via le serveur de messagerie multimédia 2. Sur réception de cette requête, le module client MMS 45 recherche le fichier descriptif dans ses moyens de stockage et l'envoie au terminal 20 expéditeur 4, via le serveur de messagerie multimédia 2. Sur réception de ce fichier descriptif, le terminal expéditeur 4 enregistre ce fichier et le MSISDN du terminal récepteur 6 dans une carte de visite 40 associée au terminal récepteur et comprise dans la base de données 38 du module carnet d'adresses 24. Le carnet d'adresses 24 du terminal expéditeur est ainsi enrichi et mis à jour avant chaque envoi d'un message multimédia à un terminal récepteur donné. REVENDICATIONS 1. Procédé de traitement d'un message d'origine contenant au moins un objet multimédia, ledit message d'origine étant généré par un terminal de télécommunication expéditeur (4) pour être envoyé à un terminal de télécommunication récepteur (6) par un réseau de communication, ledit terminal récepteur étant identifié par au moins une donnée d'identification, caractérisé en ce qu'il comprend les étapes suivantes: constitution (50) d'une base de stockage de données (36, 38) contenant au moins une information de configuration du terminal récepteur; - recherche (55) à partir de ladite ou desdites données d'identification du terminal récepteur (6), de ladite ou desdites informations de configuration du terminal récepteur dans ladite base de stockage de données (36, 38) du terminal expéditeur (4) ; - traitement (67) du ou des objets multimédias contenus dans le message pour le ou les adapter aux caractéristiques des unités de traitement et d'affichage du terminal récepteur à partir de ladite ou desdites informations de configuration; et - génération (69) d'un message de substitution comportant les objets multimédias traités. 2. Procédé de traitement d'un message selon la revendication 1, caractérisé en ce que l'étape de constitution (50) comprend au moins une étape d'établissement d'un fichier de renseignements (40) dans la base de stockage (36, 38), ledit fichier de renseignements étant associé audit terminal récepteur (6), l'étape d'établissement comportant en outre les étapes suivantes: - enregistrement (100, 102) de chaque donnée d'identification du terminal récepteur (6) dans ledit fichier de renseignements (40) par le terminal expéditeur (4) ; - transmission (104) dudit fichier de renseignements (40) du terminal expéditeur (4) vers un serveur répertoire (73) d'un réseau de communication (75), le serveur répertoire (73) comportant au moins un espace répertoire (86) associé audit terminal expéditeur (4) ; - enregistrement (106) du fichier de renseignements (40) dans ledit espace répertoire (86), réalisé par le serveur répertoire; - mise à jour (108, 114, 118, 134, 138) dudit fichier de renseignements (40) enregistré dans l'espace répertoire (86) ; et mise à jour (120, 122, 140, 142) dudit fichier de renseignements (40) enregistré dans la base de stockage (36, 38) du terminal expéditeur (4). 3. Procédé de traitement d'un message selon la revendication 2, caractérisé en ce que l'étape de mise à jour (108, 114, 118, 134, 138) dudit fichier de renseignements (40) de l'espace répertoire (86) comprend les étapes suivantes: - recherche (108, 114, 134) d'au moins une information de configuration du terminal récepteur à partir de la ou des données d'identification du terminal récepteur (6), réalisée par le serveur répertoire (73) ; et - enregistrement (118, 138) de chaque information de configuration recherchée dans le fichier de renseignements (40) de l'espace répertoire (86) associé au terminal expéditeur (4) pour créer un fichier de renseignements (40) enrichi, réalisé par le serveur répertoire (73). 4. Procédé de traitement d'un message selon la revendication 3, caractérisé en ce que l'étape de recherche (108, 114, 134) des informations de configuration du terminal récepteur comprend une étape de transmission (114, 134) d'une requête, par le serveur répertoire (73), vers un serveur (76) d'un réseau de commutation par paquets (78), ladite requête comportant au moins un chemin d'accès pointant vers les informations de configuration du terminal récepteur; ladite étape de transmission (114, 134) étant réalisée sur enregistrement ou modification dudit chemin d'accès. 5. Procédé de traitement d'un message selon la revendication 4, caractérisé en ce que l'étape de recherche (108, 114, 134) des informations de configuration du terminal récepteur (6) comprend une étape de transmission (108) d'une requête de recherche dudit chemin d'accès par le serveur répertoire (73) vers une base de données opérateur (87) du réseau de communication (75), ladite requête comportant au moins une donnée d'identification du terminal récepteur (6). 6. Procédé de traitement d'un message selon l'une quelconque des revendications 2 à 5, caractérisé en ce que l'étape de mise à jour (120, 122, 140, 142) du fichier de renseignements (40) de la base de stockage (36, 38) comprend les étapes suivantes: - transmission (120, 140) dudit fichier de renseignements (40) du serveur répertoire (73) vers le terminal expéditeur (4) ; et - enregistrement (122, 142) dudit fichier de renseignements (40) dans la base de stockage (36, 38) du terminal expéditeur (4), réalisée par le terminal expéditeur (4). 7. Procédé de traitement d'un message selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comprend une étape d'actualisation périodique de ladite base de stockage (36, 38) réalisée à une périodicité prédéfinie, ladite étape comprenant: - ladite ou lesdites étapes de mise à jour (108, 114, 118, 134, 138) du fichier de renseignements (40) de l'espace répertoire (86) selon l'une quelconque des revendications 3 à 5, et - ladite ou lesdites étapes de mise à jour (120, 122, 140, 142) du fichier de renseignements (40) de ladite base de stockage (36, 38) selon la revendication 6. 8. Procédé de traitement d'un message selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'il comporte en outre une étape de prévisualisation du message de substitution. 9. Terminal de télécommunication expéditeur (4) apte à générer un message contenant au moins un objet multimédia pour être envoyé à un terminal de télécommunication récepteur (6) comportant au moins un module de traitement (47) ou d'affichage (48) et identifié par au moins une donnée d'identification, caractérisé en ce que ledit terminal expéditeur (4) comporte: - une base de stockage (36, 38) d'au moins un fichier de renseignements (40) associé audit terminal récepteur (6), ledit fichier de renseignements (40) comportant au moins une information de configuration du terminal récepteur et la ou les données d'identification du terminal récepteur, - des moyens de traitement (30, 32, 34) du ou des objets multimédias propres à modifier le ou les objets multimédias à partir de la ou des informations de configuration pour le ou les adapter aux caractéristiques du ou des modules de traitement (47) ou d'affichage (48) du terminal récepteur. 10. Système de traitement d'un message contenant au moins un objet multimédia, ledit message étant généré par un terminal de télécommunication expéditeur (4) pour être envoyé par l'intermédiaire d'un réseau de communication (75), à un terminal de télécommunication récepteur (6) identifié par au moins une donnée d'identification, caractérisé en ce qu'il comporte un serveur répertoire (73) comportant un module de pilotage (82) apte à transmettre une requête de recherche d'au moins une information de configuration dudit terminal récepteur (6) sur un réseau de commutation par paquets (78) à partir d'une ou des données d'identification d'un terminal récepteur (6) ; ledit module de pilotage étant apte à transmettre au terminal expéditeur (4) la ou les informations de configuration du terminal récepteur. 11. Système de traitement d'un message selon la revendication 10, caractérisé en ce que ledit serveur répertoire (73) comporte des moyens de stockage de données (80) comprenant au moins un espace répertoire (86) associé audit terminal expéditeur (4) et en ce que le module de pilotage (82) est propre à enregistrer la ou les informations de configuration du terminal récepteur (6) dans un fichier de renseignements (40) de l'espace répertoire (86) associé audit terminal expéditeur (4). 12. Système de traitement d'un message selon l'une quelconque des revendications 10 ou 11, caractérisé en ce qu'il comporte un terminal expéditeur (4) selon la revendication 9. 13. Système de traitement d'un message selon la revendication 12, caractérisé en ce que le terminal expéditeur (4) comprend un module client de synchronisation (35) et en ce que le serveur répertoire (73) est un serveur de synchronisation, en ce que le module client de synchronisation (35) et le serveur de synchronisation (73) sont aptes à échanger des données pour synchroniser entre elles les informations contenues d'une part dans les fichiers de renseignements (40) enregistrés dans l'espace répertoire (86) du serveur de synchronisation (73) et d'autre part les fichiers de renseignements (40) enregistrés dans la base de stockage (36, 38) du terminal expéditeur (4).