FR 3007921 A1 20150102 FR 1356280 A 20130628 L'invention concerne un procédé de validation d'une transaction. Plus précisément l'invention porte plus particulièrement sur la réalisation d'une transaction effectuée entre un terminal et un serveur de traitement hébergeant un site web. L'invention trouve une application particulièrement intéressante dans des applications de paiement sur mobile (le terme habituellement utilisé pour ces applications est le terme anglais « mobile wallet ») qui permettent à des utilisateurs de payer des biens, des factures, au moyen de leur téléphone mobile. Suite à l'évolution de la technologie, il existe maintenant des terminaux mobiles équipés de navigateur web qui permettent l'accès aux services en ligne, appelés également « services web ». Parmi les services proposés, des services d'achat en ligne proposent à un utilisateur connecté de choisir un ou plusieurs produits. Certains de ces services proposent le paiement des produits en utilisant le service « Certicode » (marque déposée) offert par « La Banque Postale ». Le service « Certicode » permet à un utilisateur abonné au service « Certicode » de recevoir un code de validation unique lors de chaque achat en ligne. Plus précisément, lorsque l'utilisateur souhaite valider une transaction, il confirme le choix des produits puis saisit un numéro de carte de crédit via une interface du navigateur web. La fourniture du numéro de carte de crédit au service d'achat en ligne entraine la connexion du service d'achat en ligne à un serveur dédié au service « Certicode » qui commande l'envoi d'un SMS contenant un code de validation à un terminal mobile dont le numéro a été fourni au service lors d'une phase d'abonnement au service. L'utilisateur communique ensuite ce code de validation au service d'achat via l'interface du navigateur web. Ce service n'est accessible qu'aux utilisateurs qui possèdent une carte bancaire. Il ne peut être utilisé par des populations non bancarisées. Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations. A cette fin, l'invention propose un procédé de validation d'une transaction entre un terminal d'un utilisateur et un premier serveur aptes à communiquer entre eux via une première liaison de communication. Selon l'invention, le procédé de validation comprend les étapes suivantes, mises en oeuvre par ledit terminal : - réception via la première liaison, d'une demande d'un code de validation pour ladite transaction ; - établissement d'une deuxième liaison de communication avec un deuxième serveur, ledit établissement provoquant une rupture de la première liaison ; - transmission via ladite deuxième liaison de communication, d'une requête de code de validation ; - réception, suite à la transmission de ladite requête, via un premier service de messagerie, d'un message contenant un code de validation en provenance dudit deuxième serveur ; - réception, via un deuxième service de messagerie, d'un message contenant une adresse associée au premier serveur ; - rétablissement de la première liaison au moyen de ladite adresse reçue, et - transmission via ladite première liaison rétablie, dudit code de validation reçu. Le procédé de validation permet la validation d'une transaction entre un terminal et un premier serveur, par exemple un serveur web. La validation de la transaction est effectuée grâce à un code de validation demandé à un deuxième serveur par le terminal de l'utilisateur et reçu dans un message d'un service de messagerie. La fourniture d'un code de validation est un moyen de validation d'une transaction qui est simple pour l'utilisateur. Le procédé de validation ne nécessite pas la fourniture d'un numéro de carte bancaire. Lors de la demande de code de validation, la liaison de communication entre le terminal et le premier serveur est interrompue. La réception d'un message contenant une adresse associée au premier serveur permet à l'utilisateur de rétablir facilement la liaison établie entre le terminal et le serveur de traitement. Le rétablissement de cette première liaison permet de terminer la transaction commencée en utilisant le code de validation reçu suite à l'établissement de la deuxième liaison. Le code de validation est une preuve que le client a donné son accord pour la transaction. Grâce au procédé, l'utilisateur peut effectuer une transaction, même s'il ne détient pas de carte de crédit. Selon un mode de réalisation particulier du procédé de validation, le premier et/ou le deuxième service de messagerie sont du type SMS (pour « Short Message Service »). L'envoi d'un SMS est une méthode simple pour envoyer une information à un terminal. De plus, lors de la réception d'un SMS, le message, et en conséquence l'information transmise dans le message, est enregistré dans une mémoire du terminal. L'utilisateur peut ensuite accéder à l'information à n'importe quel moment. L'information reste accessible tant que l'utilisateur n'a pas volontairement supprimé le message de la mémoire du terminal. Selon un mode de réalisation particulier du procédé de validation, ladite première liaison est une liaison de type Web. Une liaison web est une liaison de communication adaptée pour réaliser une transaction. Elle permet la réception de pages web concernant un grand nombre de données consultables par un utilisateur. Elle permet également de proposer des interfaces graphiques simples et adaptées à la saisie d'informations nécessaires à une transaction. Selon un mode de réalisation particulier du procédé de validation, la demande de code de validation reçue est une page web et ladite adresse reçue est l'adresse de ladite page. Grâce à l'adresse reçue, il est facile pour l'utilisateur de se connecter de nouveau au site web et de retrouver un écran similaire à celui qu'il voyait au moment de la coupure de la liaison. L'adresse permet également au terminal, et à l'utilisateur, de retrouver les informations relatives à la transaction en cours. Selon un mode de réalisation particulier du procédé de validation, ladite deuxième liaison est une liaison de type USSD (pour « Unstructured Supplementary Service Data »). Une liaison USSD est un moyen simple et disponible sur tous les terminaux mobiles pour échanger des informations avec un serveur. Selon un mode de réalisation particulier du procédé de validation, ledit code de validation est un mot de passe de type « One Time Password ». Un mot de passé de type "One Time Password" est un identifiant à usage unique. Il ne peut être associé qu'à une seule transaction. Cela permet de sécuriser le système. L'invention se rapporte également à un procédé de traitement d'une transaction entre un terminal d'un utilisateur et un premier serveur aptes à communiquer entre eux via une première liaison de communication. Le procédé de traitement comprend les étapes suivantes, mises en oeuvre par ledit premier serveur : - transmission via la première liaison de communication, d'une demande d'un code de validation pour ladite transaction; - transmission à destination dudit terminal, via un service de messagerie, d'un message contenant une adresse associée au premier serveur ; - suite à une coupure suivie d'un rétablissement de ladite première liaison par ledit terminal au moyen de ladite adresse, réception, via ladite première liaison rétablie, d'un code de validation, ledit code de validation étant été transmis audit terminal par un deuxième serveur de gestion. Selon un mode de réalisation particulier, le procédé de traitement comporte, suite audit rétablissement de la première liaison, une étape de retransmission via la première liaison de communication, de ladite demande d'un code de validation et le code de validation est reçu dans une réponse à ladite demande retransmise. Selon un mode de réalisation particulier du procédé de traitement, ladite demande n'est pas retransmise si le délai calculé entre la transmission de ladite demande et le rétablissement de la première liaison est supérieur à une valeur de seuil prédéterminé L'invention se rapporte encore à un serveur de traitement apte à communiquer avec un terminal via une première liaison de communication, ledit serveur comprenant: - un module de transmission, via un service de messagerie, à destination dudit terminal, d'un message contenant une adresse associée audit serveur ; - un module de communication adapté pour transmettre au terminal, via ladite première liaison de communication, une demande d'un code de validation pour une transaction en cours et pour recevoir suite à une coupure suivie d'un rétablissement de ladite première liaison par ledit terminal au moyen de ladite adresse, via ladite première liaison rétablie, un code de validation, ledit code de validation étant été transmis audit terminal par un deuxième serveur de gestion. L'invention se rapporte enfin à un produit programme d'ordinateur comprenant des instructions pour mettre en oeuvre les étapes du procédé de traitement d'une transaction tel que décrit précédemment, lorsqu'il est chargé et exécuté par un processeur. D'autres particularités et avantages de la présente invention apparaitront dans la description suivante de modes de réalisation donnés à titre d'exemples non limitatifs, en référence aux dessins annexés, dans lesquels : - la figure 1 est un schéma illustrant un système selon un mode de réalisation de l'invention, - la figure 2 est un organigramme illustrant les différentes étapes d'un procédé de validation d'une transaction et d'un procédé de traitement d'une transaction selon un mode de réalisation de l'invention. L'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et/ou logiciels, apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, settop-box, routeur, etc) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc). De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. Un mode de réalisation d'un procédé de validation d'une transaction et d'un procédé de traitement d'une transaction va maintenant être décrit en référence aux figures 1 et 2. En référence à la figure 1, un système SYS comprend un terminal T d'un utilisateur U, un serveur de gestion SG et un serveur de traitement ST. Le terminal T est par exemple un terminal mobile. Plus généralement, le terminal TA est un équipement apte à communiquer via une première liaison de communication avec le serveur de traitement ST, à communiquer via une deuxième liaison de communication avec le serveur de gestion SG et à recevoir des messages d'entités distantes. Le terminal T comporte de façon connue, notamment une unité de traitement MT équipée d'un microprocesseur, une mémoire morte de type ROM, une mémoire vive de type RAM. Le terminal T peut comporter de manière classique et non exhaustive les éléments suivants: un microphone, un haut-parleur, un lecteur de disque, un moyen de stockage... Le terminal T contient un navigateur NV. Le navigateur NV est un navigateur web, c'est-à-dire un logiciel conçu pour consulter le World Wide Web. Le terminal T comporte également un clavier, un écran de visualisation ECR et un module d'affichage AFF pour l'affichage sur l'écran de visualisation ECR. Le terminal T comporte également un premier module de communication COM1, un 30 deuxième module de communication COM2, un module de réception de message RCM et une interface utilisateur INT. L'unité de traitement UT est apte à recevoir des instructions de l'interface utilisateur INT, par exemple le clavier ou tout autre moyen de sélection par l'utilisateur. Le serveur de traitement ST est par exemple un serveur et comporte de façon connue, notamment une unité de traitement UT équipée d'un microprocesseur, une mémoire morte de type ROM, une mémoire vive de type RAM. La mémoire morte de type ROM comporte des registres mémorisant un programme d'ordinateur PG comportant des instructions de programme adaptées à mettre en oeuvre un procédé de traitement d'une transaction selon un mode de réalisation de l'invention décrit ultérieurement en référence à la figure 2. Le serveur de traitement ST comporte également un module de communication COM, un module d'envoi de messages EVM et un module de traitement TT. Un mode de réalisation d'un procédé de validation d'une transaction et d'un procédé de traitement d'une transaction, mis en oeuvre dans le système SYS, va maintenant être décrit en référence à la figure 2. Lors d'une étape préalable EO, réalisée par exemple suite à une action de l'utilisateur U pour d'une part, démarrer le navigateur NV et d'autre part, saisir une adresse ADS du serveur de traitement ST, le terminal T établit une première liaison de communication Ll avec le serveur de traitement ST. La première liaison de communication Ll est une liaison de type Web. Elle est établie de façon connue par l'envoi par le premier module de communication COM1 du terminal T d'une requête de type web contenant l'adresse ADS. Typiquement, l'adresse ADS est une URL (pour « Uniform Resource Locator ») permettant d'adresser un site web SW hébergé par le serveur de traitement ST. L'envoi de l'adresse ADS provoque l'ouverture d'une session de communication entre le terminal T et le serveur de traitement ST, via la première liaison de communication Ll. Le site web SW contient une pluralité de pages web dans lesquelles un utilisateur peut naviguer. Le site web SW est par exemple un site proposant à l'achat une pluralité de produits. Il permet par exemple la sélection de produits par un utilisateur et l'achat de produits sélectionnés. L'adresse ADS est l'adresse d'une des pages du site SW, par exemple une page d'accueil. La requête envoyée est reçue par le module de communication COM du serveur de traitement ST et transmise au module de traitement TT du serveur de traitement ST. Le module de traitement TT du serveur de traitement ST envoie en retour une réponse au terminal T sous la forme d'une page Web. La page web reçue est affichée sur l'écran ECR du terminal T. La page web contient une ou plusieurs icones affichées sur l'écran ECR. Au moins certaines de ces icônes sont associées à un hyperlien et sont sélectionnables par l'utilisateur au moyen de l'interface utilisateur INT du terminal T. La sélection d'une icône provoque l'envoi d'une nouvelle requête contenant l'hyperlien associé à cette icône, via la première liaison Ll, à destination du serveur de traitement ST et la réception par le terminal T d'une nouvelle page web. L'utilisateur U peut ainsi naviguer de page en page dans le site web SW. Lors d'une étape E2, l'utilisateur U souhaitant effectuer une transaction, choisit un ou plusieurs produits Pl, P2...parmi les produits présentés dans les pages du site web SW. Chaque produit est associé à un identifiant de référence du produit. Les identifiants de référence associés aux produits choisis Pl, P2...sont enregistrés dans une mémoire temporaire du serveur de traitement ST. Cette mémoire temporaire est généralement appelée « panier ». Suite à une action de l'utilisateur U pour confirmer le choix des produits Pl, P2..., par exemple en cliquant sur une icône proposant l'achat des produits sélectionnés, le terminal T envoie, lors d'une étape E4, via la première liaison de communication Ll, une demande de validation de la transaction DVA au serveur de traitement ST. La demande de validation DVA est transmise dans une requête web La demande de validation DVA est ici une demande de paiement par terminal mobile. La demande de validation DVA contient un identifiant du terminal T, par exemple le numéro MSISDN (pour « Mobile Station International Subscriber Directory Number »). Le numéro MSISDN d'un terminal mobile est le numéro connu du public, grâce auquel on peut joindre un utilisateur sur son terminal mobile. A titre d'alternative, la demande de validation DVA contient également un identifiant de l'utilisateur, par exemple, un nom ou une référence client. L'étape E4 est suivie d'une étape E6 lors de laquelle le serveur de traitement ST reçoit la demande de validation DVA. A titre d'alternative, l'identifiant MSISDN est inséré dans la demande de validation DVA par une entité du réseau. L'étape E6 est suivie d'une étape E8 lors de laquelle le module de traitement TT du serveur de traitement ST commande l'envoi par le module de communication COM du serveur de traitement ST d'une page web WP1 contenant une demande d'un code de validation. La page web WP1 est transmise via la première liaison de communication Ll. La page WP1 est reçue et affichée par le module d'affichage AFF du terminal T lors d'une étape E10. L'étape E8 d'envoi de la page WP1 est suivie d'une étape E12 lors de laquelle le serveur de traitement ST envoie via un service de messagerie SM2, un message MS2 au terminal T. Le service de messagerie SM2 représente un deuxième service de messagerie. Le service de messagerie SM2 est une messagerie de type SMS (pour « Short Message Service ») et le message MS2 est un message de type SMS. Le message MS2 contient l'adresse AD de la page web WP1. L'adresse AD est par exemple une URL permettant d'accéder à la page WP1. Le message MS2 est envoyé à destination du terminal T par le module d'envoi de messages EVM du serveur de traitement ST. A titre d'alternative, le service de messagerie SM2 est un service de messagerie instantanée ou un service de messagerie de type courrier électronique (ou mail en anglais). A titre d'alternative, l'étape E12 d'envoi du message MS2 est réalisée avant l'étape E8 d'envoi de la page WP1. Le message MS2 est reçu par le module de réception de messages RCM du terminal T lors d'une étape E14. Lors d'une étape E16, le module de traitement TT du serveur de traitement ST enregistre un ou plusieurs paramètres PSES de la session en cours et les transmet au terminal T via la première liaison de communication Ll. Un paramètre PSES de la session est par exemple un identifiant du terminal T, par exemple le MSIDDN ou un identifiant de session attribué à la session en cours par le serveur de traitement ST. Lors d'une étape E20, le serveur de traitement ST enregistre un ou plusieurs paramètres de transaction PTR en association avec un identifiant du terminal T. Un paramètre de transaction PTR est par exemple un identifiant de référence d'un produit sélectionné lors de la transaction en cours. A titre d'alternative, les paramètres de transaction sont enregistrés en association avec un identifiant de l'utilisateur U. Ceci suppose que l'utilisateur U soit identifié au cours de la session en cours, c'est-à-dire pour la transaction. Lors d'une étape E22, le serveur de traitement ST déclenche un compteur CPT (ou « timer » en anglais) permettant de compter ou de décompter un temps T à partir d'un instant où le compteur est déclenché. Le compteur CPT est par exemple déclenché suite à l'étape E20. A titre d'alternative, le compteur CPT est déclenché dès la réception de la demande DVA ou encore dès l'envoi de la page WP1. Lors d'une étape E24, le deuxième module de communication COM2 du terminal T établit une deuxième liaison de communication L2 avec le serveur de gestion SG. La deuxième liaison L2 est établie suite à la saisie par l'utilisateur U, par exemple au moyen du clavier du terminal T, d'un code USSD (pour « Unstructured Supplementary Service Data ») permettant l' accès au serveur de gestion SG. Le code USSD saisi est par exemple le code « #140# » qui permet d'accéder au service « Orange Money » offert par France Télécom Orange. Le service « Orange Money », déployé dans plusieurs pays émergents, permet à des populations non bancarisées d'effectuer des opérations financières au moyen de leur terminal mobile. Des utilisateurs de terminaux mobiles qui souscrivent à ce service se voient attribuer un compte associé, sur lequel ils peuvent effectuer différentes opérations. La deuxième liaison L2 est un canal USSD. Le canal USSD est une fonctionnalité de base du standard GSM (pour « Global System for Mobile communications »). Il permet de véhiculer des informations au-dessus des canaux de signalisation du réseau GSM. Le canal USSD ne nécessite qu'un accès GSM de base et les services qui empruntent ce canal sont accessibles à partir de n'importe quel terminal mobile, sans adjonction de code spécifique sur le terminal L'avantage de ce canal est d'être toujours disponible et très réactif. Il est également accessible depuis les canaux de type GPRS ou UMTS. L'établissement de la deuxième liaison L2 provoque la rupture de la première liaison Ll. L'envoi du code USSD « #140# » provoque l'ouverture d'une session USSD interactive entre le terminal T et le serveur de gestion SG. Elle provoque notamment la réception et l'affichage sur l'écran ECR du terminal T d'un message textuel proposant les fonctionnalités du service « Orange Money » et invitant l'utilisateur à saisir un choix, ou à fournir une information, par exemple un code d'identification ou code PIN («pour « Personal Identification Number »). Par exemple, l'envoi du code USSD « #140# » provoque l'envoi d'un menu proposant plusieurs options pour le service, parmi lesquelles une option pour obtenir un code de validation. L'étape E24 est indifféremment réalisée avant ou après la réception du message MS2 de type SMS transmis lors de l'étape E12. Lors d'une étape E26, l'utilisateur U choisit, dans le menu reçu par le terminal T, l'option permettant d'obtenir un code de validation, valide son choix et le terminal T envoie via le deuxième module de communication COM2 et la deuxième liaison de communication L2, une demande DId de code de validation. La demande DId de code de validation est dans le mode de réalisation décrit, une valeur saisie par l'utilisateur. La valeur saisie correspond à la valeur associée à la fonction de demande de code de validation dans le menu affiché sur l'écran ECR du terminal T. La demande de code de validation DId est reçue par le serveur de gestion SG lors d'une étape E28. Dans le mode de réalisation décrit, l'étape E28 est suivie d'une étape E30 lors de la laquelle le serveur de gestion SG demande un code d'identification au terminal T via la deuxième liaison de communication L2 et reçoit en retour un code d'identification CC de l'utilisateur U. Le serveur de gestion SG vérifie alors si le code d'identification reçu CC correspond au code d'identification enregistré préalablement en association avec l'identifiant MSISDN du terminal T. A titre d'alternative, l'étape E30 n'est pas réalisée. Dans le cas où le code d'identification CC ne correspond pas au code d'identification enregistré préalablement, le processus s'arrête. Dans le cas où le code d'identification CC correspond au code d'identification enregistré préalablement, le serveur de gestion SG génère et envoie lors d'une étape E32, via un service de messagerie SM1, un message MS1 au terminal T. Le service de messagerie SM1 représente un premier service de messagerie. Le service de messagerie SM1 est un service de messagerie de type SMS et le message MS1 est un message de type SMS. A titre d'alternative, le service de messagerie SM1 est un service de messagerie instantanée ou un service de messagerie de type courrier électronique. Le message MS1 est un SMS contenant un code de validation IdS généré par le serveur de gestion SG. Le code de validation IdS est par exemple un mot de passe du type « One Time Password ». Le message MS1 est reçu par le module de réception de messages RCM du terminal T lors d'une étape E34. Lors d'une étape E36, le terminal T rétablit la première liaison de communication Ll en envoyant une requête RQ. La requête RQ contient l'adresse AD reçue dans le message MS2 de type SMS reçu lors de l'étape E14. L'envoi de la requête RQ permet de demander le rétablissement de la session en cours lors de la rupture de la première liaison de communication Ll. Plus précisément, l'utilisateur recopie, par exemple en utilisant une fonction « copier/coller », l'adresse AD reçue dans le message MS2, dans une fenêtre spécifique du navigateur NV. Cette action provoque l'envoi par le navigateur NV d'une requête de la page web PW1. Dans le mode de réalisation décrit, la requête comprend également un ou plusieurs des paramètres de session PSES reçus lors de l'étape E18. L'étape E36 est suivie d'une étape E38 lors de laquelle le serveur de traitement ST, ayant reçu la requête RQ, vérifie si le temps T écoulé depuis le déclenchement du compteur CPT est inférieur à une valeur de seuil VS prédéfinie. Si le temps T écoulé depuis le déclenchement du compteur CPT est supérieur à la valeur de seuil VS prédéfinie, le processus s'arrête. Par exemple, le serveur de traitement ST transmet au terminal T, via la première liaison de communication Ll, une page indiquant que le délai accordé pour saisir un code de validation est expiré et proposant un retour à la page d'accueil du site web SW. Si le temps T écoulé depuis le déclenchement du compteur CPT est inférieur ou égal à la valeur de seuil VS prédéfinie, le serveur de traitement ST récupère les paramètres de transaction PTR enregistrés en association avec un identifiant du terminal T lors de l'étape E20 et transmet en réponse à la requête RQ, via la première liaison Ll, la page web WP1 complétée des paramètres de transaction PTR (étape E40). A titre d'alternative, les paramètres de transaction PTR sont transmis, par exemple sous forme encodée, au terminal T avec les paramètres de session PSES lors de l'étape E16. Les paramètres de transaction PTR sont ensuite reçus dans la requête RQ et utilisés par le serveur de traitement ST pour compléter la page WP1. Le terminal T reçoit lors d'une étape E42, la page web WP1 telle que reçue lors de l'étape E10. L'utilisateur retrouve ainsi la session de communication avec le serveur de traitement ST telle qu'elle était au moment de la coupure de la liaison de communication Ll. Si la deuxième liaison de communication L2 n'a pas été coupée par l'utilisateur, le rétablissement de la première liaison de communication Ll provoque la rupture de la deuxième liaison de communication L2. L'étape E42 est suivie d'une étape E44 lors de laquelle l'utilisateur U saisit au moyen de l'interface utilisateur INT, le code de validation IdS reçu dans le message MS1 de type SMS puis il valide la saisie, provoquant ainsi l'envoi du code de validation IdS à destination du serveur de traitement ST, via la première liaison de communication Ll. Le code de validation IdS est reçu par le serveur de traitement ST lors d'une étape E46. Grâce au code de validation IdS reçu et au numéro MSISDN du terminal T, le serveur de traitement ST peut s'adresser au serveur de gestion SG pour obtenir le transfert d'une somme d'un compte de l'utilisateur U vers un compte associé au site web SW. Les étapes E4, E10, E14, E18, E24, E26, E34, E36, E42 et E44 mises en oeuvre par le terminal T, représentent les étapes du procédé de validation d'une transaction. Les étapes E6, E8, E12, E16, E20, E22, E38, E40 et E46 mises en oeuvre par le serveur de traitement ST, représentent les étapes du procédé de traitement d'une transaction. 15 REVENDICATIONS1. Procédé de validation d'une transaction entre un terminal (T) d'un utilisateur (U) et un premier serveur (ST) aptes à communiquer entre eux via une première liaison de communication (L1), le procédé comprenant des étapes suivantes, mises en oeuvre par ledit terminal (T) : - réception (E10) via la première liaison(L1), d'une demande (WP1) d'un code de validation pour ladite transaction ; - établissement (E24) d'une deuxième liaison de communication (L2) avec un deuxième serveur (SG), ledit établissement provoquant une rupture de la première liaison (L1) ; - transmission (E26) via ladite deuxième liaison de communication (L2), d'une requête (DId) de code de validation ; - réception (E34), suite à la transmission de ladite requête (DId), via un premier service de messagerie (SM1), d'un message (MS1) contenant un code de validation (IdS) en provenance dudit deuxième serveur (SG); - réception (E14), via un deuxième service de messagerie (SM2), d'un message (MS2) contenant une adresse (AD) associée au premier serveur (ST); - rétablissement (E36) de la première liaison (L1) au moyen de ladite adresse reçue (AD), et - transmission (E44), via ladite première liaison rétablie (L1), dudit code de validation reçu (IdS). 2. Procédé de validation selon la revendication 1 dans lequel le premier et/ou le deuxième service de messagerie sont du type SMS (pour « Short Message Service »). 3. Procédé de validation selon l'une des revendications précédentes dans lequel ladite première liaison (L1) est une liaison de type Web. 4. Procédé de validation selon l'une des revendications précédentes dans lequel la demande de code de validation reçue est une page web (WP1) et dans lequel ladite adresse reçue (AD) est l'adresse de ladite page. 5. Procédé de validation selon l'une des revendications précédentes dans lequel ladite deuxième liaison (L2) est une liaison de type USSD (pour « Unstructured Supplementary Service Data »). 6. Procédé de validation selon l'une des revendications précédentes dans lequel ledit code de validation est un mot de passe de type « One Time Password ». 7. Procédé de traitement d'une transaction entre un terminal (T) d'un utilisateur (U) et un premier serveur (ST) aptes à communiquer entre eux via une première liaison de communication (L1), le procédé comprenant des étapes suivantes, mises en oeuvre par ledit premier serveur (ST) : - transmission (E8) via la première liaison de communication (L1), d'une demande (WP1) d'un code de validation pour ladite transaction; - transmission (E12) à destination dudit terminal (T), via un service de messagerie (SM2), d'un message (MS2) contenant une adresse (AD) associée au premier serveur (ST); - suite à une coupure suivie d'un rétablissement de ladite première liaison (L1) par ledit terminal (T) au moyen de ladite adresse (AD), réception (E46), via ladite première liaison rétablie( L1), d'un code de validation (IdS), ledit code de validation (IdS) étant été transmis audit terminal (T) par un deuxième serveur de gestion (SG). 8. Procédé de traitement selon la revendication 7 caractérisé en ce qu'il comporte, suite audit rétablissement de la première liaison (L1), une étape de retransmission (E40) via la première liaison de communication (L1), de ladite demande (WP1) d'un code de validation et dans lequel le code de validation (IdS) est reçu dans une réponse à ladite demande retransmise. 9. Procédé de traitement selon la revendication 8 dans lequel ladite demande n'est pas retransmise si le délai calculé entre la transmission de ladite demande et le rétablissement de la première liaison est supérieur à une valeur de seuil prédéterminé 10. Serveur de traitement (ST) apte à communiquer avec un terminal (T) via une première liaison de communication (L1), ledit serveur comprenant: - un module de transmission (EVM), via un service de messagerie (SM2), à destination dudit terminal, d'un message (MS2) contenant une adresse (AD) associée audit serveur (ST); - un module de communication (COM) adapté pour transmettre au terminal (T), via ladite première liaison de communication (L1), une demande (WP1) d'un code de validation pour une transaction en cours et pour recevoir suite à une coupure suivie d'un rétablissement de ladite première liaison par ledit terminal (T) au moyen de ladite adresse (AD), via laditepremière liaison rétablie (L1), un code de validation (IdS), ledit code de validation étant été transmis audit terminal par un deuxième serveur de gestion (SG).5