FR 2821506 A1 20020830 FR 0102528 A 20010223 La présente invention concerne un procédé et un système de sécurisation d'une transaction entre un commerçant et un client porteur d'une carte de paiement. L'invention trouve une application particulièrement avantageuse dans le domaine de la sécurisation des transactions du type vente à distance effectuées au moyen d'une carte de paiement. Elle s'applique également aux transactions mettant en oeuvre une piste magnétique de ladite carte de paiement. D'une manière générale, les cartes de paiement comportent, d'une part, un visuel intégrant des informations sur le porteur, notamment son nom, ainsi que des données d'identification propres à chaque carte de paiement, à savoir son numéro d'identification et sa date d'expiration, et, d'autre part, une piste magnétique sur laquelle sont enregistrées les mêmes données d'identification. Des cartes de paiement de ce type peuvent être éditées par des groupements d'enseignes commerciales, par des organismes de financement ou par des établissements bancaires le plus souvent regroupés en réseaux. Il faut signaler que dans le cas des cartes dites bancaires, le corps de la carte peut comporter un composant électronique, parfois appelé puce , qui contient non seulement toutes les informations et données relatives à la carte et son porteur mais aussi des moyens, microprocesseur et logiciels associés, aptes à effectuer des opérations complexes d'authentification, chiffrement par exemple. Pour réaliser une transaction financière avec une carte de paiement, on peut utiliser les seules données propres à ladite carte contenues dans le visuel mentionné plus haut. Cette procédure est fréquente en France dans les transactions connues sous le nom de vente à distance . Lorsque ladite vente à distance est réalisée sur un réseau de communication comme l'Internet, le client porteur de la carte de paiement doit introduire manuellement sur le clavier de son ordinateur personnel le numéro d'identification et la date d'expiration de sa carte. Dans le cas particulier de la vente par correspondance, le client inscrit ces mêmes données sur un formulaire papier qu'il envoie ensuite au commerçant par courrier. Le commerçant transmet alors les données d'identification de la carte à un organisme de gestion accompagnées d'une demande d'autorisation de la transaction. L'organisme de gestion procède à un certain nombre de vérifications concernant la carte et le porteur et autorise ou non la transaction. On peut également effectuer une transaction au moyen d'une carte de paiement en utilisant les données d'identification présentes dans la piste magnétique de la carte. Cette procédure est maintenant relativement peu pratiquée en France dans le commerce de proximité sauf dans le cas de réseaux privatifs gérés en particulier par des groupements d'enseignes commerciales. Pour réaliser une telle transaction, le commerçant dispose d'un lecteur de pistes magnétiques qui enregistre les données de la transaction et les transmet à un organisme de gestion du réseau auquel appartient la carte. Si une autorisation est donnée par l'organisme de gestion, un bordereau imprimé par le lecteur doit être signée par le porteur de la carte pour que la transaction puisse être effectuée. Cependant, de telles cartes de paiement sont facilement duplicables, physiquement ou en récupérant les données d'identification, et fraudables. Les importants taux de fraude dans le monde bancaire proviennent de cette source. De façon à remédier à cette situation, il a été décidé d'ajouter un code confidentiel aux données d'identification de la carte, ce code n'étant connu que du seul porteur de la carte, et, surtout, de sécuriser les échanges d'informations par l'utilisation des cartes à puce. Il est alors possible : - d'authentifier à chaque transaction le porteur de la carte par présentation et vérification locale du code confidentiel, - et, ensuite, générer des preuves (certificats) sur l'acte d'achat à l'aide des secrets personnalisés que la carte contient. Toutefois, si, dans certains pays, les terminaux de traitement des cartes de paiement à puce se sont fortement déployés dans le commerce de proximité, cette procédure étant la seule à apporter par contrat la garantie de paiement au commerçant, ce n'est pas le cas aujourd'hui dans le domaine du commerce à distance. Pour ce faire, il faudrait, en effet, généraliser chez les particuliers l'usage de lecteurs de carte pouvant effectuer des transactions financières dans des conditions raisonnables de sécurité. Or, actuellement, l'échec de la diffusion dans le public des lecteurs de carte sécurisés branchés sur un ordinateur personnel pour commercer sur l'Internet démontre la difficulté d'une telle généralisation. Une autre solution fondée sur l'utilisation d'un terminal mobile bi-fente existe également mais se heurte de la même manière aux difficultés liées à un déploiement à grande échelle. Il existe aujourd'hui des sociétés qui fournissent à leurs clients des moyens permettant de sécuriser l'emploi de cartes de paiement sans puce dans le contexte de Internet. Ces moyens consistent essentiellement à éviter la circulation en ligne du numéro de la carte. On citera par exemple : - les plates-formes de commerce électronique qui proposent aux porteurs d'inscrire définitivement leur numéro de carte de paiement sur leur serveur et d'utiliser un pseudonyme (identifiant, mot de passe assorti parfois d'un questionnaire) pour accéder à la ressource. - les systèmes qui substituent au numéro réel de la carte de paiement un numéro temporaire parfaitement formé. Ce numéro, collecté auprès d'un centre d'autorisation spécialisé, est utilisé par le porteur pour effectuer un achat chez un commerçant, transite sur le serveur du commerçant où il apparaît comme un véritable numéro de carte de paiement, et remonte vers un centre d'autorisation dédié qui traite alors la transaction en substituant au numéro temporaire le vrai numéro de la carte et en renvoyant la transaction vers le centre d'autorisation de l'organisme financier du porteur. Dans tous les cas, ces procédures contournent effectivement le problème de l'interception en ligne des données de la carte, mais ne peuvent résoudre le problème de leur obtention frauduleuse par d'autres circuits et de leur utilisation en ligne. Aussi, le problème technique à résoudre par l'objet de la présente invention est de proposer un procédé de sécurisation d'une transaction entre un commerçant et un client porteur d'une carte de paiement, ladite transaction impliquant une demande d'autorisation à partir de données d'identification propres à ladite carte de paiement, procédé qui permettrait d'augmenter la sécurité des transactions pour lesquelles la connaissance des seules données d'identification de la carte suffisent pour en obtenir l'autorisation. La solution au problème technique posé consiste, selon la présente invention, en ce que la transaction est autorisée après vérification d'au moins un critère de contrôle déterminé par ledit porteur à partir d'au moins un paramètre propre à ladite transaction. De même, un système de sécurisation d'une transaction entre un commerçant et un client porteur d'une carte de paiement, ledit système comprenant au moins un organisme de gestion apte à autoriser ladite transaction à partir de données d'identification propres à ladite carte de paiement, est, selon l'invention, notamment remarquable en ce que ledit système comprend également un module décisionnel complémentaire apte à autoriser la transaction après vérification d'au moins un critère de contrôle déterminé par ledit porteur à partir d'au moins un paramètre propre à ladite transaction. Ainsi, à la demande d'autorisation usuelle mettant en jeu les données d'identification de la carte, le procédé de l'invention ajoute de manière indépendante un contrôle complémentaire qui présente la particularité, d'une part, d'être décidé par le porteur lui-même, et, d'autre part, de dépendre de paramètres liés à la transaction elle-même. Il en résulte une sécurisation très forte du fait que lesdits critères de contrôle ne circulent pas en ligne et sont difficilement accessibles aux fraudeurs. Selon un mode de réalisation de l'invention, ledit paramètre propre à la transaction est choisi dans la liste suivante, séparément ou en combinaison : existence de la transaction pendant une période donnée, nombre de transactions sur une période donnée fixe ou glissante, montant de la transaction en valeur unitaire ou cumulée, monnaie de la transaction, identité du commerçant. Par existence de la transaction pendant une période donnée, on entend la possibilité pour le porteur de décider d'autoriser ou non toute transaction, quelle qu'elle soit, pendant la période donnée choisie. La sécurisation apportée par l'invention peut donc être complète, il suffit pour cela au porteur d'interdire toute transaction purement et simplement. N est également prévu par l'invention un processus de filtrage selon lequel ladite vérification est effectuée pour une transaction d'au moins un type donné. Cette disposition se traduit au niveau du système de l'invention en ce qu'il comprend en outre un module de filtrage apte à soumettre audit module décisionnel complémentaire une demande de vérification pour une transaction d'au moins un type donné. A titre d'exemple, on peut envisager de ne pas soumettre au contrôle complémentaire des transactions dont on estime qu'elles sont suffisamment sécurisées, comme celles contenant un certificat carte à mémoire ou indiquant qu'elles ont été effectuées avec une carte de paiement à puce. Le procédé de sécurisation de l'invention n'est alors utilisé que si ladite transaction est du type vente à distance, réalisée sur l'Internet ou sur formulaire papier, ou également dans le cas où ladite transaction est du type mettant en oeuvre une piste magnétique de ladite carte de paiement. Enfin, l'invention prévoit que ledit critère de contrôle est modifiable par le porteur de la carte de paiement. A cet effet, le système de sécurisation, objet de l'invention, doit être adapté de manière à ce qu'il comprend en outre un module d'interface de configuration destiné à la modification par le porteur de la carte de paiement dudit critère de contrôle. La description qui va suivre en regard du dessin annexé, donné à titre d'exemple non limitatif, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. La figure 1 est un schéma synoptique d'un système de sécurisation conforme à l'invention. Sur la figure 1 est représenté un système de sécurisation d'une transaction entre un commerçant 10 et un client 20 porteur d'une carte de paiement, une carte bancaire, par exemple, éditée par un organisme 30 de gestion, appelé aussi réseau, spécialisé dans la diffusion et le traitement de telles cartes. Pour illustrer le procédé de sécurisation mis en oeuvre par le système de la figure 1, on supposera que ladite transaction est du type vente à distance sur l'Internet. Après avoir fait son choix dans le catalogue qui lui est présenté sur l'écran de son ordinateur personnel, le client 20 doit fournir (1) au commerçant 10 des données d'identification propres à sa carte de paiement, à savoir par exemple son numéro d'identification et sa date d'expiration. A partir de ces données, et d'autres informations liées au contexte de l'achat proprement dit, le commerçant 10 adresse (2) au centre 11 d'autorisation de son institution bancaire une demande d'autorisation de la transaction. Cette demande est transmise (3) au réseau 30 de cartes bancaires qui effectue un certain nombre de vérifications concernant lesdites données d'identification de la carte, numéro et date de validité, ainsi que, par exemple, la présence de la carte sur une liste rouge de cartes frappées d'interdiction. Pour compléter le processus de vérification, le réseau 30 de cartes bancaires consulte (4) le centre 21 d'autorisation de l'institution bancaire du porteur 20 de manière à mettre en oeuvre des contrôles internes, tels que l'état du solde du compte du porteur 20. A toutes ces vérifications qui concernent essentiellement les données d'identification de la carte, le procédé de sécurisation de l'invention ajoute une autre condition d'autorisation consistant en une opération complémentaire de vérification d'au moins un critère de contrôle déterminé par ledit porteur à partir d'au moins un paramètre propre à ladite transaction. A cet effet, le système de sécurisation de transaction de la figure 1 comprend un module décisionnel complémentaire 41 apte à effectuer ladite opération complémentaire de vérification et à autoriser la transaction en cas de vérification positive. Ainsi, le porteur 20 peut décider de refuser systématiquement telles ou telles demandes d'autorisation de transactions financières en fonction de critères qu'il aura définis lui-même. Dans ce cas, le module décisionnel complémentaire 41, consulté (5) par le centre 21 d'autorisation du porteur, renverra (6) une réponse négative à l'acceptation de la transaction. Cette interdiction d'effectuer la transaction sera alors transmise (7, 8) jusqu'au centre 11 d'autorisation du commerçant via le réseau 30. En conséquence, le commerçant 10, informé (9) par son centre 11 d'autorisation, refusera (10) la vente au porteur 20 puisque la demande d'autorisation de la transaction est un échec. On comprend que, dans un tel système, le porteur 20 a une parfaite maîtrise sur le processus d'autorisation : c'est lui et lui seul qui peut faire aboutir positivement une demande d'autorisation de transaction financière. Les critères de contrôle déterminés par le porteur 20 et utilisés par le module décisionnel complémentaire 41 peuvent être de nature très variée. A titre d'exemples, quelques critères possibles vont maintenant être présentés, qu'ils soient pris séparément ou en combinaison. Un premier critère de base a pour paramètre l'existence de la transaction elle-même, à savoir que le porteur 20 a la possibilité d'interdire ou d'autoriser toutes les transactions financières issues d'un traitement selon la procédure de vente à distance. Bien entendu, ce critère peut varier dans le temps, le porteur 20 réalisant un achat à distance pouvant autoriser temporairement pendant une période donnée, une heure par exemple, toutes transactions effectuées suivant cette procédure. Par ailleurs, ce même critère peut aussi être considéré par le module décisionnel complémentaire 41 comme un critère par défaut : en l'absence d'intention exprimée par le porteur 20 à cet égard, le module 41 bloque toutes les demandes d'autorisation qui lui sont présentées. Un second critère de contrôle est lié au paramètre représenté par le nombre de transactions traitées sur une période donnée, fixe ou glissante, définie par le porteur 20. Si, durant la période considérée, ce nombre atteint une valeur maximum, toute transaction demandée ultérieurement est systématiquement refusée. Un troisième critère est paramétré sur le montant de la transaction, que ce soit en valeur unitaire ou en valeur cumulée sur une période de temps fixe ou glissante. Plus précisément, lorsque la transaction dépasse un montant maximum fixé par le porteur 20, l'autorisation de la transaction financière est refusée. De même, lorsque le cumul des transactions effectuées sur une période donnée atteint un plafond fixé par le porteur 20, toute nouvelle transaction présentée n'est pas autorisée. Ce critère peut être traité globalement ou par commerçant. Un quatrième critère de contrôle met en jeu le paramètre constitué par la monnaie de la transaction. Ainsi, un porteur 20 pourra n'autoriser que des transactions financières libellées en francs ou en livres, les autres monnaies d'émission provoquant une réponse négative à la demande d'autorisation. Enfin, un cinquième critère repose sur le paramètre défini par l'identité du commerçant 10. Selon ce critère, un porteur 20 peut n'accepter que les demandes d'autorisation de transactions financières émanant d'un commerçant 10 ou un groupe de commerçants, identifiés par leur nom ou par leur type d'activité. Lors d'un achat par vente à distance, il est alors possible, moyennant la mise à disposition d'un annuaire de commerçants intégrant leurs numéros bancaires, de sélectionner l'acceptation de demandes d'autorisation de transactions provenant de ces seuls commerçants. On peut observer sur la figure 1 la présence dans la procédure d'autorisation d'un module 42 de filtrage dont le rôle est de soumettre au module décisionnel complémentaire 41 les demandes de vérification des critères de contrôle correspondant à des transactions d'un ou plusieurs types donnés. Dans l'exemple choisi, il s'agira de transactions de vente à distance sur Internet, comme elles peuvent tout aussi bien être des transactions de vente à distance sur formulaire papier, ou encore des transactions mettant en oeuvre la piste magnétique des cartes de paiement, ces transactions présentant un niveau de sécurisation insuffisant qui justifie un processus d'autorisation particulier. Ce module 42 de filtrage a donc pour but d'orienter vers le module décisionnel complémentaire 41 les demandes d'autorisation issues, par exemple, d'une vente à distance. Il est intégré à la chaîne de traitement du centre 21 d'autorisation de l'établissement bancaire du porteur 20, lequel procède d'abord à des vérifications qui lui sont propres, tels que l'état du solde du porteur 20, puis fait éventuellement appel au module décisionnel complémentaire 41 si la transaction est d'un type reconnu par le module 42 de filtrage. Ceci a pour effet de limiter les demandes de vérification auprès du module 41. Afin de permettre au porteur 20 de la carte de paiement de modifier ses critères de contrôle, il est prévu un module 43 de configuration servant d'interface entre le porteur 20 et le module décisionnel complémentaire 41. Ce module 43 d'interface de configuration peut se présenter sous diverses formes : - sous la forme d'un serveur Web, WAP ou Minitel. Le porteur 20 accède via son ordinateur personnel, son téléphone mobile ou son terminal Minitel, à un menu lui permettant de manière sécurisée, par identifiant et mot de passe, de configurer le module 41 selon les critères de contrôle de son choix, avec la possibilité de pouvoir éventuellement les combiner. - sous la forme d'un serveur vocal. Les services de configuration du module décisionnel complémentaire 41 peuvent également être accessibles via un serveur vocal. Mais il est clair que le paramétrage ainsi réalisé sera plus grossier, notamment au niveau des combinaisons de critères, qu'avec un serveur Web par exemple, au regard de la qualité de l'interface hommemachine vue du porteur 20. REVENDICATIONS 1. Procédé de sécurisation d'une transaction entre un commerçant (10) et un client (20) porteur d'une carte de paiement, ladite transaction impliquant une demande d'autorisation à partir de données d'identification propres à ladite carte de paiement, caractérisé en ce que la transaction est autorisée après vérification d'au moins un critère de contrôle déterminé par ledit porteur (20) à partir d'au moins un paramètre propre à ladite transaction. 2. Procédé de sécurisation selon la revendication 1, caractérisé en ce que ladite vérification est effectuée pour une transaction d'au moins un type donné. 3. Procédé de sécurisation selon la revendication 2, caractérisé en ce que ladite transaction est du type mettant en oeuvre le réseau Internet. 4. Procédé de sécurisation selon la revendication 2, caractérisé en ce que ladite transaction est du type mettant en oeuvre un formulaire papier. 5. Procédé de sécurisation selon la revendication 2, caractérisé en ce que ladite transaction est du type mettant en oeuvre une piste magnétique de ladite carte de paiement. 6. Procédé de sécurisation selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit critère de contrôle est modifiable par le porteur (20) de la carte de paiement. 7. Procédé de sécurisation selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ledit paramètre propre à la transaction est choisi dans la liste suivante, séparément ou en combinaison : existence de la transaction pendant une période donnée, nombre de transactions sur une période donnée fixe ou glissante, montant de la transaction en valeur unitaire ou cumulée, monnaie de la transaction, identité du commerçant. 8. Système de sécurisation d'une transaction entre un commerçant (10) et un client (20) porteur d'une carte de paiement, ledit système comprenant au moins un organisme (11,30, 21) de gestion apte à autoriser ladite transaction à partir de données d'identification propres à ladite carte de paiement, caractérisé en ce que ledit système comprend également un module décisionnel complémentaire (41) apte à autoriser la transaction après vérification d'au moins un critère de contrôle déterminé par ledit porteur (20) à partir d'au moins un paramètre propre à ladite transaction. 9. Système de sécurisation selon la revendication 8, caractérisé en ce qu'il comprend en outre un module (42) de filtrage apte à soumettre audit module décisionnel complémentaire (41) une demande de vérification pour une transaction d'au moins un type donné. 10. Système de sécurisation selon la revendication 9, caractérisé en ce que ladite transaction est du type mettant en oeuvre le réseau Internet. 11. Système de sécurisation selon la revendication 9, caractérisé en ce que ladite transaction est du type mettant en oeuvre un formulaire papier. 12. Système de sécurisation selon la revendication 9, caractérisé en ce que ladite transaction est du type mettant en oeuvre une piste magnétique de ladite carte de paiement. 13. Système de sécurisation selon l'une quelconque des revendications 8 à 12, caractérisé en ce qu'il comprend en outre un module (43) d'interface de configuration destiné à la modification par le porteur (20) de la carte de paiement dudit critère de contrôle. 14. Système de sécurisation selon l'une quelconque des revendications 8 à 13, caractérisé en ce que ledit paramètre propre à la transaction est choisi dans la liste suivante, séparément ou en combinaison : existence de la transaction pendant une période donnée, nombre de transactions sur une période donnée fixe ou glissante, montant de la transaction en valeur unitaire ou cumulée, monnaie de la transaction, identité du commerçant. 15. Module décisionnel complémentaire (41) pour un système de sécurisation d'une transaction entre un commerçant (10) et un client (20) porteur d'une carte de paiement selon l'une quelconque des revendications 8 à 14, caractérisé en ce que ledit module décisionnel complémentaire (41) est apte à autoriser la transaction après vérification d'au moins un critère de contrôle déterminé par ledit porteur (20) à partir d'au moins un paramètre propre à ladite transaction. 16. Module (42) de filtrage pour un système de sécurisation d'une transaction entre un commerçant (10) et un client (20) porteur d'une carte de paiement, ledit système comprenant un module décisionnel complémentaire (41) selon la revendication 15, caractérisé en ce que ledit module (42) de filtrage est apte à soumettre audit module décisionnel complémentaire (41) une demande de vérification pour une transaction d'au moins un type donné. 17. Module (43) d'interface de configuration pour un système de sécurisation d'une transaction entre un commerçant (10) et un client (20) porteur d'une carte de paiement, ledit système comprenant un module décisionnel complémentaire (41) selon la revendication 15, caractérisé en ce que ledit module (43) d'interface de configuration est destiné à la modification par le porteur (20) de la carte de paiement dudit critère de contrôle.