Brevet FR3115624A1 — publié le 20220429

L’invention porte sur un procédé d’annotation de données d’apprentissage pour une intelligence artificielle comprenant les étapes suivantes : -stocker, dans une base de données, un ensemble de données à annoter, -stocker, dans ladite base de données, au moins une première description d’une première facette de sélection de données dans ledit ensemble de données, ladite première description étant associée à une première tâche à faire exécuter par ladite intelligence artificielle, -sélectionner ladite première facette dans ladite base de données, -appliquer ladite première facette à des données dudit ensemble de données pour obtenir des premières données filtrées, -recevoir au moins une première annotation desdites premières données filtrées, et -stocker ladite première annotation dans la base de données en association avec ladite première facette. Figure pour l’abrégé : figure 11 PROCEDE D’ANNOTATION DE DONNEES D’ENTRAINEMENT DOMAINE TECHNIQUE DE L’INVENTION La présente invention concerne le domaine de l’apprentissage machine (ou « machine learning » en anglais). Plus particulièrement, la présente invention concerne l’annotation de données utilisées pour l’apprentissage machine ou l’évaluation de performances. ARRIERE-PLAN TECHNIQUE Dans le domaine de l’apprentissage machine, les modèles dit “ supervisés ” doivent être “ entraînés ” sur des ensembles de données annotées (dits “ dataset ”). Il s’agit par exemple d’images, de vidéos ou autre. Ces datasets peuvent aussi être utilisés pour évaluer les performances des machines en comparant leurs prédictions sur les données brutes aux annotations. Les données sont annotées par des concepts que l’on cherche à « apprendre » à des machines afin qu’elles soient capables de les prédire automatiquement sur des données (images, vidéos etc.) qui leur sont par la suite données en entrée. Par exemple, dans le cas d’un problème de classification d’image où l’on cherche à reconnaître un objet, par exemple un type d’animal, présent dans une image, une image d’un « dataset » contenant un chat peut être annotée avec une étiquette (« label » en anglais) “ chat ”. Dans un dataset, une étiquette est ainsi une métadonnée associée à la donnée initiale qui va renseigner la machine, lors de la phase d’entraînement, sur le concept qu’elle doit y reconnaître. Si en outre, dans un problème de détection, on cherche à connaître la position de l’objet dans l’image, il est possible d’annoter l’objet, en plus de l’étiquette « chat », avec une région (ou « boîte ») englobante qui délimite les extrémités du « chat ». Il se peut d’ailleurs qu’il y ait plusieurs fois le même objet dans l’image (c’est-à-dire plusieurs chats dans l’image), auquel cas plusieurs annotations « boîtes englobantes » peuvent être ajoutées au dataset. Comme pour l’étiquette « chat », l’étiquette « boîte englobante » est une métadonnée associée aux données initiales. Enfin, pour un problème de segmentation, on peut par exemple même aller jusqu’à délimiter les objets (les « chats ») au pixel près. Dans le cas d’une application pratique d’intelligence artificielle (ou « IA »), il y a souvent plusieurs niveaux de concepts à annoter. Par exemple, dans le cas d’une application d'assistance à des techniciens venant raccorder une maison ou un immeuble à la fibre optique, on souhaite apprendre à une machine à vérifier qu’un certain nombre d’étapes ont bien été respectées par les techniciens sur la base de photographies prises par ces derniers. L’une de ces étapes peut par exemple impliquer de mesurer la qualité du signal sortant de la fibre avec un mesureur de puissance optique ou « wattmètre ». Le technicien doit alors prendre une photographie du wattmètre indiquant à l’écran un chiffre représentant la qualité du signal. Si l’on se place du point de vue de l’application d’IA, il est naturel d’annoter les images en trois niveaux hiérarchiques. Le premier niveau d’annotation pourrait être le contexte dans lequel est prise la photo. Par exemple, il s’agit de déterminer si la photographie représente la boîte de raccordement dans la cave, la boîte de sortie de fibre dans le lieu de vie ou du wattmètre. Il s’agit donc ici d’un problème de classification. On détermine ce qui se trouve sur les images. Le deuxième niveau d’annotation pourrait être pour chaque contexte, d’annoter les informations à reconnaître. Dans le cadre du contexte “ wattmètre ”, on souhaite par exemple d’annoter la position de l’écran pour lire le chiffre à l’écran. Il s’agit donc ici d’un problème de détection. On détermine où se trouve un objet sur les images. Le troisième niveau d’annotation pourrait être, dans le cas de l’écran du wattmètre, l’annotation de la valeur indiquée à l’écran. Il s’agit d’un problème de reconnaissance automatique de caractère (ou « OCR »). On détermine un texte sur les images. Ces trois niveaux d’annotation sont un exemple. En particulier, l’ordre dans lequel elles sont effectuées dépend fortement du cas pratique. Dans d’autres cas, on peut très bien commencer par un problème de détection, puis un problème de classification au second niveau. On peut aussi prendre l’exemple de l’annotation de photographies de plateaux repas. L’objectif est d’entraîner une application d’IA permettant la facturation automatique en restaurant d’entreprise. Sur la base d’une photographie d’un plateau repas, l’IA peut déterminer le prix de ce qu’il contient. Dans cet exemple, les différents niveaux d’annotation peuvent être les suivants. Le premier niveau d’annotation peut par exemple être l’annotation de boîtes englobantes autour des différents plats et un label en fonction du type de plat. Il s’agit ici d’un problème de détection suivi d’un problème de classification. On détermine où se trouve un objet puis on détermine le type de cet objet (par exemple une entrée, un plat, un dessert etc.). Le second niveau d’annotation peut par exemple être, pour chaque type de plat, l’annotation fine de la nature du plat (par exemple pour le type « entrée », il peut s’agir de salade de carotte, terrine, etc.). Il apparaît ainsi que l’annotation des données se fait classiquement de manière hiérarchique et définit un arbre (techniquement, la structure sous-jacente est une forêt car il peut y avoir plusieurs racines qui donnent lieu à plusieurs arborescences d’annotation). L’arbre n’est pas nécessairement régulier. Il peut y avoir peu de niveau de profondeur d’un côté et beaucoup de l’autre. La pratique standard de l’état de l’art est de constituer autant d’ensembles de données que de nœuds dans l’arbre. Notamment, les images sont recadrées (“ cropped ” en anglais) autour des objets d’intérêt pour normaliser les données et faciliter le processus d’apprentissage des IA. Par exemple, les images du dataset de troisième niveau dans l'exemple du raccordement de la fibre (la lecture de la valeur du wattmètre) seraient toutes recadrées pour que l’écran du wattmètre couvre la quasi-totalité de l’image. En fait, l’image serait typiquement recadrée en utilisant la boîte englobante du deuxième niveau d’annotation (pour détecter la présence de l’écran). Dans le cas où il y aurait plusieurs boîtes dans l’image (exemple du plateau repas), chaque boîte sur une image à un niveau donné produit plusieurs images dans les niveaux inférieurs. Cette solution a l’avantage d’être conceptuellement simple. Elle est motivée par les besoins techniques des IA à entraîner. On dispose ainsi d’autant d’ensembles de données que de modèles à entraîner, et on annote précisément dans chaque ensemble de données la liste des informations que l’IA doit savoir reconnaître. Cependant, cette solution a de très nombreux inconvénients. Premièrement, cette solution ne permet pas de propager facilement les changements d’annotation, notamment dans le cas de la correction d’erreurs initiales d’annotation. Par exemple, dans le cas des plateaux repas, si une assiette était classée comme initialement étant un plat principal, elle aura été injectée dans l’ensemble de données de niveau 2 correspondant aux “ Plats Principaux ”. Cependant, s’il s’agit en réalité, par exemple, d’une entrée et que ce cela est corrigé dans l’ensemble de donnée de niveau 1 rassemblant tous les plateaux repas, la méthode de l’état de l’art qui décompose le problème en différents ensemble de données séparés ne va pas refléter ces changements. Il faudra ainsi penser à manuellement supprimer l’image de l’ensemble de données de niveau 2 “ Plats Principaux ” pour la mettre dans “ Entrées ”. Deuxièmement, les difficultés énoncées précédemment peuvent être partiellement soulagées avec des scripts informatiques responsables de vérifier l’intégrité du dataset, voir d’automatiser certaines tâches comme par exemple le recadrage et le filtrage des images. Ces scripts sont implémentés de manière ad-hoc et sont la plupart du temps peu voire pas testés, ce qui contribue à augmenter les risques d’erreurs. Enfin, dans les cas où les annotations portent sur un grand nombre de classes, l’annotation d’un ensemble de données en suivant la méthode une “ classique ” de l’art antérieur est difficile car il faut avoir en tête l’ensemble des classes disponibles pour annoter sans faire d’erreur. Les capacités de l’intelligence artificielle dépendent grandement de la qualité du dataset d’entrainement initial. On voit donc que la qualité des annotations est un problème majeur rencontré dans le domaine de l’apprentissage machine. Or, ces datasets comportent parfois un nombre d’erreurs beaucoup trop important pour permettre un entrainement efficace de l’intelligence artificielle. Il est possible de prévoir des mécanismes de correction de l’intelligence artificielle, mais cela coûte en ressources et peut aussi nécessiter un certain temps avant qu’elle atteigne le niveau de performances attendu. Cela peut retarder grandement un déploiement à l’échelle industrielle. Comme cela a été présenté ci-avant, l’annotation et la génération des datasets se fait très souvent de manière hiérarchique. Ceci implique qu’une erreur d’annotation peut se propager très profondément dans l’arbre d’annotation. Une fois l’erreur propagée, il est pratiquement impossible de revenir en arrière, sauf à ré-annoter entièrement le dataset, ce qui est en pratique inenvisageable. On peut alors au mieux corriger une erreur d’annotation à un niveau mais pas aux niveaux inférieurs, ce qui n’améliore pas réellement la qualité du dataset puisque cela introduit des incohérences. Ainsi, il existe un besoin pour améliorer l’annotation des datasets utilisés dans la conception de machines utilisées dans les applications d’intelligence artificielle. La présente invention s’inscrit dans ce contexte. Un premier aspect de l’invention concerne un procédé d’annotation de données d’apprentissage pour une intelligence artificielle comprenant les étapes suivantes : stocker, dans une base de données, un ensemble de données à annoter, stocker, dans ladite base de données, au moins une première description d’une première facette de sélection de données dans ledit ensemble de données, ladite première description étant associée à une première tâche à faire exécuter par ladite intelligence artificielle, sélectionner ladite première facette dans ladite base de données, appliquer ladite première facette à des données dudit ensemble de données pour obtenir des premières données filtrées, recevoir au moins une première annotation desdites premières données filtrées, et stocker ladite première annotation dans la base de données en association avec ladite première facette. Par exemple, ladite base de données comporte une pluralité de descriptions d’une pluralité de facettes de sélection de données dans ledit ensemble de données et ladite première description comporte un lien hiérarchique vers une deuxième description d’une deuxième facette de données dans la base de données, ladite première facette est appliquée à des deuxièmes données filtrées obtenues par application de ladite deuxième facette à des données dudit ensemble de données. Par exemple encore : ladite deuxième facette porte sur une pluralité de sous-régions dans ledit ensemble de données, et la première facette est appliquée sur chaque région sur laquelle porte la deuxième facette. Ces sous-régions sont des sous-parties des données dans ledit ensemble de données. Selon des modes de réalisation : des annotations sont associées à certaines desdites régions sur lesquelles porte ladite deuxième facette ainsi qu’à ladite deuxième facette, et la première facette est appliquée sur chaque région portant une annotation associée à la deuxième facette. Par exemple, la description de la première facette comporte une condition de filtrage appliquée aux annotations associées auxdites régions ainsi qu’à ladite deuxième facette et dans lequel la première facette n’est appliquée que pour les régions pour lesquelles ladite condition de filtrage est vérifiée. Selon des modes de réalisation, ladite condition de filtrage est associée aux régions annotées par ladite deuxième facette et dans lequel la première facette n’est appliquée que sur les données issues d’un recadrage par ces régions et pour lesquelles la condition est vérifiée. Selon des modes de réalisation, ladite annotation génère la définition d’une région dans ledit ensemble de données, ladite région est stockée en base de donnée en relation avec la région ayant servi au recadrage de la donnée annotée et ladite annotation est stockée dans ladite base de donnée en relation avec ladite première facette et ladite région. Selon des modes de réalisation, ladite annotation ne crée pas de nouvelle région et dans lequel ladite annotation est stockée dans ladite base de données en relation avec ladite première facette ainsi que la région ayant servi au recadrage de la donnée annotée. Le procédé peut en outre comporter une étape d’affichage desdites premières données filtrées pour un utilisateur, ladite annotation étant reçue de la part dudit utilisateur. Alternativement, lesdites premières données filtrées sont fournies en entrée à un module d’intelligence artificielle mettant en œuvre ladite tâche, ladite annotation étant reçue de la part dudit module. Un deuxième aspect de l’invention concerne un procédé d’apprentissage machine, pour l’exécution d’une tâche par une intelligence artificielle, comportant les étapes suivantes : accéder à une base de données comportant un ensemble de données et au moins une définition d’au moins une facette de sélection de données dans ledit ensemble de données, ladite une définition comportant en outre au moins une annotation associée à ladite facette, appliquer ladite facette de sélection de données audit ensemble de données pour obtenir des premières données filtrées, stocker lesdites premières données filtrées dans une mémoire de données d’apprentissage annotées, associer lesdites premières données filtrées aux annotations exécuter ladite tâche par ladite intelligence artificielle. Par exemple, ladite annotation est générée selon un procédé selon le premier aspect de l’invention. Un troisième aspect de l’invention concerne un dispositif comprenant une unité de traitement configurée pour la mise en œuvre d’étapes selon un procédé selon le premier et/ou le deuxième aspect(s). FIGURES La illustre l’annotation de données pour une vue racine selon des modes de réalisation. La illustre l’annotation de données pour une vue enfant créatrice de régions selon des modes de réalisation. La illustre un contexte d’utilisation l’annotation de données pour une vue enfant non créatrice de régions selon des modes de réalisation. La illustre le fait qu’une donnée n’est pas annotée par une vue enfant lorsque la condition de celle-ci n’est pas satisfaite selon des modes de réalisation. La illustre schématiquement une interface d’annotation selon des modes de réalisation. La illustre schématiquement une interface de statistiques d’annotation selon des modes de réalisation. La illustre schématiquement une interface d’accès à des images non annotées selon des modes de réalisation. La illustre schématiquement un processus d’annotation selon des modes de réalisation. La illustre schématiquement la structure d’une base de données selon des modes de réalisation. La illustre schématiquement un exemple d’annotation d’images d’une application d’assistance technique à un raccordement de fibre selon des modes de réalisation. La illustre schématiquement un procédé d’annotation selon des modes de réalisation. La illustre schématiquement un procédé d’annotation selon des modes de réalisation. La illustre schématiquement une annotation selon des modes de réalisation. La illustre schématiquement une utilisation d’annotations produites selon des modes de réalisation. La illustre schématiquement un dispositif selon des modes de réalisation. DESCRIPTION DETAILLEE DE L’INVENTION Dans ce qui suit, des modes de réalisation sont décrits qui offrent une annotation de données de manière hiérarchique. Ils permettent par exemple la conception d’applications de reconnaissance d’images ou de vidéos basées sur de l’apprentissage machine. L’invention n’est pas limitée à ce type d’application et d’autres types de données peuvent être utilisées. Les modes de réalisation de l’invention permettent de manipuler et stocker le caractère hiérarchique des concepts annotés, d’annoter plus efficacement et de découpler la notion de modèle d’apprentissage machine de la notion d’ensemble de données (ou « dataset » en anglais). Selon l’invention, les modes de réalisation tirent avantage de la structure hiérarchique des données à annoter pour faciliter l’annotation alors même que cette structure hiérarchique est une source de problème dans l’art antérieur. Il devient ainsi possible de découper un travail d’annotation en plusieurs sous-tâches indépendantes. Les modes de réalisation permettent de répondre au problème de la propagation d’erreur dans les modèles de l’art antérieur. Ils permettent par exemple de prendre en compte automatiquement les changements de classes pour les répercuter automatiquement. Les modes de réalisation permettent en outre d’annoter des données sans provoquer une inflation des celles-ci-au fur et à mesure de l’annotation. La phase de génération des données effectivement annotées peut-être reportée à une phase d’entraînement effective. Comme cela est décrit en détail dans ce qui suit, l’annotation selon les modes de réalisation prend en compte la structure hiérarchique des annotations à effectuer. Un recadrage automatique des données autour des régions pertinentes à annoter peut être effectué pour l’annotation sans générer de nouveaux sous-ensembles de données. Il est aussi possible de filtrer les images à annoter pour n’afficher que les régions de données pertinentes. Dans ce qui suit, les principes applicables aux différents modes de réalisation de l’invention sont tout d’abord présentés. Contrairement aux techniques d’annotation de l’art antérieur, les modes de réalisation de l’invention ne vont pas s’attacher à créer des « sous datasets » au fur et à mesure des annotations faites sur les données du datasets. Ainsi, l’inflation du dataset par le processus d’annotation qui est la source de la propagation des erreurs dans l’art antérieur n’est pas reprise. Au contraire, le dataset initial va être conservé et l’on va créer un système de construction dynamique de datasets (les « facettes » ou « vues ») auquel vont être associées les annotations. Ainsi, il sera possible de faire toute manipulation, y compris des corrections sur ce système de construction, sans toucher au données du dataset. Les « sous datasets » seront générés à la demande, selon l’usage souhaité (par exemple l’entraînement d’une IA) une fois le système de construction validé. Le contexte de mise en œuvre des modes de réalisation de l’invention est ainsi le suivant. On considère un ensemble de données non structurées à annoter pour permettre l’entraînement d’une intelligence artificielle sur un certain nombre de tâches. Des « données » (non annotées) font référence à tout type de donnée qui peut typiquement être produite par un capteur, un appareil de capture ou un appareil de saisie manuelle. Il peut s’agir d’une image, d’un flux vidéo, d’un nuage de point, d’une image 3D faite de voxels, d’un flux sonore, d’un texte, d’une série temporelle, etc. Des annotations sont les informations supplémentaires liées à une donnée et relatives à son contenu. Par exemple la position d’un objet dans une image et/ou sa « classe » (ou « type »). Une « tâche » désigne toute action d’une machine lui permettant de prédire automatiquement les annotations d’une donnée, ou un sous-ensemble des annotations. On peut citer un grand nombre de tâches. Quelques exemples sont cités ci-après. Pour une tâche de classification, l’annotation à prédire est une catégorie d’objet, autrement appelée une « classe », parmi une liste prédéterminée de classes possibles. Par exemple, étant donné une photo d’animal, on cherche à savoir de quel animal il s’agit. Pour une tâche de détection, l’annotation à prédire est une liste des objets présents dans l’image parmi une liste des classes d’intérêt. Chaque objet prédit doit indiquer une délimitation simple de l’objet, typiquement sous forme de boîte englobante ainsi que sa classe. Par exemple, étant donné une vidéo capturée par une voiture autonome, on cherche à savoir où sont tous les véhicules, les piétons, les cyclistes, etc. Pour une tâche de segmentation, l’annotation à prédire est la même que pour une tâche de détection, mais les objets doivent être délimités au pixel près. Pour une tâche d’OCR (acronyme d’« Optical Character Recognition »), il s’agit de prédire le texte présent dans une image. Par exemple, lire un numéro de plaque d'immatriculation à partir d’une photo de plaque. Pour une tâche d’estimation de pose, il s’agit de prédire la “ pose ” d’un objet déformable. Typiquement, des parties clés de l’objet sont identifiées au préalable et reliées par un arbre. Il s’agit alors de prédire la position des différents nœuds de l’arbre s’ils sont visibles ou d’indiquer qu’ils sont invisibles. Par exemple, dans le cas de l’estimation de la pose d’une personne, on cherche typiquement à localiser la tête, les mains, les pieds, etc. de chaque personne présente dans l’image. Pour une tâche de régression, il s’agit de prédire un nombre où un vecteur (i.e. une liste de N nombres, N étant connu au préalable). Par exemple, il s’agit de prédire l’âge d’une personne étant donné la photo d’un visage. Cette liste de tâches est bien entendu non exhaustive mais permet de se rendre compte de la variété de tâches que l’on peut demander à une IA et donc la variété des annotations possibles dans un dataset. Lorsque ces différentes tâches contribuent à la résolution d’un même problème en s’appuyant sur un ou plusieurs algorithmes de reconnaissance automatique, il est courant que ces tâches soient organisées de manière hiérarchique. La relation de hiérarchie entre une tâche A et une tâche B peut par exemple apparaître lorsque le besoin d’annoter des données pour la tâche B dépend de l’annotation de ces données pour la tâche A. Il s’agit par exemple du cas où le besoin d’annoter pour la tâche B dépend de la classe d’objet indiquée dans A. Dans l’exemple de la vérification de raccordement donné en introduction, il s’agit par exemple de l’annotation de l’écran du wattmètre qui n’est pertinente que dans le cadre où l’image montre effectivement un wattmètre et a été annotée comme telle dans le premier niveau d’annotation. Il s’agit donc d’être capable de “ filtrer ” les régions à annoter pour la tâche B en fonction d’une certaine condition sur l’annotation de la tâche A. La relation de hiérarchie peut aussi apparaître lorsque la tâche B consiste à annoter les mêmes régions de données que celles définies par la tâche A. Dans l’exemple donné en introduction concernant les plateaux repas, il s’agit par exemple d’annoter la nature du plat sur l’image issue du recadrage de l’image d’origine par la région définie dans la tâche A. Les relations de hiérarchie peuvent apparaitre pour tout autre raison qui induit le fait que l’annotation pour la tâche A peut être directement réutilisée pour définir le besoin d’annotation ou simplifier le processus d’annotation pour la tâche B. Comme mentionné ci-dessus, il est courant d’annoter une même région d’une donnée dans différentes tâches. Par exemple, c’est la cas lorsqu'une tâche de classification s’attache à annoter la classe détaillée d’un objet créé lors d’une tâche de détection en amont. On appelle région une sous partie d’une donnée définie par ses valeurs extrémales sur les différents axes de la donnée (x, y, z pour ce qui est de données spatiales et/ou t pour le cas de vidéo). Lorsque l’axe temporel est impliqué (par exemple pour une vidéo), la position spatiale (i.e. en x, y, z) peut varier pour chaque valeur de t entre t_min et t_max. L’intérêt d’une région est de pouvoir recadrer une donnée produire une nouvelle (sous-)donnée à annoter. Conformément aux modes de réalisation décrits dans ce qui suit, afin de représenter les relations hiérarchiques entre les tâches et les régions, la notion de “ facette ” est utilisée. Chaque tâche d’annotation se voit attribuer une unique facette qui lui est propre (i.e. une tâche est liée à une unique facette et vice versa). Une facette s’entend par analogie avec le terme de facette dans le domaine de la recherche d’information basée sur une classification à facette, qui donne aux utilisateurs la capacité de filtrer les données en fonction de la facette sélectionnée. Dans ce qui suit, et sans perdre de généralité, le terme de « vue » est utilisé. En plus d’être liée à une tâche, une vue peut être rattaché hiérarchiquement à une autre vue, dite « vue parente » ou « parent » (ou inversement une « vue enfant » ou « enfant »). Une vue n’ayant pas de vue parente est dite « vue racine ». Lorsqu’une vue est une vue enfant, elle définit une « condition de filtrage » sur l’annotation de la vue parente, ou « condition ». Les données de la vue parente vérifiant la condition définissent la vue enfant. Ceci permet de créer des sous datasets. Un processus d’annotation peut avoir plusieurs vues racines. Formellement, la relation de parenté entre les vues induit une structure de forêt au sens d’un ensemble d’arbre disjoints comme cela est défini en théorie des graphes. Comme cela est décrit dans ce qui suit, les vues telles que définies ci-avant permettent, dans les modes de réalisation de l’invention, de filtrer et recadrer les régions produites par la vue parente pour présenter à l’utilisateur qui effectue l’annotation, des données valides et centrées sur les régions d’intérêt. Comme cela est expliqué dans ce qui suit, cela permet d’annoter plus efficacement. Cela permet aussi de manipuler des données à la volée dans la phase d’annotation et de réserver la phase de génération des datasets annotés pour la phase d’entraînement de l’IA. Une définition plus formelle des vues est donnée ci-après. On définit l’ensemble de toutes les régions possibles et on associe une région racine à chacune des données du dataset. Ainsi, chaque donnée a au moins une vue racine. On définit la fonction de recadrage qui prend en entrée une donnée et une région et renvoie la sous-donnée issue du recadrage de par . Le fait de recadrer par une région racine ne modifie pas la donnée : . On note l’ensemble des vues et (avec l’ensemble des nombres naturels) la fonction parent telle que si est une vue racine et si est la vue parent de . On note la fonction qui définit si la région est annotée pour la vue (on pose par ailleurs , et l’ensemble des annotations possibles pour (la forme exacte de dépend du type de tâche associée à : classification, détection, etc...). On note aussi la fonction qui permet de récupérer les annotations d’une région déjà annotée dans la vue . L’ensemble des régions sur lesquelles portent les annotations d’une région par la vue est noté . Par exemple, dans le cadre d’une tâche de détection correspond à l’ensemble des régions définies par les boîtes englobantes nouvellement annotées. Si aucune région n’est créée (comme dans le cas d’une tâche de classification), alors on a . Pour gérer le cas des vue racine, on pose . On note la fonction qui vaut 0 ou 1 selon que la condition de filtrage de la vue est valide ou non (pour toute vue racine , on définit ). On appelle l’ensemble des régions à annoter pour la vue sur les données . On pose , et . Les données présentées à l’annotation pour la vue sont l’ensemble des données recadrées par les régions à annoter, c’est à dire . Ces données peuvent ensuite être annotées de la même manière que l’état de l’art, c’est à dire en considérant comme un flux de données à annoter qui peut être pris isolément du reste du processus d’annotation. Ainsi, l’interaction d’une vue avec sa vue parente (à travers les notions de région et de condition, définies plus haut) est le moyen qui permet de mettre en œuvre les manipulations nécessaires lors de l’annotation afin d’accélérer et de fiabiliser le processus d’annotation de la tâche à laquelle elle est rattachée. Cela permet de s’affranchir de l’inflation des données lors de la phase d’annotation selon les techniques de l’art antérieur. En d’autres termes, la création de la notion de « vue » permet une annotation dynamique des données ce qui a pour conséquence de ne pas créer des sous datasets au fur et à mesure de l’annotation. Selon les modes de réalisation décrits ci-après, il est possible d’annoter les données sans modifier les données en elle-même. Il est ainsi possible de modifier toute annotation à tout moment et ce avec la possibilité qui n’existe pas dans l’art antérieur de répercuter ces modifications aussi profondément que l’on souhaite puisque la liste des données à annoter pour une tâche donnée et le recadrage sur la zone d’intérêt sont calculées à la volée en fonction des annotations déjà présentes dans la tâche parente. Conformément aux définitions et formules énoncées ci-avant, on sait définir formellement les données à présenter à un utilisateur (ou un processus automatique) à partir d’un ensemble initial, pour l’annotation. Comme décrit dans ce qui suit, dans le processus d’annotation, au lieu de faire des liens directs entre données et annotations, il s’agit ici de faire des liens entre annotations et formalisation de la manière d’obtenir les données présentées à l’utilisateur (ou au processus) à partir des données initiales. Cette association permet d’améliorer le processus d’annotation. Dans ce qui suit, on illustre les équations formelles données ci-avant pour différents cas de figure. En référence à la figure 1, on illustre le cas d’une vue racine 101 où la donnée présentée à l’annotation est exactement la donnée brute de l’ensemble de données à annoter . En effet, la région à annoter est nécessairement la région racine 103 qui englobe toute la donnée 102 . Cela se retrouve via le formalisme ci-dessus car donc et donc la donnée présentée à l’annotation est . La vue racine 101 se comporte donc comme une tâche d’annotation “ standard ” qui suivrait les pratiques de l’état de l’art selon lesquelles on ajoute les annotations 104 à l’ensemble de données pour la tâche liée à . La différence est que l’annotation est rattachée à la région racine 103 et non directement à la donnée 102 . Dans le cas où il y a plusieurs vues racines, toutes les annotations sont rattachées à la même région racine 103 . On considère dans ce qui suit, des cas où les régions à annoter pour une vue B sont cette fois celles issues d’une annotation de la vue A. Dans l’exemple de la , on commence par appliquer une vue parente A 200 (parente de la vue B 202) sur une donnée 203 issue l’ensemble de données à annoter. On suppose que cette vue parente A est créatrice de nouvelles régions A 204 et 205 (par exemple dans le cas d’une tâche de détection) qui reçoivent respectivement des annotations 206 et 207. On suppose que la vue A s’applique sur une région racine 208 pour simplifier la figure (le procédé serait similaire pour le cas d’une une région non racine). On suppose que les annotations de la région 205 (trait plein) vérifient une condition B alors que celles de la région 204 ne la vérifient pas (trait en pointillés). Ainsi seule la donnée 203 recadrée par la région A 205 vérifiant la condition B sera présentée en vue de l’annotation selon la vue B. La donnée issue d’un recadrage par la région 204 n’est pas présentée. De manière générale, les données à annoter pour la vue B 202 sont les données initiales recadrées par les régions annotée par la vue A 200 dont l’annotation vérifie la condition B. Après l’application de la vue B 202 , l’annotation 209 est associée à la région 205 qui a servi au recadrage de la donnée annotée. L’exemple de la est très simplifié et ne représente qu’une seule donnée 203 initiale. Si par exemple la vue A 200 créé deux régions sur un première données et trois régions sur une deuxième donnée, alors il y aurait 5 données à annoter pour la vue B 202, issues des recadrages de chacune des 5 régions produites par la vue A 200. On voit donc dans l’exemple de la que l’ensemble des données initiales forme toujours un tout sans que rien ne lui soit ajouté. C’est simplement différentes manières de le « voir », les vues, qui sont créés au fur et à mesure et les annotations sont associées à ces vues et aux régions qui les portent, et non directement à des données. Selon l’art antérieur, au lieu de conserver un ensemble unique de données 203 , on aurait créé deux sous-ensembles de données correspondant aux deux tâches des vues A et B. Pour la vue A, qui pourrait par exemple être une vue de détection, le dataset comporterait la donnée 203 recadrée par la région 208 , annotée par deux régions (par exemple des boîtes englobantes et leurs classes) 204+206 et 205+207 . Pour la vue B, qui pourrait être une vue de classification, le dataset comporterait la donnée 203 recadrée par la région 205 et annotée par 209 . Selon l’invention, la donnée 203 n’est pas modifiée et les annotations ne lui sont pas adjointes directement. On crée plutôt une représentation des vues A et B, ainsi que des régions et on associe les annotations à ces régions. Durant le processus d’annotation, il n’y a pas de création de nouveaux sous-ensembles de données. Seules les vues sont utilisées pour générer les données à annoter et permettre à l’utilisateur (ou un processus automatique) de les annoter. Ces mêmes vues pourront servir à générer effectivement les données annotées pour les donner en entrée à une IA en phase d’entraînement. Entre-temps, le stockage et le traitement des annotations est grandement facilité car la hiérarchie entre les annotations est automatiquement conservée ce qui permet de fiabiliser le processus de mise à jour (modification ou suppression) des annotations. Dans l’exemple de la , la vue parente A n’est pas créatrice de nouvelles régions (par exemple dans le cas d’une tâche de classification). Dans ce cas l’annotation pour la vue B porte sur les mêmes régions que la vue A. On commence par appliquer une vue parente A 300 (parente de la vue B 301 ) sur une donnée 302 issue de l’ensemble de données à annoter. Comme indiqué, cette vue parente A 300 n’est pas créatrice de nouvelles régions comme précédemment. On retrouve donc après l’application de la vue A 300 , la même région 303 . Cette région est associée à l’annotation 304 . On suppose que la vue A s’applique sur une région racine 303 pour simplifier la figure (on pourrait considérer le cas d’une région qui ne l’est pas). On suppose que les annotations 304 vérifient la condition de la vue B 301 . La donnée à annoter pour la vue B 301 est alors la donnée initiale 302 recadrée par la région 303 . C’est-à-dire celle déjà annotée par la vue A 300 . Après l’application de la vue B 301 , l’annotation 305 est associée à la région 303 . On voit donc dans l’exemple de la que comme pour la , l’ensemble des données initiales forme toujours un tout sans que rien ne lui soit ajouté. C’est simplement différentes manières de le « voir », les vues, qui sont créés au fur et à mesure et les annotations sont associées à ces vues. Selon l’art antérieur, au lieu de conserver un ensemble unique de données, on aurait créé deux sous-ensembles de données correspondant aux deux tâches des vues A et B. Pour la vue A, qui pourrait par exemple être une vue de classification, le dataset comporterait la donnée 302 recadrée par la région 303 et annotée par 304 . Pour la vue B, qui pourrait aussi être par exemple une vue de classification, le dataset comporterait la donnée 302 recardée par la région 303 et annotée par 305 . L’exemple de la est similaire à celui de la sauf que l’on considère cette fois que les annotations de la vue A 304 ne satisfont pas la condition B de la vue B. Dans ce cas, la région des données ne sera pas présentée à l’utilisateur pour annotation et aucune annotation ne sera ajoutée (l’annotation 305 est absente). L’annotation de données selon les principes ci-dessus peut se présenter dans la forme décrite dans ce qui suit. Un utilisateur peut par exemple accéder à une interface 500 d’un système d’annotation telle qu’illustrée par la . Cette interface permet d’afficher les vues et de manipuler les hiérarchies entre elles. Ainsi, l’interface 500 comporte une zone d’action 501 comportant divers boutons 502 (ACT1), 503 (ACT2), 504 (ACT3). Par exemple ces boutons permettent à l’utilisateur de gérer l’ensemble de données de manière générale, par exemple en ajoutant des données, en visualisant une cartographie des vues, en supprimant des images, etc. L’interface 500 comporte aussi une zone 505 d’affichage des vues racines. Ici, par souci de concision, une vue racine 506 (V1) est représentée. D’autres vues racines pourraient être présentes dans cette zone. Dans cette zone, un bouton 508 permet à l’utilisateur d’ajouter des vues racines. L’utilisateur peut sélectionner une vue, par exemple 506 , et une zone 509 similaire à 500 apparaît pour afficher les vues enfants de la vue sélectionnée. Par exemple, les vues 510 (V1.1), 511 (V1.2), 512 (V1.3) dépendent de la vue 506 (V1) qui est donc une vue parente pour elles. Dans cette zone, un bouton 513 permet à l’utilisateur d’ajouter des vues dépendantes de la vue sélectionnée dans la zone 500 . Par exemple, l’utilisateur sélectionne la vue 506 , puis clique sur le bouton 513 pour créer une vue dépendante de la vue 506 . Le procédé continue de manière récursive aussi longtemps qu’il y a de profondeur dans l’arbre des vues. Par exemple, une zone 514 permet quant à elle d’afficher des vues dépendantes de la vue sélectionnée dans la zone 509 et un bouton 515 permet d’ajouter une vue dépendante à la vue sélectionnée. Dans l’exemple illustré, la vue 511 est par exemple sélectionnée mais ne contient pas de vue enfant. L’utilisateur clique alors sur le bouton 516 pour créer une première vue dépendante de cette vue sélectionnée. Comme illustré par la , lorsqu’il clique sur une vue de la , l’utilisateur peut visualiser les statistiques liées à cette vue. La illustre une interface 600 comprenant une zone d’action 601 avec un ensemble de boutons 602 (ACT4), 603 (ACT5), 604 (ACT6). Par exemple ces boutons permettent à l’utilisateur d’annoter des images, de corriger des annotations, d’ajouter des concepts à reconnaître, etc. L’interface 600 comporte en outre une zone 605 , avec un certain nombre de fenêtres permettant à l’utilisateur de gérer les images d’une vue. Par exemple, une fenêtre 606 (DISTR1 IMG) donne accès à une distribution des images de la vue entre différentes utilisations (on peut retrouver le nombre de données d’entraînement, de données non annotées, ou autre). Cela permet de savoir à quelle utilisation sont destinées les images de la vue. Une fenêtre 607 (DISTR2 CNCPT) donne accès à une autre distribution concernant les concepts que la machine sera amenée à prédire. Pour chaque concept, on peut voir le nombre d’images qui y sont associées. Une fenêtre 608 (IMG) peut donner accès au nombre d’images dans la vue. Une fenêtre 609 (CNCPT) donne accès au nombre de concepts associés à la vue. L’un des boutons de la zone 601 peut donner accès à l’utilisateur aux images non annotées dans une interface 700 illustrée par la . Cette interface 700 comporte une zone d’action 701 avec un certain nombre de boutons 702 (ACT7), 703 (ACT8), 704 (ACT9) permettant à l’utilisateur de faire un certain nombre d’actions. Ces boutons sont par exemple les mêmes que ceux de l’interface 600 ou peuvent être complétés par d’autres. Selon certains exemples, elle peut comporter un bouton ouvrant la possibilité à l’utilisateur d’annoter une image non encore annotée, grâce à une interface d’annotation permettant de réaliser une annotation propre au type de tâche liée à la vue sélectionnée dans l’interface 600. Cette interface est conforme aux pratiques de l’état de l’art et n’est pas décrite ici. Cela dit, contrairement à l’état de l’art, elle s’applique non pas directement à la donnée annotée mais à la région d’intérêt comme décrit dans la ci-dessous. L’interface 700 comporte en outre une zone 705 avec toutes les images 706 (IMG) non encore annotées. Par exemple, l’utilisateur sélectionne une image dans la zone en cliquant dessus et est redirigé vers l’interface d’annotation de l’image pour la tâche et la vue sélectionnée comme précédemment. Avec des interfaces telles que présentées ci-avant, on peut voir que le processus d’annotation et totalement différent de celui de l’état de l’art. En effet, les données à annoter peuvent être affichées à l’utilisateur « à la volée » en fonction des différentes vues. On profite donc de la hiérarchisation des tâches, sans pour autant créer de nouvelles données à chaque annotation. On peut donc annoter les données de manière automatique en fonction des vues parentes. La hiérarchie de vues sous forme d’arbre est donc différente d’une génération de données annotées comme selon l’art antérieur. Cette hiérarchie permet un affichage pour l’ajout d’annotation, non pas sur les données mais sur les régions produites par les vues parentes de la vue en cours d’annotation. Le processus est présenté schématiquement dans la . L’utilisateur annote typiquement les données les unes après les autres. On décrit ici comment le flux de données à annoter est généré. En entrée on trouve le flux des régions annotées 803 (REG) par la vue parente de la vue sélectionnée pour l’annotation, ci-dessous appelée vue courante. Si la vue courante est une vue racine (i.e. elle n’a pas de vue parente), alors ce flux est constitué de toutes les régions racines. Ensuite, lors de l’étape 800 (FILTR), les régions sont filtrées par la condition à appliquer pour l’annotation selon la vue courante. En sortie, on retrouve alors les régions utiles 804 (REG_CHLD) pour l’annotation souhaitée. Lors de l’étape 801 (CROP), les données à annoter sont présentées, recadrées par les régions utiles 804. En sortie, on obtient ainsi le flux de données à annoter 805 (DAT) qui sont ensuite annotées lors de l’étape 802. Les annotations sont rattachées à la région utile 804 et non à la donnée générée par le recadrage 805, si bien que cette dernière peut être supprimée une fois annotée. En sortie du processus on trouve le flux de région annoté pour la vue courante 806 (REG_ANNOT). C’est ce flux de régions annotées qui sera utilisé en lieu et place du flux 803 pour toutes les vues enfants de la vue courante. A la différence de l’art antérieur, on n’obtient pas directement un flux de données annotées, mais un flux de régions annotées, elles-mêmes liées à la donnée qui les porte et qui n’est pas dupliquée. Le procédé présenté ci-avant est décrit dans le cas d’une annotation manuelle par un utilisateur humain. Cependant, l’annotation peut aussi être réalisée à la volée par un module d’annotation automatique. Dans ce cas, le processus de la reste valable. L’étape 802 est alors mise en œuvre par le module d’annotation. Le recadrage est toujours effectué pour présenter les données au module mais il n’est plus utile dans ce cas d’afficher le résultat. Ce mode de réalisation peut être utile dans les cas où une intelligence artificielle est déjà suffisamment entraînée et donne des résultats suffisamment satisfaisants pour pouvoir convertir une prédiction en annotation lorsque le score de confiance est suffisamment élevé. On permet alors à l’intelligence artificielle de s’enrichir elle-même en lui donnant de nouvelles images annotées. En pratique, les notions de données, vues, régions, annotations sont stockées en base de données. Lorsque l’utilisateur cherche à visualiser les données non annotées (voir la ), une requête à la base de données est effectuée pour obtenir (i) toutes les régions racines si la vue courante est une vue racine et (ii) toutes les régions déjà annotées dans la vue parente et qui satisfont la condition de la vue courante dans les autres cas. A chaque annotation, un nouvel objet « annotation » est créé dans la base de données. Cet objet est lié à la vue qui l’a produit et à la région sur laquelle il porte. Si la tâche liée à la vue ne crée pas de nouvelle région mais se contente d’enrichir la région passée en entrée (comme par exemple dans le cas de la classification) alors l’annotation nouvellement crée est liée à cette région et celle-ci est considérée comme annotée pour la vue courante. L’annotation devient alors disponible à l’annotation dans les vues enfants. Si la tâche liée à la vue crée de nouvelles régions (comme par exemple dans le cas de la détection), ce sont ces nouvelles régions deviennent disponibles pour l’annotation dans les vues enfants. Pour des raisons pratiques, ces nouvelles régions mémorisent leur région parente (voir l’étape 1305 écrite ci-dessous) dans la base de données, notamment pour permettre la suppression des régions et annotations enfantes en cascade comme expliqué ci-dessous. Le stockage des annotations, non pas en lien avec des données mais en lien avec les vues hiérarchiques permet de faire des corrections d’annotation de manière très simple. Par exemple, en cas de suppression d’une région, cela permet de s’appuyer sur le mécanisme de suppression en cascade d’une base de données. Toutes les régions et annotations qui héritent de cette région supprimée dans les vues enfants sont automatiquement supprimées. En outre, lorsqu’on modifie une annotation, une des difficultés d’annotation consiste à bien vérifier si la condition de filtrage des vues enfants n’est pas violée, et le cas échéant à correctement supprimer les annotations devenues invalides. Par ailleurs, une région stocke la vue qui l’a créée afin de permettre de supprimer efficacement toutes les régions et annotations issues d’une vue donnée et de ses enfants lorsque cette vue est supprimée. La illustre une base de données selon des modes de réalisation selon une schématisation de type UML. Comme on peut le constater, à la fois les données 901 et les vues (avec leurs conditions) 902 sont liées au dataset 900 auquel elles appartiennent. Les régions 903 sont quant à elles liées aux données 901 et aux vues (avec leurs conditions) 902 qui les portent. Comme une vue doit stocker une référence à sa vue parente (cette référence est nulle dans le cas d’une vue racine), la table des vues est reliée à elle-même dans la . De la même manière, les régions peuvent stocker leur région parente comme expliqué ci-avant. Enfin, les annotations 904 héritent à la fois des régions 903 et des vues et conditions puisque les annotations sont liées à l’une et l’autre. En comparaison, un schéma du même type est aussi représenté sur la figure 9 pour une base de données d’annotation selon l’art antérieur. Cette fois, la structure est beaucoup plus simple puisque les annotations 907 sont liées aux données 906 qui sont elles-mêmes liées au dataset 905 . La base de données selon l’art antérieur ne dispose pas de la notion de vue qui permet la création à la volée des données à annoter en fonction des annotations de l’étape précédente lorsque la tâche d’annotation est hiérarchique. L’annotation d’images dans le cas d’une application d'assistance à des techniciens venant raccorder une maison ou un immeuble à la fibre optique selon des modes de réalisation est maintenant décrite en référence à la . On suppose tout d’abord une première vue racine v1 de classification 1000 (V1) nommée “ Contexte ” avec deux classes (ou type) : “ Wattmètre ” et “ Armoire ”. Cela permet de différencier deux types de photos prises par le technicien : (i) soit une photo de l’appareil servant à mesurer la puissance du signal appelé wattmètre (il va alors s’agir de dire si la puissance du signal affiché à l’écran est conforme au seuil minimum), (ii) soit une photo de l’armoire de raccordement des fibres optiques (il va alors s’agir de dire si les différentes zones de raccordement sont valides). On suppose aussi une vue v2 de détection 1001 (V2) nommée “ Écran ” ayant pour parent la vue v1 1000 et une seule classe (ou type) “ Écran ”. Son rôle est de permettre de localiser l’écran du wattmètre pour le lire. Cette vue 1001 possède une condition. Il faut que la région soit annotée “ Wattmètre ” dans la vue parente pour qu’une annotation soit associée à une image de cette vue. On suppose aussi une vue v3 d’OCR 1002 nommée “ Qualité Signal ” ayant pour parent la vue v2 1001 dont le but est de permettre d’annoter le texte à l’écran. Cette vue ne possède pas de condition, c’est-à-dire que (selon le formalisme décrit ci-avant). Une vue v4 de détection 1003 nommée “ Raccordement ” ayant pour parent la vue v1 1000 et deux classes (ou type) “ O K ” et “ K O ”. Son but est d’identifier les zones de raccordement conformes ou non. Cette vue possède une condition. Il faut que la région soit annotée “ Armoire ” dans la vue parente pour qu’une annotation soit associée à une image de cette vue. On décrit maintenant le lien entre données (en l'occurrence des images dans ce cas) et régions 1004 , annotations 1005 et vues 1006 pour deux images 1007 et 1008 . Chaque donnée porte des régions organisées sous forme d’arbre à partir d’une région racine qui englobe toute la donnée. Une annotation est rattachée à une région et une vue. En fonction du type de vue, l’annotation peut être une classe, du texte, etc. Chaque vue possède un type et éventuellement une condition. L’image 1007 représente un wattmètre. On définit alors une première région 1009 qui est une région racine. On définit aussi une sous-région 1010 autour de l’écran du wattmètre. La région 1009 est ainsi annotée 1011 selon la classe « Wattmètre ». La région 1010 reçoit quant à elle deux annotations : l’une est la classe « Écran » 1012 et l’autre est le texte reconnu par OCR sur l’écran 1013 par exemple « -4,6 dB ». Les annotations 1011 , 1012 , 1013 sont ainsi respectivement associées aux vues 1000 , 1001 , 1002 . L’image 1008 représente une armoire de raccordement. On définit alors une première région 1014 qui est une région racine. On définit aussi une sous-région 1015 et une sous-région 1016 qui correspondent à deux zones différentes de l’armoire. La région 1014 est ainsi annotée 1017 selon la classe « Armoire ». La région 1015 reçoit quant à elle une annotation « OK » 1018 car elle comporte une zone de raccordement conforme. La région 1016 reçoit une annotation « KO » 1019 car elle comporte une zone de raccordement non conforme. L’annotation 1017 est associée à la vue v1 1000 car la présence de l’armoire est une annotation de « Contexte ». Les annotations 1018 et 1019 sont toutes les deux associées à la vue v4 1003 car le bon ou mauvais raccordement est une annotation de « Raccordement ». Dans la formalisation qui précède, les conditions sont appliquées aux annotations de la vue parente en général. Les exemples qui précèdent montrent qu’il peut notamment être important de pouvoir définir des conditions sur les classes annotées dans la région parente. On décrit maintenant des variantes selon des modes de réalisation. La condition d’une vue peut par exemple porter sur la classe annotée dans la vue parente (si celle-ci est unique, voir paragraphe ci-dessous pour le cas multi-classes) pour restreindre l’annotation de à certaines classes uniquement. Cela permet par exemple de spécialiser des vues à certains contextes de prise de vue ou d’objets, typiquement afin de structurer et simplifier le travail d’annotation afin d’avoir moins de classes (ou types) à annoter. Appelons la fonction de classe qui associe une annotation de à sa classe représentée comme un entier, et l’ensemble des classes acceptables, alors étant donnée une région , on a si , 0 sinon. Dans le cas multi-classes où la vue parente permet d’annoter la région avec plusieurs classes parmi un ensemble possible de classes, on peut représenter la fonction de classe par et les classes acceptables comme une formule logique booléen sur les classes : . Dans ce cas on a . Cette variante englobe en fait le cas précédent où l’on n’a qu’une seule classe annotée à la fois. Selon des modes de réalisation lorsque l’annotation de la vue parente ne comporte pas de notion de classe, comme par exemple dans le cas de l’estimation de pose ou une annotation textuelle, on peut définir des « clusters » sur lesquels on peut aussi appliquer des conditions. On utilise la notion de clustering lorsque l’annotation d’une vue ne fournit pas directement de classe (ou type). C’est par exemple le cas pour une tâche d’estimation de pose où l’annotation correspond à placer les nœuds d’un arbre sur la donnée. On peut alors dans ce cas calculer au préalable une partition de l’espace des annotations (clustering en anglais). Cette méthode divise l’espace en groupes (ou “ clusters ”) et on peut associer toute annotation au cluster le plus proche, c’est-à-dire que l’on dispose d’une fonction qui permet d’associer une classe à une annotation. Dans certaines variantes, chaque annotation peut être associée à plusieurs clusters et la fonction de classe a la forme générale . On retombe alors exactement dans le cas du paragraphe précédent pour le cas de l’annotation multi-classes. Dans ce qui précède, on a associé les tâches et les vues de manière bijective. Cependant, selon des modes de réalisation, une tâche peut être divisée sur plusieurs vues afin notamment réduire le nombre de classes à annoter dans chaque vue. Cela permet à une personne (ou un module d’annotation) qui annote de se concentrer sur moins de classes, donc d’être plus efficace et de faire moins d’erreurs. Cela ne change rien au mode de réalisation général selon lequel, en pratique il est suffisant de garder le lien bijectif entre vue et tâche. C’est seulement au moment d’entraîner un algorithme de machine learning sur un ensemble de dataset annoté qu’il faut pouvoir combiner deux vues sœurs (i.e ayant le même parent) en une unique vue. Comme cela a été expliqué, le système des vues permet d’automatiser la manipulation des données et annotations, de manière à ce que le flux de données annoté par les différentes vues corresponde à un ensemble de datasets qui partageraient une structure hiérarchique. Dans ce schéma, une fois que des données ont été annotées pour une vue donnée, on peut alors entraîner un modèle de machine learning sur le dataset qui correspond aux données annotées de cette vue. Selon des modes de réalisation, cela revient à dire qu’un modèle est entrainé sur les données annotées par une certaine vue. Cependant, il peut être intéressant d’entraîner un modèle sur plusieurs vues. Il convient alors d’être capable de fusionner les données annotées issues de plusieurs vues en un unique ensemble de données annotées. Les étapes d’un procédé sont maintenant décrites en référence à la et suivantes, en utilisant le formalisme décrit ci-avant. Ce procédé peut être mis en œuvre dans le cas d’une application d’annotation mise en œuvre par ordinateur, avec par exemple une interface comme décrite ci-avant. C’est ainsi un utilisateur qui interagit avec l’application, via l’interface pour annoter les données. Des variantes du procédé peuvent aussi être mises en œuvre dans le cadre d’une annotation automatique, par une IA par exemple. Dans ce qui suit, on considère que des données (par exemple des images) sont déjà stockées en mémoire et associées à leur région racine. Cette association est réalisée dès l’ajout d’une donnée à la base de données : une région racine est créé pour chaque donnée ajoutée. Alternativement, on peut prévoir dans ce qui suit des étapes d’ajout ou de suppression de données à un dataset existant, soit par un utilisateur ou soit automatiquement. Ces étapes ne sont pas représentées. Dans le cas d’une application, l’utilisateur peut par exemple créer un projet d’annotation dans lequel des données à annoter et des annotations vont être stockées selon l’invention. Il s’agit par exemple d’un projet « Plateaux repas » ou « Raccordement fibre ». On décrit dans la le procédé de création d’une vue. Lors d’une étape 1101, la description d’une vue, correspondant à une tâche du projet, est créée. Il est ensuite déterminé (étape 1102) si cette vue est une vue racine. Si ce n’est pas le cas (N), le processus se poursuit avec la sélection de la vue parente lors de l’étape 1103. L’interface de la peut par exemple être utilisée, par exemple il est déterminé si c’est le bouton 513 ou 515 qui a été activé. Dans ce cas la détermination de la vue parente se fait en déterminant la vue précédemment sélectionnée par l’utilisateur avant de cliquer sur l’un de ces boutons. Si c’est le bouton 508 qui a été activé, il est alors déterminé (Y) que la vue crée est une vue racine. Une fois la vue parente sélectionnée, une condition sur cette vue parente est définie (étape 1104 ) pour permettre de filtrer les données à proposer à l’annotation pour la vue créée à l’étape 110 1 . La forme exacte de cette condition dépend du type de tâche de la vue parente. Par exemple, si la vue parente est une vue de classification ou de détection où une seule classe peut être annotée, la condition peut prendre la forme d’une liste déroulante dans laquelle l’utilisateur sélectionne les différentes classes parentes d’intérêt, ce qui permet de définir l’ensemble des classes acceptables défini ci-dessus. Si le type de tâche parente est multi-classes et permet d’annoter plusieurs classes sur la même région, la condition pourra être définie par une formule booléenne dont les clauses porteront sur la présence de certaines classes parente. Ensuite, le type d’annotations pour cette vue est créé (étape 1105), c’est-à-dire le type de tâche associée (classification, OCR, pose, détection ou autre). En fonction du type de tâche, la configuration de l’annotation est ensuite définie (étape 1106). Par exemple pour des annotations basées sur des classes, on définit les classes d’intérêt : « Écran » ou « Armoire » dans l’exemple du raccordement de fibre. Cette étape est optionnelle car les classes peuvent être modifiées après la sauvegarde de la vue en mémoire : l’utilisateur peut par exemple utiliser les boutons de la zone d’action 601 de l’interface 600 de la par exemple. Si la vue crée est une vue racine, le processus passe de l’étape 1102 ( Y ) à l’étape 1105 directement. Une fois ce processus terminé, la description de la vue est stockée en mémoire (étape 1107 ). Ensuite, en référence à la figure 12, on décrit le processus d’annotation. Il débute par la sélection d’une vue lors de l’étape 1201 . Il est ensuite déterminé lors de l’étape 1202 si la vue sélectionnée est une vue racine ou non. S’il s’agit d’une vue racine ( Y ), on initialise une boucle (étape 1203 ) lors de laquelle on va déterminer (étape 1204 ) toutes les régions non encore annotées selon la vue courante. On itère donc sur les régions racines des données en mémoire : si la région n’est pas annotée par la vue , celle-ci est sélectionnée (étape 1205 ). Sinon ( N ) la région est ignorée. L’itération se fait typiquement via une requête à une base de données mais peut être implémentée par un compteur i qui parcourt toutes les régions racines. Lors de l’étape 1206 , si i n’a pas encore terminé d’itérer sur les régions racine ( N ), on incrémente la boucle (étape 1207 ) ou alors ( Y ), si toutes les régions ont été testées, on passe à une étape de mémorisation 1208 de toutes les régions filtrées dans l’étape 1205 . Il ne s’agit pas d’un stockage d’un nouveau dataset ou la création d’un sous-dataset mais de la mémorisation de l’ensemble des régions à annoter selon la vue courante, typiquement selon un curseur renvoyé en réponse de la requête à la base de données. Cette étape est un préalable à un affichage des données pour l’utilisateur, par exemple pour préparer l’affichage des données à annoter de la zone 705 de l’interface 700 de la . De retour à l’étape 1202 , si la vue sélectionnée n’est pas une vue racine ( N ), alors une boucle est initialisée (étape 1209 ), lors de laquelle, on détermine (étape 1210 ) toutes les régions des données annotées par la vue parente. Pour chaque région annotée par la vue parente ( Y ), on détermine si elle est annotée par la vue courante lors de l’étape 1211 . Si la région n’est pas annotée par la vue courante ( Y ), alors on détermine (étape 1212 ) si la condition de filtrage de la vue parente est remplie pour la région courante. Si la condition est respectée ( Y ), alors on sélectionne la région (étape 1215 ) pour la présenter à l’annotation. Le processus continue ensuite jusqu’à ce que toutes les régions aient été considérées. Ceci est déterminé lors de l’étape 1216 . S’il reste des régions à considérer ( N ), on incrémente la boucle lors de l’étape 1217 et on reprend à l’étape 1210 . Autrement ( Y ), le processus se termine avec l’étape 1208 déjà décrite en mémorisant les régions filtrées lors de l’étape 1215 . Lors des tests des étapes 1210, 1211 et 1212, si le résultat est négatif (N), le processus continue avec l’étape 1216 comme illustré par la . Les données correspondant aux régions à annoter mémorisées à l’étape 1208 sont soit affichées pour annotation par un utilisateur, par exemple via l’interface 705 , soit fournies à un module d’annotation automatique. Cette annotation (manuelle ou automatique) est décrite en référence à la . Pour chaque région mémorisée à l’étape 1208 , on présente à l’utilisateur (humain ou algorithme) la donnée à laquelle est rattachée, recadrée par . Formellement, on présente à l’étape 1300 la donnée à l’utilisateur pour annotation selon la vue sélectionnée en 120 1 . On reçoit à l’étape 1301 une annotation pour cette donnée. Il est ensuite déterminé à l’étape 1302 si le type de type de tâche liée à est créatrice de régions. Si ce n’est pas le cas ( Y ), alors on passe à l’étape 1303 de mémorisation de l’annotation. Comme déjà indiquée, cette mémorisation se fait en lien, non pas avec les données mais avec la vue courante et la région à laquelle appartient la donnée. Si par contre l’annotation crée une ou des régions ( N ), notées , par exemple s’il s’agit d’une vue liée à une tâche de détection, on passe à une étape de mémorisation 1304 d’un lien de parenté entre les régions crées et les régions dont elles sont issues. On passe ensuite à une étape 1305 de mémorisation de l’annotation en lien avec la région crée et la vue courante et ce, pour chacune des régions crées. Par exemple, dans le cadre de la détection, on associe une classe annotée sur une boîte englobante à la région correspondante. A l’issue du processus, on peut disposer d’une base de données selon la qui stocke annotations en lien avec les vues, les régions et les conditions. La base de données contient aussi les données initiales. Comme déjà expliqué, de manière avantageuse, il n’a pas été procédé à des créations de sous-datasets. Ainsi, on peut corriger, mettre à jour les annotations à un niveau et propager facilement les changements dans les vues enfants, ce qui contribue à fiabiliser le processus d’annotation. Seule la visualisation peut être réalisée de manière temporaire pour permettre à l’utilisateur de visualiser les données des sous datasets et les annoter ou pour permettre à un processus automatique de les prendre en entrées et les annoter. Ce processus étant réalisé donnée par donnée, il reste léger et ne présente pas de complexité d’exécution. La génération des datasets se fait alors au moment d’entraîner l’IA. Soit elle se fait en une seule fois, ou alors à la volée au fur et à mesure de l’entraînement. La illustre une utilisation d’annotations produites selon des modes de réalisation. Le processus est initialisé par l’étape 1401 lors de laquelle on accède aux annotations, par exemple à une base de données selon la figure 9. On initialise ensuite une boucle (étape 1402) lors de laquelle on sélectionne les différentes vues (étape 1403 ) et on les applique aux données initiales lors de l’étape 1404 . Le résultat du filtrage est stocké en mémoire lors de l’étape 1405 , avec les annotations associées à la vue . Ainsi, ici on fait le lien entre les données et les annotations. On commence ainsi à construire le dataset qui va être utilisé par l’IA. On vérifie ensuite (étape 1406 ) si toutes les vues ont été considérées. S’il reste des vues ( N ), on incrémente la boucle (étape 1407 ) et on retourne à l’étape 1403 . Si toutes les vues ont été utilisées ( Y ), alors on passe à l’étape 1408 de fourniture du dataset à l’IA qui peut ensuite être entraînée lors de l’étape 1409 selon l’application. En outre, on peut aussi prévoir que les données sont aussi liées à des applications particulières. Dans ce cas, les vues seront aussi appliquées à un sous-ensemble de données lié à l’application considérée. La est un schéma fonctionnel d'un système 1500 pour la mise en œuvre d'une ou plusieurs modes de réalisation de l'invention. Les procédés selon des modes de réalisation sont mis en œuvre par ordinateur. Le système 1500 comprend un bus de communication auquel sont connectés : - une unité de traitement 1501 , telle qu'un microprocesseur, dénommée CPU ; - une unité de mémoire vive 1502 , dénommée RAM, pour le stockage de code exécutable d’un procédé selon un mode de réalisation de l'invention ainsi que des registres adaptés pour enregistrer les variables et paramètres nécessaires à la mise en œuvre d'un procédé selon des modes de réalisation, dont la capacité mémoire peut être étendue par une RAM optionnelle connectée à un port d'extension par exemple ; - une unité de mémoire 1503 , appelée ROM, pour le stockage de programmes informatiques destinés à mettre en œuvre les modes de réalisation de l'invention ; - une unité d’interface réseau 1504 connectée à un réseau de communication sur lequel les données numériques à traiter sont transmises ou reçues. L'interface réseau 1504 peut être une interface réseau unique, ou composée d'un ensemble de différentes interfaces réseau (par exemple des interfaces câblées et sans fil, ou différents types d'interfaces câblées ou sans fil). Les données sont écrites sur l'interface réseau pour la transmission ou sont lues à partir de l'interface réseau pour la réception sous le contrôle de l'application logicielle s'exécutant dans le CPU 1501 ; - une unité d’interface utilisateur graphique 1505 permettant de recevoir des entrées d'un utilisateur ou d'afficher des informations à un utilisateur ; - un disque dur 1506 noté HD - un module d’entrées/sorties E/S 1507 pour recevoir/envoyer des données depuis/vers des systèmes externes tels qu'une source vidéo ou un écran. Le code exécutable peut être stocké soit en mémoire morte 1503 , soit sur le disque dur 1506, soit sur un support numérique amovible comme par exemple un disque. Selon une variante, le code exécutable des programmes peut être reçu au moyen d'un réseau de communication, via l'interface réseau 1504 , afin d'être stocké dans l'un des moyens de stockage du système de communication 1500, comme le disque dur 1506, avant d'être exécuté. L'unité centrale de traitement 1501 est adaptée pour contrôler et diriger l'exécution des instructions ou des parties de code logiciel du ou des programmes selon les incarnations de l'invention, ces instructions étant stockées dans l'un des moyens de stockage susmentionnés. Après la mise sous tension, l'unité de traitement 1501 est capable d'exécuter les instructions de la mémoire vive principale 1502 relatives à une application logicielle après que ces instructions ont été chargées à partir du programme ROM 1503 ou du disque dur (HD) 1506 par exemple. Une telle application logicielle, lorsqu'elle est exécutée par l'unité centrale 1501 , entraîne l'exécution des étapes d'une méthode selon des incarnations. La présente invention a été décrite et illustrée dans la présente description détaillée en référence aux figures jointes. Toutefois la présente invention ne se limite pas aux formes de réalisation présentées. D’autres variantes, modes de réalisation et combinaisons de caractéristiques peuvent être déduits et mis en œuvre par la personne du métier à la lecture de la présente description et des figures annexées. Pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l’invention pourra appliquer des modifications ou adaptations. Dans les revendications, le terme “comporter” n’exclut pas d’autres éléments ou d’autres étapes. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes, n’exclut pas en effet la possibilité de les combiner. Les signes de référence ne sauraient être compris comme limitant la portée de l’invention. Procédé d’annotation de données d’apprentissage pour une intelligence artificielle comprenant les étapes suivantes : - stocker, dans une base de données, un ensemble de données à annoter (901), - stocker, dans ladite base de données, au moins une première description d’une première facette de sélection de données dans ledit ensemble de données, ladite première description étant associée à une première tâche à faire exécuter par ladite intelligence artificielle (902), - sélectionner ladite première facette dans ladite base de données (1201), - appliquer ladite première facette à des données dudit ensemble de données pour obtenir des premières données filtrées (1300), - recevoir au moins une première annotation desdites premières données filtrées (1301), et - stocker ladite première annotation dans la base de données en association avec ladite première facette (1303, 1304, 1305). Procédé selon la revendication 1, dans lequel ladite base de données comporte une pluralité de descriptions d’une pluralité de facettes de sélection de données dans ledit ensemble de données et dans lequel - ladite première description comporte un lien hiérarchique vers une deuxième description d’une deuxième facette de données dans la base de données (1103), - ladite première facette est appliquée à des deuxièmes données filtrées obtenues par application de ladite deuxième facette à des données dudit ensemble de données (1215). Procédé selon la revendication précédente, dans lequel - ladite deuxième facette porte sur une pluralité de régions dans ledit ensemble de données, et - la première facette est appliquée sur chaque région sur laquelle porte la deuxième facette. Procédé selon la revendication précédente, dans lequel - des annotations sont associées à certaines desdites régions sur lesquelles porte ladite deuxième facette ainsi qu’à ladite deuxième facette, et - la première facette est appliquée sur chaque région portant une annotation associée à la deuxième facette. Procédé selon l’une des revendications 2 à 4, dans lequel, la description de la première facette comporte une condition de filtrage appliquée aux annotations associées auxdites régions ainsi qu’à ladite deuxième facette et dans lequel la première facette n’est appliquée que pour les régions pour lesquelles ladite condition de filtrage est vérifiée (1212). Procédé selon la revendication 5, dans lequel ladite condition de filtrage est associée aux régions annotées par ladite deuxième facette et dans lequel la première facette n’est appliquée que sur les données issues d’un recadrage par ces régions (1300) et pour lesquelles la condition est vérifiée. Procédé selon la revendication 6, dans lequel, ladite annotation génère la définition d’une région dans ledit ensemble de données, ladite région est stockée en base de donnée en relation avec la région ayant servi au recadrage de la donnée annotée (1304) et dans lequel ladite annotation est stockée dans ladite base de donnée en relation avec ladite première facette et ladite région (1305). Procédé selon la revendication 6, dans lequel, ladite annotation ne crée pas de nouvelle région et dans lequel ladite annotation est stockée dans ladite base de données en relation avec ladite première facette ainsi que la région ayant servi au recadrage de la donnée annotée (1303). Procédé selon l’une quelconque des revendications précédentes, comportant en outre une étape d’affichage desdites premières données filtrées pour un utilisateur, ladite annotation étant reçue de la part dudit utilisateur. Procédé selon l’une des revendications 1 à 8, dans lequel lesdites premières données filtrées sont fournies en entrée à un module d’intelligence artificielle mettant en œuvre ladite tâche, ladite annotation étant reçue de la part dudit module. Procédé d’apprentissage machine, pour l’exécution d’une tâche par une intelligence artificielle, comportant les étapes suivantes : - accéder (1401) à une base de données comportant un ensemble de données et au moins une définition d’au moins une facette de sélection de données dans ledit ensemble de données, ladite une définition comportant en outre au moins une annotation associée à ladite facette, - appliquer (1404) ladite facette de sélection de données audit ensemble de données pour obtenir des premières données filtrées, - stocker (1405) lesdites premières données filtrées dans une mémoire de données d’apprentissage annotées, - associer (1405) lesdites premières données filtrées aux annotations - exécuter (1408, 1409) ladite tâche par ladite intelligence artificielle, dans lequel, ladite annotation est générée selon un procédé selon l’une des revendications 1 à 10. Dispositif (1500) comprenant une unité de traitement (1501) configurée pour la mise en œuvre d’étapes selon un procédé selon l’une quelconque des revendications précédentes.