Brevet FR3004048A1 — publié le 20141003

Arrière-plan de l'invention L'invention se rapporte au domaine général des télécommunications. Elle concerne plus particulièrement l'accès à un message déposé (ou plus généralement stocké) sur un serveur de messagerie associé à une première identité de terminal, par une deuxième identité de terminal lors d'une communication, cet accès ayant lieu une fois la communication achevée et étant destiné à permettre l'exécution d'un traitement sur le message, comme par exemple la lecture, la suppression ou la modification de ce message. Par identité de terminal, on entend ici tout type de paramètre permettant d'identifier un terminal et de le joindre, autrement dit de lui envoyer des messages au sens général du terme via un ou plusieurs réseaux de télécommunications. Il peut s'agir ainsi par exemple d'un numéro de téléphone, d'une adresse mél, d'une SIP-URI (Session Initiation Protocol - Uniform Request Identifier), etc. Il convient de noter que cette identité peut être partagée par plusieurs terminaux. De façon connue, la plupart des services de téléphonie sur réseau fixe et sur réseau mobile (qu'ils s'appuient sur des technologies à commutation de circuits ou de voix sur IP (Internet Protocol)) sont délivrés aujourd'hui avec un service de messagerie vocale. Ainsi, lorsqu'un appel émis par un terminal appelant ne peut déboucher chez un terminal appelé pour quelle que raison que ce soit (terminal occupé, non réponse, renvoi inconditionnel vers sa messagerie, terminal hors couverture, etc.), cet appel est routé par le réseau du terminal appelé vers le système de messagerie vocale du terminal appelé. L'utilisateur du terminal appelant peut alors déposer sur ce système de messagerie un message vocal à destination du terminal appelé, suite par exemple à la diffusion d'une annonce vocale d'accueil par le système de messagerie. Une fois la communication terminée (autrement dit, suite au raccrochage du terminal appelant), l'utilisateur du terminal appelant n'a aucun moyen pour réécouter, supprimer le message déposé ou bien le modifier. Une telle opportunité n'est en effet offerte que lors de la phase de dépôt du message sur le système de messagerie, mais pas après le raccrochage du terminal, autrement dit à l'issue de la communication. Ainsi, si l'utilisateur du terminal appelant se trompe dans le numéro composé et qu'il dépose à tort un message vocal sur le système de messagerie vocale du terminal appelé de façon erronée, il ne dispose d'aucun moyen pour corriger cette erreur (par exemple, pour supprimer le message avant qu'il ne soit lu par son destinataire). De même, si l'utilisateur du terminal appelant enregistre un message non approprié sur le système de messagerie vocale, ou qu'il souhaite compléter le message enregistré, il ne peut plus revenir sur ce message et n'a d'autre possibilité que de réenregistrer un nouveau message. Il convient de noter que ce problème ne se limite pas à un système de messagerie vocale mais peut concerner tout type de messagerie, comme par exemple un système de messagerie vidéo, ou multimode, ou électronique (de type asynchrone comme les méls ou de type synchrone comme les messageries instantanées, et pour lesquels les messages sont susceptibles d'être stockés sur un serveur avant d'être délivrés à leur destinataire en cas de non réponse notamment de celui-ci), ou encore d'un système de messagerie venant en support de communications de type SMS (Short Message Service) ou MMS (Multimedia Message Service) via notamment une application dite « store-and-forward », chargée de stocker les messages SMS ou MMS avant de les délivrer à leur destinataire en cas d'indisponibilité de celui-ci. Le document US 6 999 566 propose un procédé et un système permettant à un utilisateur appelant ayant déposé un message sur une messagerie vocale à l'attention d'un utilisateur destinataire ou appelé, de supprimer ce message avant qu'il ne soit écouté par ce dernier. Ce procédé s'appuie sur trois entités, à savoir sur : - un serveur auquel l'appelant transmet sa requête de suppression du message, - le système de messagerie de l'appelant, et - le système de messagerie de l'appelé. Plus précisément, sur réception d'une requête de suppression du message en provenance du terminal de l'appelant, le serveur interroge le système de messagerie de l'appelant pour connaître l'état de ce message. Si celui-ci n'a pas encore été écouté par son destinataire (i.e. par l'appelé), le serveur transmet au système de messagerie de l'appelant la requête de suppression du message. Cette requête de suppression du message est alors transmise par le système de messagerie de l'appelant vers le système de messagerie de l'appelé qui procède à la suppression du message. Le procédé proposé dans le document US 6 999 566 nécessite donc la mise en place d'un lien entre les systèmes de messagerie de l'appelant et de l'appelé, ce qui peut s'avérer complexe d'un point de vue opérationnel notamment en termes de sécurité, lorsque les systèmes de messagerie sont gérés par des opérateurs différents. Par ailleurs, les possibilités de traitement offertes sur le message déposé sur le système de messagerie de l'appelant sont relativement limitées, puisque seule une suppression du message est permise lorsque celui-ci n'a pas encore été écouté par son destinataire. Objet et résumé de l'invention L'invention permet notamment de remédier aux inconvénients précités en proposant un procédé de notification, par un système de messagerie associé à une première identité de terminal, comprenant : sur détection d'un message destiné à la première identité stocké sur un serveur du système de messagerie, ce message ayant été émis par une deuxième identité de terminal lors d'une communication, une étape d'envoi, à l'issue de cette communication, d'une notification à la deuxième identité comprenant un lien d'accès à ce message ; sur réception d'une requête d'accès à ce message émise par un terminal à partir de ce lien d'accès, une étape de vérification qu'au moins un traitement sur ce message, sélectionné par ce terminal, est autorisé ; le cas échéant, sur réception d'une commande en provenance de ce terminal identifiant un dit traitement autorisé, une étape d'exécution de ce traitement sur le message stocké sur le serveur. Corrélativement, l'invention vise également un système de messagerie associé à une première identité de terminal, comprenant : un serveur ; un module de détection, apte à détecter un message destiné à la première identité et stocké sur le serveur, ce message ayant été émis par une deuxième identité de terminal lors d'une communication ; un module d'envoi, activé sur détection par le module de détection du message stocké sur le serveur, et apte à envoyer à l'issue de la communication durant laquelle le message a été émis, une notification à la deuxième identité comprenant un lien d'accès au message stocké sur le serveur ; un module de réception d'une requête d'accès au message stocké sur le serveur émise à partir de ce lien d'accès par un terminal ; un module de vérification, activé sur réception de la requête d'accès par le module de réception, et apte à vérifier qu'au moins un traitement sur le message stocké sur le serveur, sélectionné par ce terminal, est autorisé ; un module de réception d'une commande en provenance du terminal identifiant un dit traitement autorisé ; et un module d'exécution, apte à exécuter sur le message stocké sur le serveur le traitement identifié dans la commande. L'invention offre ainsi une solution permettant à un utilisateur appelant (identifié par une deuxième identité de terminal au sens de l'invention) ayant déposé un message sur un serveur d'un système de messagerie d'un utilisateur appelé (identifié par une première identité au sens de l'invention), d'agir a posteriori sur ce message (ex. de le supprimer ou de le modifier (et notamment de modifier son contenu ou son enveloppe)), c'est-à-dire après que la communication via laquelle le message a été déposé a été achevée. Cette solution s'appuie avantageusement sur la notification par le système de messagerie de l'appelé, à l'utilisateur appelant via son terminal, d'un lien permettant d'accéder au message ainsi déposé. Grâce à ce lien, l'utilisateur appelant peut, via un terminal, accéder au message et solliciter auprès du système de messagerie de l'utilisateur appelé un traitement sur ce message. Le lien vers le message stocké sur le serveur du système de messagerie est envoyé à l'identité de terminal qui a déposé ce message (deuxième identité au sens de l'invention), ce qui permet de simplifier les interactions entre le système de messagerie de l'appelé et l'appelant. Cette identité peut en effet être aisément extraite par le système de messagerie de la communication à l'origine du dépôt du message : il peut ainsi s'agir notamment d'une identité attribuée au terminal de l'utilisateur appelant par son réseau de télécommunications ou utilisée pour communiquer sur ce réseau et présente dans la signalisation du message (typiquement son numéro de téléphone, son adresse SIP ou encore son adresse email, etc.). Si une telle identité attribuée par le réseau n'est pas disponible (par exemple parce que l'appelant a décidé de masquer cette identité), le système de messagerie peut considérer comme deuxième identité une identité telle un jeton ou token en anglais fournie le cas échéant par une plateforme de notification à distance (par exemple par un serveur APNS (Apple Platform Notification Server) tel que proposé par la société Apple ou un serveur C2M (Cloud Ta Messaging) tel que défini par la société Google), au terminal de l'appelant utilisé pour émettre le message stocké sur le serveur. De façon connue en soi, ce jeton ou token est inséré par la plateforme de notification à distance dans la signalisation d'appel permettant la transmission du message. Comme mentionné précédemment, chaque identité au sens de l'invention peut être partagée par plusieurs terminaux, de sorte que l'invention s'applique aussi bien lorsque le message est déposé sur le serveur du système de messagerie puis modifié via un même terminal de l'utilisateur appelant que via deux terminaux distincts. En d'autres mots, le terminal à l'origine de la requête d'accès n'est pas nécessairement le même terminal que celui qui a reçu le lien d'accès du système de messagerie ni que celui via lequel l'utilisateur appelant a émis le message stocké sur le serveur à destination de la première identité. Il convient de noter qu'aucune limitation n'est attachée dans la présente description à l'utilisation des expressions « appelant » et « appelé ». Ces expressions sont utilisées à titre illustratif pour désigner l'origine et le destinataire du message respectivement, mais elles ne présagent en aucun cas du type de communications et/ou de messagerie auquel s'applique l'invention. L'invention peut en effet s'appliquer à tout type de messagerie, comme par exemple une messagerie audio et/ou vidéo, une messagerie électronique de type asynchrone (ex. méls) ou de type synchrone (ex. messagerie instantanée), une messagerie de type « store-and-forward » pour des communications de type SMS ou MMS, etc. Il en est de même pour l'expression « message déposé sur un serveur » qui désigne de façon générale au sens de l'invention le fait que le message est stocké sur le serveur de messagerie après son émission par l'identité « appelante » à destination de l'identité « appelée ». Grâce à l'invention, l'utilisateur appelant peut non seulement supprimer un message stocké sur le serveur du système de messagerie de l'utilisateur appelé à l'issue de la communication via laquelle ce message a été émis (c'est-à-dire une fois cette communication terminée), mais également requérir aisément d'autres traitements sur ce message, tels que par exemple, la lecture ou la modification d'une ou de plusieurs caractéristiques de ce message. Au sens de l'invention, une modification d'une caractéristique d'un message désigne aussi bien une modification de son contenu qu'une modification de paramètre(s) associé(s) à ce message et contenu(s) dans son enveloppe. En outre, l'invention permet à l'utilisateur appelant d'accéder et de modifier un message y compris après que l'utilisateur appelé a accédé à ce message, dès lors que ce message est toujours stocké par le système de messagerie, et moyennant bien entendu la mise en oeuvre de certaines précautions afin d'éviter toute ambiguïté ou confusion auprès de l'utilisateur appelé. Ainsi, dans un mode particulier de réalisation de l'invention, le procédé de notification comprend une étape de notification à la première identité du traitement exécuté sur le message stocké sur le serveur. Ce mode de réalisation de l'invention présente un intérêt privilégié lorsque le message stocké sur le serveur a déjà été transmis ou notifié à son destinataire (première identité), qu'il ait été lu ou non par celui-ci. C'est le cas notamment lorsque le terminal du destinataire est notifié, via par exemple un service de notification à distance tel que le service APN (Apple Push Notification) développé par la société Apple ou le service C2M (Cloud To Messaging) proposé par la société Google. Par ailleurs, la solution proposée par l'invention s'appuie avantageusement sur une vérification par le système de messagerie que le terminal à l'origine de la requête d'accès émise à partir du lien d'accès transmis par le système de messagerie est autorisé à requérir un traitement sur le message stocké sur le serveur, avant de mettre en oeuvre un tel traitement. Cette vérification peut être de différentes natures. Ainsi, elle peut porter notamment sur la deuxième identité à proprement parler, en contrôlant par exemple que le terminal utilise un lien d'accès communiqué à une identité qui est bien autorisée à accéder au message pour le lire, le modifier, le supprimer, ou effectuer tout autre type de traitement permis par le système de messagerie. En variante, l'étape de vérification peut comprendre une étape de détermination d'un état du message stocké sur le serveur, l'exécution du traitement étant conditionnée par cet état. Cette étape de vérification peut en particulier consister à vérifier simplement la présence du message sur le serveur du système de messagerie. En effet, le message peut, entre le moment où le lien d'accès a été notifié à la deuxième identité et le moment où le terminal commande un traitement sur ce message, avoir été effacé du serveur (car il a été délivré à la première identité, ou effacé par celle-ci, etc.), auquel cas aucun traitement n'est plus possible sur ce message. Bien entendu, d'autres types de vérification peuvent être envisagés. Ces diverses vérifications permettent de sécuriser et d'encadrer les modifications au sens général du terme (incluant les suppressions) pouvant être apportées aux messages stockées sur le serveur du système de messagerie. Dans un mode particulier de réalisation, le lien d'accès notifié à la deuxième identité est un lien web contenant un paramètre identifiant de manière unique le message stocké sur le serveur. Ce mode de réalisation est particulièrement simple à mettre en oeuvre et facile à utiliser par l'utilisateur appelant qui n'a qu'à cliquer, recopier ou sélectionner ce lien pour accéder au système de messagerie de l'utilisateur appelé. Par ailleurs, les nouvelles générations de terminaux disposent aujourd'hui quasiment toutes de moyens pour se connecter au réseau Internet. Le paramètre identifiant le message stocké sur le serveur peut avantageusement être chiffré de sorte à renforcer la sécurité de l'accès au message. Le lien d'accès peut en outre inclure la deuxième identité de terminal, également de façon chiffrée, afin de permettre au système de messagerie de vérifier que le terminal qui utilise le lien d'accès pour accéder au message est bien associé à la deuxième identité qui est à l'origine de ce message. Dans un mode particulier de réalisation, le procédé de notification comprend, suite à l'étape de vérification, une étape d'envoi d'un message d'information au terminal listant au moins un traitement autorisé sur le message stocké sur le serveur. Ce mode de réalisation permet d'informer l'utilisateur appelant des différentes options de traitement du message qui lui sont offertes. Ainsi, par exemple, le traitement exécuté sur le message stocké sur le serveur peut être sélectionné parmi : une suppression de tout ou partie du message stocké sur le serveur ; une lecture du message stocké sur le serveur ; ou une modification d'au moins une caractéristique du message stocké sur le serveur, tel que par exemple le contenu du message ou un ou plusieurs paramètres de l'enveloppe du message (heure d'émission, date de dépôt sur le serveur, identité à l'origine du message, localisation du terminal à l'origine du message, etc.). Dans un mode particulier de réalisation, le procédé de notification comprend en outre, lorsque le traitement exécuté sur le message stocké sur le serveur est une modification d'au moins une caractéristique du message stocké sur le serveur, une étape de réception par le système de messagerie d'une indication lui permettant d'identifier cette modification. De cette sorte, le système de messagerie peut garder une trace des modifications effectuées sur le message par l'utilisateur appelant, et éventuellement indiquer à l'utilisateur appelé la nature de ces modifications. On notera que si des avantages certains tels que ceux présentés ci-avant peuvent découler de l'invention pour l'utilisateur appelant à l'origine du message stocké sur le serveur du système de messagerie, l'invention offre également la possibilité à un autre utilisateur, dès lors que celui-ci dispose du lien d'accès notifié par le système de messagerie, de modifier au sens large du terme le message stocké sur le serveur. Cette possibilité peut toutefois être limitée via la mise en oeuvre de contrôles idoines au niveau du système de messagerie afin par exemple de limiter l'accès au message à l'utilisateur appelant (notamment via des contrôles basés sur la deuxième identité). Au vu de ce qui précède, l'invention repose non seulement sur le système de messagerie de l'utilisateur appelé sur lequel est stocké le message émis par l'utilisateur appelant, mais également sur le terminal de l'utilisateur appelant à proprement parler (ou d'un autre utilisateur ayant obtenu le lien l'accès), avec lequel il va être amené à requérir un traitement sur ce message. Ainsi, l'invention vise également un procédé d'accès par un terminal à un message destiné à une première identité de terminal stocké sur un serveur d'un système de messagerie associé à cette première identité, ledit message ayant été émis lors d'une communication par une deuxième identité de terminal, ce procédé comprenant : une étape d'obtention d'un lien d'accès au message stocké sur le serveur notifié à l'issue de cette communication à la deuxième identité par le système de messagerie ; une étape d'envoi au système de messagerie d'une requête d'accès au message stocké sur le serveur à partir de ce lien d'accès ; et une étape d'envoi au système de messagerie d'une commande identifiant un traitement à exécuter sur ce message. Corrélativement, l'invention vise aussi un terminal apte à accéder à un message destiné à une première identité de terminal stocké sur un serveur d'un système de messagerie associé à cette première identité, ce message ayant été émis lors d'une communication par une deuxième identité de terminal, le terminal selon l'invention comprenant : un module de réception d'un lien d'accès au message stocké sur le serveur notifié à l'issue de cette communication par le système de messagerie à la deuxième identité ; un module d'envoi au système de messagerie d'une requête d'accès au message stocké sur le serveur à partir de ce lien d'accès ; et un module d'envoi au système de messagerie d'une commande identifiant un traitement à exécuter sur ce message. Le procédé d'accès et le terminal selon l'invention bénéficient d'avantages similaires à ceux cités précédemment pour le procédé de notification et le système de messagerie. Dans un mode particulier de réalisation, le procédé d'accès comprend en outre une étape de réception, en provenance du système de messagerie, d'un message d'information listant au moins un traitement autorisé sur le message stocké sur le serveur. Dans un autre mode particulier de réalisation, le terminal comprend une application apte à modifier au moins une caractéristique du message stocké sur le serveur, et à envoyer au système de messagerie le message modifié et une indication permettant au système de messagerie d'identifier la modification apportée au message. Ainsi, dans le contexte d'une messagerie audio et/ou vidéo, cette application peut être tout type d'application installée sur le terminal permettant de réaliser des montages audio et/ou vidéo, connue en soi. L'invention vise également un système de communication comprenant un système de messagerie selon l'invention associé à une première identité de terminal, et un terminal selon l'invention apte à accéder à un message stocké sur un serveur du système de messagerie, ce message ayant été émis par une deuxième identité de terminal. Dans un mode particulier de réalisation, les différentes étapes du procédé de notification et/ou du procédé d'accès sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un système de messagerie ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de notification tel que décrit ci-dessus. L'invention vise également un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un terminal ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé d'accès tel que décrit ci-dessus. Chacun de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. On peut également envisager, dans d'autres modes de réalisation, que le procédé de notification, le procédé d'accès, le système de messagerie, le terminal et le système de communication selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées. Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : la figure 1 représente, de façon schématique, un système de communication, un système de messagerie et un terminal conformes à l'invention dans un mode particulier de réalisation ; - les figures 2 et 3 illustrent schématiquement l'architecture matérielle du système de messagerie et du terminal de la figure 1; - la figure 4 illustre, sous forme d'ordinogramme, les principales étapes d'un procédé de notification selon l'invention telles qu'elles sont mises en oeuvre par le système de messagerie de la figure 1 ; et la figure 5 illustre, sous forme d'ordinogramme, les principales étapes d'un procédé d'accès selon l'invention telles qu'elles sont mises en oeuvre par le terminal de la figure 1. Description détaillée de l'invention La figure 1 représente, un système de communication 1 conforme à l'invention, dans son environnement, dans un mode particulier de réalisation. Dans l'exemple envisagé sur la figure 1, le système 1 de communication permet à un utilisateur U2, équipé d'un terminal T2, d'accéder à un message M stocké sur un serveur DB d'un système de messagerie 2 associé à un terminal Ti, en vue par exemple de le modifier, de le lire ou encore de le supprimer. On suppose ici que le message M a été déposé par l'utilisateur U2 lors d'une communication préalable initiée via son terminal T2 à destination du terminal Ti, cette communication ayant été renvoyée vers le système de messagerie 2 pour une raison quelconque (ex. non réponse du terminal Ti, renvoi inconditionnel vers le système de messagerie 2, terminal Ti hors couverture ou éteint, etc.). Aucune limitation n'est attachée à la nature des terminaux T1 et T2 ou du système de messagerie 2. Ainsi, les terminaux peuvent être des terminaux téléphoniques, des ordinateurs portables ou fixes, des tablettes, etc., et le système de messagerie auquel s'applique l'invention, un système de messagerie audio ou vidéo, un système de messagerie électronique, synchrone (type messagerie instantanée) ou asynchrone, un système de messagerie de type store-and- forward utilisé pour les communications SMS ou MMS, etc. Toutefois, pour mieux illustrer l'invention, on suppose ici que les terminaux Ti et T2 sont des téléphones intelligents de type « smartphones », adaptés à communiquer respectivement sur des réseaux de télécommunications NW1 et NW2 (non mentionnés sur la figure), et que le système de messagerie 2 est un système de messagerie vocale (i.e. audio). L'application de l'invention à d'autres types de systèmes de messagerie est évoquée ultérieurement. Les réseaux de télécommunications NW1 et NW2 peuvent être distincts ou identiques. Les terminaux T1 et T2 sont associés respectivement à des identités de terminaux ID1 et ID2 distinctes : ces identités ID1 et ID2 sont ici des numéros de téléphone que les terminaux T1 et T2 utilisent pour communiquer sur et/ou via les réseaux de télécommunications NW1 et NW2 (i.e. pour être joignables et émettre des communications à destination d'autres terminaux). Bien entendu, d'autres types d'identités de terminaux peuvent être envisagés dans le cadre de l'invention, en fonction notamment de la nature des terminaux et du système de messagerie, dès lors que ces identités permettent aux terminaux de communiquer sur leurs réseaux respectifs et d'être joints via ces réseaux. Ainsi, l'invention s'applique également lorsque les identités ID1 et ID2 sont des adresses électroniques, des adresses SIP ou IP, etc. Il convient de noter que les identités ID1 et ID2 peuvent être partagées par plusieurs terminaux (incluant les terminaux Ti et T2) de sorte qu'il importe peu, dans le contexte de l'invention, quel type de terminal est utilisé pour émettre le message M et y accéder ultérieurement conformément à l'invention. En particulier, des terminaux différents peuvent être utilisés par l'utilisateur U2 pour déposer le message sur le serveur DB du système de messagerie 2 puis pour accéder ultérieurement à ce message grâce à l'invention, dès lors que ces terminaux sont associés à et/ou utilisent la même identité ID2. Par ailleurs, l'invention ne se limite pas à un accès au message M par l'utilisateur appelant U2 à l'origine de ce message. Toutefois par souci de simplification, dans l'exemple envisagé ici, on suppose que les identités de terminaux ID1 et ID2 sont attribuées de façon unique aux terminaux T1 et T2 respectivement et que c'est l'utilisateur U2, à l'origine du message M, qui souhaite accéder à ce message, de sorte que dans la description, on utilise de manière équivalente l'expression « un message (ou une notification, ou une commande, etc.) destiné à ou en provenance de l'identité ID1, respectivement de l'identité ID2 » et l'expression « un message (ou une notification, ou une commande, etc.) destiné au ou en provenance du terminal T1, respectivement du terminal T2 ». Conformément à l'invention, le système de communication 1 comprend : - d'une part, le système de messagerie 2 associé à l'identité de terminal ID1 utilisée par le terminal Ti ; et - d'autre part, le terminal T2. Le système de messagerie vocale 2 est conforme à l'invention. Il dispose, dans le mode de réalisation décrit ici, de l'architecture matérielle d'un ordinateur, comme illustré schématiquement à la figure 2. Plus précisément, le système de messagerie vocale 2 comprend notamment un processeur 3, une mémoire morte 4, une mémoire vive 5, une mémoire non volatile 6 et des moyens de communication 7 sur le réseau NW1 connus en soi. La mémoire morte 4 du système de messagerie vocale constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 3 et sur lequel est enregistré un programme d'ordinateur comportant des instructions pour l'exécution des étapes d'un procédé de notification conforme à l'invention, dont les étapes sont décrites ultérieurement en référence à la figure 4 dans un mode particulier de réalisation. Ce programme d'ordinateur définit, de façon équivalente, des modules logiciels et fonctionnels du système de messagerie 2 aptes à exécuter les différentes étapes du procédé de notification et à interagir avec les composants du système de messagerie 2 décrits précédemment en référence à la figure 2. Ces modules fonctionnels sont notamment le serveur DB sur lequel sont stockés les messages déposés (i.e. émis) auprès du système de messagerie 2 (et notamment le message M destiné au terminal Ti), un module de détection des messages stockés sur le serveur DB, un module d'envoi aux identités émettrices de ces messages de notification comprenant un lien d'accès vers ces messages, un module de réception de requêtes d'accès à ces messages utilisant ce lien d'accès et émises par des terminaux, ce module de réception incluant ici un serveur web W, un module de vérification apte à vérifier si des traitements peuvent être effectués sur ces messages une fois déposés sur le serveur par les terminaux à l'origine des requêtes d'accès, un module de réception de commandes contenant de tels traitements et un module apte à exécuter ces traitements sur les messages déposés. En outre, dans le mode de réalisation décrit ici, on suppose que le système de messagerie 2 offre à l'utilisateur Ul du terminal Ti un service de messagerie vocale visuelle (ou WM pour Visual Voice Mail en anglais) associé à l'identité ID1. Corrélativement, une application VVM est installée sur le terminal Ti pour lui permettre de bénéficier pleinement de ce service. De façon connue en soi, avec le service VVM, l'utilisateur U1 n'a pas besoin de se connecter au système de messagerie 2 pour consulter de manière séquentielle les messages vocaux laissés à son attention, en fonction de la date et de l'heure de dépôt de ces messages. Dès qu'un message vocal est détecté sur le serveur DB à l'attention de l'identité ID1, autrement dit immédiatement après son enregistrement, le système de messagerie 2 envoie une notification de dépôt du message à l'identité ID1 (et donc dans l'exemple envisagé ici, au terminal Ti), et le terminal T1 via l'application VVM télécharge le fichier du message vocal correspondant (typiquement un fichier au format MPEG3 (Moving Picture Experts Group-3)). Ainsi, l'application VVM présente sur le terminal Ti permet à l'utilisateur U1 d'avoir directement accès via son terminal aux messages vocaux qui lui sont destinés ainsi qu'aux informations caractérisant ces messages (date, heure de réception, identité du déposant sous la forme de son numéro de téléphone ou de son nom si cette identité est présente dans le répertoire local ou réseau du terminal Ti ou encore dans la signalisation d'appel, etc.). L'utilisateur U1 peut alors consulter les messages vocaux qui lui sont destinés (i.e. qui sont destinés à l'identité ID1 ici), dans l'ordre dans lequel il le souhaite, les lire en partie ou totalement, les relire, les détruire, les stocker, etc. Le terminal T2 est un terminal conforme à l'invention. Il dispose, dans le mode de réalisation décrit ici, de l'architecture matérielle d'un ordinateur, comme illustré schématiquement à la figure 3. Plus précisément, le terminal T2 comprend notamment un processeur 8, une mémoire morte 9, une mémoire vive 10, une mémoire non volatile 11 et des moyens de communication 12 sur le réseau NW2 connus en soi. La mémoire morte 9 du terminal T2 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 8 et sur lequel est enregistré un programme d'ordinateur comportant des instructions pour l'exécution des étapes d'un procédé d'accès conforme à l'invention, dont les étapes sont décrites ultérieurement en référence à la figure 5 dans un mode particulier de réalisation. Ce programme d'ordinateur définit, de façon équivalente, des modules logiciels et fonctionnels du terminal T2 aptes à exécuter les différentes étapes du procédé d'accès et à interagir avec les composants du terminal T2 décrits précédemment en référence à la figure 2. Ces modules fonctionnels sont notamment un module d'obtention de liens d'accès vers des messages émis et déposés sur le serveur DB via l'identité ID2, ces liens d'accès provenant du système de messagerie 2, un module d'envoi de requête d'accès aux messages stockés sur le serveur DB et émis par l'identité ID2 à partir de ces liens d'accès, et un (ou éventuellement plusieurs) module(s) d'envoi apte(s) à envoyer via le réseau NW2 au système de messagerie 2 des commandes identifiant des traitements à exécuter sur les messages stockés sur le serveur DB émis par l'identité ID2. Dans le mode de réalisation décrit ici, est installée également sur le terminal T2, par exemple dans sa mémoire morte 9, une application APP lui permettant de réaliser des montages audio et de modifier au moins une caractéristique d'un message (i.e. de son contenu ou de son enveloppe) émis via l'identité ID2 stocké sur le serveur DB (ex. le message M) et dont un lien d'accès est notifié au terminal T2 en vue de lui permettre d'effectuer des traitements sur ce message conformément à l'invention. Une telle application est connue en soi et n'est pas décrite plus en détail ici. Nous allons maintenant décrire, en référence respectivement aux figures 4 et 5, les principales étapes d'un procédé de notification et d'un procédé d'accès telles qu'elles sont mises en oeuvre par le système de messagerie 2 et par le terminal T2, dans un mode particulier de réalisation de l'invention. Pour illustrer ces étapes, comme mentionné précédemment, on s'intéresse à un message M destiné à l'identité de terminal ID1 (autrement dit à l'utilisateur Ul auquel est attribuée cette identité de terminal pour communiquer via son terminal sur le réseau NW1), et émis par l'utilisateur U2 via son terminal T2 sur le réseau NW2 en utilisant l'identité de terminal ID2. Le message M est ici un message vocal déposé par l'utilisateur U2 sur le serveur DB du système de messagerie 2 associé à l'identité de terminal ID1, suite à un renvoi d'un appel (communication au sens de l'invention) émis par le terminal T2 à destination de l'identité ID1 vers le système de messagerie 2. Les raisons de ce renvoi sont sans incidence sur la mise en oeuvre de l'invention (ex. non réponse du terminal Ti, renvoi inconditionnel des appels destinés à l'identité ID1 vers le système de messagerie 2, terminal T1 hors couverture ou éteint, etc.). Le dépôt du message M par le terminal T2 sur le serveur DB (étape F10, figure 5) et son stockage par le serveur DB (étape E10, figure 4) sont réalisés de façon connue de l'homme du métier, et non décrite ici. Dans le mode de réalisation décrit ici, le dépôt du message M est suivi de la notification au terminal Ti (i.e. à l'identité ID1) par le système de messagerie 2 qu'un message lui étant destiné est stocké sur le serveur DB. Cette notification peut se faire éventuellement via un intermédiaire telle une plateforme de notification à distance APN ou C2M. Elle peut s'afficher sous différentes formes dans l'application VVM du terminal T1 (ex. présence d'un pop-up, affichage d'un bandeau sur l'écran du terminal, d'une pastille sur l'icône modélisant l'application VVM, etc.), de façon connue en soi. L'application VVM installée sur le terminal T1 se connecte alors immédiatement au système de messagerie vocale 2 via une interface de programmation API (Application Programming Interface) pour télécharger la liste des messages vocaux destinés à l'identité ID1, ainsi que leur datation et leur état (ex. consulté, non consulté, sauvegardé). L'application VVM se synchronise alors sur la base des informations synthétiques ainsi téléchargées. Lors de cette synchronisation, si des nouveaux messages vocaux non encore présents sur le terminal T1 et destinés à l'identité ID1 sont disponibles sur le système de messagerie 2, l'application VVM demande leur téléchargement sur le terminal Ti afin de les stocker par exemple dans une mémoire non volatile du terminal T1. Par ailleurs, si des messages vocaux destinés à l'identité ID1 stockés sur le terminal T1 ont été consultés ou détruits sur le système de messagerie 2 via un autre moyen d'accès que le terminal T1 (ex. serveur web, communication vocale,...), et que ces messages sont marqués comme étant non encore consultés dans l'application VVM, celle-ci met à jour l'état de ces messages (marqués alors comme étant consultés), et détruit les messages vocaux stockés sur le terminal T1 qui ne sont plus disponibles sur le système de messagerie 2. Il convient de noter que lorsque l'utilisateur U1 a fini de lire un message vocal via le service VVM sur son terminal Ti, l'application VVM se connecte au système de messagerie 2 via une API pour synchroniser l'état du message avec la valeur « consulté ». De même, lorsque l'utilisateur U1 supprime un message vocal sur son terminal Ti via l'application VVM, celle-ci se connecte au système de messagerie 2 via une API pour synchroniser l'état du message avec la valeur « supprimé », ce qui se traduit par la suppression du message sur le système de messagerie 2. Dans le mode de réalisation décrit ici, lors de la communication établie entre le terminal T2 et le système de messagerie 2 résultant en le dépôt du message M, le système de messagerie 2 extrait de la signalisation d'appel associée à cette communication l'identité de terminal ID2 utilisée par le terminal T2 pour communiquer sur le réseau NW2, et l'associe dans le serveur DB au message M. Il convient de noter que dans certains cas de figure, comme par exemple lorsque l'utilisateur U2 a demandé le masquage de l'identité de son terminal T2 pour ses communications sur le réseau NW2, l'identité de terminal ID2 attribuée par le réseau NW2 au terminal T2 n'est pas présente dans la signalisation d'appel associée à la communication. Dans une telle situation, le système de messagerie 2 peut extraire et associer au message M comme identité de terminal à l'origine du message (deuxième identité au sens de l'invention), une identité fournie au terminal T2 par une plateforme de notification à distance (ex. plateforme APN ou C2M) telle un jeton ou token en anglais, si le terminal T2 bénéficie d'un tel service. Une fois le message M déposé (et stocké) sur le serveur DB du système de messagerie via son terminal T2, l'utilisateur U2 raccroche son terminal T2 et met fin à la communication avec le système de messagerie 2 (étapes E30 et F20). Sur détection de l'issue de cette communication et de la présence du message M destiné à l'identité ID1 sur le serveur DB, le système de messagerie 2 envoie, via ses moyens de communications 7, à l'identité ID2 associée sur le serveur DB au message M, une notification comprenant un lien d'accès URL_M au message M (étape E40). Dans le mode de réalisation décrit ici, cet envoi est réalisé immédiatement après l'achèvement de la communication. Cette notification peut être transmise à l'identité ID2 (i.e. au terminal T2 ici), par le biais de divers moyens, tels que par exemple, via une signalisation d'appel SIP si le terminal T2 met en oeuvre le protocole SIP, dans un message SMS émis par le système de messagerie 2 sur le réseau NW1 à destination de l'identité ID2, par l'intermédiaire d'une plateforme de notification à distance (ex. plateforme APN ou C2M décrite précédemment), etc. Dans le mode de réalisation décrit ici, le lien d'accès URL_M notifié par le système de messagerie 2 au terminal T2 est un lien web contenant l'adresse URL (pour Uniform Request Locator) du serveur web W du système de messagerie 2 et, comme paramètre, une chaîne de caractères chiffrée identifiant de manière unique le message M déposé par le terminal T2 sur le système de messagerie 2 associé au terminal T1. A titre d'exemple, la notification envoyée par le système de messagerie 2 au terminal T2 peut contenir le message suivant : « pour accéder à votre message, cliquez sur le lien https://www.serveurW.fr?id=123456789abcdefghijklm >>, où la chaîne de caractères « 123456789abcdefghijklm » identifie de manière unique et chiffrée le message M. Dans une variante de réalisation, le lien web URL_M comprend également dans la chaîne de caractères chiffrée, l'identité ID2 utilisée par le terminal T2 pour déposer le message M sur le serveur DB à l'attention du terminal Ti. Ceci permet de sécuriser encore davantage l'accès au message M, via la possibilité de mettre en oeuvre des contrôles supplémentaires au niveau du système de messagerie 2 (par exemple si l'utilisateur U2 essaye d'accéder au message M via un autre terminal que le terminal T2, ou si un autre utilisateur qu'U2 essaye d'accéder à ce message). L'utilisateur U2 peut dès lors accéder au message M, en vue par exemple de le lire, de le modifier ou de le supprimer (autrement dit de lui appliquer un traitement), à partir du lien URL_M reçu du système de messagerie (étape F30), par exemple en sélectionnant le lien indiqué dans le SMS ou en cliquant dessus avec son terminal T2, ou encore en le recopiant dans un navigateur web installé sur son terminal T2. Cette sélection du lien se traduit par l'ouverture d'un navigateur web sur le terminal T2 avec l'URL positionnée sur le lien URL_M et par l'envoi par le terminal T2 d'une requête d'accès R(URL_M) au serveur web W du système de messagerie 2 (étape F40). Cette requête d'accès vise à télécharger la page web identifiée par l'URL_M afin de pouvoir accéder au message M et le cas échéant effectuer un traitement sur ce message. Sur réception de cette requête d'accès par le serveur web W du système de messagerie 2 (étape E50), celui-ci vérifie que l'utilisateur U2 est bien autorisé à accéder à ce message et à sélectionner au moins un traitement à effectuer sur ce message (étape test E60). Un tel traitement est par exemple ici la lecture du message, sa modification (i.e. modification du contenu ou d'un paramètre de son enveloppe) ou sa suppression en tout ou partie. Dans le mode de réalisation décrit ici, la possibilité pour l'utilisateur U2 d'exécuter un traitement sur le message M est conditionnée par la présence du message M sur le serveur DB et par son état (« consulté », « non consulté », « supprimé », etc.). Le serveur web W recherche donc tout d'abord si le message M identifié de manière unique dans le lien URL_M transmis par le terminal T2 dans la requête d'accès R est présent sur le serveur DB. A cet effet, il interroge le serveur DB avec l'identifiant du message M extrait du lien URL_M selon des moyens connus en soi. Plusieurs cas de figure peuvent alors se présenter. Si le message M identifié dans le lien URL_M n'existe pas sur le serveur DB du système de messagerie vocale 2 (par exemple, parce que le lien d'accès URL_M utilisé par le terminal T2 est un lien frauduleux de tentative d'accès au système de messagerie 2 de l'utilisateur U1), le serveur web W génère une page web signalant une erreur, par exemple indiquant « Erreur : Le message auquel vous tentez d'accéder n'existe pas » (réponse non à l'étape test E60 et étape E70). Aucun traitement sur le message M n'est alors permis à l'utilisateur U2 via son terminal T2. Si au contraire, le message M est bien stocké sur le serveur DB, le système de messagerie 2, via le serveur web W, détermine l'état de ce message en vue d'identifier si l'utilisateur U2 est autorisé à effectuer un traitement sur ce message. Dans l'exemple envisagé ici, le message M peut prendre trois états distincts, à savoir « consulté » (ou lu), « supprimé », ou « non consulté » (ou non lu). Si l'état du message M sur le serveur DB est « supprimé », le serveur web W génère alors une page web qu'il envoie au terminal T2 avec un message d'information prédéfini du type « Votre message a été supprimé le 24 septembre 2012 à 12h56. Vous ne pouvez plus le modifier ni le lire. » (réponse non à l'étape test E60 et étape E70). Si l'état du message M sur le serveur DB est « non consulté », le serveur web W génère une page web qu'il envoie au terminal T2 avec un message d'information prédéfini listant les traitements autorisés sur le message M du type « Vous pouvez lire, modifier ou supprimer tout ou partie de votre message » (réponse oui à l'étape test E60 et étape E80). Dans le mode de réalisation décrit ici, si l'état du message M sur le serveur DB est « consulté », le serveur web W génère également une page web qu'il envoie au terminal T2 sur avec un message d'information prédéfini du type « Votre message a été lu le 24 septembre 2012 à 12h56. Vous pouvez toutefois le lire, le modifier ou le supprimer en tout ou partie » (réponse oui à l'étape test E60 et étape E80). Autrement dit, dans le mode de réalisation décrit ici, le serveur web W détermine que l'utilisateur U2 via son terminal T2 est autorisé à traiter le message M identifié de manière unique dans le lien URL_M, si celui-ci est associé à un état « consulté » ou « non consulté » sur le serveur DB. En revanche, il détermine que l'utilisateur U2 n'est pas autorisé à traiter le message M si celui-ci ne se trouve pas sur le serveur DB ou s'il est associé à un état « supprimé » sur le serveur DB. En variante, si l'état du message M sur le serveur DB est « consulté », le serveur web W génère une page web qu'il envoie au terminal 12 avec un message d'information prédéfini du type « Votre message a été lu le 24 septembre 2012 à 12h56. Vous ne pouvez plus y accéder. » (réponse non à l'étape test E60 et étape E70). Dans une autre variante, si l'état du message M sur le serveur DB est « consulté », le serveur web W génère une page web qu'il envoie au terminal T2 avec un message d'information prédéfini du type « Votre message a été lu le 24 septembre 2012 à 12h56. Vous ne pouvez plus le modifier ni le supprimer, mais uniquement le lire. » (réponse oui à l'étape test E60 et étape E80). Sur réception de ce message d'information (étape F50), l'utilisateur U2 peut alors sélectionner un traitement parmi les traitements listés et autorisés dans le message d'information (étape F60), ou décider finalement de ne rien faire, auquel cas, aucune modification du message M n'est effectuée au niveau du système de messagerie 2. Si le terminal T2 sélectionne parmi cette liste, une lecture du message M stocké sur le serveur DB, une commande CMD-M(Lecture) identifiant ce traitement est envoyée par le terminal T2 au serveur web W (étape F70). Cette commande est envoyée ici par le terminal T2 dans une requête web au serveur web W.Dans le mode de réalisation décrit ici, sur réception de cette commande CMD-M(Lecture) par le serveur web W (étape E90), le message M est téléchargé sur le terminal T2 par le système de messagerie 2 (étape E100) afin que l'utilisateur U2 puisse lire le message vocal M directement à partir de son terminal T2. Cette étape de téléchargement pour lecture du message M est une étape d'exécution du traitement de lecture sélectionné par le terminal T2 sur le message M stocké sur le serveur DB au sens de l'invention. Il convient de noter que dans ce cas, aucune modification du message M n'est effectuée sur le serveur DB. En variante, le message M est lu directement via le serveur web W sans télécharger le message M sur le terminal T2 (étape d'exécution du traitement de lecture au sens de l'invention). Si l'utilisateur U2 sélectionne via son terminal T2 une suppression du contenu du message M stocké sur le serveur DB, une commande CMD-M(Suppression) identifiant ce traitement est envoyée par le terminal T2 au serveur web W, dans une requête web (étape F70). Dans le mode de réalisation décrit ici, sur réception de cette commande CMDM(Suppression) par le serveur web W (étape E90), une demande de confirmation de la suppression est transmise au terminal T2 (via par exemple l'affichage, en réponse à la requête web du terminal T2, d'un formulaire web lui offrant la possibilité de confirmer ou d'annuler la suppression du message). Si l'utilisateur U2 ne confirme pas la suppression du message, aucune suppression du message M n'est effectuée sur le serveur DB. En revanche, si l'utilisateur U2 confirme la suppression du contenu du message M, le formulaire web contenant cette confirmation est transmis vers le serveur web W, qui se charge alors de supprimer le contenu du message M stocké sur le serveur DB (exécution du traitement de suppression du message M au sens de l'invention, étape E100). Le serveur DB conserve toutefois ici l'identifiant du message ainsi que son enveloppe, qui contient notamment les caractéristiques suivantes : date, heure du message et identité ID2 à l'origine du message M, localisation potentielle du terminal T2, etc. En variante, l'enveloppe du message est également supprimée du serveur DB. Dans une autre variante encore, seule l'identité ID2 à l'origine du message M est conservée après suppression du contenu du message M sur le serveur DB. L'utilisateur U2 peut également sélectionner via son terminal T2 le traitement correspondant à une modification de tout ou partie du message M stocké sur le serveur DB, ce qui se traduit par l'envoi d'une commande CMD-M(Modification) identifiant ce traitement par le terminal T2 au serveur web W via une requête web (étape F70). Dans le mode de réalisation décrit ici, sur réception de la commande CMD- M(Modification) par le serveur web W (étape E90), le message M est téléchargé sur le terminal T2 par le système de messagerie 2 via le serveur web W depuis le serveur DB. De cette sorte l'utilisateur U2 a la possibilité, en utilisant l'application APP de montage audio installée sur son terminal T2 de modifier tout ou partie du message M ainsi téléchargé. En variante, les modifications peuvent être apportées directement à partir d'une copie du message M stockée lors de son émission par le terminal T2 (par exemple dans sa mémoire non volatile 9, afin d'éviter tout téléchargement). Cette modification peut porter sur le contenu du message M à proprement parler ou sur toute autre caractéristique du message M, comme par exemple sur une caractéristique de l'enveloppe du message M (ex. la date de dépôt du message, l'identité ID2 à l'origine de ce message (positionnement à une identité anonyme ou à une identité distincte de ID2), la localisation du terminal à l'origine du message M ou celui utilisé pour accéder au message M conformément à l'invention après son dépôt, etc.). De façon connue, l'application de montage APP présente généralement le message sur lequel on peut effectuer un montage sous la forme d'une ligne de temps ou ligne de montage. Pour ne modifier qu'une partie du contenu du message M, l'utilisateur U2 peut sélectionner via l'application APP un segment de la ligne de montage correspondant à la partie du message qu'il souhaite modifier. La partie sélectionnée peut alors être supprimée et remplacée par une autre partie préalablement enregistrée (ou captée en direct via un microphone ou un dispositif comparable). Plutôt que de remplacer complètement le message, le recours à une telle application permet de remplacer uniquement une portion de message que l'utilisateur U2 juge indésirable. En variante, plutôt que de sélectionner un segment de la ligne de montage, l'utilisateur U2 peut indiquer, via l'application APP, un point d'insertion dans la ligne de montage à partir duquel il souhaite introduire un nouveau segment de message. De cette sorte, l'utilisateur U2 peut préciser un point important d'un message qu'il avait oublié d'indiquer auparavant lors du dépôt du message M à l'étape F10, ou personnaliser après coup son message vocal. Le message noté M' ainsi modifié par l'utilisateur U2 via l'application APP est ensuite transmis par le terminal T2 au système de messagerie 2 dans un message CMD-M' (ce message est requête web ici). Dans le mode de réalisation décrit ici, ce message CMD-M' comprend en outre une indication permettant au système de messagerie 2 d'identifier quelle(s) modification(s) a (ont) été apportée(s) au message M. Par exemple, il peut indiquer une nouvelle insertion de séquence à partir de l'instant T0+5 secondes, et d'une durée de 3 secondes. Dans le mode de réalisation décrit ici, sur réception du message CMD-M' par le serveur web W, une demande de confirmation de la modification du message M présent sur le serveur DB est transmise au terminal T2 (en réponse à la requête web CMD-M'), via par exemple l'affichage d'un formulaire web offrant la possibilité de confirmer ou d'annuler la modification du message. Si l'utilisateur U2 ne confirme pas la modification du message M, aucune modification du message M n'est effectuée sur le serveur DB. En revanche, si l'utilisateur U2 confirme la modification du contenu du message M, le formulaire web contenant cette confirmation est transmis par le terminal T2 vers le serveur web W, qui se charge alors de mettre à jour le message M sur le serveur DB, par exemple en le remplaçant par le message M' envoyé par le terminal T2 dans le message CMD-M' (exécution du traitement de modification du message M au sens de l'invention, étape E100). Le serveur DB conserve par ailleurs ici l'identifiant du message M ainsi que son enveloppe, qui contient notamment les caractéristiques suivantes : date, heure du message et identité ID2 à l'origine du message M. En variante, lorsqu'une ou plusieurs caractéristiques de l'enveloppe du message M ont été modifiées et identifiées dans le message CMD-M', le serveur web W met à jour ces caractéristiques sur le serveur DB. Suite à l'exécution du traitement sélectionné par le terminal T2 sur le message M, le système de messagerie 2 notifie ici au terminal Ti, sur son identité ID1, le traitement exécuté sur le message M (lecture, suppression ou modification) (étape E110). Cette notification peut se faire via l'envoi d'un message SMS par le système de messagerie 2 sur le terminal Ti, ce message SMS contenant par exemple une information du type « Un message sur votre messagerie a été supprimé ou modifié par son déposant». Si le message M a été modifié lors de l'étape E100, le message SMS peut par ailleurs inclure des indications permettant à l'utilisateur U1 d'identifier quelles modifications ont été apportées au message M, notamment si ce message M était dans un état « consulté » lorsque le terminal T2 a demandé à y accéder. La présence de telles indications permet à l'utilisateur U1 de visualiser en connaissance de cause uniquement ce que l'utilisateur U2 a modifié sur le message M. En variante, la notification au terminal Ti du traitement exécuté à l'étape E100 peut se faire par l'intermédiaire d'une plateforme de notification à distance (ex. plateforme APN ou C2M) telle que mentionnée précédemment. Celle-ci envoie alors un message de notification à l'application VVM du terminal Ti de sorte à la forcer à se resynchroniser avec le système de messagerie 2, afin soit de supprimer la copie du message M déjà téléchargée sur le terminal Ti et non encore lue par l'utilisateur U1, soit de remplacer cette copie par le message M' modifié en fonction du traitement exécuté sur le message M à l'étape E100. Dans un autre mode de réalisation de l'invention, afin d'éviter que l'utilisateur U1 ne consulte un message M stocké sur le serveur DB en cours de modification ou de suppression, un paramètre ou marqueur peut être activé au niveau du système de messagerie 2 associé à l'identité ID1, de sorte à rendre ce message M inaccessible par le terminal Ti durant le traitement initié par le terminal T2 pour modifier ou supprimer le message. Le message M (ou sa version modifiée M') redevient alors automatiquement accessible une fois le traitement exécuté par le système de messagerie 2 à l'étape E100. Dans le mode de réalisation décrit ici, le système de messagerie 2 est un système de messagerie vocale. Toutefois cette hypothèse n'est pas limitative et l'invention s'applique à d'autres types de messagerie. Ainsi, par exemple, le procédé de notification et le procédé d'accès peuvent être utilisés pour modifier/supprimer ou lire un message stocké : - sur un serveur d'un système de messagerie vidéo, ou multinnode (i.e. audio/vidéo) ; - sur un serveur d'un système de messagerie électronique, synchrone (ex. messagerie instantanée) ou asynchrone (ex. emails, une communication étant considérée comme achevée une fois Vernal' envoyé par l'utilisateur émetteur) ; ou sur un serveur de type « store-and-forward » pouvant être utilisé pour stocker des messages SMS ou MMS avant d'être remis à leur destinataire en cas de non disponibilité de celui-ci. Dans ce cas, le traitement d'un message SMS ou MMS conformément à l'invention n'est possible que tant que le message n'a pas été remis à son destinataire et est stocké sur le serveur. Par ailleurs, dans le mode de réalisation décrit ici, le système de messagerie 2 et le terminal T2 interagissent pour le traitement du message M via une interface web. En variante, d'autres protocoles peuvent être utilisés pour mettre en oeuvre cette interaction, comme par exemple le protocole FTP (File Transfer Protocol), ou un protocole ou une application propriétaire. En outre, comme mentionné précédemment, dans le mode de réalisation décrit ici, c'est l'utilisateur U2 à l'origine du message M qui cherche à accéder à ce message en vue de lui appliquer un traitement a posteriori, l'utilisateur U2 utilisant à cet effet le même terminal T2 pour déposer son message sur le serveur DB et pour y accéder. Ces hypothèses ne sont toutefois pas limitatives, et l'utilisateur U2 peut utiliser des terminaux distincts pour émettre le message M lors d'une communication et requérir un traitement une fois cette communication achevée. De même, on peut envisager qu'un utilisateur distinct de l'utilisateur U2 à l'origine du message M puisse requérir l'accès au message M s'il y est autorisé par l'utilisateur U2, après avoir obtenu le lien d'accès au message M par exemple par l'intermédiaire de l'utilisateur U2. Dans le mode de réalisation décrit ici, un seul lien d'accès est envoyé par le système de messagerie 2 à l'identité ID2. Dans un autre mode de réalisation, on peut envisager que plusieurs liens d'accès soient envoyés à l'identité ID2 en fonction par exemple des traitements pouvant être appliqués sur le message M (un lien d'accès pour une suppression du message, un lien d'accès pour une modification, etc.). REVENDICATIONS1. Procédé de notification, par un système de messagerie (2) associé à une première identité de terminal (ID1), comprenant : sur détection (E10) d'un message (M) destiné à la première identité stocké sur un serveur (DB) du système de messagerie, ledit message ayant été émis par une deuxième identité de terminal (ID2) lors d'une communication, une étape d'envoi (E40), à l'issue de cette communication, d'une notification à la deuxième identité (ID2) comprenant un lien d'accès (URL_M) à ce message ; sur réception (E50) d'une requête d'accès à ce message émise par un terminal à partir de ce lien, une étape de vérification (E60) par le système de messagerie qu'au moins un traitement sur ce message, sélectionné par ce terminal, est autorisé ; le cas échéant, sur réception (E90) d'une commande (CMD_M) en provenance de ce terminal identifiant un dit traitement autorisé, une étape d'exécution (E100) de ce traitement sur le message stocké sur le serveur. 2. Procédé de notification selon la revendication 1 comprenant en outre une étape de notification (E110) à la première identité du traitement exécuté sur le message stocké sur le serveur. 3. Procédé de notification selon la revendication 1 ou 2 dans lequel le lien d'accès (URL_M) notifié à la deuxième identité est un lien web contenant un paramètre identifiant de manière unique le message stocké sur le serveur. 4. Procédé de notification selon l'une quelconque des revendications 1 à 3 comprenant, suite à l'étape de vérification, une étape d'envoi (E80) d'un message d'information audit terminal listant au moins un traitement autorisé sur le message stocké sur le serveur. 5. Procédé de notification selon l'une quelconque des revendications 1 à 4 dans lequel le traitement exécuté sur le message stocké sur le serveur est sélectionné par le terminal parmi : une suppression de tout ou partie du message stocké sur le serveur ; une lecture du message stocké sur le serveur ; ou une modification d'au moins une caractéristique du message stocké sur le serveur. 6. Procédé de notification selon l'une quelconque des revendications 1 à 5 comprenant en outre, lorsque le traitement exécuté sur le message stocké sur le serveur est une modification d'au moins une caractéristique du message stocké sur le serveur, une étape de réception par le système de messagerie d'une indication lui permettant d'identifier cette modification. 7. Procédé de notification selon l'une quelconque des revendications 1 à 6 dans lequel l'étape de vérification (E60) comprend une étape de détermination d'un état du message stocké sur le serveur, l'exécution (E70,E80) du traitement étant conditionnée par cet état. 8. Procédé de notification selon l'une quelconque des revendications 1 à 7 dans lequel la deuxième identité est une identité attribuée par un réseau de télécommunications ou une identité fournie par une plateforme de notification à distance à un terminal utilisé pour émettre le message stocké sur le serveur. 9. Procédé d'accès par un terminal (T2) à un message (M) destiné à une première identité de terminal (ID1) et stocké sur un serveur (DB) d'un système de messagerie (2) associé à cette première identité, ledit message ayant été émis lors d'une communication par une deuxième identité de terminal (ID2), ce procédé comprenant : une étape (F30) d'obtention d'un lien d'accès (URL_M) au message (M) stocké sur le serveur (DB) notifié à l'issue de cette communication (F20) par le système de messagerie (2) à la deuxième identité de terminal (ID2) ; une étape d'envoi (F40,F70) au système de messagerie (2) d'une requête d'accès (R) au message stocké sur le serveur à partir de ce lien d'accès ; et une étape d'envoi au système de messagerie d'une commande (CMD_M) identifiant un traitement à exécuter sur ce message. 10. Procédé d'accès selon la revendication 9 comprenant en outre une étape de réception en provenance du système de messagerie d'un message d'information listant au moins un traitement autorisé sur le message stocké sur le serveur. 11. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de notification selon l'une quelconque des revendications 1 à 8 ou du procédé d'accès selon la revendication 9 ou 10 lorsque ledit programme est exécuté par un ordinateur. 12. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de notification selon l'une quelconque des revendications 1 à 8, ou un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé d'accès selon la revendication 9 ou 10. 13. Système de messagerie (2) associé à une première identité de terminal (ID1), comprenant :un serveur (DB) ; un module de détection, apte à détecter un message destiné à la première identité et stocké sur le serveur, ce message ayant été émis par une deuxième identité de terminal lors d'une communication ; un module d'envoi, activé sur détection par le module de détection du message stocké sur le serveur, et apte à envoyer à l'issue de ladite communication une notification à la deuxième identité comprenant un lien d'accès au message stocké sur le serveur ; un module de réception d'une requête d'accès au message stocké sur le serveur émise par un terminal à partir de ce lien d'accès ; un module de vérification, activé sur réception de la requête d'accès par le module de réception, et apte à vérifier qu'au moins un traitement sur le message stocké sur le serveur, sélectionné par le terminal, est autorisé ; un module de réception d'une commande en provenance du terminal identifiant un dit traitement autorisé ; et un module d'exécution, apte à exécuter sur le message stocké sur le serveur le traitement identifié dans ladite commande. 14. Terminal (T2) apte à accéder à un message destiné à une première identité de terminal (ID1) stocké sur un serveur (DB) d'un système de messagerie (2) associé à cette première identité, ledit message ayant été émis lors d'une communication par une deuxième identité de terminal (ID2), ledit terminal comprenant : un module d'obtention d'un lien d'accès au message stocké sur le serveur notifié à l'issue de cette communication par le système de messagerie (2) à la deuxième identité de terminal (1D2); un module d'envoi au système de messagerie d'une requête d'accès au message stocké sur le serveur à partir de ce lien d'accès ; et un module d'envoi au système de messagerie d'une commande identifiant un traitement à exécuter sur ce message. 15. Terminal (T2) selon la revendication 14 comprenant en outre une application (APP) apte à modifier au moins une caractéristique du message stocké sur le serveur, et à envoyer au système de messagerie le message modifié et une indication permettant au système de messagerie d'identifier la modification apportée au message.35