FR 2851103 A1 20040813 FR 0350014 A 20030206 La présente invention concerne un système de sécurisation d'une opération à effectuer entre une première entité et une deuxième entité, sur présentation par la première entité à la deuxième entité d'un code d'identification. L'invention s'applique de manière avantageuse, mais non limitative, au domaine de la sécurisation d'opérations effectuées à distance, notamment à travers un réseau de télécommunication tel que l'Internet, par exemple. Parmi les opérations effectuées à distance entre deux entités mettant en oeuvre un code d'identification, on peut citer les transactions impliquant 10 une première entité, le client, et une deuxième entité, le marchand. Au cours d'une telle transaction, le marchand est généralement amené à demander au client de lui présenter un code d'identification destiné essentiellement au règlement du montant de la transaction. Le plus souvent, ce code d'identification est un numéro de carte bancaire, éventuellement accompagné 1 5 d'une date d'expiration. En réponse à la demande du marchand, le client saisit alors le numéro de sa carte et la date d'expiration, si nécessaire, et les présente au marchand pour conclure la transaction. Dans la plupart des cas, le numéro de carte présenté au marchand par le client est un numéro permanent correspondant à celui de la carte physique, 20 en général à puce, délivrée par la banque au client. Cependant, même si elles offrent une image attrayante par l'innovation qu'elles représentent, ces opérations effectuées à distance avec présentation d'un numéro de carte bancaire permanent provoquent bien souvent une certaine réticence liée aux risques qui y sont associés. En effet, la fraude 25 attachée au paiement par cartes bancaires sur l'Internet a fortement contribué à dégrader la confiance des consommateurs en ce nouveau type de transactions. Afin de regagner la confiance des consommateurs, des opérateurs de cartes bancaires ont proposé un service dit de "carte virtuelle dynamique", ou 30 CVD, dont le principe est le suivant: au lieu de présenter son numéro de carte bancaire permanent au marchand, le client requiert auprès d'une troisième entité, un opérateur de CVD, la fourniture d'un numéro de carte virtuelle dynamique et le présente au marchand. Ce numéro de carte dynamique fait office de code d'identification temporaire dans la mesure o son usage est 5 limité, voire unique, et protège de ce fait le consommateur contre les conséquences d'une fraude éventuelle. Ces systèmes de paiement mettant en oeuvre des numéros de carte dynamique présentent l'avantage d'être totalement transparents pour le marchand puisqu'ils n'impliquent aucune modification ni aucun équipement 10 supplémentaire. Par contre, ils ne permettent pas au marchand de savoir si le numéro présenté par le client est un numéro de carte permanent ou un numéro temporaire. Or, dans le cas o il s'agit d'un numéro temporaire, la probabilité pour que ce numéro soit un numéro fraudé est bien plus faible que dans le cas o il s'agit d'un numéro permanent attaché à une carte physique. 15 Par conséquent, n'étant pas en mesure de contrôler l'origine du numéro qui lui est présenté par le client, le marchand ne peut intervenir sur l'acceptation ou le refus de la transaction, ce qui, compte tenu des risques encourus, conduit à une situation inacceptable o l'intégrité de la transaction ne serait pas garantie. Aussi, le problème technique à résoudre par l'objet de la présente invention est de proposer un système de sécurisation d'une opération à effectuer entre une première entité, disposant d'un code d'identification permanent, et une deuxième entité, sur présentation par la première entité à la deuxième entité d'un code d'identification, ledit système comprenant une 25 troisième entité apte à fournir à la première entité, sur requête, un code d'identification temporaire, système qui permettrait à la deuxième entité de s'assurer de la sécurité de l'opération à effectuer. La solution au problème technique posé consiste, selon la présente invention, en ce que la troisième entité est apte à vérifier sur requête de la 30 deuxième entité que le code d'identification présenté par la première entité n'est pas un code d'identification permanent. Ainsi, la deuxième entité, le marchand dans l'exemple d'application évoqué plus haut, dispose d'un moyen pour contrôler que le numéro de carte présenté par la première entité, le client, est bien temporaire et non permanent. S'il s'avérait que le numéro présenté était permanent, donc de sécurité moindre, le marchand pourrait interdire la transaction. D'autre part, l'invention prévoit également que la troisième entité est apte à effectuer et à fournir à la deuxième entité une validation du code 5 d'identification temporaire présenté par la première entité. Plus particulièrement, selon l'invention, ladite validation consiste à vérifier que le code d'identification présenté par la première entité est un code d'identification temporaire effectivement fourni par la troisième entité et qu'il n'a pas été déjà utilisé. Il s'agit là de contrôles visant à garantir non seulement que le code d'identification présenté est bien connu de la troisième entité qui l'a fourni mais également qu'il n'a pas été rejoué par une personne non autorisée qui l'aurait obtenu à l'insu de la première entité. C'est d'ailleurs dans ce but que, selon une autre option avantageuse de 15 l'invention, la troisième entité est apte à vérifier que l'entité ayant présenté le code d'identification temporaire à la deuxième entité est ladite première entité, auteur de ladite requête. Enfin, un contrôle optionnel supplémentaire consiste, selon l'invention, en ce que, une date de validité ayant été attribuée audit code d'identification 20 temporaire, la troisième entité vérifie que ladite date de validité n'est pas expirée. On remarquera que l'ensemble de ces contrôles réalisés par la troisième entité permet de réduire le risque de refus au moment de la demande d'autorisation de la transaction émise par le marchand vers la 25 banque du client. Les frais liés aux demandes d'autorisation étant généralement imputés aux marchands, il y a en effet avantage pour ces derniers de limiter les demandes d'autorisation qui n'auraient a priori aucune chance d'aboutir. La description qui va suivre en regard du dessin annexé, donné à titre 30 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é sous forme schématique un système de 35 sécurisation d'une opération à effectuer entre une première entité 10 et une deuxième entité 20. Comme cela a déjà été évoqué plus haut, l'opération à effectuer peut être une transaction impliquant un client en tant que première entité 10 et un marchand en tant que deuxième entité 20. On prendra ici un exemple particulier de transaction consistant pour un 5 client 10 à recharger un téléphone mobile 12 auprès d'un marchand 20, en l'occurrence un opérateur de téléphonie mobile. En effet, suite aux nombreux cas de fraudes observés, les opérateurs de téléphonie mobile n'acceptent le paiement à distance par carte bancaire dans le cadre du rechargement de téléphones mobiles qu'avec de très fortes contraintes pour l'utilisateur 10 (présentation de deux attestations d'identité par exemple). Ce moyen de paiement est donc devenu très marginal pour les opérateurs de téléphonie mobile. C'est dans ce contexte que le système de sécurisation, objet de l'invention, prend tout son intérêt puisqu'il permet de garantir aux opérateurs un paiement avec des risques limités. Dans l'application choisie, le client 10 dispose d'un terminal 11 de communication, ici par exemple un ordinateur personnel, tandis que l'opérateur 20 de téléphonie mobile est équipé d'un serveur 21, le terminal 11 du client et le serveur 21 de l'opérateur étant mis en relation via l'lnternet ou un réseau téléphonique. Dans un premier temps, le client 10 se connecte (1) 20 au moyen de son terminal 11 sur le site Web de l'opérateur 20 par exemple et accède au service de rechargement de téléphones mobiles, lequel est installé sur un serveur 31 SOP (Serveur OPérateur) hébergé sur une troisième entité, opérateur de cartes virtuelles dynamiques CVD, représentée par la plateforme 30 de la figure 1. Après que le client 10 ait saisi sur un formulaire de demande de rechargement présenté sur l'écran de son terminal 11 les détails de la transaction: numéro du téléphone mobile12 à recharger, type de recharge, montant de la recharge, l'opérateur 20 invite le client 10 à lui présenter un code d'identification destiné au règlement du montant de la recharge, ici un 30 numéro de carte bancaire. Plutôt que de fournir le numéro de sa carte bancaire physique, dit numéro de carte permanent, le client 10 requiert (2) auprès de la plate-forme 30, par l'intermédiaire de son terminal 11, la fourniture d'un numéro temporaire de carte virtuelle dynamique CVD. En réponse, un serveur 32 de carte virtuelle dynamique SCVD retourne (3) sur le terminal 11 du client 10 un numéro de CVD. Le client 10 peut alors répondre (4) à l'invitation de l'opérateur 20 en lui présentant le numéro temporaire de carte virtuelle dynamique CVD qu'il a obtenu de la plate-forme 30. Avant de transmettre (7) une demande d'autorisation à la banque du client 10, le serveur 21 de l'opérateur 20 effectue auprès de la plate-forme 30 un certain nombre de contrôles visant à assurer une sécurisation maximale de la transaction. io C'est dans ce but que le serveur 21 envoie (5) au serveur 31 SOP de la plate-forme 30 le numéro de carte bancaire que lui a présenté le client 10 via son terminal 11, accompagné d'une requête visant à obtenir de la plate-forme 30 qu'elle vérifie que ce numéro n'est pas un numéro permanent, ceci en conformité avec l'exigence de l'opérateur 20 rappelée plus haut de ne pas 15 accepter les règlements par cartes bancaires physiques telles qu'elles sont délivrées par les institutions bancaires accompagnées d'un numéro permanent. Cette vérification peut consister à obtenir auprès du serveur 31 de la plate-forme 30 une validation du numéro temporaire de la carte virtuelle 20 dynamique CVD, et notamment à vérifier que le numéro de carte présenté par le client 10 est bien un numéro temporaire effectivement fourni par le serveur 32 SCVD de la plate-forme 30 et que ce numéro temporaire n'a pas déjà été utilisé. Un autre contrôle possible consiste à attribuer une date de validité au 25 numéro temporaire de CVD au moment o il est fourni au client 10 et à vérifier que ladite date de validité n'est pas expirée lorsque le numéro temporaire est présenté par le client à l'opérateur 20. On peut également envisager qu'un contrôle supplémentaire soit effectué par le serveur 31 SOP dans le but de s'assurer que la personne qui a 30 présenté le numéro temporaire de CVD est bien le client 10 ayant requis le numéro temporaire auprès du serveur 32 SCVD. Cette vérification est possible lorsque l'accès (1) au service ou la requête (2) d'un numéro temporaire est précédé d'une étape d'authentification du client 10 à l'aide d'un identifiant, éventuellement accompagné d'un mot de passe. Il est alors facile 35 pour la plate-forme 30 de vérifier que la personne associée audit identifiant est bien la même que celle à laquelle a été attribué le numéro temporaire de CVD. Si tous les contrôles sont positifs, le serveur 31 SOP en informe (6) l'opérateur 20 qui peut donc poursuivre la procédure transactionnelle en transmettant (7) à la banque du client 10 une demande d'autorisation. A réception de l'autorisation de la banque, le serveur 21 de l'opérateur confirme (8) la transaction au terminal 11 du client 10. Eventuellement, le serveur 21 peut également envoyer (9) sur le téléphone mobile 12 un message court (SMS) de confirmation informant le client 10 que le téléphone 10 mobile 12 a bien été rechargé. La description qui précède fait référence à un opérateur de téléphonie mobile en tant que marchand, mais il est bien entendu que le système de sécurisation conforme à l'invention peut être mis en oeuvre pour tout type de transactions impliquant n'importe quelle catégorie de marchands. De même, la portée de l'invention ne saurait être limitée aux seules transactions entre clients et marchands, mais s'étend également à des opérations de nature quelconque dès lors qu'elles concernent deux entités dont l'une requiert de l'autre la présentation d'un code d'identification. REVENDICATIONS 1. Système de sécurisation d'une opération à effectuer entre une première entité (10) disposant d'un code d'identification permanent, et une deuxième entité (20), sur présentation par la première entité à la deuxième entité d'un code d'identification, ledit système comprenant une troisième entité (30) apte à fournir à la première entité (10), sur requête, un code (CVD) i0 d'identification temporaire, caractérisé en ce que la troisième entité (30) est apte à vérifier sur requête de la deuxième entité (20) que le code d'identification présenté par la première entité (10) n'est pas un code d'identification permanent. 2. Système de sécurisation selon la revendication 1, caractérisé en ce 15 que la troisième entité (30) est apte à effectuer et à fournir à la deuxième entité (20) une validation du code (CVD) d'identification temporaire présenté par la première entité (10). 3. Système de sécurisation selon la revendication 2, caractérisé en ce que ladite validation consiste à vérifier que le code d'identification présenté 20 par la première entité (10) est un code (CVD) d'identification temporaire effectivement fourni par la troisième entité (30) et qu'il n'a pas été déjà utilisé. 4. Système de sécurisation selon l'une des revendications 2 ou 3, caractérisé en ce que, une date de validité ayant été attribuée audit code (CVD) d'identification temporaire, la troisième entité (30) vérifie que ladite 25 date de validité n'est pas expirée. 5. Système de sécurisation selon l'une quelconque des revendications 2 à 4, caractérisé en ce que la troisième entité (30) est apte à vérifier que l'entité ayant présenté le code (CVD) d'identification temporaire à la deuxième entité (20) est ladite première entité (10), auteur de ladite requête.