FR 3118815 A1 20220715 FR 2100160 A 20210108 L'invention concerne notamment un procédé d'obtention d'un modèle d’estimation de la progression de l’exécution d’une tâche logicielle T. Ce procédé comportant des étapes consistant à : – décomposer (S11) le code source de la tâche T en une pluralité de sous-tâches, et configurer (S12) le code source de la tâche avec l'association à chaque entrée d’une sous-tâche dans le code source, d'au moins un bloc d’instructions spécifiques, appelé "jalon", chaque jalon étant codé de manière à délivrer des informations dites d'exécution au cours d'une session considérée d'exécution de la tâche ; – effectuer (S21) un nombre déterminé de sessions d'exécution de test de la tâche et obtenir (S22) un corpus d'informations d'exécution à partir des informations d'exécution délivrées par les jalons au cours des sessions d'exécution de test ; – obtenir (S32) un modèle d'estimation de progression d'exécution de la tâche par apprentissage automatique (S31) à partir du corpus d'informations d'exécution. Figure de l’abrégé : Figure 2 Estimation de la progression de l'exécution d'une tâche logicielle La présente invention a trait de manière générale au domaine de la conception de plateformes logicielles et concerne notamment un procédé et un système de création automatique d'un modèle d'estimation de la progression de l'exécution d'un tâche logicielle, ainsi qu'un procédé d'utilisation d'un tel modèle. État de la technique Une plateforme logicielle (c'est-à-dire un environnement logiciel permettant la gestion ou l'utilisation de services applicatifs) est conçue soit de manière "monolithique", c'est-à-dire sous la forme d'un seul bloc logiciel, soit selon une organisation en "micro-services", c'est-à-dire consistant en une division de la plateforme en composants autonomes permettant de meilleures conditions de maintenance et d'évolution. Dans de nombreuses applications, par exemple des applications liées au traitement de la vidéo, d'apprentissage de modèle d'intelligence artificielle, ou encore de déploiement d'applications de type cloud computing ("informatique en nuage" en français), il arrive qu'une tâche logicielle complexe, mise en œuvre par un terminal d'un utilisateur, induise une durée importante de traitement par un processeur informatique, une telle durée pouvant s'étendre de l'ordre de quelques minutes à parfois plusieurs jours, dans des cas extrêmes ; il devient alors utile voire nécessaire d'informer l'utilisateur du déroulement de l'exécution de la tâche, et plus précisément de la progression temporelle de son exécution. Ainsi, de manière classique, lors de l'exécution d'une telle application, celle-ci provoque l'affichage sur un terminal d'utilisateur, d'une animation graphique telle qu'une barre de progression ou un sablier, afin d'informer l'utilisateur de la progression de son exécution. D'un point de vue de l'utilisateur, celui-ci dans la plupart des cas ne voit sur l'écran de son terminal qu'une indication visuelle de progression d'une tâche donnée, par exemple une barre de progression, qui évolue au cours du temps de manière saccadée et qui par conséquent ne revêt que peu d'intérêt pratique. En effet, à titre d'exemple, si la barre reste figée pendant quelques minutes à un niveau de progression donné, correspondant par exemple à un taux d'achèvement de 30% (trente pour cent) de la tâche, et qu'elle évolue ensuite subitement pour atteindre un taux d'achèvement de 80%, on comprend aisément que ce manque de linéarité dans l'affichage de la progression de la tâche, réduit fortement l'intérêt pour l'utilisateur d'une telle présentation. Pour parvenir à fournir à l'utilisateur un indicateur progressif, fluide et pertinent du degré d'achèvement de la tâche logicielle considérée, il serait nécessaire d'introduire dans la logique de conception du code logiciel de l'application un nombre significatif d'éléments de code, que l'on désignera dans la suite de l'exposé par "jalons", identifiables et permettant, au cours de l'exécution de l'application, d'estimer par exemple sous forme de pourcentages la quantité d'étapes logicielles réalisées et celle d'étapes restant à effectuer. Ainsi, le choix et le mode d'intégration de tels jalons dans le code d'une tâche logicielle, revêt une importance cruciale afin de pouvoir estimer efficacement en temps réel le degré d'achèvement de la tâche lors de son exécution. Cependant, la mise en place de jalons dans le code d'un logiciel considéré présente des difficultés multiples. D'abord, l'insertion de jalons dans le code constituerait un surcroît de travail pour les équipes de développement logiciel. Ensuite, l'insertion, même à profusion, de jalons dans le code du logiciel ne serait pas nécessairement suffisante pour parvenir à une estimation satisfaisante du degré d'achèvement de la tâche, étant donné que le logiciel considéré peut présenter ce que l'on appelle des "goulets d'étranglement" — c'est-à-dire des points dans le logiciel qui limitent les performances globales du logiciel avec des effets sur les temps de traitement et de réponse —, et qui ne sont pas connus à l'avance par les développeurs, par conséquent déterminer a priori les endroits pertinents du code où insérer des jalons n'est pas chose aisée. Une autre difficulté provient du fait que certaines architectures logicielles favorisent le développement d'applications par des équipes indépendantes organisées pour développer, chacune, des composants indépendants de l'application. C'est le cas notamment de l'architecture dite en microservices selon laquelle une application est structurée comme un ensemble de services faiblement couplés, des microservices, qui communiquent les uns avec les autres en utilisant des interface de programmation applicative API ( Application Programming Interface ) indépendantes du langage de programmation. Ce type d'architecture logicielle ne favorise pas la concertation entre les équipes de développement quant à la pertinence et l'homogénéité des jalons logiciels choisis et à leur utilisation de bout en bout dans la chaîne logicielle. Enfin, certaines tâches logicielles complexes sont basées sur des fils d'exécution parallèle ( multithreading ) qui complexifieraient l'interprétation de jalons atteints au cours de l'exécution d'une telle tâche ; en effet, dans ce cas, l'exécution de la tâche ne se déroule plus selon un franchissement séquentiel et déterministe de jalons successifs. Un but de la présente invention est d'améliorer la situation exposée ci-dessus. A cet effet, selon un premier aspect , la présente invention a pour objet un procédé d'obtention d'un modèle d’estimation de la progression de l’exécution d’une tâche logicielle T. Ce procédé est remarquable en ce qu'il comporte des étapes consistant à : – (C1) décomposer le code source de la tâche T en une pluralité de sous-tâches, et configurer le code source de la tâche avec l'association à chaque entrée d’une sous-tâche dans le code source, d'au moins un bloc d’instructions spécifiques, appelé "jalon", chaque jalon étant codé de manière à délivrer des informations dites d'exécution au cours d'une session considérée d'exécution de la tâche ; – (C2) effectuer un nombre déterminé de sessions d'exécution de test de la tâche et obtenir un corpus d'informations d'exécution à partir des informations d'exécution délivrées par les jalons au cours des sessions d'exécution de test ; – (C3) obtenir un modèle d'estimation de progression d'exécution de la tâche par apprentissage automatique à partir du corpus d'informations d'exécution. Le procédé d'obtention d'un tel modèle, exposé ci-dessus, associe par conséquent, d'une part, l'insertion judicieuse dans le code source de la tâche logicielle de jalons permettant, chacun, de repérer efficacement un endroit précis du code source lors de son exécution, et d'autre part, un mécanisme d'apprentissage automatique reposant sur un corpus de données d'exécution obtenues lors d'un nombre important de sessions d'exécution de test de la tâche. Un tel modèle obtenu par apprentissage statistique peut ensuite être utilisé efficacement par un module de prédiction (voir second aspect de l'invention plus bas) afin d'évaluer "en temps réel" la progression d'exécution de la tâche logicielle en phase d'exploitation, par un terminal utilisateur par exemple, sur la base d'informations d'exécution transmises par les jalons précités placés dans le code source de la tâche, au cours du processus d'exécution de la tâche. Cette évaluation, tout au long de l'exécution de la tâche, de la progression de son exécution, et en particulier du temps restant jusqu'à son achèvement, permet une restitution efficace et fiable de la progression de la tâche à l'utilisateur, par exemple sous la forme d'une barre de progression, affichée sur l'écran d'un terminal informatique. Selon une caractéristique de réalisation du procédé d'obtention, les informations d'exécution délivrées par un jalon considéré comprennent au moins un identifiant de la tâche T, un identifiant de la session d'exécution, une information d'horodatage d'exécution du jalon, et des données dites de contexte, relatives au contexte d'exécution de la sous-tâche associée au jalon. Ces diverses informations d'exécution délivrées par un jalon donné, et en particulier les informations d'horodatage permettent d'évaluer statistiquement (par apprentissage) de manière efficace notamment une durée d'exécution entre deux jalons successifs de la tâche et finalement une durée d'exécution restante de la tâche, à partir d'un jalon exécuté donné. Selon une autre caractéristique de réalisation du procédé d'obtention, les données de contexte comprennent un ensemble de variables dynamiques d'entrée de la sous-tâche associée au jalon considéré, ces variables dynamiques ayant un effet direct sur la performance d'exécution globale de la tâche. La prise en compte de telles variables dynamiques permet, lors de l'exploitation du modèle selon le procédé d'utilisation (voir deuxième aspect de l'invention plus bas), d'augmenter la précision de la prédiction de la progression de la tâche lors d'une session d'exécution, en prenant en compte des informations de contexte liées à cette session d'exécution. Selon d'autres caractéristiques de réalisation du procédé d'obtention : – L'étape (C1) de décomposition du code source de la tâche T comprend la représentation du code source par une structure de données de type graphe acyclique orienté constitué de sommets et d'arêtes, dans laquelle les sommets correspondent aux jalons placés en entrée de sous-tâches et les arêtes constituent les sous-tâches proprement dites exécutées entre deux jalons. – La tâche logicielle T est fournie par une plateforme logicielle hébergée par un premier système informatique, et dans lequel chaque jalon est codé de manière à déclencher lors de son exécution la transmission des informations d'exécution à un second système informatique mettant en œuvre un moteur d'apprentissage. – Les informations d'exécution sont transmises par les jalons, via une interface de programmation applicative, API, à destination du second système informatique, en utilisant un protocole de type HTTP au travers d'un réseau de communication. – A l'issue de l'étape (C3) d'apprentissage, le modèle d’estimation de la progression de l’exécution de la tâche T, est implémenté sous la forme d'une fonction de prédiction mise en œuvre par un module de prédiction (PM). Selon un deuxième aspect , la présente invention concerne un procédé d'utilisation d'un modèle d'estimation de la progression de l'exécution d'une tâche logicielle, obtenu selon un procédé d'obtention tel qu'exposé ci-dessus. Ce procédé d'utilisation comprenant des étapes de : – (U1) déclenchement, par l'exécution de chacun des jalons codés dans le code de la tâche, de l'envoi d'une information d'exécution du jalon à destination d'un module de prédiction d'exécution, cette information d'exécution du jalon comportant une donnée d'identification de jalon ; – (U2) génération, en fonction du résultat du traitement des informations d'exécution de jalon, par le module de prédiction, d'une information de progression d'exécution de la tâche ; – (U3) envoi par le module de prédiction, à un module de gestion d'interface graphique du dispositif utilisateur, de chacune des informations de progression d'exécution de la tâche ; – (U4) modification, par le module de gestion d'interface graphique, d'une interface graphique affichée dans le dispositif utilisateur, en fonction de chacune des informations de progression d'exécution de la tâche. Ce procédé d'utilisation du modèle obtenu selon le procédé d'obtention exposé plus haut, permet d'estimer efficacement la progression de l'exécution de la tâche par un processeur d'un terminal informatique d'un utilisateur, au cours d'une session d'exécution de la tâche, et de permettre ainsi de restituer graphiquement de manière fiable la progression de l'exécution de la tâche sur un écran du terminal informatique. Selon un troisième aspect , la présente invention a pour objet un système informatique pour la mise en œuvre d'un procédé d'obtention d'un modèle d’estimation de la progression de l’exécution d’une tâche logicielle T, tel qu'exposé plus haut selon le premier aspect de l'invention, et d'un procédé d'utilisation d'un tel modèle, tel qu'exposé ci-dessus selon le second aspect de l'invention. Ce système comprend : – un serveur fournissant une plateforme logicielle incluant la tâche logicielle T ; – un serveur comprenant un moteur d'apprentissage destiné à générer le modèle d'estimation selon le procédé d'obtention précité, et un module de prédiction configuré pour estimer, selon le procédé d'utilisation précité, lors d'une session d'exécution de la tâche T, la progression en temps réel de l'exécution de la tâche et transmettre des informations indicatives de la progression, à un module de gestion d'interface graphique ; – un module de gestion d'interface graphique configuré pour mettre à jour une interface graphique d'un terminal informatique en fonction des informations indicatives de la progression de la tâche T. Selon un quatrième aspect , la présente invention a pour objet une programme informatique stocké sur un support matériel incorporé dans un serveur connecté à un réseau de communication, l'exécution du programme par un processeur du serveur, provoquant la mise en œuvre d'au moins certaines des étapes d'un procédé, selon le premier aspect de l'invention exposé plus haut, d'obtention d'un modèle d’estimation de la progression de l’exécution d’une tâche logicielle T ; et/ou la mise en œuvre d'au moins certaines des étapes d'un procédé, selon le deuxième aspect de l'invention exposé plus haut, d'utilisation d'un tel modèle d'estimation de la progression de l'exécution d'une tâche logicielle. Un tel programme informatique selon l'invention peut utiliser divers langages de programmation, et comprendre des modules sous forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Les avantages procurés par un système informatique et un programme informatique, selon l'invention, tels qu'exposés ci-dessus, sont identiques ou contribuent à ceux mentionnés supra en relation avec le procédé d'obtention d'un modèle d’estimation de la progression de l’exécution d’une tâche logicielle, et avec le procédé d'utilisation d'un tel modèle, selon l'invention, et ne seront par conséquent pas rappelés ici. La présente invention vise aussi un support d’enregistrement lisible par un système informatique et sur lequel sont stockées les instructions d'un programme informatique tel que celui mentionné ci-dessus. Un tel support d’enregistrement peut être constitué par n'importe quelle entité ou dispositif capable de stocker un tel programme. Par exemple, un tel 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 amovible tel qu’une clé USB ou un moyen d’enregistrement magnétique, tel qu’un disque dur. D'autre part, un programme (ou application logicielle) selon l'invention pourra être en particulier téléchargé sur un réseau de type Internet. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : – La représente un exemple de système informatique dans lequel les procédés de création et d'utilisation d'un modèle d'estimation de l'exécution d'une tâche logicielle, selon l'invention, peuvent être mis en œuvre. – La représente sous forme d'organigramme les étapes principales étapes d'un procédé selon l'invention de création automatique d'un modèle d'estimation de la progression de l'exécution d'une tâche logicielle. – La illustre, à titre d'exemple, le déroulement d'une session d'exécution d'une tâche logicielle T représentée par un graphe acyclique. – La représente sous forme d'organigramme les étapes principales d'un procédé selon l'invention d'utilisation d'un modèle d'estimation de la progression de l'exécution d'une tâche logicielle. – la illustre un premier exemple de réalisation de mise à jour d'une barre de progression restituant la progression de l'exécution d'une tâche logicielle, dont l'exécution est modélisée conformément à l'invention. – la illustre un second exemple de réalisation de mise à jour d'une barre de progression restituant la progression de l'exécution d'une tâche logicielle, dont l'exécution est modélisée conformément à l'invention. – la illustre un troisième exemple de réalisation de mise à jour d'une barre de progression restituant la progression de l'exécution d'une tâche logicielle, dont l'exécution est modélisée conformément à l'invention. Description détaillée Définitions Dans le cadre de la présente description les termes suivants sont utilisés avec les définitions associées : – " Tâche logicielle " : Processus informatique provoqué par l'exécution d'instructions d'un programme constituant une unité d'exécution par exemple un fil d'exécution ( thread en anglais). Une telle tâche logicielle peut par exemple être une application logicielle spécifique dont l'exécution occupe une durée relativement importante, dépassant au minimum quelques minutes, ou bien une fonctionnalité particulière d'un logiciel, par exemple une fonction de traitement d'images numériques, ou une fonctionnalité de chargement d'un environnement de communication informatique, etc. – " Jalon " : Bloc d'instructions particulières placé à un endroit précis du code source d'un programme informatique réalisant une tâche logicielle et qui permet de générer, lors de l'exécution du bloc précité, une information indiquant que l'exécution de la tâche est parvenue jusqu'à une instruction située à l'endroit du code où est placé le jalon considéré. Un tel jalon se comporte de manière similaire mais dans un but différent à un point d'arrêt informatique. Pour rappel (selon Wikipédia) un "point d'arrêt" est une marque placée par le programmeur à un endroit précis d'un programme informatique (généralement dans le code source ou le code assembleur obtenu à l'aide d'un désassembleur), qui permet d'indiquer à un débogueur d'arrêter l'exécution lorsqu'il atteindra cet endroit. C’est un moyen de scruter dans le détail l’exécution du programme en le faisant progresser petit à petit, afin de repérer des défauts de conception ou de mieux le comprendre. – " Modèle d'exécution d'une tâche logicielle " : il s'agit ici d'une expression simplifiée pour désigner un modèle d'estimation de la progression d'exécution de la tâche logicielle considérée, obtenu selon l'invention, par apprentissage automatique à partir d'un corpus d'informations d'exécution résultant d'un nombre donné d'itérations d'exécution de test de la tâche. La illustre un exemple de système informatique dans lequel les procédés, selon l'invention, de création et d'utilisation d'un modèle d'estimation de l'exécution d'une tâche logicielle, sont mis en œuvre. Comme représenté sur la ce système comprend un serveur SVR, tel qu'un serveur d'applications, fournissant une plateforme logicielle SPF qui inclut la tâche logicielle T dont le processus d'exécution est modélisé conformément à l'invention. La plateforme SPF peut être exécutée à distance ou téléchargée pour être exécutée en phase d'exploitation, via un réseau de communication NW par exemple de type Internet, dans un terminal informatique UT quelconque d'utilisateur, et en particulier la tâche T dont l'exécution est au préalable modélisée pour restituer efficacement la progression de son exécution à l'utilisateur du terminal UT. La plateforme logicielle SPF inclut en outre une application logicielle APP-S spécifique permettant d'une part de configurer et modéliser l'exécution de la tâche T, à distance via un terminal T1, tel qu'un ordinateur personnel, d'un programmeur de la plateforme ; et d'autre part, d'utiliser le modèle obtenu, lors d'une exécution ultérieure de la tâche via un terminal d'utilisateur UT. Le système représenté à la comprend également un serveur LMS de machine d'apprentissage (learning machine server) incluant un module moteur d'apprentissage LE (learning engine) et un module mémoire MEM4 dans lequel est stocké un modèle (MOD) d'exécution d'une tâche logicielle obtenu selon un procédé d'obtention d'un modèle, selon l'invention, tel que décrit plus bas en liaison avec la . Le serveur LMS comprend également un module PM de prédiction du temps d'exécution de la tâche T, utilisant le modèle MOD obtenu au préalable. Le serveur est LMS est constitué d'éléments agencés selon une architecture matérielle d'ordinateur, du même type que celle du serveur SVR détaillée ci-après. Bien que sur la , les serveurs SVR et LMS apparaissent comme deux entités distinctes, selon le mode de réalisation envisagé, les deux serveurs précités peuvent être incorporés dans une même entité matérielle. Comme illustré sur la , le serveur SVR est constitué d'éléments agencés selon une architecture matérielle d'ordinateur, cette architecture comprenant : – un processeur PRC ; – un premier module mémoire MEM1 dans lequel sont enregistrées les instructions de programme de l'application APP-S mentionnée plus haut, et dont l'exécution par le processeur (PRC) provoque en particulier la mise en œuvre des étapes du procédé d'obtention d'un modèle d'exécution, selon l'invention ; – un second module mémoire MEM2 dans lequel est stockée la plateforme logicielle SPF incluant la tâche T précitée ; – un module I/O d'interface de communication réseau, capable d'établir des communications selon un protocole de communication tel qu'un protocole de type HTTP ( HyperText Transfer Protocol ), par exemple le protocole HTTPS ( HyperText Transfer Protocol Secure ), sur le réseau NW pour communiquer avec les terminaux UT ou T1 ainsi qu'avec le serveur LMS de machine d'apprentissage ; – un module système d’exploitation OS gérant l’interaction entre les différents modules précités et le processeur (PRC) du serveur SVR. De même, comme illustré sur la , le terminal T1 utilisé par un programmeur est constitué d'éléments agencés selon une architecture matérielle d'ordinateur, cette architecture comprenant : – un processeur PRC-1 ; – un module mémoire MEM3 dans lequel est stocké la tâche T obtenue par téléchargement depuis le serveur SVR, une application logicielle APP1 spécifiquement conçue notamment pour configurer la tâche T avec des jalons appropriés permettant de mettre en œuvre le procédé de création d'un modèle, comme exposé plus bas ; – un module I/O d'interface de communication réseau, capable d'établir des communications selon un protocole de communication tel qu'un protocole de type HTTP, par exemple le protocole HTTPS, sur le réseau NW pour communiquer avec le serveur SVR ou avec le serveur LMS ; – un module d’affichage SCR/KB associé à un clavier (tactile ou mécanique) et un écran d'affichage (non représenté) couplé avec un module de gestion d'interface graphique GUI ( Graphical User Interface ) pour présenter graphiquement à l'utilisateur du terminal T1 des données relatives au processus de création d'un modèle d'exécution de la tâche T et de test du modèle obtenu ; et – un module système d’exploitation, OS-1, par exemple le système d’exploitation Windows™ de la société Microsoft, gérant l’interaction entre les différents modules et le processeur (PRC-1) du terminal T1. On notera ici que le terminal UT d'un utilisateur quelconque de la plateforme logicielle SPF, est constitué selon une architecture matérielle similaire à celle décrite ci-dessus en relation avec le terminal T1. La représente sous forme d'organigramme les étapes principales d'un procédé selon l'invention d'obtention d'un modèle d'estimation de la progression de l'exécution d'une tâche logicielle (dit modèle d'exécution d'une tâche). Comme représenté sur la , le procédé d'obtention du modèle débute par une première phase P1 de modification du code source de la tâche T. Cette première phase commence par une étape S11 de décomposition du code source de la tâche T en un ensemble de sous-tâches. A cette fin, le code source est d'abord représenté par une structure de données de type graphe acyclique orienté noté G(S, A) et constitué de sommets S(i) et d'arrêtes A(j). Les sommets S(i) correspondent aux endroits du code dans lesquels seront placés les jalons, tandis que les arêtes A(j) constituent les sous-tâches proprement dites effectuées entre deux jalons successifs. Les jalons sont par conséquent placés en entrée des sous-tâches identifiées dans le code source de la tâche T. La illustre, à titre d'exemple, le déroulement d'une session d'exécution d'une tâche logicielle T représentée par un graphe acyclique. Dans cet exemple, la tâche T est composée de cinq sous-tâches A(0) à A(4), correspondant à quatre sommets S(0) à S(3) du graphe. Les sous-tâches A(0) et A(1) démarrent à partir du même sommet S(0) ; les sous-tâches A(1) et A(3) démarrent à partir du même sommet S(1) ; la sous-tâche A(4) démarre à partir du sommet S(2). Dans cet exemple de graphe de tâche logicielle, un jalon sera inséré dans le code source de la tâche, aux endroits correspondant respectivement aux sommets S(0) à S(3). Comme illustré par le tableau situé sur la partie gauche de la , dans cet exemple les sous-tâches A(0) et A(1) de la tâche T sont prises en charge par un premier module de la plateforme logicielle SPF, la sous-tâche A(3) par un second module de la plateforme SPF, et les sous-tâches A(2) et A(4) par un troisième module de la plateforme SPF. En pratique, les instructions atomiques définies dans un programme d'ordinateur constitué de lignes de code source (code machine ou code interprété) sont susceptibles de contenir des cycles de différente nature. En particulier ces cycles peuvent être des boucles de type suivant : – boucles itérative à cardinalité connue (boucles "for") ; – boucles itératives à condition d’arrêt (boucles "while", "do while") ; – boucles récursives ; – boucles "cachées" résultant de cycles d'appels mutuels entre fonctions (par exemple, une fonction U appelle une fonction V qui appelle une fonction W, laquelle fonction W pouvant appeler à son tour la fonction U). Si de telles boucles existent et sont exprimées dans la représentation initiale de la tâche T — auquel cas le graphe initial serait cyclique —, on rappelle ici que l'on peut extraire de tout graphe cyclique, un graphe acyclique, qui substitue à chaque cycle présent dans le code une arête unique. Suite à la décomposition du code source de la tâche T, en sous-tâches (étape S11), chaque sous-tâche de l'ensemble de sous-tâches A(j) obtenu, est susceptible d'avoir aucun, un ou plusieurs attributs dits "statiques", notés A(j, k), caractérisant la nature de la sous-tâche, par exemple : sous-tâche à durée fixe, sous-tâche contenant de la récursivité, etc. De plus, les attributs A(j, k) peuvent avoir un caractère numérique ou catégoriel. Par exemple : – A(j, "type") = "produit_matriciel" – A(j, "type_nombre_lignes") = "variable" – A(j, "type_nombre_colonnes") = "fixe" – A(j, "nombre_colonnes") = 6 Ou encore : – A(j, "type") = "requête_SQL" – A(j, "taille_max_données ") = 8Ko Dans ce qui suit, on utilise la notion de "session", notée σ, pour désigner une exécution particulière de la tâche T, que cette réalisation soit effectuée pendant une phase de test unitaire, de qualification/livraison, ou d’utilisation réelle de la plateforme logicielle (à ne pas confondre avec le sens usuel donné à une session en relation avec l’usage d’une application pendant une durée donnée de connexion utilisateur). Ainsi, en plus de ses attributs purement statiques, une sous-tâche A(j) considérée utilisera, lors d'une session σ donnée, un ensemble de variables d’entrée dépendant du contexte d’exécution notées sous forme de clés-valeur : V(j, σ, clé, valeur). Ces variables (dynamiques) d'entrée de la sous-tâche associée au jalon considéré ont un effet direct sur la performance d'exécution globale de la tâche T. Ces clés-valeurs seront les données brutes utilisées par le processus d’apprentissage décrit plus bas, en charge de construire un estimateur du degré d'achèvement ( completion en anglais) de la tâche T. La constitution de cette liste de clés-valeurs devra être définie au préalable par l’équipe de développement de la plateforme logicielle SPF et portera seulement sur les variables qui ont un effet concret sur le comportement et les performances des traitements effectués par la tâche T, en d’autres termes, il s'agira de variables signifiantes pour le processus d’apprentissage. De retour à la , une fois le code source de la tâche T décomposé en sous-tâches A(j) (étape S11), à l'étape suivante, S12, des jalons sont insérés dans le code source de la tâche à l'entrée de chacune des sous-tâches, selon l'exemple de mise en œuvre exposé. En d'autres termes, des jalons sont insérés à chaque sommet S(i) du graphe G(S, A) mentionné plus haut. Plus précisément, les jalons insérés dans le code source de la tâche T sont des blocs d'instructions spécifiques, et chaque jalon peut être désigné par le sommet du graphe S(i) (obtenu à partir du code source de la tâche) auquel il se rapporte. En pratique, chacun des jalons S(i) insérés dans le code source de la tâche T permet d'effectuer les opérations suivantes : – récupérer en entrée, lors de l’exécution de la tâche T, la valeur (ou identifiant) d’une session σ particulière ; – transmettre au module d'apprentissage LE du serveur LMS, un identifiant permanent de la tâche T, un horodatage précis (par exemple en millisecondes) du passage au jalon S(i), la valeur de la session σ, et le jeu complet des clés-valeurs V(j,σ,clé-1,valeur-1), V(j,σ,clé-2,valeur-2) …, qui vont être utilisées par la ou les sous-tâches A(j) démarrant à partir du sommet S(i) ; – propager via les sous-tâches A(j) la valeur de la session σ aux sommets S(i’) adjacents à S(i). D'un point de vue implémentation logicielle d'un jalon, celle-ci peut revêtir différentes formes. Il peut s'agir, par exemple, d'un code propriétaire réalisé par l'équipe de développement logiciel ou d'un code automatiquement généré au moyen d'un générateur de code automatique, tel que par exemple des plateformes de description d'API ( Application Programming Interface ) ouvertes utilisant un langage de description d'interface (IDL) tel que celui connu sous le nom de Swagger™, ou bien des librairies tierces utilisant des définitions réalisées sur les plateformes précitées afin de générer du code automatiquement, par exemple les solutions proposées par Swagger Codegen™, Spring Boot™, etc. Par ailleurs, l'aspect syntaxique d'un jalon S(i) peut être de nature variable, utilisant par exemple l'invocation explicite de fonctions développées par l'équipe de développement, ou de simples "annotations" (ou "décorateurs") dans le cadre de code généré automatiquement, par exemple selon une syntaxe de type "@" utilisée dans les composants fournis par Spring™ ou Spring Boot. L'avantage d'un tel type d'implémentation de jalons dans le code source de la tâche T considérée est qu'elle ne requiert qu'un investissement limité de la part de l'équipe de développement, puisqu'elle consiste, dans le cas le plus coûteux, en une invocation d'interfaces API et une concertation minimale au sein de l'équipe, afin que le codage des jalons puisse permettre la propagation de l'information de session (σ) de bout en bout des modules logiciels composant la tâche T considérée. Dans le cas le plus favorable, ce type d'implémentation ne requiert qu'une simple utilisation (par annotation ou utilisation de "décorateurs") d'une librairie tierce automatisant entièrement l'invocation ou la propagation d'information, précitées. L'implémentation de tels jalons dans le code source de la tâche T permettra, comme exposé plus bas, lors d'une exécution de test de la tâche, de pouvoir transmettre au module d'apprentissage, notamment les informations d'exécution suivantes : – un identifiant unique désignant la tâche T ; – le graphe G(S, A) correspondant aux traitements de bout en bout réalisés par la tâche ; – les éléments descriptifs statiques A(j, k) caractérisant chaque sous-tâche A(j) ; et – une collection de données (corpus de données) constituées pour chaque session σ d'exécution de test de la tâche T, et pour chaque sous-tâche A(j), d'une liste de clés-valeurs et de la valeur de l'horodatage ξ (en millisecondes) correspondant au passage du jalon S(i) à partir duquel est déclenchée la sous-tâche A(j), c'est-à-dire : — Valeur d'horodatage ξ du passage du jalon S(i) — V(j, σ, clé-1, valeur-1) — V(j, σ, clé-2, valeur-2) — … — V(j, σ, clé-n, valeur-n) De retour à la , après l'étape S12 d'insertion de jalons dans le code source de la tâche T, on passe alors à la deuxième phase P2 du procédé au cours de laquelle des sessions d'exécution de test de la tâche T sont réalisées (étape S21) afin d'obtenir un corpus d'informations d'exécution, telles que définies ci-dessus, délivrées au cours de l'exécution par les jalons insérés dans le code de la tâche T. Les informations d'exécution générées au cours des sessions de test sont fournies au module d'apprentissage LE. Lorsque ce dernier évalue (étape S22) que le corpus d'informations obtenu est suffisant pour permettre un apprentissage automatique pertinent d'un modèle d'exécution de la tâche T (plus précisément : modèle d'estimation de la progression de l'exécution de la tâche), les sessions de test sont arrêtées, et l'on passe à la troisième phase P3 du procédé, c'est-à-dire à la phase d'obtention d'un modèle d'exécution de la tâche T, par apprentissage statistique à partir du corpus d'informations d'exécution obtenu. Ainsi, à l'étape S31, l'opération d'apprentissage automatique d'un modèle statistique d'exécution de la tâche T est mise en œuvre. Au préalable, les valeurs d'horodatages obtenues au cours des différentes sessions de test sont calibrées de manière à faire référence à une base temporelle commune partant d'un instant initial (instant zéro), en effectuant pour chacune des sessions, la différence de chaque valeur d'horodatage obtenue avec la valeur d'horodatage correspondant à celle du passage au premier jalon S(0) du code de la tâche. Selon le mode de réalisation choisi, le processus d'apprentissage d'un modèle statistique mis en œuvre par le module d'apprentissage LE pourra utiliser une famille de fonctions statistiques plus ou moins diversifiées en ajustant des hyper-paramètres inhérents à la famille de fonctions, effectuer une exploration plus ou moins large selon le temps et les ressources consacrées au processus d'apprentissage, en utilisant une méthode d'optimisation telle que celle désignée par " grid search ". Par exemple, le module LE du serveur LMS pourra chercher un prédicteur optimal parmi divers types de fonctions de régression, tels que régression logistique, linéaire, polynomiale, multiple, ou encore parmi un réseau de neurones artificiel, ou parmi d'autres familles de fonctions. A l'issue du processus d'apprentissage à partir du corpus d'informations d'exécution, un modèle d'estimation (MOD) de la progression d'exécution de la tâche T est obtenu, à l'étape S32, et est sauvegardé dans la mémoire MEM4 du serveur LMS. Le modèle d'estimation obtenu peut alors être utilisé pour toute nouvelle session d'exécution σ de la tâche T, afin d'établir une estimation "au fil de l'eau" de la progression de la nouvelle occurrence correspondante de la tâche T, en fonction de la connaissance des couples clés-valeurs utilisés dans les sous-tâches composant la tâche T. On dispose ainsi d'un prédicteur de progression d'exécution de la tâche T considérée, capable de fournir lorsque l'exécution est parvenue à un jalon considéré S(J), une estimation de la durée nécessaire à la réalisation de la ou des sous-tâches adjacentes qui commencent à partir du jalon S(j). Une telle estimation est exploitable afin de représenter de manière continue l'avancement de la réalisation de la tâche T, par exemple sous la forme d'une barre de progression affichée sur un écran, jusqu'à un ou plusieurs prochains jalons, successeurs du jalon S(j) considéré. Le modèle (MOD) d'estimation de la progression de la tâche T obtenu comme exposé ci-dessus, peut ensuite être "déployé" (ou mis à disposition) en tant que prédicteur de temps d'exécution, c'est-à-dire être utilisé par un utilisateur de la plateforme SPF via un terminal UT, lorsque la tâche logicielle T est exécutée, afin de restituer graphiquement à l'utilisateur une information fiable concernant le déroulement de l'exécution de la tâche, et plus précisément estimer le degré d'achèvement de la tâche, via une barre de progression par exemple. On rappelle ici qu'un modèle statistique peut être assimilé à une fonction qui, prenant en entrée des variables numériques et/ou catégorielles, retourne un résultat numérique (comme ici, dans le cadre d'une fonction de régression) ou un résultat catégoriel (comme dans le cadre d'une classification). Il faut par conséquent que ce modèle soit utilisable dans le langage de programmation utilisé au sein du code source de la plateforme logicielle SPF. Or celle-ci peut être assujettie à différentes contraintes de gestion et de mise à jour de son code source, ce qui implique différents modes de réalisation possibles pour la mise à disposition du modèle MOD, sous la forme d'un module de prédiction (PM) du temps d'exécution de la tâche T. Ainsi, selon un premier mode de réalisation, le serveur d'apprentissage LMS "expose" (c'est-à-dire, offre l'accès à) une interface accessible à la plateforme logicielle SPF, permettant à celle-ci de générer directement dans un certain nombre de langages cibles (par exemple Java, C, C++, PHP ( Hypertext Preprocessor ), etc.) la fonction mathématique correspondant au module de prédiction (PM) basé sur le modèle MOD d'exécution de la tâche T. La plateforme logicielle SPF peut par conséquent, dans ce mode de réalisation, utiliser directement la fonction de prédiction par une instruction de son code source (soit immédiatement si le composant utilisateur est écrit dans un langage interprété, soit via une étape de compilation si ce composant est écrit dans un langage compilé). Selon un second mode de réalisation, le serveur d'apprentissage LMS expose le modèle d'exécution MOD lui-même via une interface API spécifique. Dans ce cas, sans aucune modification de son code source, la plateforme logicielle SPF pourra réaliser les prédictions de temps d'achèvement de la tâche T, en invoquant directement cette API. Le choix de l'un ou l'autre des deux modes de réalisation précités dépendra de la prise en compte de considérations de gestion de code source ou d'optimisation des flux d'exécution entre la plateforme logicielle SPF et le serveur d'apprentissage LMS. Par conséquent, selon le mode de réalisation choisi, le module de prédiction (PM) utilisant le modèle appris MOD peut être soit intégré dans le code source de la plateforme logicielle SPF, soit intégré dans le serveur d'apprentissage LMS mais accessible par la plateforme SPF (via une API). Dans les deux cas, lors de l'exécution de la tâche T, des requêtes de calcul de temps d'exécution seront générées et adressées au module de prédiction, pour estimer la progression de l'exécution de la tâche T. La représente sous forme d'organigramme les étapes principales d'un procédé selon l'invention d'utilisation du modèle d'estimation (MOD) de la progression de l'exécution d'une tâche logicielle T, obtenu selon le processus décrit en relation avec la . Comme représenté sur la , le procédé d'utilisation du modèle (MOD) d'exécution de la tâche T comprend une première étape S41 au cours de laquelle l'exécution de la tâche T est déclenchée à partir d'un terminal d'utilisateur UT. Le code de la tâche T contenant des jalons comme expliqué plus haut, à l'étape S42, lors de l'exécution de chacun des jalons, une information d'exécution du jalon est générée et transmise au module de prédiction PM. L'information d'exécution de jalon contient une information d'identification du jalon permettant d'identifier une ou plusieurs sous-tâches associées au jalon considéré. Le module de prédiction traite chacune des informations d'exécution reçues comme une requête correspondante de calcul de temps d'exécution de la tâche. A l'étape S43, le module de prédiction PM traite chacune des requêtes de calcul dans leur ordre d'arrivée, et génère en conséquence, en réponse à chacune de ces requêtes, une information de progression de l'exécution de la tâche T. Cette information de progression d'exécution peut être par exemple une durée d'exécution restante de la tâche. A l'étape S44, les informations de progression d'exécution sont transmises au module GUI de gestion d'interface graphique du terminal UT d'utilisateur. Enfin, à l'étape S45, le module de gestion GUI du terminal UT met à jour l'interface graphique — en pratique une barre de progression affichée sur l'écran du terminal —, en fonction de chacune des informations de progression d'exécution reçues, dans leur ordre d'arrivée. De ce fait, la mise à jour de la barre de progression s'effectue de manière continue et permet d'informer l'utilisateur du terminal UT de la progression de la tâche T, d'une manière fiable et réaliste. Les figures 5, 6 et 7 illustrent différents exemples de réalisation de mise à jour d'une barre de progression restituant la progression de l'exécution d'une tâche logicielle, dont l'exécution est modélisée conformément à l'invention. Les figures 5, 6 et 7 reprennent l'exemple de déroulement d'exécution d'une tâche logicielle T représentée par un graphe acyclique, décrit plus haut en liaison avec la . On notera ici que l'utilisation effective du modèle d'exécution de la tâche T, une fois ce dernier calculé et déployé, ne doit pas affecter les performances de la tâche principale T. En effet, le fait de solliciter le modèle implique l'établissement d'une requête vers un service chargé d'effectuer une ou plusieurs opérations algébriques et restituer un résultat, ce qui nécessite une durée de traitement. Cela est d'autant plus vrai lorsqu'il y a en plus des problèmes de latence réseau, si le modèle, en tant que composant logiciel, est hébergé par le serveur d'apprentissage LMS lui-même. Pour limiter une dégradation possible de la performance de la tâche T par l'utilisation du modèle d'exécution de la tâche, comme évoqué au paragraphe précédent, on peut envisager une architecture logicielle selon laquelle l'opération d'invocation du modèle d'exécution de la tâche T avec les données de contexte disponibles (jalons, notamment), d'une part ; et, d'autre part, l'opération de propagation vers le composant graphique d'affichage du terminal d'utilisateur (UT) de l'estimation de la progression d'exécution de la tâche, fournie par le modèle d'exécution, sont prises en charge par un fil d'exécution ( thread ) spécifique n'affectant pas l'exécution du ou des fils d'exécution de la tâche principale T. Un type d'architecture logicielle pouvant répondre à cet objectif peut être basé par exemple selon le principe connu " publish-subscribe " (publier-s'abonner). Les exemples fournis par les figures 5-7 s'appliquent notamment à ce type d'architecture. La illustre un premier exemple. Dans cet exemple, l'envoi d'informations d'exécution vers le module de prédiction PM est déclenché par le passage du processus d'exécution de la tâche T par chacun des jalons placés initialement dans le code (désignés ici par "jalons primaires") et qui ont servi au processus d'apprentissage du modèle. Ces jalons correspondent aux sommets S(0)-S(3) et indiquent le commencement des sous-tâches associées A(0)-A(4). Cela est illustré sur la par les quatre points situés sur la ligne de temps verticale Ta. Dans cet exemple, les informations d'exécution sont traitées comme des requêtes de calcul de temps d'exécution de la tâche T (c'est-à-dire d'estimation de la progression d'exécution de la tâche). Dans l'exemple illustré par la , le module de prédiction PM de la progression d'exécution de la tâche T, est sollicité non seulement suite au passage du processus d'exécution par chacun des jalons primaires (ayant servi au processus d'apprentissage du modèle) comme dans l'exemple de la . Cependant, il existe en plus dans le code de la tâche des jalons additionnels dits "jalons secondaires" n'ayant pas servi à l'apprentissage du modèle, et qui déclenchent l'envoi d'informations d'exécution additionnelles à destination du module de prédiction. Ces informations additionnelles peuvent servir au module de prédiction à améliorer une prédiction basée sur les requêtes de calcul déclenchées par le passage du processus d'exécution par les jalons primaires. Par exemple, un tel jalon secondaire peut être indicatif de l'exécution d'une instruction située au milieu du code d'une sous-tâche donnée, dont l'exécution d'un point de vue algorithmique garantit que l'on se situe à la moitié du temps d'exécution total de la sous-tâche. Ce type d'information additionnelle permet par conséquent d'améliorer une estimation de la progression d'exécution de la tâche, effectuée uniquement avec les informations d'exécution issues des jalons primaires. Dans l'exemple de la , la ligne de temps Tb représente l'envoi d'informations d'exécution lors du passage du processus d'exécution par les quatre jalons primaires, comme sur la , mais aussi par le passage par quatre jalons secondaires. Dans l'exemple illustré par la , c'est le module de gestion d'interface graphique du terminal UT qui reçoit les informations d'exécution de jalons (primaires) et qui communique avec le module de prédiction afin d'obtenir des informations d'estimation de progression d'exécution de la tâche T. Dans cet exemple, l'opération d'envoi au module de prédiction PM des informations d'exécution générées lors de l'exécution des jalons afin que le module PM effectue l'estimation de la progression de l'exécution de la tâche T, et l'opération d'invocation du module de prédiction afin que le module de gestion d'interface graphique puisse obtenir les informations d'estimation de la progression pour mettre à jour l'interface graphique du terminal UT (en pratique une barre de progression), sont deux opérations indépendantes. Dans l'exemple de la , comme illustré par la ligne de temps Tc, l'invocation du module de prédiction est réalisée selon une fréquence fixe. Dans l'intervalle temporel entre deux invocations successives du modèle de prédiction, des messages successifs contenant des informations d'exécution de jalons peuvent avoir été reçus par le module de gestion de l'interface graphique ; ces messages ne sont alors transmis par le module de gestion au module de prédiction (sous forme de requêtes) seulement qu'à l'instant d'invocation prochain défini par la fréquence d'invocation précitée. Procédé d'obtention d'un modèle d’estimation de la progression de l’exécution d’une tâche logicielle T, le procédé comportant des étapes consistant à : – (C1) décomposer (S11) le code source de la tâche T en une pluralité de sous-tâches, et configurer (S12) le code source de la tâche avec l'association à chaque entrée d’une sous-tâche dans le code source, d'au moins un bloc d’instructions spécifiques, appelé "jalon", chaque jalon étant codé de manière à délivrer des informations dites d'exécution au cours d'une session considérée d'exécution de ladite tâche ; – (C2) effectuer (S21) un nombre déterminé de sessions d'exécution de test de la tâche et obtenir (S22) un corpus d'informations d'exécution à partir des informations d'exécution délivrées par lesdits jalons au cours des sessions d'exécution de test ; – (C3) obtenir (S32) un modèle d'estimation de progression d'exécution de la tâche par apprentissage automatique (S31) à partir du corpus d'informations d'exécution. Procédé selon la revendication 1, dans lequel lesdites informations d'exécution délivrées par un jalon considéré comprennent au moins un identifiant de la tâche T, un identifiant de la session d'exécution, une information d'horodatage d'exécution du jalon, et des données dites de contexte, relatives au contexte d'exécution de la sous-tâche associée au jalon. Procédé selon la revendication 2, dans lequel lesdites données de contexte comprennent un ensemble de variables dynamiques d'entrée de la sous-tâche associée au jalon considéré, lesdites variables dynamiques ayant un effet direct sur la performance d'exécution globale de la tâche. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel l'étape (C1) de décomposition du code source de ladite tâche T comprend la représentation du code source par une structure de données de type graphe acyclique orienté constitué de sommets et d'arêtes, dans laquelle les sommets correspondent aux jalons placés en entrée de sous-tâches et les arêtes constituent les sous-tâches proprement dites exécutées entre deux jalons. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel la tâche logicielle T est fournie par une plateforme logicielle (SPF) hébergée par un premier système informatique (SVR), et dans lequel chaque jalon est codé de manière à déclencher lors de son exécution la transmission desdites informations d'exécution à un second système informatique (LMS) mettant en œuvre un moteur d'apprentissage (LE). Procédé selon la revendication 5, dans lequel lesdites informations d'exécution sont transmises par les jalons, via une interface de programmation applicative, API, à destination dudit second système informatique (LMS), en utilisant un protocole de type HTTP au travers d'un réseau de communication (NW). Procédé selon l'une quelconque des revendications 1 à 6, dans lequel à l'issue de l'étape (C3) d'apprentissage, le modèle d’estimation de la progression de l’exécution de la tâche T, est implémenté sous la forme d'une fonction de prédiction mise en œuvre par un module de prédiction (PM). Procédé d'utilisation d'un modèle d'estimation de la progression de l'exécution d'une tâche logicielle, obtenu selon un procédé d'obtention conforme à l'une quelconque des revendications 1 à 7, le procédé d'utilisation comprenant des étapes de : – (U1) déclenchement, par l'exécution de chacun des jalons codés dans le code de la tâche, de l'envoi (S42) d'une information d'exécution du jalon à destination d'un module de prédiction d'exécution, ladite information d'exécution du jalon comportant une donnée d'identification de jalon ; – (U2) génération (S43), en fonction du résultat du traitement des informations d'exécution de jalon, par ledit module de prédiction, d'une information de progression d'exécution de la tâche ; – (U3) envoi (S44) par le module de prédiction, à un module de gestion d'interface graphique du dispositif utilisateur, de chacune desdites informations de progression d'exécution de la tâche ; – (U4) modification (S45), par ledit module de gestion d'interface graphique, d'une interface graphique affichée dans le dispositif utilisateur, en fonction de chacune des informations de progression d'exécution de la tâche. Système informatique pour la mise en œuvre d'un procédé d'obtention d'un modèle (MOD) d’estimation de la progression de l’exécution d’une tâche logicielle T, selon l'une quelconque des revendications 1 à 7, et d'un procédé d'utilisation d'un tel modèle, selon la revendication 8, ledit système comprenant : – un serveur (SVR) fournissant une plateforme logicielle (SPF) incluant la tâche logicielle T ; – un serveur (LMS) comprenant un moteur d'apprentissage (LE) destiné à générer ledit modèle d'estimation (MOD) selon un procédé conforme à l'une quelconque des revendications 1à 7, et un module de prédiction (PM) configuré pour estimer, selon un procédé d'utilisation conforme à la revendication 8, lors d'une session d'exécution de la tâche T, la progression en temps réel de l'exécution de ladite tâche et transmettre des informations indicatives de ladite progression, à un module de gestion d'interface graphique ; – un module de gestion d'interface graphique configuré pour mettre à jour une interface graphique d'un terminal informatique (UT) en fonction desdites informations indicatives de la progression de la tâche T. Programme informatique (LE, PM) stocké sur un support matériel incorporé dans un serveur (LMS) connecté à un réseau de communication (NW), l'exécution du programme par un processeur du serveur, provoquant la mise en œuvre d'au moins certaines des étapes d'un procédé, selon l'une quelconque des revendications 1 à 7, d'obtention d'un modèle (MOD) d’estimation de la progression de l’exécution d’une tâche logicielle T ; et/ou la mise en œuvre d'au moins certaines des étapes d'un procédé, selon la revendication 8, d'utilisation d'un tel modèle d'estimation de la progression de l'exécution d'une tâche logicielle.