Le domaine technique de l'invention est celui des services de télécommunications et concerne plus particulièrement les services de transactions. Plus précisément, la présente invention concerne les cartes virtuelles dynamiques (CVD), systèmes de transaction selon lequel un client a la possibilité de télécharger de son PC via une applet sécurisée une carte virtuelle dynamique, permettant l'achat de biens en vente à distance par saisie des paramètres de cette carte. L'utilisation de la carte virtuelle pour te paiement est complètement transparente pour le marchand qui ne voit passer que les paramètres d'une carte « classique » (aucun kit spécifique n'est à implémenter par le marchand). La récupération de CVD via SMS, SVI, WAP et USSD est également possible. Désignée aussi bien par les termes génériques « Carte Virtuelle Dynamique (CVD) », « Carte Virtuelle », « e-Card » ou le terme commercial « e-Carte Bleue », la carte est qualifiée de virtuelle, ce qui signifie ici non physique. Cette appellation désigne non seulement un numéro de carte bancaire virtuelle à 16 chiffres dont les caractéristiques vérifient les mêmes propriétés notamment cryptographiques qu'un numéro de carte bancaire physique, mais également les paramètres associés à ce numéro : nom, prénom, date de fin de validité et numéro de CW (Carte Vérification Value). Ce groupe de paramètres peut être généré à distance par sollicitation et authentification préalable de l'utilisateur par tous les canaux liés à la vente à distance (Serveur vocal, SMS, WAP, Internet et éventuellement Minitel voire courrier postal). Ce « Numéro de carte virtuelle » n'est valable qu'une seule fois pour un montant fixé au moment du téléchargement de cette carte. Une telle carte virtuelle dynamique est délivrée par un serveur de carte virtuelle dynamique ou SCVD, c'est à dire un serveur habilité à délivrer des numéros de carte virtuelle. Ces serveurs sont soit liés à des organismes bancaires techniquement et contractuellement, soit directement hébergés par ces organismes bancaires. Un numéro de carte virtuelle est obtenu par le client via son terminal client, celui-ci pouvant être un terminal mobile, un PDA, un téléphone fixe, etc.. Ainsi le document de brevet ORBISCOM WO 9949424 fait état de la possibilité pour un utilisateur de télécharger depuis son PC via une applet sécurisée une carte virtuelle dynamique, permettant l'achat de biens en vente à distance par saisie des paramètres de cette carte. L'utilisation de la carte virtuelle pour le paiement est complètement transparente pour le marchand qui ne voit passer que les paramètres d'une carte « classique » (aucun kit spécifique n'est à implémenter par le marchand). L'utilisation habituelle de CVD en mobilité n'est pas pratique en raison de plusieurs sessions de browsing à gérer. L'invention vise à apporter une amélioration ergonomique, et notamment à simplifier l'utilisation d'une CVD auprès d'un marchand pour des utilisateurs en mobilité (achat via PDA/téléphone mobile/téléphone fixe). En outre, certains marchands ne sont pas équipés de lecteurs de cartes bancaires physiques, et ne peuvent non plus faire l'objet d'un paiement par CVD. L'invention permet à ces commerçants (professionnels en mobilité) d'accepter les CVD. Enfin, une conséquence de l'invention est qu'une CVD puisse être aisément utilisée pour recharger un compte prépayé chez un marchand donné (en remplacement d'une carte prépayée dans le cas d'un opérateur de téléphonie). L'utilisation d'un tel numéro de CVD garantit au marchand (ou opérateur) que le client est dûment enregistré et identifié auprès de l'organisme habilité à délivrer des CVD. Le risque de fraude est quasi-nul. Ces buts sont atteints selon l'invention grâce à un procédé de transaction entre un client et un serveur de réception de parement par carte de paiement virtuelle, comprenant une étape de fourniture d'une carte de paiement virtuelle au serveur de réception de paiement, comprenant en outre l'étape préliminaire de prise en compte de coordonnées pré-étabiies de la part du client à destination d'un serveur d'émission de cartes virtuelles en vue de rémission d'une carte virtuelle, caractérisé en ce qu'il comprend l'étape consistant à utiliser une liaison directe entre le serveur de cartes virtuelles et le serveur de réception de paiement pour fournir à ce serveur la carte virtuelle émise par le serveur de cartes virtuelles. On propose également selon l'invention un dispositif de transaction comprenant un serveur de réception de paiement, un serveur émetteur de cartes de paiement virtuelles, le serveur de cartes virtuelles étant apte à fournir une carte de paiement virtuelle à la réception de coordonnées de client préétablies et le serveur de réception de paiement étant apte à entériner un paiement en échange de la réception d'une carte virtuelle, le dispositif étant caractérisé en ce qu'il comprend en outre des moyens formant une liaison directe entre le serveur de réception de paiement et le serveur de cartes virtuelles, le serveur de cartes virtuelles incorporant des moyens d'émission de la carte virtuelle sur ce lien direct à destination du serveur de réception de paiement. D'autres buts, caractéristiques et avantages de l'invention apparaîtront à la lecture de la description détaillée qui va suivre, faite en référence aux figures annexées sur lesquelles : - la figure 1 est une vue schématisée illustrant une première approche selon l'invention ; - la figure 2 illustre une première variante d'ensemble fonctionnel conforme à l'invention ; - la figure 3 illustre une seconde variante d'ensemble fonctionnel conforme à l'invention ; - la figure 4 est une vue schématisée illustrant une seconde approche selon l'invention ; - la figure 5 illustre une troisième variante d'ensemble fonctionnel conforme à l'invention ; - la figure 6 illustre une quatrième variante d'ensemble fonctionnel conforme à l'invention. Le premier mode d© réalisation de l'invention concerne le rechargement d'un compte prépayé, via tout canal de vente à distance (SVI Serveur Vocal Interactif, WAP, WEB, USSD, SMS, etc.), au moyen d'une carte virtuelle à usage unique. L'invention permet implicitement au marchand d'être assuré par un tiers de confiance (SCVD) que le client est enregistré auprès de ce tiers et donc que les risques de fraude autour du numéro de carte utilisé pour le paiement sont quasi nuls. La garantie de paiement est envisageable. Ce mode de réalisation concerne également le rechargement de tous types de comptes prépayés, en particulier les comptes prépayés téléphoniques. Sur les figures 1 et 2, on a représenté un terminal du client sous la référence 10. Le terminal du client est utilisé comme un terminal classique (mobile, PDA, téléphone fixe...). Les fonctions WAP, SMS, USSD sont préférentieliement présentes. Un SCVD (serveur de cartes virtuelles dynamiques), référencé 20, est ici prévu apte, après une authentification du client à générer à la demande du client un numéro de CVD qui est transmis au marchand. Un serveur 30 du marchand joue le rôle de réception du paiement, comme on le décrira par la suite, ce serveur sert d'intermédiaire entre les terminaux mobiles des clients, le SCVD et les banques, et gère les comptes prépayés des clients. La référence 30 vise ici le serveur marchand qui comprend un serveur de rechargement 35. Un système bancaire 40 assure la compensation entre les différents acteurs (clients, marchands) pour débiter/créditer les comptes. En outre, une API 50 assure les dialogues entre le serveur 30 de rechargement et le SCVD 20, dialogues normalisés par cette APl 50. L'API définit les dialogues entre le ou les serveurs de marchands, tels que le serveur 30 (comprenant le serveur de rechargement 35) et Ie ou les SCVD tels que le SCVD 20. Préalablement, Ie client s'est inscrit au service « carte virtuelle » via sa banque 40 lui permettant tout achat en vente à distance et peut ainsi accéder à ce service via son terminal client 10. Le serveur du marchand 30 va proposer comme moyen de paiement le paiement par carte bancaire virtuelle. En sélectionnant ce moyen de paiement le client 10 va être invité par le marchand 30 à saisir un code identifiant et son mot de passe. Ce code 5 va être transmis en background au serveur 20 qui, après authentification du client 10, va calculer un numéro de carte virtuelle pour ce client et le transmettre au serveur marchand 30. Le serveur marchand 30 crédite alors le compte prépayé du client du montant associé à la carte bancaire virtuelle et traite le numéro de carte O virtuelle comme n'importe quel numéro de carte bancaire en vente à distance. Pour cela, ies étapes décrites maintenant en détail vont être mises en œuvre par l'ensemble représenté à Ia figure 2. En référence à la figure 2, un client, à partir de son terminal 10 5 (mobile, PDA, téléphone fixe, ...), désire utiliser le système de CVD (serveur 20) pour créditer un système de compte prépayé géré par le site marchand (serveur marchand 30). Pour cela, le client 10 appelle le serveur marchand 30 qui est accrédité auprès du serveur SCVD 20. O II accède ainsi au serveur 35 (étape 1) de rechargement du marchand et sélectionne l'option lui permettant de recharger son compte prépayé par CVD. Puis il saisit ses paramètres d'authentification auprès du serveur de rechargement 35 (étape 2). 5 Puis le serveur de rechargement 35 transmet les paramètres d'authentification au SCVD 20 (étape 3) et le SCVD (étape 4) authentifie le client 10. Le serveur de rechargement 35 (étape 5) propose alors différents montants pour le rechargement O Le client 10 sélectionne alors un montant (étape 6). Le serveur de rechargement 35 fait alors une demande de CVD au SCVD 20 pour le montant choisi (étape 7). Ensuite le SCVD 20 calcule un numéro de CVD et le transmet au serveur de rechargement 35 (étape 8). Le serveur de rechargement 35 demande alors le crédit du compte prépayé de l'utilisateur 10 pour le montant choisi (étape 9). Le crédit est ensuite confirmé (étape 10). Le serveur de rechargement 35 stocke alors le numéro de CVD pour une future compensation (étape 11). Puis le serveur de rechargement 35 confirme à ('utilisateur 10 te rechargement du compte, le montant du rechargement et ie numéro de CVD utilisé, par mini messages (étape 12). En fin de journée, le serveur de rechargement marchand 35 envoie ses fichiers de transactions vers Ie système bancaire 40 ce qui déclenche les procédures de compensation (étape 13). Les dialogues repérés dans les références 3, 4, 7, 8 sont préférentiellement normalisés pour avoir toujours la même interface entre les différents serveurs de rechargement 35 et les SCVD 20. Ce mode de réalisation modifie donc le système de paiement de façon à pouvoir récupérer un numéro de carte bancaire virtuelle pour recharger un compte prépayé, le tout dans une unique session. Les cartes prépayées actuellement existantes sont souvent matérialisées par un support physique. De plus les marchands, pour distribuer ces cartes, sont obligés de recourir à un réseau de vendeurs rémunérés. Dans ce mode de réalisation, le support n'existe plus et rémetteur de la carte prépayée n'a plus de royalties à verser, ce qui est un avantage supplémentaire. Selon une autre variante, telle qu'illustrée à la figure 3, le client 10 accède au serveur de rechargement 35 du système marchand 30 et sélectionne l'option lui permettant de recharger son compte prépayé avec Li ne CVD (étape 1). Puis le client 10 est redirigé, par le serveur de rechargement 35, vers le SCVD 20 pour authentification sans intermédiaire (étape 2). Le SCVD 20 authentifie alors le client 10 puis redirige le client 10 vers le serveur de rechargement 35 en précisant que le client est authentifié pour la session (étape 3). Ensuite, des étapes similaires à celles décrites précédemment sont mises en oeuvre. Le serveur de rechargement 35 propose différents montants pour le rechargement (étape 4). L 'utilisateur 10 sélectionne alors un montant (étape 5). Puis le serveur de rechargement 35 fait une demande de CVD au SCVD pour le montant choisi (étape 6). Alors le SCVD 20 calcule un numéro de CVD et le transmet au serveur de rechargement 35 (étape 7). Le serveur de rechargement 35 demande alors le crédit du compte prépayé de l'utilisateur 10 pour le montant choisi Retape 8). Le crédit est ensuite confirmé (étape 9). Le serveur de rechargement stocke ensuite le numéro de CVD pour une future compensation (étape 10). Le serveur de rechargement 35 confirme ensuite à l'utilisateur 10 Ie rechargement cfu compte, le montant du rechargement et le numéro de CVD utilisé, par mini-messages (étape 11). Et en fin de journée, le serveur de rechargement marchand 35 envoie ses fich iers de transaction vers le système bancaire 40, ce qui déclenche les procédures de compensation (étape 12). Les dialogues repérés sous les références 2, 3, 6, 7 sont préférentiellement normalisés pour avoir toujours la même interface entre les différents serveurs de rechargement 35 et les SCVD 2O. Dans les deux cas exposés ci-avant, le serveur marchand 30 est interface au SCVD 20 par une interface spécifique 50 (API ). En outre, le client est inscrit au service « carte virtuelle » via sa banque et peut accéder à ce service via son terminal mobile 10 ou n'importe quel te rminal d'accès distant (PC1 PDA etc...). Après autfientification du client 10, Ie SCVD 20 calcule un numéro de CVD qu'il transmet au marchand 30 grâce à cette API. Les opérateurs ou marchands recherchant une solution sécurisée de rechargement à distance, en particulier via terminal mobile, se trouvent avantageusement aidés par un tel système. En effet, les utilisateurs étant d'une part préalablement enregistrés auprès de leur banque pour pouvoir utiliser le service « carte virtuelle » et d'autre part authentifiés auprès du SCVD, les risques de fraude liés au numéro de carte utilisé sont quasiment nuis. On décrira maintenant un autre mode de réalisation (figures 4 et 5), toujours conforme à l'invention. Ce mode de réalisation vise les systèmes nécessitant un paiement par carte bancaire certifié tels que l'achat à distance via les canaux liés au e-commerce, mais aussi plus spécifiquement le paiement de proximité chez les marchands ne disposant pas de terminal de paiement bancaire (médecins à domicile, taxis, ...). Les marchands ne disposant pas de terminaux de paiement, en particulier les professionnels itinérants (taxis, médecins à domicile, livreurs, etc), sont donc particulièrement concernés par ce mode de réalisation. Le système est maintenant organisé de la façon suivante : le marchand possède un terminal mobile (mobile, PDA, téléphone fixe, ...) lui permettant de dialoguer avec un gestionnaire de marchands en utilisant les canaux classiques (WAP, SMS, USSD ou Vocal). Le serveur gestion naire de marchands 36 est un serveur accrédité par les marchands pour servir d'intermédiaire entre les terminaux mobiles des marchands, le SCVD et les banques. Il gère le dialogue entre lui et le SCVD pour récupérer le numéro de CVD, et il gère également le dialogue entre lui et le terminal du marchand pour avoir l'acceptation du marchand. Le terminal du marchand 37 est utilisé comme un terminal classique (mobile, PDA, téléphone fixe). Une API 50 assure et normalise les dialogues entre le ou les serveurs (sites) marchands ou les gestionnaires de marchands et le SCVD. Dans ce mode de réalisation, on retrouve un terminal client 10, un SCVD 20, un marchand 30, un système bancaire 40, une API 50. Là encore, un interfaçage du serveur marchand avec le SCVD est proposé. Là encore, le client est inscrit au service « carte virtuelle » via sa banque 40 et peut accéder à ce service via son terminai client 10. Lors de l'acte de paiement de proximité, le client 10 se connecte cette fois au SCVD 20 avec son terminal client 10, s'authentifie, saisit le montant de la transaction. Le gestionnaire de marchands peut également récupérer les paramètres pour fauthentification et l'obtention de la CVD pour le montant du bien à acheter et les transmettre au SCVD 20. Le SCVD 20 calcule alors un numéro de CVD, le transmet au serveur gestionnaire de marchands 36 auquel est inscrit le marchand 30 et le serveur 36 gestionnaire de marchands enregistre les caractéristiques de la transaction pour une compensation ultérieure. Le SCVD 20 acquitte alors par mini-message le client 10 sur la délivrance du numéro de CVD et sur ie montant associé. Le gestionnaire de marchands 36 acquitte, lui, par mini¬ message le marchand 30 sur la transaction carte bancaire. Plus précisément, les étapes suivantes sont mises en œuvre (figure 5). D'abord le client 10 se connecte au SCVD 20 pour demander un numéro de CVD (étape 1). Puis le SCVD 20 demande au client 10 de s'authentifier (étape 2). Ensuite, le client 10 saisit un code d'accès alphanumérique (étape 3). Le SCVD 20 demande alors au client de saisir le montant de la transaction, le code du marchand puis calcule un numéro de CVD pour le montant saisi (étape 4). Le SCVD 20 transmet ensuite le numéro de CVD au gestionnaire de marchands 36 dont il retrouve l'adresse grâce au code marchand (étape 5). Puis le gestionnaire de marchands 36 envoie une demande de confirmation de la transaction au marchand 30 (terminal 37) grâce à une base MSISDN/code marchand (étape 6). Le marchand 30 valide alors la transaction (étape 7). Puis le gestionnaire de marchands 36 confirme la transaction au SCVD et stocke le numéro de CVD pour la transaction (étape 8). Le SCVD 20 envoie ensuite au client 10 un mini-message de confirmation de la génération du numéro de CVD et de la transaction (étape 9). En fin de journée, le gestionnaire de marchands 36 envoie ses fichiers de transactions vers le système bancaire 40, ce qui déclenche la procédure de compensation (étape 1 1). Les dialogues repérés par les références 5 et 8 sont préférentiellement normalisés pour avoir toujours la même interface entre les différents sites gestionnaires de marchands et les SCVD. On notera que dans une variante correspondant à une vente à distance, l'exemple qui vient d'être décrit est également valable, dans la mesure où l'intermédiaire est remplacé par un serveur marchand, qui joue également le rôle d'interface de choix de produits. L'utilisation d'un gestionnaire de marchands décharge là aussi la tâche de gestion du paiement d'un tel serveur marchand. En variante, on met en œuvre les étapes suivantes {figure 6) : D'abord, le client 10 choisit de payer un bien par carte virtuelle (étape 1). Puis le client 10 transmet ses paramètres d'authentification, le code du marchand, le montant de la transaction auprès du gestionnaire de marchands 36 (étape 2). Puis, après un contrôle de la base MS ISDN/Code marchand, c'est le gestionnaire de marchands 36 qui transmet au SCVD 20 les paramètres d'authentification (étape 3). Le SCVD 20 authentifie ensuite le client 10 (étape 4). Le gestionnaire de marchands 36 fait alors une demande de CVD au SCVD pour le montant du bien (étape 5). Puis le SCVD 20 calcule un numéro de CVD et le communique au gestionnaire de marchands 36 (étape 6). A ce stade, le gestionnaire de marchands 36 envoie une demande de confirmation de la transaction au marchand 30 sur son terminal (37) (étape 7). Le marchand 30 valide la transaction (étape 8). Le gestionnaire de marchands 36 stocke alors le numéro de CVD, le code marchand, pour une future compensation <étape 9), Puis le gestionnaire de marchands 36 confirme au client 10 la livraison du bien, le montant et le numéro de CVD utilisé par mini-message (étape 10). En fin de journée, le gestionnaire de marchands 36 envoie ses fichiers de transactions vers le système bancaire 40, ce qui déclenche la procédure de compensation (étape 11). Enfin, la banque 40 crédite le compte marcrtand et débite le compte client (étape 12). Les dialogues repérés aux références 3, 4, 5, 6 sont préférentiellement normalisés pour avoir toujours Ia même interface entre les différents sites gestionnaires de marchands et i&s SCVD. Cet exemple ci-dessus fournit l'avantage d'u ne fiabilité de paiement élevée. En outre if permet au marchand de déléguer à un gestionnaire de marchands de dialogue avec le SCVD, une APl définissant alors avantageusement les dialogues entre les sites marchands ou les serveurs gestionnaires de marchands et les SCVD. Contrairement à certains des cas décrits ci-avant où les clients et les marchands sont en reiation directe, un gestionnaire de marchand s'occupe avantageusement ici des liaisons avec le serveur SCVD et les banques. Cet exemple s'appuie sur le fait que les clients et les marchands délèguent à un mandataire les liaisons avec le serveur SCVD et les banques. Les exemples décrits permettent donc de pallier au fait que les terminaux actuels ne peuvent pas gérer deux sessions différentes avec une ergonomie satisfaisante (ici la récupération du numéro de CVD et le paiement).