FR 2814622 A1 20020329 FR 0012228 A 20000926 Procédé de transaction en ligne comportant une pluralité d'étapes d'échanges de messages entre un émetteur, un destinataire et un serveur de validation. La présente invention concerne le domaine des transactions en ligne, notamment mais non exclusivement pour le paiement en ligne. Elle concerne plus particulièrement un procédé de transaction en ligne comportant une pluralité d'étapes d'échanges de messages entre un émetteur, un marchand et un serveur de validation On connaît dans l'état de la technique de nombreuses solutions de paiement en ligne. Ces solutions nécessitent : soit des programmes complexes de chiffrement avec des algorithmes toujours vulnérables et de durée de vie limitée, soit des matériels spécifiques encore peu répandus au plan mondial (lecteurs de carte sur PC), soit l'installation sur chaque poste utilisateur de logiciels spécifiques dont le paramétrage et la gestion des versions ne sont pas aisés et qui risquent de perturber le fonctionnement de logiciels précédemment installés, soit une combinaison des éléments ci-dessus. On connaît également la solution la plus répandue, fondée sur la communication du numéro de carte de crédit, au cours de sessions parfois chiffrées avec SSL et rarement authentifiées par des certificats. Celles-ci donnent lieu à de nombreuses fraudes et un des objets du procédé présenté est de se substituer partiellement au paiement à l'aide de cartes de crédit. On connaît également des solutions de paiement avec des cartes prépayées, grâce auxquelles le client de la transaction peut procéder à un paiement par la transmission d'une clé figurant sur une carte. En particulier, le brevet FR2739322 associe à des clés masquées figurant sur le coupon, un montant fixé à l'avance. L'objet de la présente invention est de proposer un procédé de transaction en ligne facile à mettre en oeuvre, ne nécessitant aucune modification du terminal du client, garantissant des niveaux de sécurité adaptés aux différents besoins et permettant de certifier tout ou partie des éléments de la transaction. Typiquement, le système est fondé sur un coupon physique associé à un compte anonyme prépayé, distribué par les commerces de détail et débité avec l'autorisation d'un serveur de validation. L'intérêt du coupon physique est son caractère anonyme et la conservation des secrets à l'extérieur du monde informatique. Sur chaque coupon, des clés, variables à chaque transaction permettent : l'identification des parties, - la validation des transactions, le chiffrage en émission des informations, le déchiffrage en réception des informations, le choix du type de transaction à réaliser. Le système comporte trois options pouvant être soit indépendantes soit combinées : - avec risc sque à u - avec risque limitation de risque à un montant maximum choisi par l'utilisateur à chaque transaction ; - avec validation directe où les transactions sont validées par l'utilisateur au niveau d'un système central ; avec objet certifié ou tout ou partie de l'objet de la transaction est échangé de façon chiffrée avec le serveur central à l'aide de tables de codage spécifiques. Coupons avec limitation de risque Le premier mécanisme est analogue au mode de paiement actuellement et durablement le plus répandu sur Internet, celui par carte de crédit, avec des échanges entre marchands, clients et serveur (s) de validation sécurisés par un algorithme asymétrique (SSL, etc. ) avec certificats. Il présente cependant une meilleure sécurité que celui-ci du fait du prépaiement et du mécanisme d'accord client explicité ci-dessous. Le système se distingue du paiement par carte de crédit en ce le risque client est limité. Chaque paiement requiert la soumission du numéro du coupon et d'un code de transaction. Ce dernier, différent pour chaque transaction, est matérialisé par un mot de passe présent sur le coupon. Le coupon comporte ainsi une série de mots de passe, associés chacun à une et une seule transaction. De plus, un débit maximal (5 F, 50 F, 100 F, etc. ) est associé sur le coupon à chaque code de transaction. Le risque est donc limité pour chaque transaction au montant maximal associé au code de transaction. Le système est résistant aux attaques systématiques car la probabilité de génération d'un numéro de coupon valide est très faible et parce que l'usage du seul numéro de coupon est sans utilité. Il faut en effet disposer en plus du code de transaction. Or un nombre défini de tentatives infructueuses peut bloquer le coupon. Coupons avec limitation de risque et validation direct Le mécanisme précédent peut être enrichi d'une validation de la transaction par le client sur un site central (ou un ensemble distribué de serveur) lors d'une session directe, sans tiers intermédiaire, entre le client et le serveur. Le client dispose d'une boîte aux lettres sur ce site, différente pour chaque coupon, où sont reçus des marchands les données de chaque transaction. Le client les consulte et s'il est d'accord, les valide. Le client accède à sa boîte aux lettres par un numéro de privé, présent sur le coupon et différent du numéro de coupon présenté aux commerçants. Il valide-ou invalide-chaque transaction à l'aide d'un mot de passe présent sur le coupon et variable à chaque consultation. Pour les échanges de biens physiques, le client dispose sur le site central du délai de rétractation légal. Pour les ventes de biens immatériels, le client reçoit dans sa boîte aux lettres-s'il valide la transaction-un identifiant et un mot de passe qui lui donneront accès, au service du marchand. Ce système est résistant aux attaques systématiques du fait de l'existence de deux numéros de coupon, l'un utilisé pour le paiement du marchand et l'autre utilisé pour la validation de la transaction sur le site central. Aucun lien n'existe entre les deux numéros ailleurs qu'au centre de validation et que sur le coupon physique. A la différence du premier procédé qui ne certifie que l'accord du client pour un paiement d'une certaine valeur, ce système certifie l'objet de la transaction entre le client et le marchand (le produit, le prix et les autres conditions). Coupons avec table de codage Un autre mécanisme de certification de l'objet concerne l'usage de tables de codage/décodage. Ces tables, présentes à la fois sur le coupon et dans le serveur de validation, permettent de coder-de façon triviale et accessible à toute personne alphabétisée-l'information échangée entre le client et le serveur de validation, éventuellement via le marchand. Un montant (e. g. 124 F) est chiffré par le client à l'aide d'une table de codage (e. g. l- > h, 2-p, 4-7t), associé au montant en clair-ou à tout autre élément de la transaction-et transmis au centre de validation, via le marchand. La caractéristique des tables est leur génération aléatoire. Aucun programme d'un tiers malveillant ne peut déchiffrer le codage parce que celui-ci est réalisé sans algorithme. Le centre de validation confronte les informations en clair et chiffrées et s'assure ainsi de l'intégrité du montant et de l'authentification du coupon. Les informations chiffrées de la sorte peuvent être de toute nature et peuvent porter par exemple sur un montant et/ou un pari et/ou une référence de commande. Ce système permet de remplacer la valeur maximale de la première option par une valeur ou des informations exactes et certifiées. EXPOSE De façon générale, ce procédé est fondé sur des coupons, porteurs d'un identifiant IC et d'un ensemble de numéros de transaction NTi associés chacun à un code (ou clé) de transaction CT, valant signature. Chaque numéro de transaction peut être aussi associé à une table de codage/décodage TCi permettant de chiffrer et donc de certifier des éléments choisis de l'objet de la transaction (OBJ... OBJin). Selon son acception la plus générale l'invention concerne un procédé de transactions en ligne comportant une pluralité d'étapes d'échanges de messages entre un client, un marchand et un serveur de validation, caractérisé en ce que le serveur de validation et le client disposent chacun d'un exemplaire d'au moins un coupon comportant pour chaque transaction un accord client ACi. Le procédé est caractérisé en ce qu'une condition nécessaire de validation de la transaction est la réception par le serveur de validation d'un accord client ACi autorisé, c'est-à-dire dont la valeur et/ou la structure sont reconnues par le serveur de validation par un quelconque moyen ou calcul. Il est également caractérisé en ce qu'une seconde condition nécessaire de validation de la transaction est que l'accord client AC, n'ait pas précédemment été validé ou invalidé par le serveur de validation permettant ainsi d'empêcher l'utilisation multiple d'un accord client. Il est encore caractérisé en ce qu'un accord client AC, comporte typiquement un identifiant de coupon IC, un numéro de transaction NTi et un code de transaction CT, constituant ainsi un accord électronique. Il est enfin caractérisé en ce que les composantes de l'accord client ACi (IC, NTi, CTi) peuvent être soumises au serveur de validation soit de façon simultanée soit de façon séquentielle, dans un ordre variable et dans une pluralité d'échanges formant la transaction. Dans certains cas, les coupons ne comportent pas les trois éléments de l'accord client ci-dessus. L'essentiel est de pouvoir d'identifier sans ambiguïté la transaction. A titre d'exemple, si l'identifiant IC est absent du coupon, il faudra que le numéro de transaction NTi et/ou le code de transaction CTi permettent d'identifier la transaction. Dans tous les cas, le code de transaction CTi est requis. Selon un premier mode de mise en oeuvre, dit mode à limitation de risque, un montant maximum, variable pour chaque transaction, est associé à chacune de celles-ci, permettant ainsi de limiter le risque transaction par transaction. Un tiers malveillant interceptant le code de transaction Cm, nie pourrait débiter le compte que du montant maximal défini pour la transaction. Selon un second mode de mise en oeuvre dit mode à objet certifié, une table de codage TC1, présente sur le coupon, variable à chaque transaction et connue seulement du serveur de validation et du client, permet de chiffrer le message constitué d'au moins une des composantes de l'objet de la transaction (OBJij : montant ou nom du client ou date de valeur ou adresse de livraison, etc.). Selon une variante de ce mode à objet certifié, la table de codage/décodage TCi permet une traduction de chaque caractère ou symbole de l'objet ou d'une composante de l'objet de la transaction, en un autre caractère ou symbole (A74, 69K, etc. ). Les tables TCi sont générées de façon aléatoire. Il n'existe donc aucun algorithme permettant de déchiffrer ce codage du fait de son caractère purement aléatoire. De plus, le processus de codage/décodage est réalisable aisément par tout être humain alphabétisé à l'aide de la table présente sur le coupon, sans l'aide d'un quelconque équipement. L'interception par un tiers malveillant d'un nombre important de transactions ne lui permet pas de déchiffrer l'algorithme de codage/décodage pour la simple raison qu'il n'existe pas. Selon une première option de réalisation du mode à objet certifié, le message comportant l'objet de la transaction ou certaines de ses composantes, est transmis chiffré par la table de codage, ce qui permet au récepteur d'authentifier le transmetteur et assure la confidentialité du message transmis. Dans une première variante de cette option de réalisation du mode à objet certifié, le message comportant l'objet de la transaction ou certaines de ses composantes, est transmis, dans un sens en clair et dans l'autre sens transcodé avec la table TCi. Ceci permet au transmetteur du message en clair, typiquement le client, d'identifier le récepteur, typiquement le serveur de validation, et de s'assurer de l'intégrité du message reçu afin d'autoriser ou d'interdire la poursuite de la transaction. Ce procédé présente l'avantage de ne pas faire effectuer de codage par le client mais de lui faire seulement vérifier le codage réalisé par le serveur de validation, ce qui est plus ergonomique. Dans une seconde variante de cette option de réalisation du mode à objet certifié, le message comportant l'objet de la transaction ou certaines de ses composantes, est transmis à la fois en clair et de façon chiffrée avec la table de codage TCi, ce qui permet au récepteur d'identifier le transmetteur et de s'assurer de l'intégrité du message reçu et ainsi d'autoriser ou d'interdire la poursuite de la transaction. Selon une seconde option de réalisation du mode à objet certifié, une table de codage est utilisée pour chaque sens de transmission ce qui accroît la sécurité des échanges mais rend plus complexe l'usage manuel des tables de codage. Selon une troisième option de réalisation du mode à objet certifié, les échanges de messages entre le client, le marchand et le serveur de validation, comportent : une étape de choix par le client ou le serveur de validation de la transaction à réaliser, par exemple en transmettant un numéro de transaction, - une étape de transmission sous une forme non codée de tout ou partie de l'objet de la transaction (montant de la commande, nature, adresse, etc. ), cette étape étant initiée par le client et adressée au serveur de validation, une étape de vérification par le serveur de validation de la validité de l'identifiant de coupon et du numéro de transaction, une étape de transmission par le serveur de validation au client de l'objet de la transaction reçu du client, chiffré par le serveur à l'aide de la table de codage, une étape de vérification par le client à l'aide de la table de codage, de l'identité entre l'objet de la transaction en cours, envoyé en clair au serveur de validation, et celui reçu chiffré de celui-ci, une étape de transmission pour accord par le client, au serveur de validation, du code de transaction. Selon une quatrième option de réalisation du mode à objet certifié, tout ou partie des éléments d'informations transmis lors de certaines étapes de transmission sont échangés entre le serveur de validation et le client par l'intermédiaire du marchand. Ceci permet de limiter les flux directs entre le serveur de validation et les clients en les régulant par le transit des sites marchands. Les procédés de chiffrement et de validation utilisés, notamment les tables de codage TC, rendent possible ce transit. Selon un troisième mode de mise en oeuvre dit mode à validation directe, la validation de la transaction est réalisée lors d'un échange direct, c'est-à-dire sans l'intermédiaire du marchand ou de tout autre tiers, entre le client et le serveur de validation. La transaction est donc réalisée en deux étapes, une première étape où le client saisit les éléments de la transaction auprès du marchand et une seconde étape durant laquelle le client consulte l'objet de la transaction (montant, produits, référence, etc.) préalablement transmis au serveur de validation par le marchand, puis valide la transaction. Selon un mode de mise en oeuvre dit mode combiné, au moins deux des trois des modes, à limitation de risque, à objet certifié et à validation directe, sont mis en oeuvre dans un même système. Ceci permet de faire varier, selon par exemple des critères d'importance ou de montant, le déroulement de la transaction. Un même coupon peut comporter des transactions prédéfinies pour fonctionner selon l'un ou l'autre des trois modes précités. En outre, le déroulement d'une transaction n'est pas nécessairement défini à l'avance. Il peut être choisi ou modifié dynamiquement par un des acteurs de la transaction sur détection d'un événement, par exemple le dépassement d'un en cours. Les deux mécanismes peuvent être combinés. De plus, il est possible d'associer à une transaction donnée des propriétés autres que celles liées au déroulement de celle-ci. Le mode à limitation de risque en est un exemple (montant maximum par transaction) mais le champ des applications est vaste (un droit d'accès à certains sites, des conditions de livraison, etc.). Cette propriété est soit explicitement mentionnée sur le coupon soit connue par avance d'un moins des acteurs de la transaction typiquement le client, par exemple à l'aide d'une caractéristique associée au numéro de transaction NTi ou au code de transaction CTi (couleur, position sur le coupon, etc.). Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, le client dispose, pour réaliser certaines transactions effectuées directement, c'est-à-dire sans l'intermédiaire d'un tiers, sur le serveur de validation d'un identifiant de coupon supplémentaire, dit identifiant privé de coupon IP. Cet identifiant n'est jamais transmis à quiconque autre que le serveur de validation. Le client dispose également de numéros et de codes de transaction NT'i et CT'i pour valider ces transactions. Ces numéros et codes peuvent selon les choix de mise en oeuvre, être absents, identiques ou différents des numéros et codes NTi et CTi. L'introduction d'un identifiant privé IP, jamais transmis aux marchands, permet d'accroître le niveau de sécurité du système. Ainsi dans le mode à validation directe, l'interception malveillante lors de l'échange entre le marchand et le client, du numéro de coupon IC et du code de transaction, est sans objet puisque la validation de la transaction nécessite l'usage de l'identifiant IP lors d'un échange direct avec le serveur de validation. Selon une autre variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, le coupon possède un identifiant complémentaire dit identifiant à recevoir IR, permettant à un premier client de créditer le compte d'un second client en utilisant l'identifiant de coupon à recevoir IR du second client, au cours d'une session directe avec le serveur de validation. L'identifiant à recevoir IR est public et communicable sans risque à tout tiers. Cette option réalise ainsi un mode de paiement universel entre deux détenteurs de coupons quelle que soit leur localisation et leur mode d'accès (Internet, SMS, WAP, téléphonique, etc.). Selon une autre variante également opérationnelle pour l'ensemble des trois modes de mise en oeuvre, l'identifiant privé de coupon IP est utilisé par le client pour obtenir, dans une session directe avec le serveur de validation, un complément de coupon, sous forme de fichier image ou alphanumérique, comportant soit de nouveaux codes de transaction soit de nouvelles tables de codage/décodage. Dans cette variante, le complément de coupon est transmis sans identifiant IC'et IR'. Il est uniquement utilisable avec les identifiants IC et IR du coupon actuel. Le client est le seul avec le serveur de validation, à être capable de faire le lien entre l'identifiant privé IP et l'identifiant de coupon IC. Ce procédé permet de prolonger la durée de vie d'un coupon lorsque le client a épuisé tous les codes de transactions ou toutes les tables de codage du coupon ou d'autres informations associées à la transaction. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, un nouveau coupon, doté de tous ses attributs et identifiants, est transmis électroniquement et de façon chiffrée, du serveur de validation au client, sous forme image ou sous forme alphanumérique selon les options de mise en oeuvre. La clé de déchiffrement du fichier électronique du nouveau coupon est présente sur le coupon actuellement utilisé par le client. Ce peut être par exemple un code de transaction ou tout autre information. L'algorithme de chiffrement est variable selon les implémentations et peut être limité par exemple à une compression standard de type ZIP avec clé. Ce procédé permet de distribuer des coupons sous forme informatique après paiement de ceux-ci sur le serveur de validation. Ce chiffrement du fichier de coupon n'exclut pas un chiffrement de l'ensemble de la session par un algorithme de type SSL. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, l'objet de la transaction ou une partie de celui-ci (OBJil, etc.) est transmis électroniquement par le serveur de validation au client de façon chiffrée par un algorithme autre que les tables de codage TCi, le cas échéant via le marchand. La clé de déchiffrement du fichier électronique comportant cet objet, variable à chaque transaction, est présente sur le coupon utilisé par le client et peut-être soit le code de la transaction CTi en cours, soit une autre valeur associée à la transaction. L'algorithme de chiffrement est variable selon les implémentations et peut être limité par exemple à une compression standard de type ZIP avec clé. Ce mécanisme permet par exemple au client de ne donner son accord client que sur réception d'un objet de transaction certifié par le serveur de validation car chiffré par lui. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, la signature électronique du fichier contenant l'objet de la transaction est transmise électroniquement par le serveur de validation au client, le cas échéant via le marchand. L'algorithme de calcul de la signature dépend d'une clé, associée à la transaction, présente sur le coupon et connue seulement du client et du marchand. Le client dispose également d'un logiciel réalisant cet algorithme. Lorsque qu'il reçoit l'objet de la transaction, il peut calculer la signature de l'objet à l'aide de la clé et la comparer à la signature reçue pour donner ensuite son accord sur la transaction. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, typiquement adapté aux transactions où le service vendu est un service en ligne, nécessitant un accès par identifiant et mot de passe, le marchand transmet au serveur de validation l'identifiant (user ID) et le code d'accès au service en ligne (mot de passe) alloué au client. Le client obtient ces autorisations d'accès au service du marchand soit par redirection vers une adresse de messagerie (e-mail, SMS, boîte vocale, etc. ) soit dans une session directe, sans tiers intermédiaire, avec le serveur de validation. L'avantage de ce procédé est qu'il rend sans objet l'interception malveillante, lors des transactions des clients avec les marchands, des identifiants et des codes de transaction. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, les échanges comprennent une étape supplémentaire de transmission, du serveur de validation au client, d'une référence de transaction RF, chiffrée, soit à l'aide de la table de codage TCl soit par tout autre moyen déchiffrable à partir des informations présentes sur le coupon. Cette référence de transaction, après déchiffrage, comprend un élément d'information connu du client et du serveur de validation (IC et/ou NTi et/ou CTi et/ou une autre valeur présente sur le coupon et associée à la transaction) permettant ainsi au client de s'assurer de la bonne fin de la transaction et de la conservation d'une trace au sein du serveur de validation. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, les échanges entre au moins deux des trois intervenants de la transaction sont chiffrés. Typiquement les sessions entre le client et le marchand ou entre le client et le serveur seront chiffrées par un algorithme asymétrique et très répandu comme SSL avec une authentification des parties via des certificats. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, le procédé comporte une étape d'invalidation de l'exemplaire du coupon ou de l'identifiant de transaction détenu par le serveur de validation dont l'identifiant correspond à celui de la transaction engagée. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, le procédé comporte une étape d'invalidation de l'exemplaire du coupon détenu par le serveur de validation sur réception d'un nombre défini d'accords clients incorrects. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, le procédé comporte une étape d'invalidation de la transaction activée lorsque le délai entre deux étapes consécutives dépasse une valeur prédéterminée. Un tel procédé permet de maintenir l'unité transactionnelle de la transaction en annulant toute transaction incomplète. Il peut également empêcher l'usage ultérieur des codes de transaction par un intervenant mal intentionné interceptant les éléments de la transaction. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, l'identification par le client du serveur de validation est réalisé typiquement en début de session par la réception par le client d'un code supplémentaire de transaction CT, issu du serveur de validation. Ce procédé permet de garantir au client la mise en relation avec le serveur de validation. Couplé au procédé de la revendication 30, il permet d'éviter l'usage différé de codes de transaction interceptés par un tiers malveillant. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, les codes, tables et autres informations associés sur le coupon à deux transactions différentes ne sont pas nécessairement distinctes. A titre d'exemple, dans certaines mises en oeuvre, il peut être acceptable que les tables de codage TCi soient les mêmes pour chaque transaction du coupon. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, les coupons sont constitués par des supports physiques, papier, plastique ou tout autre support, présentant des inscriptions comportant typiquement l'identifiant de coupon IC, des codes de transaction CT, et des tables de codage de transaction TCi ainsi que les identifiants privés et à recevoir IP et IR. Certains de ces éléments peuvent ne pas être présents. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, un masquage est réalisé pour certains éléments du coupon. Le masquage des identifiants IC et IP est typiquement mis en oeuvre. En général, celui des codes de transaction n'est pas nécessaire. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, les coupons sont mis en oeuvre soit sous forme numérique avec un codage bitmap soit sous forme alphanumérique. Dans les deux cas, l'usage du coupon peut être strictement identique à l'usage d'un coupon papier. Le coupon présente en plus l'avantage de pouvoir être téléchargé et donc acheté à distance, ce qui diminue fortement les coûts de distribution. Dans le second cas, celui du coupon alphanumérique, l'usage d'un logiciel client assez simple peut permettre de faciliter le déroulement de la transaction, notamment l'usage des tables de codage. Il peut également permettre de chiffrer, à chaque transaction, l'identifiant de coupon IC. Selon une variante opérationnelle pour l'ensemble des trois modes de mise en oeuvre, certains messages échangés sont constitués par des messages conformes aux protocoles SMS et WAP des radiocommunications mobiles, aux suites de protocoles du réseau Internet et enfin aux transferts d'informations via le réseau téléphonique commuté. L'usage de tels coupons permet par exemple aux abonnés mobiles d'un réseau GSM de régler des services SMS ou WAP fournis soit par un tiers ou un opérateur concurrent. EXEMPLES L'invention sera mieux comprise à la lecture de la description qui suit, concernant un exemple non limitatif de réalisation se référant aux dessins annexés. Le procédé selon l'invention est basé sur une information partagée entre deux acteurs A et B, deux copies d'un coupon étant détenues respectivement par le serveur de validation et par le client de la transaction. Pour l'option prépayée, un système central temps réel, distribué ou non, de vérification de solde est mis en oeuvre. Les coupons matériels sont remis au client, par exemple le consommateur ou client de sites de commerce électronique, par distribution dans des commerces de détail (buralistes, GS, etc. ). Les coupons informatiques peuvent être distribués par Internet. Les coupons permettent la réalisation de plusieurs transactions à distance par coupon, et notamment des transactions sécurisées permettant une validation très simple, sans outil logiciel ou matériel pour le client. Ils se caractérisent lorsqu'ils sont sur support physique par la conservation des secrets à l'extérieur du monde informatique (coupons papier) et la possibilité de soldes reportables d'un coupon à l'autre. Les codes de transaction ne servent qu'une fois. Pour l'option avec objet certifié, le codage des montants est réalisé sans algorithme : il n'existe aucune fonction calculable permettant d'obtenir le symbole codé à partir du symbole en clair et réciproquement. L'intégrité de l'objet de la transaction échangé et l'authentification des parties est assurée par le mécanisme du codage. L'échange ne peut être altéré par un tiers entre-deux sans invalider la transaction. La vérification de l'exactitude du codage est réalisée sans calcul par le client. Les figures présentées en annexe permettent d'illustrer l'invention : la figure 1 représente une vue de dessus d'un coupon pour la mise en oeuvre du mode à limitation de risque de l'invention ; la figure 2 représente une vue de dessus d'un coupon pour la mise en oeuvre du mode à objet certifié ; la figure 3 représente une vue schématique des messages échangés pour le mode à objet certifié ; la figure 4 représente une vue de dessus d'un coupon pour la mise en oeuvre du mode à validation directe ; la figure 5 représente une vue schématique des messages échangés dans le mode à validation directe ; Dans ces exemples, les coupons sont formés par un support matériel portant une pluralité de zones imprimées. Une copie de chaque coupon est mémorisée dans la mémoire protégée d'un serveur de validation, sous une forme numérique. Le coupon-matériel ou numérique-comporte tout d'abord un identifiant de coupon IC (1). Cet identifiant est unique, secret, et attribué aléatoirement ou séquentiellement au moment de l'édition du coupon. Cet identifiant peut être occulté avant utilisation du coupon par une couche de masquage à gratter ou par un opercule amovible. Le coupon comporte ensuite une pluralité d'identifiant de transaction (11) et numéro de transaction NT. (2). Dans le cas du mode à objet certifié, à chaque transaction est associée une table de codage de transaction TC, (21). Ce tableau permet de chiffrer-sans algorithmedes informations de l'objet de la transaction (montants, paris, etc. ) spécifique à chaque transaction. Le coupon comporte en outre un code de transaction (22) formant chacune une clé de validation client par transaction Cit\. Le coupon comprend optionnellement en outre un identifié privé IP (23). Il s'agit d'un numéro masqué ou non selon les options, uniquement utilisé sur le site du serveur de validation, pour les opérations de gestion (virement de coupon à coupon, etc. ) et pour la validation des transactions dans le cas du mode à validation directe. Le coupon comprend optionnellement un identifiant public pour recevoir IR (24) pour recevoir un paiement d'un autre possesseur de coupon. Il s'agit d'un identifiant du coupon, suite de symboles alpha., communiqué à des tiers pour recevoir des paiements. Le coupon comprend optionnellement une suite ordonnée de symboles S, représentant un prix, un pari, etc, appelée ci-après objet. Une table de codage variable par transaction TCi est connue uniquement du client et du serveur. En 1, le client émet la valeur Si en clair. Après 2, le client compare l'objet Si à l'objet S'i décodé à l'aide de la table TCiprésente sur son coupon. En cas de différence, il n'envoie pas son code de transaction CT et la transaction i est invalidée. En cas d'accord, il envoie CTi et reçoit la référence de transaction Ruf,, chiffrée ou non selon les options de mise en oeuvre. S'il ne reçoit pas une référence valide, il peut prendre contact avec le service de gestion clientèle pour vérifier la réception de CTi par le serveur de validation et obtenir cette référence. Tous les codes et tables associés à une transaction ne servent qu'une fois. Le serveur de validation enregistre les paramètres de transaction : nature, montant, date et heure et identités du coupon et du commerçant. PRECISION DE VOCABULAIRE Pour des raisons de clarté du discours, dans les revendications ci-après, les termes client et marchand seront utilisés, pour représenter l'émetteur et le destinataire de la transaction. Les revendications ne se limitent pas à une transaction marchande comprenant un marchand, un client et un serveur de validation mais concernent tout type de transaction comprenant un émetteur, un destinataire et un serveur de validation. REVENDICATIONS 1-Procédé de transaction en ligne, comportant une pluralité d'étapes d'échanges de messages entre un client, un marchand et un serveur de validation dont une étape de validation d'une transaction par un serveur de validation ou un ensemble de serveurs distribués, caractérisé en ce que le serveur de validation et le client disposent chacun d'un exemplaire d'au moins un coupon comportant pour chaque transaction un accord client ACi, et en ce qu'une condition nécessaire de validation de la transaction i est la réception par le serveur de validation d'un accord client ACi autorisé, c'est-à-dire dont la valeur et/ou la structure sont reconnues par le serveur de validation par un quelconque moyen ou calcul, le procédé étant en outre caractérisé en ce qu'une seconde condition nécessaire de validation de la transaction est que l'accord client ACi n'ait pas précédemment été soit validé M fois soit invalidé par le serveur de validation, et en ce que le nombre M de validations peut être fixé à 1, permettant ainsi d'empêcher l'utilisation multiple d'un accord client, le procédé étant en outre caractérisé en ce qu'un accord client ACi est constitué d'une combinaison comportant nécessairement un identifiant de coupon IC, un numéro de transaction NTi [un numéro séquentiel de chaque transaction figurant sur le coupon par exemple] un code de transaction CTi [un mot de passe ou une clef], et en ce que les composantes de l'accord client ACi (CTI, IC, NTJ sont soumises au serveur de validation soit de façon simultanée soit de façon séquentielle, dans un ordre variable et dans une pluralité d'échanges formant la transaction. 2-Procédé de transaction en ligne, selon la revendication 1, caractérisé en ce qu'un au moins de l'identifiant de coupon IC ou du numéro de transaction NTi, n'est pas présent sur le coupon et n'est pas une composante de l'accord client ACipour la transaction i. 3-Procédé de transaction en ligne dit mode à limitation de risque, selon l'une quelconque des revendications 1 à 2, caractérisé en ce qu'un montant maximum, variable à chaque transaction est associé à chacune de celle-ci, et caractérisé en ce que ledit montant maximum est explicitement mentionné sur le coupon et/ou connu par avance par le client et le serveur de validation, en fonction d'une caractéristique de l'accord client ACi et/ou d'une de ses composantes. 4-Procédé de transaction en ligne, selon l'une quelconque des revendications précédentes, dit à mode certifié, caractérisé en ce qu'au moins une des composantes de l'objet de la transaction est transmise du serveur de validation vers le client ou inversement, le cas échéant via le marchand, en étant codée/décodée à l'aide d'une table de codage/décodage TCi, variable à chaque transaction, ladite table figurant à l'identique sur l'image du coupon au sein du serveur de validation et sur le coupon à disposition du client. 5-Procédé de transaction en ligne, selon la revendication 4 caractérisé en ce que la table de codage/décodage TCi, présente sur le coupon, est mise en oeuvre par une traduction de chaque caractère ou symbole de l'objet ou d'une composante de l'objet de la transaction, en un autre caractère ou symbole [A-74, 6"K, etc.], et caractérisée en ce que la table de codage TCi permet de chiffrer caractère par caractère le message MESi constitué de la concaténation des composantes choisies de l'objet de la transaction, chaque symbole m, k, de rang k dans le message, étant chiffré à l'aide d'un tableau à deux colonnes Mlk la première comportant l'alphabet des symboles (entrée) et la seconde une transposition aléatoire de cet alphabet (sortie). 6-Procédé de transaction en ligne selon l'une quelconque des revendications 4 et 5, caractérisé par la transmission durant la transaction, outre de l'identifiant de coupon IC : soit d'au moins une composante de l'objet de la transaction, chiffrée avec la table TCi (OBJij1 ... OBJijp). soit dans un sens, d'au moins une composante de l'objet de la transmission en clair et dans l'autre sens, d'au moins une même composante de l'objet de la transaction, chiffrée avec la table TC, (OBJ1j1 ... OBJijp). soit du couple constitué d'au moins une composante de l'objet de la transaction chiffrée avec la table TCi et de la même composante en clair (TCi (OBJi1, OBJi2, etc.), (OBJi1, OBJ, etc.)). 7-Procédé de transaction en ligne, selon l'une quelconque des revendications 4 à 6, caractérisé en ce que deux tables de codage/décodage (TC1 et TC2i) sont associées à chaque transaction, chacune étant utilisée pour un sens de transmission donné, du client vers le serveur de validation et réciproquement. 8-Procédé de transaction en ligne, selon l'une quelconque des revendications 4 à 7 caractérisé en ce que les échanges de messages entre le client, le marchand et le serveur de validation, comportent : une étape de choix par le client ou le serveur de validation de la transaction à réaliser, par exemple en transmettant un numéro de transaction, une étape de transmission sous une forme non codée, de l'identifiant de coupon IC, d'un numéro de transaction NTi et au moins d'un élément de l'objet de la transaction (OBJil, OBJi2, etc. ), cette étape étant initiée par le client et adressée au serveur de validation, une étape de vérification par le serveur de validation de la validité de l'identifiant de coupon et du numéro de transaction, une étape de transmission par le serveur de validation au client des éléments de l'objet de la transaction reçus du client, chiffrés par le serveur de validation à l'aide de la table de codage CTi, une étape de vérification par le client à l'aide de la table de codage, de l'identité entre les éléments de l'objet de la transaction en cours, envoyés en clair au serveur de validation, et ceux reçus chiffrés de celui-ci, une étape de transmission pour accord par le client, au serveur de validation, du code de transaction CTi. 9-Procédé de transaction en ligne, selon l'une au moins des revendications 4 à 8 caractérisé en ce que tout ou partie des éléments d'informations transmis lors d'au moins une des étapes de transmission est échangée entre le serveur de validation et le client par l'intermédiaire du marchand. 10-Procédé de transaction en ligne, dit à validation directe, selon l'une quelconque des revendications précédentes, caractérisé en ce qu'une condition nécessaire de validation de la transaction est réalisée lors d'un échange direct, c'est-à-dire sans l'intermédiaire du marchand ou de tout autre tiers, entre le client et le serveur de validation, échange durant lequel le client consulte tout ou partie de l'objet de la transaction préalablement transmis au serveur par le marchand, et communique au serveur de validation un accord client autorisé. 11-Procédé de transaction en ligne, selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il met en oeuvre au moins deux des trois des modes à limitation de risque, à objet certifié et à validation directe. 12-Procédé de transaction en ligne, selon l'une quelconque des revendications précédentes, caractérisé en ce que le déroulement de la transaction à réaliser dépend du choix préalable de la transaction par au moins un des trois acteurs, le client, le marchand ou le serveur de validation, ledit choix étant réalisé par transmission soit du numéro soit du code de transaction soit d'un autre paramètre présent sur le coupon identifiant sans ambiguïté la transaction. 13-Procédé de transaction en ligne, selon l'une quelconque des revendications précédentes, caractérisé en ce que le déroulement de la transaction en cours dépend d'une décision par au moins un des trois acteurs de la transaction, le client, le marchand ou le serveur de validation, en fonction d'une propriété de la transaction en cours. 14-Procédé de transaction en ligne, selon l'une au moins des revendications précédentes, caractérisé en ce que le déroulement de la transaction, selon un des modes suivants : le mode à limitation de risque, le mode à objet certifié, le mode à validation directe, un autre mode, une variante des modes précédents, dépend d'une décision d'au moins un des trois acteurs de la transaction, le client, le marchand ou le serveur de validation, fondée soit sur le choix préalable d'une transaction donnée du coupon, par avance associée à un mode ou une variante de mode donné, soit sur la détection par l'acteur concerné de la réalisation d'un événement lors du déroulement de la transaction. 15-Procédé de transaction en ligne selon l'une quelconque des revendications précédentes, caractérisé en ce qu'à au moins une transaction du coupon est associée au moins une propriété, soit explicitement mentionnée sur le coupon soit connue par avance d'un moins des acteurs de la transaction. 16-Procédé de transaction en ligne selon l'une quelconque des revendications précédentes, caractérisé en ce qu'à au moins une transaction est associée au moins une propriété, choisie parmi : un montant maximum, un droit ou un interdit quelconque [par exemple un droit ou une limitation d'accès à certains sites de contenu], un type de transaction particulier [e. g. mode certifié] des conditions de livraison, un niveau de sécurité, une date de validité, ladite au moins une propriété de la transaction étant explicitement mentionnée sur le coupon et/ou connue par avance d'un moins des acteurs de la transaction [en général le client et le serveur de validation, par exemple selon une caractéristique du numéro de transaction NT, ou du code de transaction CTJ. 17-Procédé de transaction en ligne, selon l'une quelconque des revendications précédentes caractérisé en ce que le client dispose, pour réaliser certaines transactions directement sur le serveur de validation, c'est-à-dire sans l'intermédiaire d'un tiers, d'une part d'un identifiant de coupon supplémentaire, dit identifiant privé de coupon IP, jamais transmis à quiconque autre que le serveur de validation, et d'autre part de numéros et de codes de transaction Nut', et CT'i pouvant selon les choix de mise en oeuvre, être absents, identiques ou différents des codes NTi et Cit,. 18-Procédé de transaction en ligne, selon les revendications 10 et 17 caractérisé en ce que l'accord client utilisé pour la validation directe AC'i est différent de AC, [utilisé dans ce cas pour le dialogue avec le marchand] et constitué d'une part de l'identifiant privé IP et d'autre part d'un numéro et d'un code de transaction NT' et CT'i pouvant, selon les choix de mise en oeuvre, être absents, identiques ou différents des codes NTi et CTi. 19-Procédé de transaction en ligne, selon au l'une quelconque des revendications précédentes caractérisé en ce que les coupons comportent, outre l'identifiant de coupon IC, un identifiant supplémentaire IR, dit identifiant à recevoir, permettant à un premier client de créditer le compte d'un second client en utilisant l'identifiant de coupon à recevoir IR du second client, au cours d'une session directe, sans tiers intermédiaire, avec le serveur de validation. 20-Procédé de transaction en ligne, selon l'une quelconque des revendications précédentes caractérisé en ce que l'identifiant privé de coupon IP est utilisé par le client pour obtenir, dans une session directe avec le serveur de validation, au moins un code de transaction CTi supplémentaire du coupon actuel, associé le cas échéant à un numéro de transaction NTi et/ou au moins une table de codage/décodage TCi et/ou au moins une information supplémentaire liée à la même transaction, et caractérisé en ce que la session ne comporte aucun échange des identifiants du coupon actuel IC et IR, et en ce que ces informations seront utilisables avec les identifiants IC, IP et IR du coupon actuel. 21-Procédé de transaction en ligne, selon l'une quelconque des revendications précédentes caractérisé en ce qu'un nouveau coupon est transmis électroniquement par le serveur de validation au client de façon chiffrée, et caractérisé en ce que la clé de déchiffrement du fichier électronique du nouveau coupon est présente sur le coupon actuellement utilisé par le client. 22-Procédé de transaction en ligne, selon l'une quelconque des revendications précédentes caractérisé en ce que tout ou partie des éléments de l'objet de la transaction (OBJi, etc.) est transmis par le serveur de validation au client de façon chiffrée, le cas échéant via le marchand, et caractérisé en ce que la clé de déchiffrement du fichier comportant tout ou partie des éléments de l'objet, variable à chaque transaction, est présente sur le coupon utilisé par le client et peut-être soit le code de la transaction CTi en cours soit une autre valeur associée à ladite transaction. 23-Procédé de transaction en ligne, selon l'une quelconque des revendications précédentes caractérisé en ce que la signature électronique du fichier contenant tout ou partie des éléments de l'objet de la transaction (OBJil, etc.) est transmise électroniquement par le serveur de validation au client, le cas échéant via le marchand, et caractérisé en ce que le client dispose d'une part des mêmes tout ou partie des éléments de l'objet de la transaction (OBJ etc.) et du même algorithme de calcul de signature, et caractérisé en ce que cet algorithme est dépendant d'une clé CSi, variable à chaque transaction, présente sur le coupon. 24-Procédé de transaction en ligne, selon l'une quelconque des revendications précédentes caractérisé en ce que le marchand transmet au serveur de validation l'identifiant du client et le code d'accès au service en ligne alloué au client, et caractérisé en ce que le client obtient ces éléments d'accès au service dans une session directe, sans tiers intermédiaire, avec le serveur de validation, et caractérisé en ce que le client utilise pour s'identifier sur le serveur de validation soit l'identifiant de coupon IC soit l'identifiant privé IP, complété ou non, selon les options de mise en oeuvre, du code de transaction pertinent. 25-Procédé de transaction en ligne, selon l'une quelconque des revendications précédentes caractérisé en ce que le serveur de validation dispose d'une option de renvoi par une messagerie de au moins une des composantes de l'objet de la transaction obtenues du marchand, vers l'adresse de messagerie préalablement choisie par le client et enregistrée dans le serveur de validation. 26-Procédé de transaction en ligne, selon les revendications précédentes caractérisé en ce que les échanges comprennent une étape supplémentaire de transmission, du serveur de validation au client, le cas échéant via le marchand, d'une référence de transaction RFi totalement ou partiellement chiffrée, soit à l'aide de la table de codage TCi soit par tout autre moyen déchiffrable à partir d'informations présentes sur le coupon, et caractérisé en ce que la référence de transaction, après déchiffrage, comprend un élément d'information connu du client et du serveur de validation (IC et/ou NTi et/ou C1 ou une autre valeur associée à la transaction) permettant ainsi au client de s'assurer de la bonne fin de la transaction au sein du serveur de validation. 27-Procédé de transaction en ligne, selon l'une au moins des revendications précédentes caractérisé en ce qu'au moins un des échanges suivants est chiffré et/ou authentifié : les sessions directes entre le serveur de validation et le client [par exemple par un algorithme asymétrique comme SSL], les sessions entre le client et le marchand [par exemple par un algorithme asymétrique comme SSL], les sessions entre le marchand et le serveur de validation. 28-Procédé de transaction en ligne, selon l'une au moins des revendications précédentes, caractérisé en ce qu'il comporte une étape d'invalidation de l'exemplaire du coupon ou de l'identifiant de transaction détenu par le serveur de validation dont l'identifiant correspond à celui de la transaction engagée. 29-Procédé de transaction en ligne, selon l'une quelconque des revendications précédentes, caractérisé en ce que l'envoi au serveur de validation d'un nombre défini d'accords client ACi associés à un même coupon et comportant des numéros ou des codes de transaction NT, ou CTi non autorisés provoque l'invalidation du coupon et donc l'invalidation de tous les accords clients associés à ce coupon. 30-Procédé de transaction en ligne, selon l'une au moins des revendications précédentes, caractérisé en ce qu'il comporte une étape d'invalidation de la transaction activée lorsque le délai entre deux étapes consécutives dépasse une valeur prédéterminée. 31-Procédé de transaction en ligne, selon l'une au moins des revendications précédentes, caractérisé en ce qu'il comporte par transaction deux codes de transaction CTll et CTi2 présents sur le coupon, transmis durant la transaction, le premier du serveur de validation au client et le second du client au serveur de validation. 32-Procédé de transaction en ligne, selon l'une au moins des revendications précédentes, caractérisé en ce qu'au moins deux valeurs de même type, identifiants codes, tables de codage ou autre, présentes sur le coupon et associées à deux transactions différentes, sont identiques. 33-Procédé de transaction en ligne, selon l'une au moins des revendications précédentes, caractérisé en ce que les coupons sont constitués par des supports physiques présentant des inscriptions comportant au moins un code de transaction CT, et au moins un des éléments suivants : un identifiant de coupon IC, au moins un numéro de transaction NT, au moins une table de codage TCi, - un identifiant de coupon IP, un identifiant de coupon IR, au moins une autre valeur associée à la transaction. 34-Procédé de transaction en ligne, selon l'une au moins des revendications précédentes, caractérisé en ce que l'un au moins des codes de transaction Cit,, des tables de codages TC, des identifiants de coupon IC, IP ou IR, est masqué sur le coupon avant l'utilisation. 35-Procédé de transaction en ligne, selon l'une au moins des revendications précédentes, caractérisé en ce que les coupons à disposition du client sont constitués par des fichiers numériques sous forme image ou alphanumérique. 36-Procédé de transaction en ligne, selon l'une au moins des revendications précédentes, caractérisé en ce que certaines informations échangées sont constituées de messages SMS aptes à être émis ou reçus par un téléphone cellulaire. 37-Procédé de transaction en ligne, selon l'une au moins des revendications précédentes, caractérisé en ce que certaines informations échangées sont constituées de messages conformes au protocole WAP aptes à être émis ou reçus par un téléphone cellulaire. 38-Procédé de transaction en ligne, selon l'une au moins des revendications précédentes caractérisé en ce que certaines informations échangées sont constituées de messages conformes aux protocoles Internet aptes à être émis ou reçus par un équipement informatique connecté au réseau Internet. 39-Procédé de transaction en ligne, selon l'une au moins des revendications précédentes caractérisé en ce que certaines informations échangées sont constituées de messages vocaux, à fréquence multiple (DTMF) ou minitel, aptes à être émis ou reçus par un équipement téléphonique ou une personne, connecté au réseau téléphonique commuté.