Brevet FR3159029A1 — publié le 20250808

Procédé de gestion de l’appel par un client d’une interface de programmation applicative L’invention se rapporte à un procédé de gestion de l’appel par un client logiciel (C) d’une interface de programmation applicative (API), ledit client (C) ayant une identité (ID), ledit appel visant à exécuter un élément (M) interfacé par l’interface de programmation applicative (API), le procédé comprenant les étapes suivantes réalisées pour un appel donné avant l’accès à l’interface (API) : Vérification (CHK) de l’identité (ID) du client logiciel (C) ; Extraction (XTR) des valeurs (V) des arguments passés en paramètre par le client logiciel (C) dans l’appel de l’interface de programmation applicative (API) ; Autorisation (AUT) pour l’appel donné d’accéder à l’interface (API) en fonction de l’identité (ID) du client logiciel (C) et les valeurs extraites (V). Figure 1 Procédé de gestion de l’appel par un client d’une interface de programmation applicative Le domaine technique est celui de l’informatique. Plus précisément, l’invention se rapporte à un procédé de gestion de l’appel par un client d’une interface de programmation applicative. Une interface de programmation applicative (traduction de l’anglais application programming interface , rendu par l’acronyme API) est un moyen pour un logiciel donné de donner à d’autres logiciels l’accès à des données ou à des fonctionnalités rendues par le logiciel donné. Le logiciel qui offre l’accès à des données ou à des fonctionnalités ou en général à un de ses éléments rend un service à d’autres logiciels qui sont en général dénommées comme étant les clients du service offert. On parle alors d’une architecture client-serveur. Dans cette dénomination, la notion de service (l’accès à une donnée ou à une fonctionnalité ou à tout autre élément à travers une interface de programmation applicative) est confondue avec une notion de serveur (une machine réelle ou virtuelle sur laquelle s’exécute un ou plusieurs logiciels qui rendent des services). Cette dénomination est cependant utilisée largement par l’homme du métier. Les architectures client-serveur et l’utilisation d’APIs sont très répandues en informatique. Dans une telle architecture, un serveur informatique est disposé dans un réseau de communication dans lequel sont également présents des clients. Les clients peuvent adresser, par l’intermédiaire du réseau de communication, des requêtes au serveur permettant d’accéder aux différents services offerts à travers une API. Le serveur réalisera un contrôle d’accès pour vérifier si le client est autorisé à accéder au service demandé, et le fournira si c’est le cas. Le service demandé pourra être par exemple la fourniture d’une donnée qui sera alors lue par le client pour traitement ultérieur ou bien l’exécution d’une action particulière. En général, un serveur pourra être interrogé par plusieurs clients différents. La requête sera émise par le client en utilisant un protocole de communication donné. Un protocole qui peut être utilisé dans ce contexte est le protocole HTTP (acronyme de l’anglais Hyper Text Transfer Protocol ). Ce protocole est à l’origine utilisé pour permettra le transfert d’informations d’un site Web vers un navigateur Web ainsi que la navigation Web en général, mais les requêtes GET et POST présentes dans le protocole HTTP peuvent aussi être utilisées pour transférer des données d’un client vers un serveur et recevoir des données en retour. On parle alors de service Web, traduction de l’anglais web service . On peut également remarquer que la consultation de sites Web en général se fait selon une architecture client-serveur, où le navigateur Web joue le rôle d’un client, le serveur Web est un serveur, et la requête du client vers le serveur consiste à récupérer le contenu d’un site Web depuis un serveur afin de pouvoir l’afficher dans le navigateur. Mais il est possible d’utiliser le protocole HTTP dans le cadre d’une architecture client-serveur et de la mise à disposition de services Web pour récupérer tout type de données, ou pour commander tout type d’action, sans se limiter à la navigation et à l’affichage de sites Web. Dans le cas où l’architecture client-serveur utilise HTTP comme protocole de communication, le système de contrôle d’accès utilisé sera celui du protocole HTTP lui-même. Dans ce cas, un client adressera une requête selon le protocole HTTP à un serveur identifié par une adresse donnée par un identifiant uniforme de ressource, ou URI (acronyme de l’anglais Uniform Resource Identifier ). L’appel d’une API se décompose classiquement en deux éléments. Le premier est le nom d’une méthode appelée ; le second est la ou les valeurs d’arguments passés en paramètres à la méthode appelée. Par exemple, dans le cas d’un service Web, la méthode appelée sera définie par un verbe du protocole HTTP (par exemple, le verbe GET) ainsi que par l’URI appelée, et la ou les valeurs d’arguments appelés pourront être passés en paramètres dans l’appel HTTP. L’appel de la méthode permet d’accéder à tout type d’élément du service. Prenons comme exemple une API qui permet de connaître le statut d’itinérance (traduction de l’anglais roaming ) d’un téléphone mobile. Un opérateur de télécommunications pourra définir et déployer dans ses réseaux un service Web qui permet d’obtenir cette information, ou toute autre technique permettant d’offrir une API. Dans le cas d’un service Web, l’information sera par exemple obtenue en réalisant l’appel suivant : GET http://API/roaming_status?tel_num=’+33123456789’ D’autres APIs peuvent être accessibles sous l’adresse http://API. Dans l’exemple ci-dessus, la méthode appelée est dénommée roaming_status et un paramètre dénommé tel_num est passé en argument, avec la valeur +33123456789 qui est le numéro de téléphone pour lequel le statut d’itinérance est demandé. En retour, le client recevra une chaîne de caractères qui contient l’information demandée. Par exemple, une chaîne ’roaming=yes_country=Thailand’ indique que le téléphone demandé est bien en itinérance et se trouve en Thaïlande. D’autres formats de réponse peuvent bien sûr être définis. De plus, les arguments de la méthode peuvent être passés dans d’autres formats, par exemple dans des objets JavaScript qui utiliseront la notation JSON (acronyme de l’anglais JavaScript Object Notation ) ou des objets écrits en langage XML (acronyme de l’anglais Extensible Markup Language ). L’exemple donné ci-dessus s’inscrit dans le cadre où l’interface de programmation applicative est programmée comme un service Web mais d’autres techniques de déploiement d’APIs existent, comme la technologie CORBA (acronyme de l’anglais Common Object Request Broker Architecture ) ou SOAP (acronyme de l’anglais Simple Object Access Protocol ). État de la technique Un point important des architectures client-serveur et des interfaces de programmation applicatives est la technique de contrôle d’accès retenue. En effet, une ressource donnée ne doit pouvoir être accédée que par un client autorisé. Pour cela, un système de contrôle d’accès est mis en place. Le contrôle d’accès s’assure qu’un client donné, lorsqu’il appelle une API pour obtenir une ressource, est d’une part identifié et d’autre part autorisé à appeler la méthode de l’API. Dans le cas où l’architecture client-serveur utilise HTTP comme protocole de communication, le système de contrôle d’accès utilisé pourra être celui du protocole HTTP lui-même. Dans ce cas, comme on l’a vu, un client adressera une requête selon le protocole HTTP à un service identifié par une adresse donnée par un identifiant uniforme de ressource, ou URI (acronyme de l’anglais Uniform Resource Identifier ). La requête sera alors acceptée ou refusée par le serveur Web hébergeant le service Web identifié par l’URI selon les conditions données par le protocole HTTP. Le client fournit dans un en-tête de la requête son identifiant et un mot de passe ou un haché cryptographique de mot de passe, selon le mode d’authentification retenu. Si le client est autorisé à accéder à la ressource, c’est-à-dire à l’URI, et si le mot de passe correspond bien à l’identifiant du client, la requête sera traitée par le serveur Web et la ressource accédée par le client. Dans les architectures client-serveur, le système de contrôle d’accès se limite à vérifier que le client identifié a bien l’autorisation d’appeler la méthode qu’il appelle et de le bloquer si ce n’est pas le cas. Pour reprendre l’exemple donné ci-dessus d’accès au statut d’itinérance d’un téléphone mobile, un client autorisé à accéder à l’API GET http://API/roaming_status pourra réaliser cet appel pour n’importe quelle valeur du paramètre tel_num, c’est-à-dire pour n’importe quel numéro de téléphone mobile. Cette situation présente des inconvénients. Comme le contrôle d’accès ne porte que sur la méthode appelée, un client autorisé pourra accéder à la méthode demandée pour toutes les valeurs possibles des arguments passés en paramètre à la méthode. Pour reprendre l’exemple de l’API fournissant le statut d’itinérance d’un téléphone mobile, cette information peut être intéressante pour des entreprises en dehors du secteur des télécommunications. Une banque, par exemple, peut détecter que des paiements sont effectués par une carte de crédit en Thaïlande et suspecter une fraude. En consultant le statut d’itinérance du téléphone mobile du propriétaire de la carte de crédit en question, la banque peut avoir une information sur la localisation du propriétaire et confirmer ou infirmer que sa carte de crédit est victime d’une fraude, s’il se trouve bien actuellement en Thaïlande. Un opérateur de télécommunications peut donc trouver intérêt à vendre à une banque l’accès à l’API donnant ce statut d’itinérance. Mais l’opérateur de télécommunications doit également protéger la confidentialité des données de ses clients. Or, donner l’accès à l’API à une banque permettra à cette dernière de connaître le statut d’itinérance de tous les téléphones mobiles gérés par l’opérateur de télécommunications et pas seulement de ceux qui appartiennent à des clients de la banque. Dans le cas de systèmes hérités (traduction de l’anglais legacy systems ), il n’est pas possible, ou en tout cas très difficile, de modifier les programmes développés. Ceux-ci peuvent par exemple avoir été développés dans des langages de programmation qui ne sont plus usités. Ou bien, le programme a été développé par un fournisseur qui déclare ne plus pouvoir ou vouloir le modifier, ou en tout cas pas pour un prix acceptable. En l’absence de possibilité de modifier le système hérité, il n’est donc pas possible d’ouvrir à un tiers l’accès à ses APIs pour des raisons de protection de la confidentialité des données de ses clients. Cette situation est fréquente. Toujours dans notre exemple du statut d’itinérance d’un téléphone mobile, l’API a pu être développée initialement pour les besoins internes du système d’information de l’opérateur de télécommunications, par un équipementier de systèmes de télécommunications. Dans un tel développement, pour des besoins internes, il n’était pas vu comme intéressant de pouvoir différencier entre différents clients de l’API. Le fournisseur peut refuser de modifier le développement pour un prix raisonnable. La seule solution est alors une solution contractuelle, c’est-à-dire de demander à un utilisateur externe de l’API de limiter son usage de l’API à des arguments pour lesquels cet usage lui est autorisé mais sans pouvoir assurer par un outil informatique que cette limitation est bien respectée. Un autre inconvénient de la situation actuelle est le manque d’évolutivité du contrôle d’accès. Un client donné peut ou non être autorisé à appeler une méthode donnée sans que ne soit précisées les possibilités d’évolution des règles régissant cet accès. L’invention vient améliorer la situation. Selon un premier aspect fonctionnel, l’invention a trait à un procédé de gestion de l’appel par un client logiciel d’une interface de programmation applicative, ledit client logiciel ayant une identité, ledit appel visant à exécuter un élément interfacé par l’interface de programmation applicative, le procédé comprenant les étapes suivantes réalisées pour un appel donné avant l’accès à l’interface : Vérification de l’identité du client logiciel ; Extraction des valeurs des arguments passés en paramètre par le client logiciel dans l’appel de l’interface de programmation applicative ; Autorisation pour l’appel donné d’accéder à l’interface en fonction de l’identité du client logiciel et des valeurs extraites. Grâce à l’invention, un contrôle d’accès est réalisé qui s’appuie de surcroît sur l’analyse des valeurs des arguments qui sont passés en paramètre à l’élément appelé lors de l’appel de l’interface de programmation applicative. L’élément qui est destiné à être exécuté à la suite de l’appel à l’interface de programmation applicative appartient à un système logiciel et matériel. Cet élément du système qui est appelé peut être par exemple une méthode, qui va exécuter un ou plusieurs calculs et rendre des données, ou exécuter diverses actions, ou bien une requête de base de données qui se contentera alors de fournir une ou plusieurs données en réponse, ou tout autre élément informatique. L’élément appelé est un élément logiciel qui s’appuie pour son exécution sur différents éléments matériels et logiciels présents dans un système plus vaste, interfacé par l’interface de programmation applicative. Ce système sera le plus souvent un système hérité, qui ne peut être modifié, mais l’invention peut s’appliquer à des systèmes développés récemment. Ce contrôle est réalisé au moment de la vérification de l’identité du client logiciel, c’est-à-dire au moment où il est contrôlé que le client est bien autorisé à appeler l’interface. Mais, en plus de ce contrôle d’accès standard, une vérification supplémentaire est effectuée, portant sur les arguments passés à l’interface de programmation applicative, avant d’autoriser l’accès à l’interface et donc l’exécution de l’élément visé par l’appel. Comme cette vérification est réalisée avant l’accès à l’interface de l’élément appelé, elle est faite en dehors du système logiciel qui est interfacé par l’interface de programmation applicative. De cette manière, le contrôle d’accès qui réalise une gestion fine des droits d’accès peut être déployé y compris quand le système interfacé est un système hérité, qui ne peut pas être modifié. Selon encore un premier mode de mise en œuvre particulier de l’invention, le procédé comprend, si l’appel donné est autorisé à accéder à l’interface, une étape d’ajout dans une base de règles d’une règle comprenant une valeur obtenue à la suite de l’exécution de l’élément appelé, ladite règle ajoutée étant relative à une étape d’autorisation ultérieure d’un autre appel. Grâce à ce premier mode, le système de contrôle d’accès selon l’invention est évolutif. Le contrôle d’accès se fonde sur un ensemble de règles autorisant ou non l’accès du client à l’interface en fonction des valeurs des paramètres de l’appel à autoriser. Le contrôle d’accès va dépendre de résultats de l’exécution de l’élément appelé par le client logiciel. Ceci permet au système d’évoluer mais aussi de fournir facilement à une base de règles les règles nécessaires à son fonctionnement. Selon un deuxième mode de mise en œuvre particulier de l’invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent mode, une règle ajoutée dans la base de règles est une règle autorisant un appel ultérieur du même client logiciel vers la même interface de programmation applicative. Dans ce deuxième mode de réalisation, la forme de la règle ajoutée est précisée. Il s’agit ici uniquement d’une règle d’autorisation, et exactement pour le même client et pour le même appel. Ce mode permet de peupler aisément la base de règles des autorisations nécessaires à l’utilisation de l’interface de programmation applicative. Selon un autre mode de réalisation, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, la règle ajoutée dans la base de règles est associée à une durée de validité. Grâce à ce mode de réalisation, la base de règles utilisée pour définir les autorisations d’accès évolue dans le temps. Une autorisation peut ainsi être donnée de façon temporaire, afin de pouvoir réaliser une opération pendant un temps limité seulement, puis de l’interdire afin de protéger la ressource accédée par l’appel. Ce type d’autorisation temporaire peut particulièrement bien s’appliquer aux opérations de commerce électronique tels que l’achat d’un panier collecté sur un site de commerce électronique ou bien aux opérations de mise à jour d’un compte client, comme la validation d’un nouveau mot de passe. Selon un mode de réalisation, qui pourra être mis en œuvre cumulativement avec le mode précédent, la durée de validité associée à la règle ajoutée est déterminée par une valeur obtenue à la suite de l’exécution de l’élément appelé. Selon un mode de réalisation, qui pourra être mis en œuvre alternativement avec le mode précédent, la durée de validité associée à la règle ajoutée est une valeur fixée à l’avance. Grâce à ces deux modes de réalisation, le fonctionnement de l’évolution dans le temps de la base de règles est précisé. Cette évolution peut être pilotée par le système interfacé qui fournit, en même temps que les valeurs qui définissent la règle ajoutée, sa durée de validité. Ou bien la durée de validité est définie a priori ce qui veut dire que l’ensemble des règles finissent par se périmer au bout d’un certain temps. Ces deux modes peuvent se combiner, à savoir que les deux modes peuvent s’appliquer suivant la nature de la règle ajoutée, ou bien la durée définie à l’avance peut ne s’appliquer que si la durée de validité n’est pas transmise par une valeur obtenue suite à l’exécution de l’élément appelé. Selon un autre mode de réalisation, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, si l’appel n’est pas autorisé après interrogation de la base de règles, une erreur est renvoyée au client logiciel. Grâce à ce mode de réalisation, une information est fournie au client logiciel si son accès à l’interface de programmation applicative est refusé pour les valeurs des arguments soumis comme paramètres. Le client logiciel pourra ainsi modifier son appel si besoin ou transmettre l’information à des utilisateurs ou à d’autres composants logiciels. Ses informations sont fournies sans que l’élément ni le système interfacé par l’interface de programmation applicative n'aient eu à intervenir. Selon un autre mode de réalisation, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, l’appel est un appel d’un service Web utilisant le verbe POST et une règle ajoutée est une règle autorisant un appel ultérieur du même client logiciel sur le même service Web utilisant l’un des verbes GET, HEADER, PUT ou PATCH. Grâce à ce mode de réalisation, la constitution de la base de règles est facilitée. Le client logiciel est autorisé à réaliser un appel de l’API avec un verbe POST. En retour, une référence est obtenue, qui pourra être utilisée par un appel avec un autre verbe et cet appel ultérieur est autorisé dans la base de règles. Selon un autre mode de réalisation, qui pourra être mis en œuvre alternativement ou cumulativement avec les modes précédents, l’appel est un appel d’un service Web et les arguments de la méthode appelée sont présents dans un objet informatique utilisant la notation JSON. Grâce à ce mode de réalisation, l’invention est appliquée aux services Web, qui forment une catégorie très répandue des architectures client-serveur. Les valeurs des arguments transmises comme paramètres des méthodes appelées peuvent être regroupées dans un objet informatique utilisant la notation JSON. Un outil tel que JSONpath peut alors permettre d’accéder aux valeurs en question présentes dans l’objet. Selon un premier aspect matériel, l’invention se rapporte à une entité de gestion gérant l’appel par un client logiciel d’une interface de programmation applicative, ledit client logiciel ayant une identité, ledit appel visant à exécuter un élément interfacé par l’interface de programmation applicative, l’entité de gestion comprenant les modules suivants : Un module de vérification de l’identité du client logiciel ; Un module d’extraction des valeurs des arguments passés en paramètre par le client logiciel dans l’appel de l’interface de programmation applicative ; Un module d’autorisation pour l’appel donné d’accéder à l’interface en fonction de l’identité du client logiciel et des valeurs extraites ; et caractérisée en ce que, pour un appel donné, les étapes de vérification, d’extraction et d’autorisation sont toutes réalisées avant l’accès à l’interface. Selon un mode de réalisation du premier aspect matériel, l’entité de gestion comprend de surcroît une base de règles, lesdites règles étant relatives à l’autorisation pour l’appel d’accéder à l’interface. Selon un autre aspect matériel, l’invention a trait à un programme d'ordinateur apte à être mis en œuvre par une entité de gestion, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes du procédé de gestion défini ci-dessus. Enfin, selon un autre aspect matériel, l’invention a trait à un support de données sur lequel est enregistré un programme d’ordinateur comprenant des séquences d’instructions pour la mise en œuvre du procédé de gestion défini ci-dessus. Le support de données peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique tel qu’un un disque dur. D'autre part, le support peut être un support transmissible tels qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Le programme selon l’invention peut utiliser tout type de technologie informatique en terme de langages de programmation compilés, interprétés, ou une combinaison des deux ainsi qu’en terme de systèmes d’exploitation. Brève description des figures L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple, et faite en référence aux dessins annexées sur lesquels : FIG. 1 représente un client logiciel réalisant un appel d’une interface de programmation applicative et une entité de gestion gérant cet appel selon l’invention. FIG. 2 illustre un exemple d’étapes mises en œuvre dans le cadre d’un mode de réalisation de l’invention. FIG. 3 illustre un autre exemple d’étapes mises en œuvre dans le cadre d’un autre mode de réalisation de l’invention. Description détaillée La FIG. 1 représente un client logiciel C, qui dispose d’une identité ID. La FIG. 1 représente également un système logiciel S. Ce système S comprend un élément M, par exemple une méthode informatique. L’élément M est interfacé par une interface de programmation applicative API. La FIG. 1 représente également une entité de gestion 100 en charge de gérer un appel du client C vers l’interface de programmation API. Dans l’exemple de réalisation représenté dans la FIG. 1 , l’entité de gestion 100 comprend les éléments suivants : Un module 101 de vérification CHK de l’identité ID du client logiciel C ; Un module 102 d’extraction XTR des valeurs V des arguments passés en appel ; Un module 103 d’autorisation AUT de l’accès à l’interface ; Une base de règles DB. Dans d’autres exemples de réalisation, l’entité de gestion 100 ne comprend pas une base de règles DB. Le client C, l’entité de gestion 100 et le système S sont reliés entre eux par un réseau de communication non représenté dans la FIG. 1 . Il peut s’agir du réseau Internet, ou d’un réseau privé, ou bien d’une combinaison de plusieurs réseaux. La liaison entre le client C et l’entité de gestion 100 peut se faire par exemple grâce au réseau Internet alors que l’entité de gestion 100 va ensuite communiquer avec le système S par un réseau privé. Le client logiciel C s’exécute sur un matériel qui présente l’architecture matérielle d’un ordinateur conventionnel. Ce matériel comporte notamment un processeur, une mémoire vive de type RAM et une mémoire morte telle qu’une mémoire de type Flash, ROM, (non représentés sur la figure) et peut comporter des dispositifs d’entrée-sortie tels que claviers et/ou écrans (non représentés sur la figure). Dans tous les cas, le matériel sur lequel s’exécute le client C comporte des moyens de communication qui lui permettent d’accéder à un ou plusieurs réseaux de communication. Ce matériel peut être par exemple un ordinateur ou bien un ordiphone (traduction de l’anglais smartphone ) ou bien des composants matériels d’une architecture en nuage (traduction de l’anglais cloud architecture ). Le système logiciel S est également hébergé dans un matériel qui présente l’architecture matérielle d’un ordinateur conventionnel. Il comporte notamment un processeur, une mémoire vive de type RAM et une mémoire morte telle qu’une mémoire de type Flash, ROM, (non représentés sur la figure) et peut comporter des dispositifs d’entrée-sortie tels que claviers et/ou écrans (non représentés sur la figure). Dans tous les cas, le matériel sur lequel s’exécute le client C comporte des moyens de communication qui lui permettent d’accéder à un ou plusieurs réseaux de communication. Ce matériel peut être par exemple un ordinateur ou bien un ordiphone (traduction de l’anglais smartphone ) ou bien des composants matériels d’une architecture en nuage (traduction de l’anglais cloud architecture ) ou bien un serveur. L’élément M présent dans le système S est appelé à travers l’interface API. Il peut s’agir d’une méthode informatique, d’une requête à une base de données ou tout autre élément informatique. L’élément M comprend l’exécution d’une partie logicielle sur des éléments matériels qui peuvent appartenir au système S ou bien être déporté sur des éléments matériels extérieurs dans le cas d’une architecture en nuage. Le client logiciel C et le système S forment une architecture client-serveur, c’est-à-dire que le système S offre, par l’intermédiaire de l’interface de programmation applicative API, la possibilité à plusieurs clients logiciels C d’obtenir des données ou de faire réaliser des opérations en effectuant un appel à travers l’interface API. Dans l’exemple représenté ici, l’opération réalisée à travers l’interface API est l’appel de la méthode M. La même interface API peut permettre d’appeler d’autres éléments du système S. Et de plus, le système S peut comprendre d’autres interfaces donnant accès à d’autres éléments logiciels et matériels. De cette manière, le client C n’est pas un programme monolithique mais utilise des données et fonctions rendues par le système S. De nombreuses architectures sont possibles. Par exemple, le client logiciel C peut être une application mobile s’exécutant sur un ordiphone et qui va appeler des éléments du système S à travers l’interface API et éventuellement d’autres interfaces pour obtenir certaines données ou faire réaliser certaines opérations. Le système S sera alors un logiciel qui peut s’exécuter sur un ou plusieurs serveurs matériels ou bien dans une architecture en nuage. Le client C peut être aussi une application hébergée dans un ordinateur personnel, ou bien une application Web qui s’exécute de manière virtuelle dans un navigateur Web. Ces architectures peuvent également utiliser, à la fois pour l’exécution du client C ou du système S, des techniques de machine virtuelle ou de conteneurisation des composants logiciels. L’interface de programmation applicative API peut être implémentée selon plusieurs techniques informatiques possibles. Par exemple, le système logiciel S peut être intégré dans un serveur Web et l’interface API sera alors une URL offerte par le serveur Web. D’autres techniques sont possibles telles que SOAP ou CORBA. L’entité de gestion 100 présente également l’architecture matérielle d’un ordinateur conventionnel. Ce matériel comporte notamment un processeur, une mémoire vive de type RAM et une mémoire morte telle qu’une mémoire de type Flash, ROM, (non représentés sur la figure) et peut comporter des dispositifs d’entrée-sortie tels que claviers et/ou écrans (non représentés sur la figure). Dans tous les cas, le matériel sur lequel s’exécute l’entité de gestion 100 comporte des moyens de communication qui lui permettent d’accéder à un ou plusieurs réseaux de communication et en particulier d’être en communication à la fois avec le client logiciel C et le système S. La nature de l’entité de gestion 100 peut, dans certains modes de réalisation, dépendre de la technique utilisée pour interfacer l’élément M du système S. Dans le cas où le système S est interfacé par une interface Web, par exemple, l’entité de gestion 100 pourra être un élément du serveur Web qui donne accès à l’interface API. D’autres modes de réalisation sont possibles suivant la technique d’interfaçage retenue. Dans tous les cas, l’entité de gestion 100 est distincte du système S. Le système S est en général un système hérité, qui ne peut pas être modifié, même si l’invention peut également s’appliquer à l’interfaçage de nouveaux systèmes S. Un exemple de mode de réalisation possible de l’invention est alors le suivant. Le client logiciel C adresse à l’interface API du système S une demande d’exécution d’une méthode M et passe en paramètre de cette demande des valeurs V. Cette demande ou appel de l’interface API est d’abord traitée par l’entité de gestion 100 avant toute exécution d’élément appartenant au système S. Par exemple, le système S est un service Web et peut être accédé en lui adressant des requêtes HTTP. Ces requêtes sont alors gérées par un serveur Web et l’entité de gestion 100 peut être une partie du système de contrôle d’accès du serveur Web. Le module 101 de l’entité de gestion 100 va d’abord vérifier CHK l’identité ID du client logiciel C. Par exemple, dans une architecture de service Web, l’identité ID du client C est transmise dans un en-tête (traduction de l’anglais header ) de la requête HTTP. En plus de l’identité ID, le client C va transmettre un mot de passe ou un certificat cryptographique. Cette donnée de sécurité est utilisée par le module 101 pour vérifier que l’identité ID présentée par le client C est bien la bonne. D’autres techniques de vérification d’identité sont possibles autres que celles utilisées par les serveurs Web. Si la vérification CHK de l’identité ID du client logiciel C échoue, le procédé selon l’invention ne se poursuit pas et un code d’erreur peut être remonté au client logiciel C ou bien une alerte de sécurité ou toute autre mesure appropriée. Le module 102 de l’entité de gestion 100 va ensuite procéder à l’extraction XTR des valeurs V des arguments passés en appel de la méthode M. Dans le cas d’un service Web, par exemple, la requête appelée par le client C pourra comprendre un objet informatique du langage JavaScript enregistré selon la notation JSON. Un outil tel que JSONpath permettra de retrouver les valeurs V passées en argument dans cet objet selon la notation JSON. Toujours dans une architecture de service Web, les valeurs V peuvent être définies dans les paramètres URL de la requête HTTP réalisée par le client C. Si l’interface API utilise d’autres techniques qu’une architecture Web, d’autres méthodes seront utilisées pour extraire XTR les valeurs V en accord avec la technologie d’interfaçage employée. On peut noter que dans le cas d’un serveur Web classique, le système de contrôle d’accès ne réalise pas l’extraction XTR des valeurs V. En effet, un serveur Web va simplement vérifier qu’un client C dont l’identité ID est vérifiée CHK peut ou non appeler une interface API en accédant à l’URL correspondante. Si l’appel est autorisé pour le client C dont l’identité ID est vérifiée CHK, les valeurs V sont transmises au système S sans aucun contrôle supplémentaire. L’opération d’extraction XTR est présentée ici comme ayant lieu après l’opération de vérification CHK de l’identité ID du client logiciel C, mais dans d’autres modes de réalisation, cette opération prend place avant ou bien les deux opérations sont réalisées en parallèle. L’ordre d’exécution de ces deux opérations de vérification CHK et d’extraction XTR n’a pas d’importance dans la réalisation du procédé selon l’invention. Le module 103 de l’entité de gestion reçoit l’identité ID vérifiée CHK du client logiciel C et les valeurs V des paramètres passés en argument de l’appel à la méthode M. Dans l’exemple de réalisation représenté par la FIG. 1 , ces données permettent au module 103 d’interroger la base de règles DB, ce qui est représenté dans la figure par un point d’interrogation. La présence ou l’absence d’une règle concernant la possibilité pour le client C à l’identité ID vérifiée de procéder à un appel de l’interface API pour la méthode M avec les valeurs V va conduire le module 103 à autoriser ou non l’appel en question. D’autres modes de réalisation sont possibles, qui n’utilisent pas une base de règles DB. L’autorisation AUT peut être par exemple directement déterminée par le module 103 à partir d’informations présentes dans le module 103 lui-même. En l’occurrence, dans l’exemple représenté dans la FIG. 1 , l’appel en question est autorisé AUT par le module 103, ce qui est représenté par le symbole OK en regard du point d’interrogation qui représente l’interrogation de la base de règles DB. L’appel de la méthode M avec les valeurs V par le client C peut donc se poursuivre jusqu’à l’interface de programmation applicative API. Une caractéristique essentielle du procédé selon l’invention, présente dans tous les modes de réalisation, est que les opération de vérification CHK de l’identité ID, d’extraction XTR des valeurs V et enfin d’autorisation AUT de l’appel sont exécutées avant l’accès à l’interface de l’appel en question, donc avant la moindre exécution d’un élément du système S en lien avec l’appel. Autrement dit, toutes les opérations du procédé selon l’invention prennent place en dehors du système S, ce qui permet de les réaliser dans le cadre d’un système S hérité qui ne peut en aucun cas être modifié. L’avantage principal de l’invention réside dans cette possibilité d’application à une interface API d’un système S hérité qui ne peut être modifié. Une fois l’appel autorisé AUT, celui-ci est transmis à l’interface API. L’appel accède alors à l’interface API. Cette interface API va alors transmettre l’appel à l’élément du système S qui va effectuer la méthode M, avec en argument la ou les valeurs V. L’exécution de la méthode M interfacée par l’interface de programmation applicative API va produire la valeur V’. D’autres valeurs peuvent être produites selon la nature de la méthode M appelée. Des actions ne produisant pas de valeurs en retour peuvent également être effectuées par le système S. Cette valeur V’ est obtenue par le client logiciel C comme résultat de l’appel par le client C de la méthode M à travers l’interface API. Dans certains modes de réalisation de l’invention, non représentés dans la FIG. 1 , la valeur obtenue V’ va être utilisée par l’entité de gestion 100 pour ajouter dans la base de règles DB une nouvelle règle d’autorisation AUT utilisant la valeur obtenue V’. La FIG. 2 , quant à elle, présente un exemple d’étapes et d’échanges de messages mis en œuvre dans le cadre d’un mode de réalisation de l’invention. Dans l’exemple illustré par la FIG. 2 , l’architecture du client logiciel C et du système S qui comprend l’élément M interfacé par l’interface API est une architecture Web. Les messages échangés pour accéder aux services du système S interfacé par l’interface API, et en particulier l’élément M, sont des requêtes HTTP comprenant des verbes HTTP tels que GET, POST, PUT etc. D’autres réalisations sont possibles utilisant d’autres techniques de requêtages d’interfaces de programmation applicative. Dans l’exemple de la FIG. 2 , le client logiciel C émet une requête HTTP vers un système S pour obtenir le statut d’itinérance d’un téléphone mobile. Dans notre exemple, le système S peut être un système hérité, présent dans le système d’information d’un opérateur de télécommunications. Dans une architecture Web classique, le contrôle d’accès du serveur Web porte uniquement sur la possibilité pour un client C donné de requêter un service Web. C’est au service Web de s’assurer que la requête peut porter sur telle ou telle valeur. Dans notre exemple, le système S ne peut pas être modifié et fournit le statut d’itinérance pour un numéro donné num en retour d’une requête HTTP GET status(num) sans contrôler que le client logiciel C soit légitime à obtenir cette information. Cette situation est classique pour un système S prévu uniquement pour donner des informations à d’autres applications du système d’information de l’opérateur de télécommunications qui sont donc par nature légitimes à obtenir les informations du système S. Il peut être pertinent pour l’opérateur de télécommunications qui gère le système S d’ouvrir à des partenaires tiers la possibilité d’accéder aux services Web du système S. Par exemple, une banque peut souhaiter connaître le statut d’itinérance de ses clients afin d’améliorer la lutte anti-fraude. Le client logiciel C peut être alors un élément du système d’information d’une banque qui, en présence d’activités suspectes à l’étranger du compte d’un de ses clients, pourra vérifier grâce au statut d’itinérance s’il est effectivement présent à l’étranger ou pas. Cependant, il faut s’assurer que le client logiciel C ne pourra pas accéder à des informations relatives à d’autres clients de l’opérateur de télécommunications que ceux qui ont donné leur autorisation pour que cette information soit accessible. Or, le système S ne peut en général pas être modifié. Une gestion fine des droits d’accès ne peut pas lui être ajouté. Le contrôle d’accès réalisé par le serveur Web pour donner accès à l’interface API du système S n’est pas non plus adapté. L’invention prend tout son intérêt dans cette situation. Le client logiciel C, par exemple un élément du système d’information d’une banque, souhaite interroger l’interface de programmation applicative API du système S pour connaître le statut d’itinérance d’un téléphone mobile. Cette information est accessible en adressant à l’interface API la requête HTTP GET status(num1). L’entité de gestion 100 est par exemple, dans ce mode de réalisation, un composant du serveur Web qui donne accès à l’interface API sous forme de requêtes HTTP. L’entité de gestion 100 va vérifier CHK l’identité ID du client logiciel C et extraire XTR les valeurs V de l’appel à l’interface API. Il s’agit ici en l’occurrence du numéro de téléphone num1. La FIG. 2 représente dans un rectangle l’opération réalisée par le module 103 d’autorisation. Dans l’exemple représenté ici, le module 103 procède en interrogeant une base de règles DB. Deux règles présentes dans la base de règles DB indiquent d’une part que l’interrogation de la requête du statut d’itinérance est possible en général pour le client C dont l’identité ID est vérifiée et de plus que cette interrogation est autorisée OK pour le numéro de téléphone num1. Le module 103 de l’entité de gestion 100 va donc autoriser AUT l’accès à l’interface API de l’appel par le client C dont l’identité est ID de la requête donnant le statut d’itinérance pour le numéro de téléphone num1. Cet appel se poursuit donc vers l’interface de programmation applicative API qui interface le système S. Celui-ci est disposé à répondre et va donc répondre au client logiciel C. Comme la technologie d’interrogation de l’interface API est un service Web, le système S répond tout d’abord par un message d’information 200 OK qui est un message standard du protocole HTTP. Le système S, qui est un système hérité, sans modification, répond et donne le statut d’itinérance à travers l’interface API, ce qu’il fait à chaque fois qu’il est requêté et qu’il est disponible. L’information est transférée au client logiciel C. Ultérieurement, le client logiciel C souhaite requêter le statut d’itinérance pour le numéro de téléphone num2. Dans ce cas, l’interrogation de la base de règles DB par le module 103 montre que le client logiciel C dont l’identité ID a été vérifiée CHK n’est pas autorisé NOK à obtenir le statut d’itinérance du numéro de téléphone num2. L’information peut être explicitement donnée dans une règle de la base DB, comme indiqué dans la FIG. 2 , ou bien, dans d’autres exemples, l’absence d’une règle autorisant explicitement l’accès du client C à l’information va suffire pour le module 103 à ne pas autoriser AUT la poursuite de l’appel et à accéder à l’interface API. L’appel du client C n’est donc pas autorisé AUT et l’entité de gestion 100 répond par un message d’information 403 Forbidden qui est un message standard du protocole HTTP au client logiciel C. D’autres messages standards peuvent être utilisés de préférence, par exemple le message 404 Not Found afin de ne pas fournir d’information à un éventuel attaquant. Dans cet exemple de réalisation, l’appel n’est pas autorisé AUT à accéder à l’interface API par l’entité de gestion 100 après interrogation de la base de règles DB, et par conséquent, une erreur est renvoyée au client logiciel. Ici, l’appel n’est pas transmis à l’interface API du système S. Comme ce système hérité n’a pas pu être modifié, si l’appel avait été transmis, le système S aurait procédé à l’exécution de l’appel et aurait fourni une réponse. Le client C, élément du système d’information d’une banque, en l’absence de l’invention, pourrait accéder aux statuts d’itinérance de n’importe quel téléphone mobile, ce qui serait une faille de sécurité importante pour le système d’information de l’opérateur de télécommunications. L’invention permet donc d’ouvrir les interfaces API des systèmes S hérités à des tiers, sans avoir à les modifier, et en préservant leur sécurité. L’exemple de la FIG. 2 est donné dans le contexte de l’ouverture d’API d’un système d’information dans le domaine des télécommunications mais l’invention peut s’appliquer dans tout autre domaine industriel ou commercial dans lequel on souhaite ouvrir les interfaces de systèmes d’information. La FIG. 3 , quant à elle, présente un autre exemple d’étapes et d’échanges de messages mis en œuvre dans le cadre d’un mode de réalisation de l’invention. Dans cet exemple, comme dans celui de la FIG. 2 , l’architecture du client logiciel C et du système S est une architecture Web et les messages échangés pour accéder aux services du système S interfacé par l’interface API sont des requêtes HTTP comprenant des verbes HTTP tels que GET, POST, PUT etc. D’autres réalisations sont possibles utilisant d’autres techniques de requêtages d’interfaces de programmation applicative tels que SOAP ou CORBA ou d’autres. Dans l’exemple de la FIG. 3 , le système S est un élément du système d’information d’un opérateur de télécommunications. L’invention peut s’appliquer dans tout domaine industriel en sus de celui repris dans les exemples présentés ici. Dans notre exemple, l’objectif est de permettre à un client de l’opérateur de réaliser par lui-même certaines opérations de gestion. Pour cela, un client logiciel C peut appeler l’interface API du système S en adressant une requête HTTP POST mgmt(num) pour indiquer sa volonté de réaliser dans le futur certains actes de gestion (traduction de l’anglais management , abrégé en mgmt) pour le numéro de téléphone num. L’entité de gestion 100 va réaliser un contrôle d’accès tel que décrit dans l’exemple de la FIG. 2 afin de s’assurer que cette requête est autorisée. Le client logiciel C peut être par exemple une application mobile, hébergée dans l’ordiphone dont le numéro de téléphone est num et cette application peut disposer d’un identifiant ID unique. Dans l’exemple présenté ici, le module d’autorisation 103 utilise une base de règles DB pour décider si un appel donné peut accéder ou non à l’interface API. L’entité de gestion 100 peut alors avoir dans sa base de règles DB que seul le client logiciel C muni de l’identifiant ID est autorisé AUT à poster vers le système S la requête HTTP POST mgmt(num). Ce procédé d’autorisation AUT, déjà décrit dans la FIG. 2 , n’est pas davantage détaillé ici. En retour, le système S transmet au client C le message d’information 200 OK qui est un message standard du protocole HTTP puis fournit au client C une valeur V’, à savoir dans cet exemple un identifiant de gestion hdlr1 (abrégé de l’anglais handler ) qui permettra ultérieurement au client logiciel C de réaliser des opérations de gestion en adressant d’autres requêtes à l’interface API du système S. Dans un mode de réalisation de l’invention, l’entité de gestion 100 récupère cette valeur V’ en retour et l’utilise pour créer une nouvelle règle ajoutée ADD à la base de règles DB. Cette opération est représentée dans la FIG. 3 par un rectangle dans lequel une règle est ajoutée à la base DB, ladite règle consistant à autoriser à l’identifiant ID (celui du client C) d’effectuer l’opération de gestion data_inc pour l’identifiant de gestion hdlr1. Cette opération de gestion a par exemple pour effet d’augmenter le forfait données attribué au numéro de téléphone correspondant à l’identifiant de gestion hdlr1. D’autres règles, correspondant à d’autres opérations de gestion, peuvent bien sûr être rajoutées. Dans la suite, comme montré sur la FIG. 3 , le client logiciel C peut effectivement appeler l’interface API avec la requête HTTP PUT data_inc(hdlr1). Cette requête est autorisée AUT par l’entité de gestion puisque la règle correspondante a été ajoutée précédemment dans la base de règles DB en utilisant la valeur de retour V’, à savoir l’identifiant de gestion hdlr1. L’effet de cette requête sera alors, par exemple, d’augmenter le forfait de données attribué au numéro de téléphone correspondant à l’identifiant de gestion hdlr1. En revanche, la même requête HTTP effectuée par le même client logiciel C mais pour un autre identifiant de gestion hdlr2 ne sera pas autorisée. Dans ce cas, l’entité de gestion 100 répond par un message d’information 403 Forbidden qui est un message standard du protocole HTTP au client logiciel C. Dans certains modes de réalisation, la règle R ajoutée ADD est associée à une durée de validité. La règle R ajoutée ADD ne sera donc active que pendant une durée limitée. La durée de validité peut être transmise dans les arguments obtenus en retour de l’appel et de l’exécution de l’élément M. Dans d’autres modes de réalisation, la durée de validité est définie a priori par l’entité de gestion 100. Les deux modes de réalisation peuvent être combinés. Certains types de règles R ajoutées ADD peuvent avoir une durée de validité fournie en retour par l’élément M alors que d’autres auront une durée prédéfinie. La durée prédéfinie peut aussi être une durée de validité par défaut qui sera appliquée si une durée n’est pas présente dans les valeurs fournies en retour de l’appel de l’élément M. Grâce à l’invention, sans modifier le système S hérité, qui ne peut pas intégrer un système de contrôle d’accès ajouté, il est donc possible de mettre en place des opérations de gestion effectuées par des clients logiciels situés en dehors du système d’information dans lequel se trouve le système S. L’utilisation d’identifiants de gestion permet d’éviter des attaques où les numéros de téléphone sont devinés par des attaquants sachant comment requêter le système S. Signalons enfin ici que, dans le présent texte, le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.). Procédé de gestion de l’appel par un client logiciel (C) d’une interface de programmation applicative (API), ledit client logiciel (C) ayant une identité (ID), ledit appel visant à exécuter un élément (M) interfacé par l’interface de programmation applicative (API), le procédé comprenant les étapes suivantes réalisées pour un appel donné avant l’accès à l’interface (API) : Vérification (CHK) de l’identité (ID) du client logiciel (C) ; Extraction (XTR) des valeurs (V) des arguments passés en paramètre par le client logiciel (C) dans l’appel de l’interface de programmation applicative (API) ; Autorisation (AUT) pour l’appel donné d’accéder à l’interface (API) en fonction de l’identité (ID) du client logiciel (C) et des valeurs extraites (V). Procédé de gestion selon la revendication 1 caractérisé en ce qu’il comprend, si l’appel donné est autorisé (AUT) à accéder à l’interface (API), l’ajout (ADD) dans une base de règles (DB) d’une règle (R) comprenant une valeur obtenue (V’) à la suite de l’exécution de l’élément (M) appelé, ladite règle ajoutée (R) étant relative à une étape d’autorisation (AUT) ultérieure d’un autre appel. Procédé de gestion selon la revendication 2 caractérisé en ce qu’une règle (R) ajoutée dans la base de règles (DB) est une règle autorisant un appel ultérieur du même client logiciel (C) vers la même interface de programmation applicative (API). Procédé de gestion selon l’une des revendications 2 ou 3 caractérisé en ce que la règle ajoutée (R) dans la base de règles (DB) est associée à une durée de validité. Entité de gestion (100) gérant l’appel par un client logiciel (C) d’une interface de programmation applicative (API), ledit client logiciel (C) ayant une identité (ID), ledit appel visant à exécuter un élément (M) interfacé par l’interface de programmation applicative (API), l’entité de gestion (100) comprenant les modules suivants : Un module (101) de vérification (CHK) de l’identité (ID) du client logiciel (C) ; Un module (102) d’extraction (XTR) des valeurs (V) des arguments passés en paramètre par le client logiciel (C) dans l’appel de l’interface de programmation applicative (API) ; Un module (103) d’autorisation (AUT) pour l’appel donné d’accéder à l’interface (API) en fonction de l’identité (ID) du client logiciel (C) et des valeurs extraites (V) ; et caractérisée en ce que, pour un appel donné, les étapes de vérification (CHK), d’extraction (XTR) et d’autorisation (AUT) sont toutes réalisées avant l’accès à l’interface (API). Entité de gestion (100) selon la revendication 5 comprenant de surcroît une base de règles (DB), lesdites règles étant relatives à l’autorisation (AUT) pour l’appel d’accéder à l’interface (API). Programme d'ordinateur apte à être mis en œuvre par une entité de gestion, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes du procédé de gestion défini dans la revendication 1. Support de données, sur lequel est enregistré un programme d’ordinateur comprenant une séquence d’instructions pour la mise en œuvre du procédé de gestion conforme à la revendication 1 lorsqu’il est chargé dans et exécuté par un processeur.