FR 2965691 A1 20120406 FR 1057955 A 20101001 Quantification de l'utilisation d'une application Internet par un dispositif de traitement de données. Domaine technique L'invention se rapporte à un procédé de quantification de l'utilisation d'une application par un dispositif de traitement de données. Par quantification, on entend ici l'une attribution d'une grandeur mesurable liée à l'utilisation de l'application. La grandeur est indifféremment une durée d'utilisation, un nombre d'utilisations, etc. Le dispositif en question comprend des ressources physiques et logicielles aptes à exécuter une application et à communiquer avec un autre dispositif, ci-après désigné par le terme serveur, au travers d'un réseau de communication dont la nature est quelconque (Internet, GSM, 3G, Wi-Fi, etc.). Les ressources incluent au moins un processeur et au moins une mémoire pour stocker des données numériques Le dispositif en question est par exemple un ordinateur, un radiotéléphone, un lecteur/enregistreur par exemple de type MP3 (acronyme du terme anglais "Windows Media Audio"), etc. L'application en question est une application de type "Application Web" ci-après désignée par l'expression "application internet" connue de l'homme du métier. Ce type d'application correspond à un programme applicatif manipulable par le biais d'un navigateur de type Internet. La particularité des applications Internet, par rapport à une application classique, est que l'environnement d'exécution d'une application internet, à savoir les ressources physiques et logicielles qui serviront à l'exécuter, est situé sur un dispositif autre que le dispositif dans lequel est stocké le navigateur. Le plus souvent, le navigateur est situé sur un terminal de type ordinateur personnel, et l'environnement d'exécution est situé sur un serveur. Dans cette configuration, l'application peut être manipulée à distance par le biais du navigateur. La manipulation permet notamment l'envoi de messages destinés à l'environnement d'exécution de l'application concernée et la réception de messages issus de l'environnement d'exécution. Etat de la technique Aujourd'hui, des applications internet sont mises à disposition par des fournisseurs d'applications, notamment des opérateurs de télécommunication. La plupart des applications sont payantes et le mode de facturation varie d'une application à une autre. Il existe aujourd'hui plusieurs modes de facturation dont les suivants. Un premier mode de vente se base par exemple sur une vente basée sur un téléchargement. Une fois le téléchargement réalisé, le prix du téléchargement ayant été fixé au préalable, le fournisseur et le développeur peuvent se partager la vente. Un deuxième mode permet un nombre de téléchargement(s) illimités) moyennant le paiement d'une somme d'argent forfaitaire par exemple mensuelle. Un autre mode peut aussi se baser sur une vente aux enchères d'une application. Il existe aussi un mode dans lequel un développeur d'applications a la possibilité de fixer le prix de vente. Ce mode est surtout employé lorsque le développeur en question est un développeur indépendant. Dans ce contexte, le développeur s'inscrit auprès du fournisseur qui mettra à disposition son application. Le développeur fixe ensuite un prix et perçoit par exemple un pourcentage des revenus générés par son application. Cette liste de modes de facturation n'est bien évidemment pas exhaustive. D'autres modes peuvent bien évidemment s'ajouter à cette liste. Un point commun aux modes de facturation listés ci-dessus est qu'ils ne se basent pas sur l'utilisation réelle qui est faite de l'application. Or, le fournisseur d'applications Internet, ou le développeur d'applications selon le mode de facturation choisi, peut souhaiter facturer l'utilisation d'une application en fonction de l'utilisation réelle qui est faite de l'application. Or, il n'existe pas dans l'état de la technique de moyens permettant de quantifier l'utilisation réelle qui est faite de l'application par un utilisateur donné. L'invention vient améliorer la situation. L'invention L'invention a pour objet un procédé de quantification de l'utilisation d'une application, l'environnement d'exécution de l'application étant situé sur un dispositif, dit premier dispositif, et manipulable via une interface programmatique présente sur un deuxième dispositif, le premier et le deuxième dispositif étant relié par l'intermédiaire d'un réseau de communication, caractérisé en ce qu'il comprend une étape de quantification apte à quantifier l'utilisation d'une application en se basant sur les messages échangés entre l'interface et l'environnement d'exécution de l'application. Ainsi, des échanges entre l'application de type Internet et l'environnement d'exécution servent à quantifier l'utilisation qui est faite d'une application. Nous verrons dans la suite qu'un module s'intercale entre le premier et le deuxième dispositif afin d'intercepter tout ou partie des messages destinés à l'environnement d'exécution d'une application et/ou à une interface programmatique. Ces interceptions permettront de quantifier l'utilisation qui est faite d'une application et en définitive permettront une facturation liée à l'utilisation réelle qui est faite d'une application. Divers modes de réalisation de l'invention sont envisageables Nous verrons dans la suite de la description que le nombre de messages échangés peut suffire à quantifier. Ainsi, Dans un mode de mise en oeuvre de l'invention, une quantification correspond à un comptage de tout ou partie du nombre de messages échangés entre l'application et l'interface. Ce mode de mise en oeuvre est intéressant en ce que l'interface programmatique et/ou les applications Internet ne nécessitent pas de modifications. Dans un autre mode de mise en oeuvre de l'invention, la quantification comprend une extraction de données temporelles issues des messages échangés, et un calcul de temps d'utilisation basé sur les données temporelles extraites. L'extraction de données temporelles, par l'heure de début de l'utilisation et l'heure de fin d'utilisation, incluses dans les messages échangés peuvent suffire pour quantifier une utilisation. Nous verrons dans la suite que les données temporelles peuvent être fournies par l'environnement d'exécution de l'application. Cette caractéristique a pour avantage de fournir une information relativement précise de l'utilisation qui est faite de l'application car l'information provient de l'environnement d'exécution de l'application en cours d'exécution. Dans un autre mode de mise en oeuvre de l'invention, le module mémorise un droit d'utilisation lié à l'utilisation d'une application. Dans cette configuration, au cours de l'utilisation de l'application, le module transmet à l'application l'évolution du droit dans le temps. Grâce à ce mode de mise en oeuvre, l'application est informée d'une fin de droit et peut à ce titre agir en conséquence. L'action en question peut consister par exemple à bloquer l'utilisation de l'application lorsque le droit est épuisé. Dans un autre mode de mise en oeuvre de l'invention, à une application donnée et à un utilisateur donné correspond un type de quantification particulier. Lors de l'utilisation d'une application, le module ayant connaissance de la correspondance, quantifie l'utilisation selon le type de quantification associé à l'application en cours d'exécution et à l'utilisateur utilisant l'application. Grâce à ce mode de mise en oeuvre, les types de quantification peuvent être variés, le module se chargeant d'identifier le type afin de fournir des données pertinentes à l'application. Selon un autre aspect, l'invention a trait à une application apte à être stockée dans une mémoire, ladite application étant accessible depuis une interface programmatique située sur un dispositif, dit deuxième dispositif, et dont l'environnement d'exécution est situé sur un autre dispositif, dit premier dispositif, caractérisé en ce que l'application comprend des moyens d'insertion aptes à insérer, dans les messages qu'elle transmet à destination de l'interface, des données permettant de quantifier l'utilisation qui est faite de l'environnement pour une application en cours d'exécution. Selon un mode de mise en oeuvre, l'environnement d'exécution de l'application reçoit, au cours de son utilisation, l'évolution du droit dans le temps ; dans cette configuration, l'application comprend avantageusement des moyens de blocage aptes à requérir le blocage l'utilisation de l'application par exemple lorsque le droit est épuisé. L'invention a aussi trait à un module de comptage apte à être installé dans un réseau de communication et apte à intercepter des messages échangés entre une interface programmatique et un environnement d'exécution associé à une application Internet accessible depuis l'interface. Selon l'invention, le module est caractérisé en ce qu'il comprend des moyens pour fournir des informations relatives aux messages échangés. Selon un mode de mise en oeuvre, le module comprend des moyens de comptage aptes à compter tout ou partie des messages échangés entre l'interface et l'environnement d'exécution de l'application en cours d'exécution. Selon un autre mode de mise en oeuvre, le module comprend des moyens d'extraction de données aptes à extraire des données temporelles dans les messages échangés et des moyens de calcul aptes à calculer le temps d'utilisation en fonction des données temporelles extraites. Le module peut aussi comprendre des moyens de mémorisation d'un droit d'utilisation d'une application, et des moyens pour transmettre à l'environnement d'exécution l'évolution du droit d'utilisation dans le temps. Selon un autre mode de mise en oeuvre, à une application donnée et à un utilisateur donné correspond un type de quantification particulier. Dans cette configuration, le module comprend des moyens de mémorisation apte à mémoriser la correspondance, et des moyens pour quantifier selon le type de quantification associé à l'application en cours d'exécution et à l'utilisateur utilisant l'application. Enfin, l'invention a trait au programme d'ordinateur apte à être mis en oeuvre dans un module tel que défini ci-dessus, ledit programme comprenant des instructions de code qui, lorsque le programme est exécuté, réalise tout ou partie des étapes du procédé de l'invention défini ci-dessus, à savoir au moins l'étape de quantification apte à quantifier l'utilisation d'une application en se basant sur les messages échangés entre l'interface et l'environnement d'exécution de l'application. 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és. Les figures: La figure 1 représente un système informatique sur lequel est illustré un exemple de réalisation illustrant un procédé de quantification de l'utilisation d'une application Internet. La figure 2 est une vue d'échanges de messages illustrant un mode de réalisation du procédé de l'invention. Les figures 3 à 5 illustrent quant à elles des variantes du procédé décrit en référence à la figure 2. Description détaillée d'un exemple de réalisation illustrant l'invention La figure 1 représente un système SYS comprenant un premier dispositif de traitement de données SRV. Ce premier dispositif stocke des applications Internet APP et des ressources physiques et logicielles constituant un environnement pour l'exécution des applications. Le système SYS comprend un deuxième dispositif de traitement de données PC relié au premier dispositif par l'intermédiaire d'un réseau RES. Le réseau RES est quelconque. Dans notre exemple, le réseau utilisé est le réseau Internet. Dans notre exemple, le serveur SRV comprend un environnement d'exécution incluant un processeur PRO1, dit premier processeur, relié à une mémoire MEM1, dite première mémoire. Le premier processeur PRO1 et la première mémoire MEM1 sont reliés par l'intermédiaire d'un bus de données BUS1, dit premier bus. Dans notre exemple, l'ordinateur PC comprend un processeur PRO2, dit deuxième processeur, relié à une mémoire MEM2, dite deuxième mémoire, par l'intermédiaire d'un bus BUS2, dit deuxième bus. Chaque dispositif comprend en outre des moyens d'entrée/sortie IO1, IO2 respectifs pour recevoir des données depuis le réseau RES et envoyer des données vers le réseau RES. L'environnement d'exécution des applications, situé sur le serveur, est accessible depuis le deuxième dispositif de traitement de données PC par le biais d'un navigateur NAV stocké sur dans la mémoire MEM2 installé dans le deuxième dispositif PC. Le navigateur en question est par exemple le navigateur Internet Explorer connu de l'homme du métier mais ne se limite pas à ce navigateur en particulier. Dans notre exemple, le deuxième dispositif est un ordinateur PC. Le navigateur NAV comprend généralement des zones à sélectionner qui lorsqu'elles sont manipulées, envoient des requêtes à destination de l'environnement d'exécution de l'application concernée. Le navigateur est également apte à recevoir des réponses issues de l'environnement d'exécution associé à l'application à qui la requête était adressée. Dans notre exemple, la communication sur le réseau RES s'effectue selon le protocole http connu de l'homme du métier. Selon l'invention, un module MOD, ci-après désigné par module de comptage, est connecté au réseau et a pour fonction d'intercepter tout ou partie des messages échangés entre le navigateur NAV et l'environnement d'exécution d'une application Internet APP. Ce module a pour fonction de fournir des données aidant à quantifier l'utilisation qui est faite d'une application APP. Le module MOD correspond à un dispositif de traitement de données en ce qu'il comprend un processeur, dit troisième processeur auquel est relié une 2965691 s mémoire MEM3, dite troisième mémoire, et une entrée/sortie I/03, reliés par l'intermédiaire d'une bus de données BUS3, dit troisième bue de données. Le module MOD peut quantifier de plusieurs façons selon le mode de facturation choisi. La quantification peut consister par exemple 5 à compter le nombre de messages échangés entre le navigateur et l'environnement d'exécution de l'application concernée à évaluer la durée d'utilisation d'une application, etc. 10 Un mode de réalisation est décrit ci-dessous. Ce mode se base sur une quantification consistant en une durée d'utilisation. L'application choisie pour illustrer l'invention est une application qui permet de lire des articles d'un journal. Le mode de facturation choisi dans notre exemple est basé sur le temps de lecture d'un article. On suppose que la facturation est réalisée par une entité 15 ENT avec laquelle le module MOD peut communiquer au travers d'un réseau quelconque. L'entité ENT en question comprend des moyens permettant de communiquer avec le module et d'élaborer une facture en fonction de données reçues. Nous ne rentrerons pas dans les détails structurels de cette entité car 20 sans intérêt pour l'explication de l'invention. Dans notre exemple, l'entité ENT communique est connecté au réseau RES et communique avec l'extérieur par ce biais. Aussi, sont stockés dans l'entité ENT, les modes de facturation de chaque application Internet à appliquer. Ces modes de facturation sont définis au 25 préalable par le fournisseur et/ou le développeur de l'application. Un exemple de réalisation est décrit en référence à la figure 2. Sur cette figure 2 ainsi que sur les figures suivantes un axe du temps indique le sens d'exécution des étapes. L'exemple comprend plusieurs étapes ET1 à ET10. Lors d'une première étape ET1, un utilisateur développeur DVP d'une application télécharge son application de lecture par l'intermédiaire d'un terminal (non représenté sur la figure) et requiert un stockage de cette application APP sur le serveur SRV. Lors d'une deuxième étape ET2, un utilisateur se connecte au serveur SRV et achète l'application de lecture APP. L'achat est suivi d'un téléchargement de l'application APP et d'un stockage de l'application sur l'ordinateur PC. Lors d'une troisième étape ET3, un utilisateur ouvre le navigateur, et requiert l'exécution de l'application de lecture. Une requête http de lecture est transmise à destination de l'environnement d'exécution de l'application. Lors d'une quatrième étape ET4, l'application APP reçoit la requête http et télécharge l'article demandé sur l'ordinateur PC. Lors d'une cinquième étape ET5, l'utilisateur lit l'article. Lors d'une sixième étape ET6, dans notre exemple de réalisation, l'application APP envoie à une fréquence choisie un message http incluant une information d'incrément du temps passé au module de comptage. A cet effet, l'application est conçue initialement, par exemple par le développeur de l'application, pour permettre la transmission de telles données dans un message http. Lors d'une septième étape k 1/, l'utilisateur décide de ne plus utiliser l'application APP et ferme à ce titre la session. Le navigateur NAV transmet une requête http apte à requérir une fermeture de l'application auprès du serveur SRV. Lors d'une huitième étape ETB, l'application émet une requête http apte à requérir une fin de session. Dans notre exemple, le message comprend un en-tête incluant des paramètres dont un premier paramètre indiquant que la session est fermée et un deuxième paramètre indiquant que le temps d'utilisation de l'appli a été de "X" minutes. Lors d'une neuvième étape ET9, le module MOD intercepte la requête http et extrait de l'entête des infos dont les "X" minutes. Lors d'une dixième étape ET10, le module MOD envoie une requête http incluant l'information sur le temps passé à l'entité ENT dédiée à la facturation. A ce stade du procédé, l'entité ENT est capable d'élaborer une facture en conséquence. Des variantes du mode de réalisation peuvent être envisagées dont les suivantes. Selon une lére variante du mode de réalisation, le module MOD a connaissance du mode de facturation à appliquer. Dans ces conditions, le module est apte à transmettre à l'application une demande d'arrêt d'utilisation de l'application. Dans cette configuration, en référence à la figure 3, l'étape ET6 est suivie, lorsque le module MOD constate que le temps d'utilisation est épuisé, d'une étape ET6-3a au cours de laquelle le module transmet au serveur SRV un message informant que l'utilisateur a épuisé son droit d'utilisation de l'application. D'une étape ET6-3b optionnelle au cours de la quelle le module informe l'entité ENT. Dans cette lé' variante, la huitième étape ETB, la neuvième étape ET9 et la dixième étape ET10, sont supprimées. Selon une 2ième variante du mode de réalisation, le module MOD mémorise un droit d'utilisation lié à l'utilisation d'une application et l'évolution de ce droit dans le temps. Dans cette configuration, le module MOD peut, au cours de l'utilisation de l'application, transmettre à l'application l'évolution du droit dans le temps. Par exemple, si le mode de facturation se base sur une quantité prédéfinie au-delà de la quelle l'application ne peut plus être utilisée, le module ayant connaissance de la quantité utilisée et à fortiori de la quantité restante, peut informer l'application de cette quantité restante. En reprenant l'exemple décrit ci-dessus, et en référence à la figure 4, la sixième étape ET6 est associée à une étape ET-6-4a au cours de laquelle des messages issus du module sont envoyés à destination du serveur SRV pour informer de la quantité restante. Cette caractéristique permettra à l'application de bloquer l'utilisation de l'application lorsque le droit sera épuisé. Le blocage est possible même si la communication est interrompue entre le module et l'application pendant une durée donnée. En effet, l'application connaissant la quantité restante fournie par le module est capable pendant l'interruption de constater, au fil du temps, que la quantité restante est nulle et d'agir en conséquence par exemple en bloquant l'accès à l'application. L'action résultante est par exemple que l'application APP envoie, lors d'une étape ET6-4b une information à l'entité ENT indiquant que le droit est épuisé. L'entité ENT peut alors élaborer une facture en conséquence. L'information relative au droit épuisé peut aussi être transmise par l'application APP au module MOD, le module se chargeant ensuite de fournir l'information à l'entité ENT. La figure 4 n'illustre que deux envois de messages selon l'étape ET6-4a, cependant le nombre peut être inférieur ou supérieur. Selon une 3ième variante du mode de réalisation, le module MOD est capable de se réinitialiser par exemple dans le cas d'un droit mensuel à un nombre limité par exemple de morceaux de musique. Dans cette configuration, en référence au mode de réalisation qui précède et à la figure 5, le procédé comprend une étape Ef6-5 au cours de laquelle le module requiert une remise à zéro des compteurs. La suite du procédé selon cette 3'eme variante est indifféremment l'ensemble des étapes EI7 à ET10, ou l'ensemble des étapes Ef6-3a et ET6-3b, ou l'ensemble des étapes ET6-4 et ET6-4b. La figure 5 n'illustre qu'un envoi de message selon l'étape ET6-5 pour une mise à jour des compteurs mensuels. Cependant le nombre de messages peut bien évidemment être supérieur par exemple un message par mois si la périodicité du droit est mensuelle. Selon une 4'ème variante du mode de réalisation, dans le cas où l'utilisation d'une application ne requiert aucun droit, le module de comptage est apte à rester inactif en ce sens qu'il laisse passer les messages et ne consulte pas les entêtes des messages échangés. Il ne transmet pas non plus de messages à l'application APP. A noter que les échanges auraient en toute rigueur dû inclure des données utiles à la facturation à savoir au moins l'identifiant du développeur. Aussi, lorsqu'une application Internent est exécutée, une clé secrète est par exemple associée à l'utilisateur de l'application. Dans cette configuration, on peut identifier le développeur et l'utilisateur de l'application et établir une facturation avec ces données. Le procédé décrit ci-dessus est réalisable par l'intermédiaire des moyens suivants : L'application APP comprend pour la réalisation de la sixième étape ET6 décrite ci-dessus, des moyens d'insertion INS aptes à insérer, dans les messages qu'elle transmet à destination de l'interface, des données permettant de quantifier l'utilisation qui est faite de l'application. L'application comprend, pour la réalisation du blocage décrit en référence à la deuxième variante décrite ci-dessus, des moyens de blocage BLC aptes à requérir le blocage de l'utilisation de l'application lorsque le droit est épuisé. Le module de comptage MOD comprend, notamment pour la réalisation de la dixième étape ET10, des moyens INF pour fournir des informations relatives aux messages échangés. - Le module comprend, notamment pour la réalisation de la neuvième étape ET9 décrite ci-dessus, des moyens d'extraction EXTC de données aptes à extraire des données temporelles dans les messages échangés et des moyens de calcul aptes à calculer le temps d'utilisation en fonction des données temporelles extraites. - Le module comprend des moyens de calcul CLC aptes à calculer le temps d'utilisation en fonction des données temporelles extraites. Le module comprend des moyens de quantification QNT pour quantifier selon le type de quantification associé à l'application en cours d'exécution et à 10 l'utilisateur utilisant l'application. Dans notre exemple, les moyens cités ci-dessus sont des programmes d'ordinateurs stockés en mémoire à savoir dans la première mémoire MEM1 si les moyens sont inclus dans l'environnement d'exécution de l'application APP ou la troisième mémoire MEM si les moyens sont inclus dans le module MOD. 15 REVENDICATIONS1. Procédé de quantification de l'utilisation d'une application (APP), l'environnement d'exécution de l'application étant situé sur un dispositif (SERV), dit premier dispositif, et manipulable via une interface programmatique (NAV) présente sur un deuxième dispositif (PC), le premier et le deuxième dispositif étant relié par l'intermédiaire d'un réseau de communication (RES), caractérisé en ce qu'il comprend une étape de quantification apte à quantifier l'utilisation d'une application en se basant sur les messages échangés entre l'interface (NAV) et l'environnement d'exécution de l'application (APP). 2. Procédé selon la revendication 1, caractérisé en ce qu'une quantification correspond à un comptage de tout ou partie du nombre de messages échangés entre l'application et l'interface. 3. Procédé selon les revendications 1 ou 2, caractérisé en ce que la quantification comprend une extraction de données temporelles issues des messages échangés, et un calcul de temps d'utilisation basé sur les données temporelles extraites. 4. Procédé selon la revendication 3, caractérisé en ce que les données temporelles sont transmises par l'application à destination d'un module (MOD) s'intercalant entre l'environnement d'exécution de l'application et l'interface (NAV). 5. Procédé selon la revendication 4, caractérisé en ce que le module (MOD) mémorise un droit d'utilisation lié à l'utilisation d'une application et en ce qu'au cours de l'utilisation de l'application, le module transmet à l'application l'évolution du droit dans le temps. 6. Procédé selon la revendication 1, caractérisé en ce qu'à une application donnée et à un utilisateur donné correspond un type de quantification particulier, en ce que, lors de l'utilisation d'une application, le module ayant connaissance de la correspondance, quantifie selon le type de 14quantification associé à l'application en cours d'exécution et à l'utilisateur utilisant l'application. 7. Application (APP) apte à être stockée dans une mémoire, ladite application étant accessible depuis une interface programmatique (NAV) située sur un dispositif (PC) et dont l'environnement d'exécution est situé sur un autre dispositif (SRV), caractérisé en ce que l'application (APP) comprend des moyens d'insertion (INS) aptes à insérer, dans les messages qu'elle transmet à destination de l'interface (NAV), des données permettant de quantifier l'utilisation qui est faite de l'environnement pour une application (APP) en cours d'exécution. 8. Application selon la revendication 7, caractérisé en ce que l'environnement d'exécution reçoit l'évolution du droit dans le temps et en ce que l'application comprend des moyens de blocage (BLC) aptes à requérir le blocage de l'utilisation de l'application lorsque le droit est épuisé. 9. Module de comptage (MOD) apte à être installé dans un réseau de communication et apte à intercepter des messages échangés entre une interface programmatique et un environnement d'exécution associé à une application (APP) accessible depuis l'interface, caractérisé en ce qu'il comprend des moyens (INF) pour fournir des informations relatives aux messages échangés. 10. Module selon la revendication 9, caractérisé en ce qu'il comprend des moyens d'extraction (EXTC) de données aptes à extraire des données temporelles dans les messages échangés et des moyens de calcul (CLC) aptes à calculer le temps d'utilisation en fonction des données temporelles extraites. 11. Module selon la revendication 9, caractérisé en ce qu'il comprend des moyens de mémorisation d'un droit d'utilisation d'une application, et en ce qu'il comprend des moyens pour transmettre à l'environnement d'exécution l'évolution du droit d'utilisation dans le temps. 12. Module selon la revendication 11, caractérisé en ce qu'à une application donnée et à un utilisateur donné correspond un type de quantification particulier, ledit module comprenant comprend des moyens de mémorisation (MEM3) apte à mémoriser la correspondance, et des moyens de quantification (QNT) pour quantifier selon le type de quantification associé à l'application en cours d'exécution et à l'utilisateur utilisant l'application. 13. Programme d'ordinateur apte à être mis en oeuvre dans un module (MOD) tel que défini dans la revendication 8, ledit programme comprenant des instructions de code qui, lorsque le programme est exécuté, réalise l'étape définie dans la revendication 1.