La présente invention concerne un procédé de traitement des données d'un titre de transport. Un titre de transport est ce qui permet à un utilisateur d'utiliser des services de transport publics, tels que le métro, le train, le bus... Un titre de transport comporte un support physique, le support de titre, sur lequel sont mémorisées des données. On distingue ainsi le support logique (titre de transport), c'est à dire l'ensemble formé par le support physique et ses données, du support physique en tant que tel. Le support physique peut être de différentes technologies: magnétique, carte à puce avec ou sans contact, jeton à puce... Les données qui sont mémorisées sont des données relatives à un ou plusieurs contrats d'utilisation d'un service de transport. Un contrat d'utilisation d'un service de transport est couramment appelé un produit, car c'est ce qui est vendu par les opérateurs de transport. Un produit peut être par exemple un abonnement mensuel à un service de métro dans une zone géographique déterminée. On appelle instance de produit ou de contrat les données associées à un contrat qui sont mémorisées sur un support physique. D'autres données peuvent être mémorisées sur le support physique. Ces autres données peuvent être des données personnelles (nom, adresse, date de naissance...) décrivant le titulaire du titre de transport. Bien entendu, les titres de transports anonymes (billets de métro par exemple) ne comportent pas de données personnelles. De façon conventionnelle, une instance de produit est mémorisée sous la forme d'un fichier. Le fichier comporte plusieurs enregistrements présentant chacun le même format. Un enregistrement est composé de champs. La norme ENV 1545 (1998) du CEN (Comité Européen de Normalisation) définit par exemple des formats des champs de données enregistrés. Il existe de nombreux champs dans un fichier d'instance de contrat. On trouve notamment un champ de tarification, un champ d'identification de l'instance, des champs relatifs à la vente, des champs relatifs à la validité du contrat... Le champ de tarification peut être codé par un nombre entier identifiant lès règles qui s'appliquent à la détermination du prix, de la validation et du contrôle d'un contrat. Ces règles et leur application sont connues du système, notamment les équipements frontaux. Le champ d'identification de l'instance est un numéro de série unique qui permet d'identifier cette instance de contrat. Les champs relatifs à la vente comprennent par exemple la date et l'heure de vente du contrat, un numéro d'identification de l'équipement frontal ayant servi à la vente... Les champs relatifs à la validité du contrat comprennent par exemple des informations sur le point de départ du voyage, la destination, le nombre de zones autorisées, une date de fin de validité... Les équipements réalisant des opérations de lecture ou d'écriture sur les titres de transports sont appelés des équipements frontaux, c'est à dire appartenant au "front-office". On les désigne aussi par l'acronyme MAD issu de l'expression anglo-saxonne "Media Access De vice". On trouve parmi ces équipements les équipements de validations, qui peuvent permettre de valider un titre à l'entrée d'une zone payante ("check-in") ou à sa sortie ("check-out"). Les équipements de validations doivent traiter les titres rapidement. Cette contrainte sur le temps de traitement ne leur permet pas de lire toutes données des instances de contrat mémorisées. Le procédé selon l'invention permet à un équipement frontal tel q'un équipement de validation, de sélectionner le contrat le plus approprié, et ce avec un temps de traitement réduit. A cet effet, l'invention a pour objet un procédé de traitement d'un titre de transport dans lequel sont mémorisées des instances de contrat, caractérisé en ce que: • on lit un fichier de présélection, le fichier de présélection comprenant un enregistrement par instance de contrat mémorisée, chaque enregistrement comportant au moins un champ de sélection d'une part et un pointeur référençant une instance de contrat d'autre part, • on prépare une liste de présélection, à partir des données lues dans le fichier de présélection, la liste de présélection référençant les instances de contrat mémorisées par ordre de préférence. L'invention a aussi pour objet Titre de transport dans lequel sont mémorisées des instances de contrat, caractérisé en ce qu'est aussi mémorisé un fichier de présélection, le fichier de présélection comprenant un enregistrement par instance de contrat mémorisée, chaque enregistrement comportant au moins un champ de sélection d'une part et un pointeur référençant une instance de contrat d'autre part, le fichier de présélection étant destiné à être utilisé par ce procédé. L'invention présente plusieurs avantages. D'une part, l'invention permet en outre de mettre en œuvre des règles de sélection complexes pour choisir le contrat le plus approprié. D'autre part, l'invention est particulièrement utile lorsqu'un titre de transport est partagé par plusieurs opérateurs de transports différents. En effet, dans un tel contexte, un titre de transport peut contenir une pluralité de contrats provenant d'opérateurs différents, certains opérateurs ne pouvant pas traiter les données d'autres opérateurs. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description détaillée suivante présentée à titre d'illustration non limitative et faite en référence aux figures annexées, lesquelles représentent : la figure 1 , un exemple de procédé selon l'invention, la figure 2, un exemple de fichier enregistré sur le titre de transport pour la mise en œuvre du procédé selon l'invention.

On se réfère maintenant à la figure 1. Selon l'invention, on enregistre dans le titre de transport un fichier de présélection. Le fichier de présélection contient certaines informations relatives aux contrats, et plus précisément relatives aux instances de contrats mémorisées dans le titre de transport. Le fichier de présélection est en quelque sorte un résumé des informations contenues dans les instances de contrats, ce résumé servant à effectuer une présélection. La présélection 1 est un traitement au cours duquel on prépare une liste de présélection référençant les instances de contrat par ordre de préférence d'utilisation. Un exemple d'un tel traitement sera décrit plus en détail ci-dessous. Une fois la présélection 1 réalisée, on peut lire les données des instances de contrat sélectionnées à l'étape de présélection, et ce dans l'ordre de préférence d'utilisation, jusqu'à obtenir une instance de contrat utilisable. Cette instance de contrat correspond au contrat choisi. On peut alors traiter les données de cette instance de contrat pour effectuer une validation par exemple, lors de l'entrée ("check-in") ou de la sortie ("check- out") d'une zone payante. On se réfère maintenant à la figure 2. Le fichier de présélection 3 comporte un enregistrement 31 par instance de contrat. Chaque enregistrement présente le même format et est composé de champs 32, 33, 34, 35. On trouve parmi ces champs des champs de sélection 32, 33, 34 d'une part, et un pointeur d'autre part 35. Le pointeur 35 permet d'associer un enregistrement du fichier de présélection à une instance de contrat particulière. Selon l'invention, on définit une priorité utilisateur associée à chaque instance de produit. Une priorité utilisateur représente une préférence émise par l'utilisateur dans l'ordre d'utilisation des produits qu'il détient dans son titre de transport. La priorité utilisateur peut être une donnée d'un champ de sélection. Selon l'invention, on définit aussi un état de veille. Lorsqu'un produit est dans un état de veille, il ne peut être utilisé par un équipement frontal sans avoir été préalablement activé. L'état de veille peut être une donnée d'un champ de sélection. Selon un mode de réalisation avantageux, la priorité utilisateur et l'état de veille sont codés dans un même champ de sélection 34. Ce champ, désigné par "UserPreference" dans la suite de la description, peut être codé par un entier par exemple. Une valeur de cet entier permet de marquer les produits dans un état de veille. Les autres valeurs de cet entier permettent de définir une priorité utilisateur. Dans ce cas, le fait de définir une priorité utilisateur signifie implicitement qu'un produit est activé, et le fait de placer un produit dans un état de veille empêche de définir une priorité utilisateur pour ce produit. Ceci n'est pas gênant dans la mesure où un produit placé dans un état de veille ne doit jamais être utilisé. Bien entendu, il est possible d'utiliser des champs de sélection différents pour enregistrer la priorité utilisateur d'une part, et pour marquer les produits qui sont dans un état de veille d'autre part. Selon un mode de réalisation pratique, le champ "UserPreference" est codé sur un octet. Les priorités utilisateurs peuvent prendre trois valeurs (1, 2 et 3 par exemple), la valeur plus faible correspondant au produit le moins préféré, la valeur la plus élevée correspondant au produit préféré. On peut associer l'état de veille du produit à une valeur plus faible (0) que la priorité la plus faible (1 ). Dans la suite de la description, les valeurs possibles du champ "UserPreference" sont désignées dans l'ordre croissant par "produit préféré", "produit normal", "produit moins préféré", et "produit suspendu", la valeur "produit suspendu" correspondant à un produit dans l'état de veille. Lorsqu'un produit est vendu, on peut enregistrer dans le titre de transport une instance de produit dont la priorité utilisateur a une valeur "produit normal" par défaut. Bien entendu, cette valeur par défaut peut être remplacée par une autre valeur spécifiée par l'utilisateur. On décrit maintenant d'autres champs de sélections possibles. Un champ de sélection 33 peut permettre de déterminer si une instance particulière est déjà en cours d'utilisation ou non. Une telle situation se présente dans le cas d'un transfert d'un mode de transport à un autre par exemple. Ce champ permet de résoudre des conflits potentiels dans la recherche de contrats, c'est à dire d'utiliser un contrat en cours plutôt que d'en utiliser un nouveau. Ce champ 33 peut être codé par une valeur logique, c'est à dire de type boolean. On désigne ce champ par "IsUsed" dans la suite de la description. Un autre champ de sélection 32 contenir un identificateur définissant la famille de contrat à laquelle chaque instance de contrat appartient. Une famille de contrat correspond à une définition générale du contrat, c'est à dire à une classe de contrat (appelée "template" dans la littérature anglo-saxonne). L'identificateur peut être codé par un nombre entier. On désigne ce champ 32 par "ProductTemplate" dans la suite de la description. Dans un contexte multi-opérateur, les familles de produit disposent d'un identificateur unique et partagé par les opérateurs de transport. En d'autres termes, il n'y a pas de collision entre les numéros identifiant les familles de contrats d'opérateurs de transports différents. Une famille de contrat définit par exemple: • la liste des opérateurs de transports chez qui on peut utiliser un contrat de cette famille, • la liste de modes de transports pouvant être utilisés avec les contrats de cette famille, • la liste des zones géographiques dans lesquelles peut voyager le titulaire d'un contrat de cette famille, • la liste des lignes de transports (train, métro, bus...) pouvant être utilisées par le titulaire d'un contrat de cette famille, • des caractéristiques relatives aux limites de validités temporelles des contrats de cette famille... D'autres caractéristiques peuvent être définies dans une famille de contrat, ces caractéristiques n'étant pas utiles à l'étape de présélection. On peut notamment définir le nom de la famille, la liste des détaillants autorisés à vendre les produits de cette famille, la liste des profils voyageurs autorisés (étudiant, militaire, personne âgé,...)... On se réfère à nouveau à la figure 1 pour décrire plus en détail l'exemple de mise en œuvre du procédé de sélection d'un produit à valider. Le procédé de sélection comporte deux étapes principales, une étape de présélection 1 selon l'invention, et une étape de choix du produit à valider 2 à partir du résultat de la présélection. La présélection débute par la lecture 10 de tous les enregistrements du fichier de présélection pour former une liste de présélection initiale. A partir de cette liste de présélection initiale, on réalise une ou plusieurs étapes de filtrage, ces étapes de filtrage étant optionnelles. Elles permettent de ne retenir parmi les instances mémorisées dans le titre de transport uniquement celles pertinentes. Une première étape de filtrage 11 consiste à ne retenir que les contrats activés, c'est à dire pour lesquels le contrat n'est pas dans un état ». de veille. Ce filtrage est réalisé simplement en éliminant de la liste de présélection les enregistrements pour lesquels le champ "UserPreference" 34 a une valeur "produit suspendu". Une seconde étape de filtrage 12 consiste à ne retenir que les contrats reconnus par l'opérateur de transport dont l'équipement cherche à traiter le titre de transport. Ce filtrage est réalisé simplement en éliminant de la liste de présélection les enregistrements pour lesquels le champ : "ProductTemplate" 32 a une valeur non comprise - dans une liste prédéterminée de l'équipement. Bien entendu, les étapes de filtrage décrites ci-dessus le sont à titre d'illustration. Des variantes peuvent être envisagées pour éliminer des enregistrements (chaque enregistrement correspond à une instance de contrat) de la liste de présélection. Si à l'issu de l'une ou l'autre étape de filtrage, la liste de présélection est vide, le traitement du titre s'arrête sans qu'aucun contrat n'ait pu être sélectionné. On décrit maintenant l'étape de tri 13 des contrats référencés par la liste de présélection (restant après filtrage le cas échéant) par ordre de préférence. Le tri des contrats peut être réaliser en pratique en triant les enregistrements de la liste de présélection. On peut classer les enregistrements en utilisant plusieurs critères de tri successif. Un premier critère de tri peut être basé sur la valeur du champ "Isllsed" 33. En d'autres termes, on préférera utiliser en priorité un contrat en cours plutôt que d'en utiliser un nouveau Un second critère de tri peut être basé sur la valeur de la priorité utilisateur. On utilise à cet effet la valeur du champ "UserPreference" 34. Dans ce mode de réalisation avantageux, il suffit de classer les enregistrements avec la valeur de ce champ (par valeurs décroissantes). On notera que la présence de l'étape de filtrage 11 qui précède rend encore plus pratique l'utilisation d'un codage de l'état de veille et de la priorité utilisateur sur un seul champ. Un troisième critère de tri peut être basé sur une priorité donnée par l'opérateur de transport auquel appartient l'équipement traitant de titre. Ce critère de tri peut être basé sur la valeur du champ "ProductTemplate" 32. Un opérateur de transport pourra ainsi choisir de valider de préférence un contrat qu'il a vendu plutôt qu'un contrat vendu par un tiers. Un quatrième critère de tri peut être de sélectionner en priorité les contrats les plus récents. A cet effet, on peut trier les enregistrements par ordre d'apparition dans la de présélection initiale, dans la mesure où les enregistrements correspondants aux nouveaux contrats sont placés en tête du fichier de présélection. Ceci peut être réalisé simplement en numérotant les enregistrement lors de la lecture du fichier de présélection, ce numéro étant ensuite utilisé pour le quatrième critère de tri. A la fin du tri, on dispose d'une liste de présélection avec des enregistrements triés par ordre de préférence. Cette présélection permet de gagner du temps dans la suite du traitement car la plupart des contrats inutilisables sont déjà supprimés, leurs données n'ayant pas à être lues, et car les contrats restant sont triés. On décrit maintenant l'étape de choix 2 du produit à valider. On lit 20 les données du premier contrat référencé par la liste de présélection. A partir de ces données, on teste la validité géographique et temporelle du contrat. Si le contrat est valide, on le choisit. Sinon, on poursuit le traitement avec la lecture 21 de données du contrat suivant. Bien entendu, l'invention ne se limite pas à ce mode de réalisation décrit. On comprendra par exemple que l'ordre dans lequel sont effectuées les étapes de tri ou de filtrage n'a pas d'importance, l'étape de tri pouvant par exemple précéder les étapes de filtrages, ou certaines étapes de filtrage seulement.