La présente invention concerne, de façon générale, le domaine des cartes à puce dites «' intelligentes » (Smartcard selon la terminologie anglo-saxonne) , au sens où de telles cartes constituent un support électronique de données, qui se présente sous la forme d'une carte à format réduit, doté de plus d'une capacité de traitement mise en œuvre par un microprocesseur et son système d'exploitation et leur environnement (mémoires de différents types, entrées/ sorties) . l'invention concerne plus particulièrement les cartes à puce multi-applicatives, comprenant une pluralité d'applications installées sur la même carte, permettant donc l'exécution d'applications évoluées, dédiées à des usages variés. Dans ce contexte, c'est principalement l'entité émettrice de la carte qui est compétente en ce qui concerne la gestion du contenu de la carte. Ainsi, elle est seule à pouvoir exécuter certaines fonctions de gestion des applications, telles que le chargement d'une application sur la carte, l'installation de l'application ou encore la suppression de l'application de la carte. Les applications installées sur la carte sont typiquement développées par l'entité émettrice de la carte dans un environnement sécurisé. Toutefois, un déploiement d'applications sur la carte uniquement sous l'autorité de l'entité émettrice de la carte présente des inconvénients, en terme de souplesse et d'adaptabilité aux différents besoins des utilisateurs notamment. D'ailleurs, on cherche de plus en plus à faire de la carte à puce un environnement d'exécution de programme ouvert, permettant un chargement dynamique d'applications. On cherche également à rendre plus souples et plus évolutive la gestion des applications cartes. On se place donc dans un contexte où les applications cartes ne sont plus développées sous le contrôle de l'entité émettrice de la carte, mais sont développées et proposées par des fournisseurs d'applications tiers, qui sont propriétaires de leurs applications. Ces applications propriétaires sont susceptibles d'être chargées dynamiquement dans la carte postérieurement à sa délivrance par l'entité émettrice, à travers un réseau quelconque par exemple. II est donc nécessaire dans ce cas, pour le fournisseur d'applications, de passer des arrangements contractuels, tant commerciaux que techniques, entre lui et l'entité émettrice de la carte, afin de définir les conditions d'utilisation de son ou ses applications susceptibles d'être installées sur la carte. Ce contrat passé entre le fournisseur d'applications et l'entité émettrice de la carte se traduit concrètement par l'installation sur la carte, lors de son initialisation, d'un domaine de sécurité associé au fournisseur d'applications, qui correspond en quelque sorte à un droit d'usage donné par l'entité émettrice de la carte au fournisseur d'application. Ainsi, chaque application ultérieurement chargée sur la carte doit être associée à un domaine de sécurité, qui est spécifié par l'entité émettrice de la carte lorsque l'application est téléchargée. Les différents domaines de sécurité sont implémentés sur la carte par l'intermédiaire d'applications spécifiques, une pour chaque domaine de sécurité, permettant de mettre en œuvre et de faire respecter le mode de fonctionnement défini contractuellement entre l'entité émettrice de la carte et chaque fournisseur d'applications. Ces applications spécifiques de domaine de sécurité ont notamment pour rôle d'authentifier et de vérifier les applications du fournisseur d'applications associé pendant le processus de téléchargement. Elles offrent également des services communs pour toutes les applications d'un fournisseur d'applications donné, sans quoi l'exécution de l'application sur la carte n'est pas possible. Le domaine de sécurité d'un fournisseur d'applications est donc l'application, créée sur la carte lors de son initialisation, qui est garante du bon fonctionnement des applications de ce fournisseur installées sur la carte postérieurement à sa délivrance. Ainsi, lors de la phase de chargement et d'installation d'une application sur une car.te multi- applicative, il est primordial de s'assurer que l'application en question est bien rattachée au domaine de sécurité de la carte associé au fournisseur de l'application concerné. De cette façon, le fournisseur d'applications, propriétaire de l'application en question, est assuré que les règles de fonctionnement et d'utilisation de son application sur la carte, fixées contractuellement avec l'entité émettrice de la carte, seront respectées. Or, jusqu'alors, c'est l'entité émettrice de la carte qui spécifie le domaine de sécurité associé à l'application lors de son téléchargement. Il n'existe pas de mécanismes spécifiques mis en œuvre sur la carte, permettant de renforcer les obligations contractuelles passées entre le fournisseur de l'application et l'entité émettrice de la carte, de sorte à ce que le fournisseur de l'application puisse être assuré que l'utilisation sur la carte de son application sera bien conforme à ce qui a été prédéfini, en d'autres termes que l'application chargée et installée sur la carte est bien rattachée à son domaine de sécurité. Par ailleurs, la gestion du cycle de vie des applications d'un fournisseur d'application est placée sous l'autorité de l'entité émettrice de la carte, conformément aux conditions de fonctionnement prévues initialement par contrat entre l'entité émettrice et le fournisseur. Ainsi, l'entité émettrice de la carte est habilitée à prendre la main sur l'application d'un fournisseur d'applications déjà installée sur la carte, notamment pour la verrouiller de sorte à en contrôler l'accès ou encore pour la supprimer de la carte, lorsque l'accord entre le fournisseur et l'entité émettrice a expiré par exemple. Là encore, aucun mécanisme spécifique n'est prévu sur la carte pour s'assurer que l'autorisation du fournisseur d'application a bien été donnée par ce dernier pour permettre la suppression ou le verrouillage d'une ou de ses applications sur la carte. Cette autorisation est importante dans la mesure où une application sur carte demeure de la responsabilité du fournisseur de cette application et toute action sur celle-ci devrait normalement être effectuée avec le consentement du fournisseur propriétaire de l'application. Egalement, dans le contexte d'une carte multi- applicative, lorsqu'une application est chargée, elle importe le plus souvent d'autres applications ou API (acronyme anglo-saxon pour « Application Programming Interface ») qui sont déjà installées sur la carte et qui sont nécessaires à sa mise en œuvre sur la carte. En effet, l'application a besoin de faire appel à des bibliothèques de programmes regroupant des collections de fonctions pour fonctionner et, dans le contexte d'une carte multi-applicative, l'application chargée doit indiquer ces bibliothèques de façon à ce que le système d'exploitation de la carte puisse faire l'édition de liens. Or, sur une carte à puce multi-applicative formant une plate-forme ouverte, il n'existe aucun mécanisme permettant de contrôler l'utilisation d'une API ou d'une application développée par un fournisseur par un autre fournisseur d'application. Ainsi, un fournisseur d'application peut utiliser toute API appartenant à un autre fournisseur d'application, au détriment des droits de propriété de ce dernier. Dans ce contexte, la présente invention, qui se fonde sur ces différents constats, a pour but de prévoir des mécanismes spécifiques, permettant de s'assurer de l'autorisation d'un fournisseur d'applications préalablement à toute action effectuée sur une application délivrée par ce fournisseur sur une carte multi-applicative, de sorte que le fournisseur d'applications puisse contrôler l'accès et l'utilisation de ses applications sur la carte et donc assurer notamment le respect de ses droits de propriété. La présente invention vise ainsi à renforcer les conditions de réalisation des liens contractuels qui sous-tendent la coopération entre l'entité émettrice de la carte et le fournisseur d'applications, Avec cet objectif en vue, l'invention a ainsi pour objet un procédé de gestion d'un dispositif électronique multi-applicatif, comprenant un système d'exploitation prévu pour supporter une pluralité d'applications, chaque application appartenant à un fournisseur d'applications disposant d'un domaine de sécurité qui lui est propre installé initialement sur le dispositif, ledit procédé étant caractérisé en ce que, à la réception d'une commande de chargement d'une application sur le dispositif, ledit système d'exploitation vérifie que ladite application est associée à un domaine de sécurité correspondant au domaine de sécurité du fournisseur de ladite application et, en cas de succès de la vérification, autorise son chargement et son installation sur le dispositif en la rattachant automatiquement audit domaine de sécurité. Selon un premier mode de réalisation, l'étape de vérification consiste à rechercher parmi les domaines de sécurité installés sur le dispositif, celui dont l'identifiant de fournisseur d'application correspond à l'identifiant de l'application devant être chargée. Selon un deuxième mode de réalisation, la commande de chargement reçue comprend, en plus de l'application devant être chargée, l'identifiant de fournisseur d'application correspondant au domaine de sécurité devant être associé, la vérification consistant à contrôler que ledit identifiant correspond à l'identifiant de ladite application. Selon une autre caractéristique de l'invention, une étape de contrôle de l'accès à au moins une application installée sur le dispositif effectué par le domaine de sécurité du fournisseur d'applications auquel ladite application est associée, est mise en œuvre par le système d'exploitation du dispositif, pour autoriser une action sur ladite application. De préférence, le contrôle d'accès consiste à requérir la production d'une signature électronique et à vérifier ladite signature. L'action sur l'application peut consister à supprimer ladite application le dispositif. L'action sur l'application peut encore consister à verrouiller l'utilisation de ladite application. L'action sur l'application peut encore consister en l'utilisation au moins partielle de ladite application par une nouvelle application chargée sur le dispositif appartenant à un autre fournisseur d'applications. Selon une variante, les applications consistent en des interfaces de programmation d'application API.

L' invention concerne également une carte à puce multi-applicative, caractérisé en ce qu'elle comprend des moyens pour la mise en œuvre du procédé tel qu'il vient d'être décrit. De préférence, la carte est une carte de type JavaCard. D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante donnée à titre d'exemple illustratif et non limitatif et faite en référence aux figures suivantes, dans lesquelles : -la figure 1 illustre schématiquement le mode de gestion du contenu de la carte selon l'invention, lors de la phase de chargement et d'installation d'une application sur la carte, et -la figure 2 illustre un exemple du mode de gestion du contenu de la carte selon l'invention, dans le cas d'une importation d'application déjà installée sur la carte. La carte à puce multi-applicative est basée dans un mode de réalisation préféré, sur le système d'exploitation JavaCard (marque déposée) . Suivant cette norme, les applications pour les cartes multi- applicatives sont programmées par les fournisseurs d'applications sous forme d'applets. la norme JavaCard introduit un moyen pour les applets d'interagir directement. Ainsi, une applet peut utiliser des modules d'une autre applet à travers une interface de partage. La figure 1 illustre donc dans ce contexte, un mode de gestion d'une carte multi-applicative 10 dotée de son système d'exploitation OS, lors d'une phase de chargement d'une application dans la carte. Plus précisément, selon cet exemple, l'application chargée dans la carte consiste en une interface de programmation d'application APIl fournie par un fournisseur d'applications Pl. Comme il a déjà été expliqué, un domaine de sécurité SD(Pl) pourace fournisseur d'applications a été implémenté sur la carte et regroupe l'ensemble des applications et des interfaces de programmation d'application appartenant à ce fournisseur d'applications en particulier. Les interfaces de programmation forment un ensemble de bibliothèques Java, qui regroupent des procédures et des objets prédéfinis, utilisables de façon modulaire et qui permettent de mettre en œuvre des applications Java. Ainsi, on cherche à s'assurer que l'interface de programmation APIl délivrée par le fournisseur d'application Pl, est rattachée au bon domaine de sécurité, à savoir le domaine de sécurité de Pl, SD(Pl) . Pour ce faire, on va utiliser un identifiant spécifique de l'application devant être chargée sur la carte et un identifiant spécifique de fournisseur d'application, permettant d'identifier le domaine de sécurité associé. En effet, lorsqu'un domaine de sécurité est créé sur la carte, il est associé à un fournisseur d'applications et il contient donc l'identifiant de ce fournisseur d'applications. Dans le contexte des cartes à puce multi- applicative, toutes les applications sont identifiées par un identifiant unique nommé AID (pour « Application Identifier ») , défini par la norme ISO/IEC 7816-5. Cet identifiant AID est codé sur 16 octets, dont les 5 premiers octets représentent au niveau de la norme l'identifiant RID (pour « Registered application provider Identifier ») permettant d'identifier l'organisme émetteur de l'application. Grâce à ces identifiants, à la réception de la commande de chargement de l'interface de programmation APIl sur la carte, le système d'exploitation OS de la carte va automatiquement vérifier, tel qu'illustré par la référence 20 de la figure 1, que le domaine de sécurité SD(Pl) choisi pour cette application possède bien le même RID que l'application en question. Selon un premier mode de réalisation, le système d'exploitation OS recherche dans une liste qu'il a à sa disposition référençant l'ensemble des domaines de sécurité installés sur la carte, un domaine de sécurité dont l'identifiant RID correspond à l'identifiant AID de l'interface de programmation APIl devant être chargée. Le domaine de sécurité SD(Pl) est alors trouvé et le système d'exploitation OS autorise alors le chargement et l'installation de l'interface de programmation APIl sur la carte en la rattachant automatiquement au domaine de sécurité associé SD(Pl). Selon un autre mode de réalisation, l'identifiant RID du fournisseur d'application correspondant au domaine de sécurité qu'on souhaite associer à l'interface de programmation APIl est transmis en même temps que cette dernière. Ainsi, la vérification 20 consiste simplement à vérifier la correspondance de cet identifiant RID avec l'identifiant AID de l'application, pour s'assurer que l'application chargée APIl est bien rattachée au domaine de sécurité SD(Pl) associé au fournisseur de l'application Pl. Dans le cas où la vérification décrite en 20 échoue, le chargement de l'interface de programmation APIl est rejeté par la carte. Ainsi, grâce aux mécanismes qui viennent d'être décrits, il est possible de s'assurer automatiquement, par l'intermédiaire du système d'exploitation de la carte, que l'interface APIl délivrée par le fournisseur d'applications Pl est installée sur la carte sous son bon domaine de sécurité SD(Pl) . Un autre objectif de l'invention consiste également à s'assurer par des moyens spécifiques prévus sur la carte que l'on a bien l'autorisation du fournisseur d'applications concerné lorsque le système d'exploitation OS souhaite accéder à une application de ce fournisseur déjà installée sur la carte, en vue de réaliser une action quelconque sur cette application. Notamment, cette action peut consister en la suppression de l'application ou en un verrouillage de l'utilisation de cette application sur la carte. Un privilège est alors défini pour les domaines de sécurité associés aux fournisseurs d'applications qui souhaitent contrôler l'accès à leurs applications sur la carte et que leur autorisation soit formellement demandée préalablement à toute action de suppression ou de verrouillage de leurs applications installées sur la carte. A cet effet, une information spécifique permet de caractériser un tel domaine de sécurité et peut alors être utilisée par le système d'exploitation de la carte comme critère pour déterminer si une autorisation d'accès existe, lorsqu'il souhaite accéder à une application associée à ce domaine de sécurité pour la supprimer par exemple. Ainsi, le système d'exploitation, lorsqu'il verra ce privilège, va devoir appeler une interface particulière sur ce domaine de sécurité pour que ce dernier donne son autorisation pour accéder à l'application concernée par la suppression. Concrètement, une signature électronique est rajoutée dans la commande émise par le système d'exploitation et cette signature doit être vérifiée préalablement par le domaine de sécurité associé. Ce contrôle d'accès à une application sur la- carte; imposé par le domaine de sécurité du fournisseur d'applications auquel cette application est associée, est également mis en œuvre dans le cas où l'action sur l'application consiste en une utilisation, au moins partielle, de ladite application par une nouvelle application chargée sur la carte appartenant à un autre fournisseur d'applications. En effet, lorsqu'une nouvelle application ou interface de programmation est chargée, pour pouvoir fonctionner, elle peut être amenée à utiliser d'autres interfaces de programmation déjà installées sur la carte et appartenant à un domaine de sécurité d'un autre fournisseur d'applications. Auquel cas, il est important, dans un souci de préserver les droits de propriété de ce fournisseur d'applications, de permettre à ce dernier de contrôler l'utilisation de ses applications ou API sur la carte. La figure 2 illustre un exemple de ce mode de gestion du contenu de la carte, dans le cas où d'une importation d'application déjà installée sur la carte par une application appartenant à un autre fournisseur d'applications. Un domaine de sécurité SD(Pl) associé au fournisseur d'applications Pl est installé sur la carte à puce multi- applicative 10. Les interfaces de programmation d'application APIl, API2 et API3 appartenant à ce fournisseur Pl ont déjà été chargées et installées sur la carte suivant le mode de gestion expliqué plus haut en référence à la figure 1, en étant donc associées au domaine de sécurité SD(Pl) . Une interface de programmation API P2, provenant d'un fournisseur d'applications P2 différent de Pl, est chargée sur la carte. Dans l'exemple de la *figure 2, cette interface API P2 souhaite utiliser l'APIl du fournisseur d'application Pl déjà installée sur la carte. En d'autres termes, elle doit importer des ressources de cette APIl pour pouvoir être chargée sur la carte. Or, l'interface de programmation APIl qui doit être importée par l'interface de programmation API P2 qui est en train d'être chargée, appartient à un domaine de sécurité SD(Pl) qui veut contrôler son accès. En effet, un privilège est défini pour le domaine de sécurité SD(Pl), qui permet au système d'exploitation de la carte de savoir que ce domaine de sécurité requiert la production d'une signature pour autoriser la connexion à son interface de programmation APIl associée. Le système d'exploitation OS de la carte, voyant ce privilège, avant d'autoriser l'édition de liens entre les interfaces de programmation API P2 et APIl, va appeler une interface sur le domaine de sécurité SD(Pl) pour que ce dernier donne son autorisation. Pour ce faire, la signature, qui a normalement été donnée par le fournisseur d'application Pl pour autoriser à se connecter à son interface de programmation APIl, doit être ajoutée lors du chargement de l'interface de programmation API P2 sur la carte. Dans le cas où l'API P2 devrait importer des ressources d'autres applications ou interfaces de programmation appartenant à Pl, il serait nécessaire d'ajouter une signature par applications ou interfaces de programmation importées. Le système d'exploitation fait alors appel à la vérification de la signature et le domaine de sécurité SD (Pl) va vérifier la signature, pour donner son autorisation à l'utilisation des ressources de son interface de programmation APIl. Si la signature est vérifiée avec succès, l'API P2 est installée sur la carte. En cas d'échec, le chargement de l'API P2 n'est pas autorisé, car cela signifie que cette application essaye d'utiliser des ressources auxquelles elle n'est pas habilitée à accéder. Ainsi, lorsqu'une application est en train d'être chargée, le système d'exploitation identifie la liste des applications déjà installées sur la carte que souhaite utiliser l'application en train d'être chargée et détermine les domaines de sécurité associés à ces applications. Si, parmi ces domaines de sécurité se trouvent des domaines de sécurité qui requièrent un contrôle d'accès pour autoriser l'utilisation de leurs applications, alors le système d'exploitation effectue ce contrôle d'accès. Bien que toute la description ci-dessus ait été faite en relation avec une carte à puce multi- applicative, il doit être compris que les caractéristiques de la présente invention peuvent s'appliquer plus généralement à tout dispositif électronique multi-applicatif, comprenant un système d'exploitation prévu pour supporter une pluralité d'applications. En particulier, la présente invention peut s'appliquer à la gestion du contenu d'un micro¬ ordinateur de type PC, l'entité émettrice se rapportant alors au propriétaire du PC.