Brevet FR3069075A1 — publié le 20190118

SYSTÈME ET PROCÉDÉ POUR INTÉGRER DU CONTENU DE MESSAGE DANS UN DISPOSITIF CIBLE DE TRAITEMENT DE DONNÉES CONTEXTE L'invention concerne de façon générale des systèmes de messagerie, et en particulier des procédés, des systèmes et des produits-programmes d'ordinateur pour intégrer du contenu de message dans un dispositif de traitement de données cible. Dans les systèmes de messagerie conventionnelle, un utilisateur peut avoir besoin de saisir des données non structurées concernant un élément commun, par exemple des factures numériques ou électroniques concernant des frais, vers un dispositif de traitement de données cible relatif à un domaine d'application dédié, tel qu'un système de rapport de frais ; le dispositif de traitement de données cible traite ensuite les données saisies par l'utilisateur et si les données saisies et les reçus sont en conformité, le système de rapport de frais génère un rapport de frais pour un ou plusieurs reçus fournis par un utilisateur pour traitement. Dans certains cas, l'utilisateur peut se connecter directement au dispositif de traitement de données cible via une interface dédiée pour remplir manuellement un formulaire pour chaque opération ou transaction (p. ex. un voyage d'affaires), dans lequel il doit entrer l'information contenue dans des reçus ou des factures. Ce type d'interaction est fastidieux, chronophage et source d'erreurs (erreurs typographiques, etc.) pour l'utilisateur. Par ailleurs, elles peuvent générer des informations erronées ce qui oblige l'utilisateur à vérifier le formulaire ou même les données saisies à nouveau. De plus, lorsque ces interactions sont manuelles, elles sont aussi limitées en matière de quantité ou de richesse d'information collectée. Par conséquent, il existe un besoin pour des systèmes, procédés et produits- programmes d'ordinateur améliorés permettant d'intégrer un contenu dans un dispositif de traitement de données cible. RÉSUMÉ Dans le but de traiter ces problèmes et d'autres problèmes, un système pour intégrer du contenu de message dans un dispositif cible de traitement est fourni, le dispositif de traitement de données cible étant configuré pour traiter des données entrées ayant une 2 structure de donnée prédéfinie, le système comprenant un serveur de messagerie configuré pour recevoir un message d'un dispositif client de messagerie qui exécute une application de messagerie, le message comprenant le contenu du message. Le système comprend par ailleurs un dispositif orchestrateur configuré pour intégrer au moins une partie du contenu du 5 message dans un dispositif de traitement de données cible, le dispositif orchestrateur étant par ailleurs configuré pour : - recevoir la partie du contenu de message du serveur de messagerie ; et - transmettre un fichier déterminé à partir de la partie de contenu de message vers un dispositif de traitement de fichier, le dispositif de traitement de fichier étant configuré pour 10 transformer chaque fichier reçu en un fichier de description comprenant un ensemble de clés prédéfinies, au moins certaines des clés étant associées à une ou plusieurs valeurs, le dispositif orchestrateur étant configuré pour déterminer un fichier d'entrée ayant la structure de donnée prédéfinie à partir du fichier de description et pour transmettre le fichier d'entrée déterminé au dispositif de traitement de données cible. 15 Dans un mode de réalisation, le dispositif orchestrateur est connecté au serveur de messagerie selon un premier protocole de communication, et/ou à l'application de messagerie selon un second protocole, et/ou au dispositif de traitement de données cible selon un troisième protocole de communication. L'application de messagerie peut comprendre une interface d'application et une 20 extension d'application configurée pour générer un rendu de fichier d'entrée déterminé à partir du fichier de description fourni par le dispositif de traitement de fichier dans une zone dédiée de l'interface d'application. Le dispositif de traitement de fichier peut être configuré pour mapper un ou plusieurs éléments de donnée de ladite partie du contenu de message au moins sous forme de clés d'un 25 ensemble prédéfini de clés, le dispositif de traitement de fichier étant configuré pour générer le fichier de description de la partie du contenu de message comprenant ledit ensemble de clés prédéfinies, ladite une ou plusieurs valeurs associées aux clés du fichier de description étant déterminées à partir des éléments de données qui y sont mappés. Le dispositif de traitement de fichier peut être par ailleurs configuré pour déterminer des 30 ensembles de données de positionnement à partir du fichier reçu du dispositif orchestrateur, chaque ensemble de données de positionnement identifiant la position d'un élément de donnée 3 du fichier mappant une clé de l'ensemble prédéfini de clés, chaque ensemble de données de positionnement étant inclus dans le fichier de description associé à la clé mappée à l'élément de donnée. Chaque ensemble de données de positionnement peut comprendre les coordonnées de 5 positionnement dans un référentiel donné. Dans un mode de réalisation, l'interface d'application peut être une interface d'application graphique, l'extension d'application étant configurée pour rendre le fichier de description dans une zone dédiée de l'interface application. Le dispositif de traitement de fichier peut être par ailleurs configuré pour déterminer une 10 notation pour chaque valeur associée à une clé donnée de l'ensemble prédéfini de clés et pour inclure la notation déterminée pour la valeur associée à la clé donnée dans le fichier de description. L'extension d'application peut par ailleurs être configurée pour afficher une image de la partie du contenu de message dans la zone dédiée et pour générer l'affichage d'un ou de 15 plusieurs éléments sélectionnables de mise en évidence pour chaque élément de donnée de la partie de contenu du message en mappant une clé, chaque élément de mise en évidence pour un élément de donnée donné étant affiché sur une position dans l'image affichée qui est déterminée à partir de l'ensemble des données de positionnement identifiant la position de l'élément de donnée. 20 Le dispositif orchestrateur peut être configuré pour utiliser un identifiant de message associé au message pour chaque échange entre le dispositif orchestrateur et le serveur de messagerie, et/ou l'extension d'application, et/ou le dispositif de traitement de fichier et/ou le dispositif cible. Par ailleurs, un procédé est fourni pour intégrer du contenu de message dans un 25 dispositif de traitement cible, le dispositif de traitement de données cible étant configuré pour traiter une donnée entrée ayant une structure de donnée prédéfinie, le procédé comprenant la réception d'un message d'un dispositif client de messagerie qui exécute une application de messagerie, le message comprenant le contenu du message. Le procédé peut comprendre l'intégration d'au moins une partie du contenu du message dans ledit dispositif de traitement de 30 données cible, le procédé étant par ailleurs configuré pour déterminer un fichier déterminé à partir de la partie de contenu de message et pour transformer le fichier en un fichier de 4 description comprenant un ensemble de clés prédéfinies, au moins certaines des clés étant associées à une ou plusieurs valeurs, le procédé comprenant la dérivation d'un fichier d'entrée ayant la structure de donnée prédéfinie à partir dudit fichier de description et transmettant ledit fichier d'entrée déterminé au dispositif de traitement de données cible pour traitement du fichier 5 d'entrée déterminé par le dispositif de traitement cible. Un produit-programme d'ordinateur est également fourni, il comprend : un support non transitoire de stockage lisible par ordinateur ; et des instructions stockées sur le support de stockage non transitoire, lisible par ordinateur qui, lorsqu'il est exécuté par un processeur, amène le processeur à intégrer du 10 contenu de message dans un dispositif de traitement de données cible, le dispositif de traitement de données cible étant configuré pour traiter la donnée d'entrée ayant une structure de donnée prédéfinie, le processeur étant par ailleurs amené à: - recevoir un message en provenance d'un dispositif client de messagerie qui exécute une application de messagerie, le message comprenant un contenu de message ; 15 - intégrer au moins une partie du contenu de message dans le dispositif de traitement de données cible, le processeur étant par ailleurs amené à déterminer un fichier déterminé à partir de la partie de contenu de message et à transformer le fichier en un fichier de description comprenant un ensemble de clés prédéfinies, au moins certaines des clés étant associées à une ou plusieurs 20 valeurs, - déterminer un fichier d'entrée ayant la structure de donnée prédéfinie à partir du fichier de description et transmettre le fichier déterminé au dispositif de traitement de données cible pour un traitement du fichier d'entrée déterminé par le dispositif de traitement cible. 25 BRÈVE DESCRIPTION DES DESSINS Les dessins, qui font partie intégrante de cette spécification, illustrent des modes variés de réalisation de l'invention et, avec la description générale de l'invention ci-dessus et la description détaillée des modes de réalisation donnée ci-après, servent à expliquer les modes de réalisation de l'invention. 5 - La Figure 1 est une vue schématique d'un exemple d'environnement d'exploitation incluant un système pour intégrer au moins un fichier dans un dispositif de traitement de données cible ; - La Figure 2 illustre un exemple d'interface d'application selon un mode de réalisation ; 5 - La Figure 3 illustre de façon schématique un exemple de structure de message électronique ; - La Figure 4 est une vue schématique d'un dispositif de traitement de fichiers, selon certains modes de réalisation ; - La Figure 5 est une vue schématique d'un moteur d'extraction de données du dispositif 10 de traitement de fichiers, selon certains modes de réalisation ; - La Figure 6 représente un exemple de vue de l'interface d'application, selon certains modes de réalisation ; - La Figure 7 est un organigramme décrivant le procédé d'intégration d'au moins une partie de contenu de message dans un dispositif de traitement de données cible, selon certains 15 modes de réalisation ; - La Figure 8 est un organigramme décrivant le processus d'initialisation oeuvre par l'extension d'application selon certains modes de réalisation ; - La Figure 9 est un organigramme décrivant le processus d'intégration d'un fichier joint dans un dispositif de traitement cible, selon certains modes de réalisation ; 20 - La Figure 10 est un organigramme décrivant le processus implémenté par le dispositif de traitement de fichiers, selon certains modes de réalisation ; - La Figure 11 est une vue d'un exemple de fichier de description au format Json ; - La Figure 12 est un organigramme décrivant le processus d'affinage d'un fichier de description dans certains modes de réalisation ; et 6 - La Figure 13 est un diagramme d'un dispositif ou système informatique. DESCRIPTION DÉTAILLÉE La Figure 1 est une vue schématique d'un exemple d'environnement d'exploitation 5 incluant un système 100 pour intégrer au moins un fichier dans un dispositif de traitement de données cible 2. Le système 100 peut comprendre un serveur de messagerie 11 configuré pour recevoir un message électronique 12 (tel qu'un « courriel », un message instantané également connu sous le nom de chat ou flux de conversation en ligne) provenant d'un dispositif client de messagerie 14 qui exécute une application de messagerie 15. Le message électronique peut 10 comprendre un contenu de message sous forme de données de message incluses dans le corps du message, et/ou un ou plusieurs fichiers joints au message (également désignés « pièces jointes » ou « fichiers joints »). Le contenu du message peut aussi concerner une ou plusieurs opérations (également désignées comme « transactions »). L'application peut par exemple être Microsoft Outlook et le serveur de messagerie 11 peut par exemple être Microsoft 15 Exchange Server (Microsoft Outlook et Microsoft Exchange Server sont des marques déposées de l'entreprise Microsoft). Le dispositif de traitement de données cible 2 peut être configuré pour traiter un fichier de données saisies ayant une structure de donnée prédéfinie et étant relatif à des opérations cibles, conformément à un processus dédié. 20 Dans un exemple d'application de l'invention, le dispositif de traitement de données cible 2 peut être un dispositif de traitement de frais ou un outil (également désigné comme dispositif de rapport de frais) utilisé par une entreprise ou une entité pour traiter les rapports de frais engagés par les salariés de l'entreprise ou de l'entité, ou par un particulier pour gérer ses frais personnels. Dans un contexte d'entreprise, un tel dispositif de traitement de frais 2 peut 25 être configuré pour recevoir un fichier de description qui identifie une opération de frais (p. ex. des frais de voyage) afin de générer un rapport de frais permettant de rembourser l'utilisateur si les données saisies relatives aux frais sont en conformité avec des règles prédéfinies. Tous Chacun des frais pouvant être associé à un relevé de frais représentant l'ensemble des frais engagés par une entreprise ou pour le compte d'une entreprise pour une transaction donnée. 30 Le dispositif de traitement de frais 2 peut être localisé à l'intérieur (p. ex. une application logicielle de bureau préinstallée sur le dispositif de l'utilisateur) ou à l'extérieur de chaque dispositif client 14, et/ou distribué entre de multiples ordinateurs (p. ex. sous forme d'une 7 application logicielle serveur-client, telle qu'une application web). Dans un tel exemple d'application, les fichiers joints peuvent comprendre des pièces jointes correspondant à des reçus relatifs à un ou plusieurs frais, les pièces jointes étant par exemple une photo ou une copie scannée d'un reçu, une facture électronique en format PDF envoyée par un hôtel, un 5 restaurant ou une société de taxis qui correspond au service facturé dans le reçu. Le serveur de messagerie 11 peut être configuré pour recevoir des messages électroniques, faire tampon avec les messages reçus et envoyer des messages vers un dispositif de destination. Chaque dispositif client 14 (également désigné comme « dispositif d'utilisateur ») peut 10 être un dispositif informatique personnel, une tablette informatique, un terminal client léger, un smartphone et/ou un autre dispositif informatique. Chaque client 14 peut héberger des navigateurs web et/ou un logiciel d'applications personnalisées (p. ex. un système client), et peut inclure une interface utilisateur client. De façon générale, le dispositif clients 14 peut être tout système informatique approprié 15 configuré pour exécuter l'application de messagerie 15 associée à l'interface d'application 150 via laquelle un utilisateur peut envoyer ou recevoir des messages électroniques. Chaque message électronique 12 peut être associé à un identifiant de message unique qui identifie de façon unique le message. L'application de messagerie 15 peut comprendre un gestionnaire d'interface 151 pour 20 transmettre les données d'application dans l'interface d'application 150. Le serveur de messagerie 12 peut être configuré pour stocker chaque message électronique dans une base de données avec les fichiers joints, si le contenu du message comprend des pièces jointes. Le terme « pièce jointe de message » tel qu'il est utilisé dans les présentes (également 25 désigné dans les présentes comme « pièce jointe de courriel », un « fichier joint » ou tout simplement « une pièce jointe ») fait référence à un fichier électronique ou à un document compris dans un courriel, le fichier électronique étant représenté par un élément de représentation cliquable, tel qu'une vignette associée à un nom de fichier. Chaque fichier joint 121 a un format de fichier, par exemple un format jpeg, gif, pdf, Word, Html. Un format de 30 fichier peut être « structuré » ou « non structuré ». Les pièces jointes du message peuvent inclure des photos ou des images ayant des formats différents. Une pièce jointe d'un message 8 peut autrement inclure un fichier qui est dans le corps du message, tel qu'une image dans un courriel ou une autre reproduction du fichier en question. Le système 100 peut comprendre un dispositif orchestrateur 18 configuré pour intégrer le contenu du message sélectionné reçu par l'application de messagerie 15 dans le dispositif de 5 traitement de données cible 2. Le contenu du message peut être tout contenu reçu dans tout type de messages pris en charge par l'application tels qu'un contenu de courriel, un message instantané, un flux. En prenant l'exemple d'un courriel, le contenu peut être inclus dans le corps du courriel ou dans un fichier joint. Pour faciliter la compréhension de certains modes de réalisation de l'invention, la 10 description qui suit sera faite en référence à l'intégration de fichiers joints dans un dispositif de traitement de données cible, mais les hommes de métier comprendront aisément que de façon générale l'invention s'applique à un contenu de message reçu par une application de messagerie 15. Cependant, les termes « pièce jointe » ou « fichier joint » doivent être interprétés comme comprenant tout contenu de message inclus. 15 Les fichiers joints peuvent être sélectionnés ou filtrés par le dispositif orchestrateur 18 en fonction de plusieurs critères relatifs au fichier, tels que le nom du fichier, l'extension du fichier, la taille du fichier. L'application de messagerie 15 peut comprendre une extension d'application exécutable 152 (une extension d'application peut aussi être désignée comme un « plug-in », 20 « add-in » ou « un composant logiciel d'extension ») configurée pour ajouter une caractéristique d'intégration de donnée dynamique 15. En particulier, l'extension d'application 152 peut être 4 configurée pour gérer une zone dédiée de l'interface d'application 150 et pour interagir avec le dispositif orchestrateur 18. L'extension d'application 152 peut par ailleurs être configurée pour générer une restitution de données reçues du dispositif orchestrateur 18. 25 L'application d'interface 150 et en particulier la zone dédiée de l'interface application gérée par l'extension d'application 152 peut comprendre différents types d'éléments graphiques, tels que des fenêtres, des champs d'entrée de texte, des icônes, des éléments sélectionnables, des éléments de contrôle graphique tels que des menus déroulants ou des boîtes de liste, des boutons d'activation, etc. 30 Le système 100 peut par ailleurs comprendre un dispositif de traitement de fichier 19 (également désigné comme « dispositif de transformation de fichier)>) configuré pour convertir ou transformer un fichier d'entrée 190 dans un format non structuré en un fichier de 9 description 191 ayant la structure de donnée prédéfinie prise en charge par le dispositif de traitement de données cible 2 et comprenant un ensemble prédéfini de clés, au moins certaines de ces clés étant associées à une ou plusieurs valeurs. Dans une application de l'invention pour les rapports ou la gestion de frais, l'ensemble 5 des clés peut inclure des clés qui sont communes à tous les reçus (également désignées comme « clés obligatoires ») tels que : - le type de reçu ; - la date du reçu ; - le montant du reçu ; 10 - l'identification du vendeur (nom de la société qui facture tel que le nom d'un hôtel, le nom d'une société de taxis, etc.). L'ensemble des clés peut par ailleurs inclure des clés qui dépendent d'un sous-type de reçu (p. ex. un reçu de taxi, un reçu d'hôtel, un reçu de restaurant) tel que : - l'itinéraire d'un taxi (origine/destination) pour un reçu de taxi ; 15 - le nombre de nuits pour un reçu d'hôtel ; - les services en supplément pour un hôtel : petit-déjeuner, dîner, etc. Le dispositif orchestrateur 18 peut être configuré pour : - recevoir les fichiers sélectionnés stockés par le serveur de messagerie 11 ou provenant directement du dispositif client de messagerie 14 (l'utilisateur peut par exemple faire 20 suivre un courriel comprenant un reçu en pièce jointe à un composant du dispositif orchestrateur); et - transmettre un ensemble de fichiers déterminés à partir d'au moins certains fichiers parmi les fichiers sélectionnés au dispositif de traitement de fichier 19. Le dispositif orchestrateur 18 peut être configuré pour transmettre un fichier de 25 description 182 déterminé à partir du fichier de description 191 au dispositif de traitement de données cible 2. Dans un mode de réalisation préféré, le fichier de description 191 peut être affiné antérieurement par le dispositif orchestrateur 18 en réponse à des saisies reçues de l'utilisateur via la zone dédiée de l'interface application gérée par l'extension d'application 152. 10 En particulier, l'extension d'application 152 peut être configurée pour générer un rendu du fichier de description déterminé à partir du fichier de description 191 fourni par le dispositif de traitement de fichier en utilisant le gestionnaire d'interface 151. Le dispositif de traitement de données cible 2 peut ensuite traiter le fichier de 5 description 182, reçu du dispositif orchestrateur 18 et initier un processus dédié dépendant du champ d'application du dispositif de traitement de données cible. Dans certains modes de réalisation, chaque fichier 190 saisi dans le dispositif de traitement de fichier 19 par le dispositif orchestrateur 18 correspondant à un fichier joint d'origine 121, peut être associé à un identifiant d'utilisateur et/ou à un contexte (par exemple, 10 une information de voyage, une information d'entreprise, une information de lieu pour un reçu de voyage, dans l'exemple d'implémentation d'un rapport de frais de l'invention). Dans une application de l'invention pour la génération de rapport de frais ou de gestion de frais, le système 100 selon des modes de réalisation de l'invention permet une acquisition fiable des reçus relatifs à des frais sans que l'utilisateur soit obligé de saisir manuellement les 15 données dans un formulaire via une interface directe avec le système de traitement de frais 2. Le système de traitement de frais peut donc acquérir, vérifier et effectuer un rapprochement pour chaque reçu avec un compte d'utilisateur permettant de rembourser l'utilisateur qui a fait la dépense. Le fait de simplifier, en augmentant la fiabilité et le taux d'acquisition des données de frais par le système de traitement de frais 2, peut améliorer le délai de remboursement pour 20 l'utilisateur. Par ailleurs, selon des modes de réalisation de l'invention, le dispositif client 14 peut intégrer différents frais relatifs à un ou plusieurs relevés de dépenses dans le dispositif de traitement de frais 2 sans que l'utilisateur ait besoin d'interfacer directement avec le dispositif de traitement de frais ou de remplir un formulaire dédié dans l'interface du dispositif de traitement 25 de frais. Dans certains modes de réalisation, le dispositif orchestrateur 18 peut être connecté au serveur de messagerie 11 selon un premier protocole de communication, à l'application de messagerie 150 selon un second protocole, au dispositif de traitement de fichier cible 19 selon un troisième protocole de communication et au dispositif de traitement de données cible 2 selon 30 un quatrième protocole de communication 11 Dans un mode de réalisation, les premier, second, troisième et quatrième protocoles de communication peuvent être les mêmes. Autrement, au moins une partie du premier, second, troisième et quatrième protocole de communication peut être différente. L'extension d'application de messagerie 152 peut être lancée automatiquement lorsque 5 l'utilisateur lance l'application de messagerie 15. Autrement, l'extension d'application de messagerie 152 peut être lancée de façon dynamique en réponse à une ou plusieurs conditions relatives aux fichiers joints présents dans un courriel, tels que par exemple, si un courriel comprend au moins un fichier joint, ou si le courriel comprend au moins un fichiers joints ayant des noms de fichiers spécifiques, ou des extensions de fichier spécifiques, ou des conditions 10 relatives à l'émetteur, par rapport à la formulation de l'objet d'un courriel, ou d'autres conditions qui peuvent être déterminées par apprentissage automatique avec d'autres courriels reçus précédemment. Dans un autre mode de réalisation, l'extension d'application 152 peut être lancée de façon statique en réponse à l'activation d'un élément d'activation dédié, tel qu'un bouton, par un 15 clic de l'utilisateur. Un tel élément d'activation peut être affiché dans l'interface d'application 15, par exemple directement dans le corps du courriel, ou dans la barre d'outils. L'activation de l'extension d'application de messagerie 152 peut déclencher une sélection d'un sous-ensemble des fichiers joints en fonction d'une ou plusieurs conditions, telles que des conditions relatives au format de la pièce jointe. L'activation de l'extension d'application 20 de messagerie 152 peut par ailleurs causer l'affichage d'une vignette de chaque fichier sélectionné dans une zone dédiée de l'interface de l'application. Dans un autre mode de réalisation, l'utilisateur peut sélectionner directement les fichiers joints par une opération de glisser-déposer pour les amener dans la zone dédiée en cliquant sur un bouton de sélection associé à chaque fichier joint. L'extension d'application peut ensuite 25 générer une vignette actionnable par un clic pour les pièces jointes sélectionnées dans la surface dédiée. Dans certains modes de réalisation, l'extension d'application peut par ailleurs afficher une vue entière de chaque fichier joint (p. ex. un reçu) en cours d'intégration dans le dispositif de traitement de données cible 2 sous forme d'une image. Dans certains modes de réalisation, le fichier joint affiché qui était initialement affiché visuellement dans son intégralité 30 peut être agrandi ou diminué avec le zoom par l'utilisateur afin d'améliorer la vue du reçu pour l'utilisateur. 12 Dans certains modes de réalisation, le dispositif de traitement de fichier 19 peut faire partie du dispositif orchestrateur 18. Cependant, la description qui suit de certains modes de réalisation de l'invention sera faite par référence à un dispositif séparé de traitement de fichier 19. 5 Le serveur de messagerie 11 peut communiquer avec un ou plusieurs dispositifs client 14 via un réseau de communication 60. Le dispositif orchestrateur 18 peut être hébergé dans le même système informatique que le dispositif de traitement de fichier 19 et/ou le dispositif de traitement de données cible 2, et/ou le serveur de messagerie 11. Autrement, le dispositif orchestrateur 18, le dispositif de 10 traitement de fichier 19 et/ou le dispositif de traitement de données cible 2, et/ou le serveur de messagerie 11 peuvent être hébergés dans des systèmes informatiques différents et communiquer via un ou plusieurs réseaux de communication. Chaque réseau de communication utilisé pour permettre la communication entre deux dispositifs du système 100 peut inclure un ou plusieurs réseaux privés et/ou publics (p. ex. 15 Internet) qui permettent l'échange de données, par exemple de l'Internet, d'un réseau de zone locale (LAN), d'un réseau de zone étendue (WAN), d'un réseau cellulaire voix/données, d'une ou de plusieurs connexions par bus à haute vitesse et/ou d'autres types de réseaux de communication. Chaque réseau de communication tel que le réseau 100 peut utiliser des technologies de communication standards et/ou des protocoles tels que 4G, Ethernet, 802.11, 20 TCP/IP (Protocole de contrôle de transmission/Protocole Internet), HTTP (Protocole de transport hypertexte), FTP (Protocole de transfert de fichier), etc. Les données peuvent être échangées sur chaque réseau selon des technologies d'échange de données différentes et/ou des formats tels que le langage de balisage hypertoede (HTML), le modèle JSON et le langage de balisage étendu (XML). 25 Dans une opération conventionnelle : - en mode de transmission, le dispositif client de messagerie 11 peut demander au serveur de messagerie 11 de transmettre un message 12 à un ou plusieurs destinataires identifiés dans les éléments de désignation de destinataires 122 correspondant aux dispositifs clients destinataires, à l'intérieur du même réseau ou sur un autre réseau accessible. 30 - en mode réception, le dispositif client 14 peut recevoir un message 12 provenant d'un autre dispositif client directement en mode « pousser » (push) ou indirectement via la 13 réception d'une notification informant le serveur 12 de la réception d'un nouveau message, le dispositif client étant ensuite configuré pour « tirer » (pull) le message du serveur 11. Un jeton de sécurité peut être utilisé pour récupérer les fichiers et valider la communication/les échanges. 5 Faisant référence à la figure 2, un exemple d'interface d'application 150 est représentée avec le dispositif de traitement cible 2 envisagé dans un dispositif de rapport de frais, conformément à un exemple de mode de réalisation. Selon cet exemple de mode de réalisation, l'activation de l'extension d'application de messagerie 152 peut déclencher un affichage dans une zone d'interface dédiée 5 située dans une partie de l'interface 10 d'application 150. La zone d'interface 150 peut comprendre la boîte de réception de messages dans une portion 1500 de la zone d'interface incluant le courriel actuel qui comprend des pièces jointes. Dans le mode de réalisation exemplaire illustré par la figure 2, la zone dédiée 5 peut être divisée en trois parties comprenant par exemple : - une première partie 50 (« partie de vue de l'image »), 15 - une seconde partie 51 (« vue des vignettes »), et - une troisième partie 52 (« partie de vue du formulaire de vérification »). La première partie 50 peut être fournie pour afficher une vue sous forme d'image de chaque pièce jointe qui peut être une vue entière et qui peut être déplacée, agrandie ou diminuée par l'utilisateur, pendant le traitement de cette pièce jointe par le dispositif 20 orchestrateur 18. La seconde partie 51 peut inclure une vignette des pièces jointes pertinentes (des images de courriel). La troisième partie 52 peut être fournie pour afficher un formulaire de vérification déterminé à partir du fichier de description 191 renvoyé par le dispositif de traitement de fichier 19. Cela permet à l'utilisateur de comparer les données du formulaire tel qu'il a été extrait par le système de traitement de fichier avec le fichier joint d'origine 25 correspondant 121 affiché dans la partie 50. L'homme de métier comprendra aisément que le formulaire ne se limite pas aux champs du formulaire indiqués dans l'exemple de la figure 2, mais peut inclure d'autres champs qui peuvent être extraits ou déduits (par exemple le champ « pays » peut être déduit d'un élément de donnée « adresse » ou « devise »). 14 Les fichiers affichés dans la zone dédiée 5 peuvent être traités de façon séquentielle par le dispositif orchestrateur 18. Dans ce mode de réalisation, le traitement d'un fichier joint 121 par le dispositif orchestrateur 18 peut être déclenché par l'utilisateur. Dans une application plus générale de l'invention, un quelconque contenu d'un message pourrait être traité de façon 5 similaire. La partie 50 de vue de l'image peut par exemple inclure un élément de zoom 501 pour permettre à l'utilisateur de zoomer ou de déplacer un fichier joint affiché. Dans un autre mode de réalisation, l'extension d'application 152 peut inclure des cases à cocher dans la seconde partie 52 de la zone dédiée 5 à côté de chaque fichier joint individuel, l'utilisateur pouvant 10 sélectionner une pièce jointe pour intégration dans le dispositif de traitement de données cible 2 en utilisant la case à cocher. Dans un autre mode de réalisation, les fichiers joints peuvent être traités automatiquement selon un ordre arbitraire ou des critères prédéfinis. Dans un autre mode de réalisation, les fichiers sélectionnés (p. ex. les reçus) peuvent être traités parallèlement par le dispositif orchestrateur 18 et/ou le dispositif de traitement de 15 fichier 19. Pour faciliter la compréhension de l'invention, la description suivante sera faite en référence à un traitement séquentiel des fichiers sélectionnés à titre d'illustration. Dans certains modes de réalisation, la partie 52 de vue du formulaire 52 peut par ailleurs inclure un bouton de validation 520 qui peut être sélectionné par l'utilisateur pour valider le formulaire. 20 La figure 3 montre de façon schématique un exemple de structure de message électronique 12 envoyé à partir du dispositif client de messagerie 14 au serveur de messagerie 11. Comme on le voit, un message électronique 12 peut comprendre une donnée brute 120, des éléments de désignation de destinataire 122 identifiant un ou plusieurs 25 destinataires, des pièces jointes de messages 121, un identifiant de message 123 identifiant de façon unique le message, des attributs de message 124 représentant les attributs du message tel que l'attribut d'expiration d'un message. La figure 4 est une vue schématique d'un dispositif de traitement de fichier selon certains modes de réalisation. 30 Le dispositif de traitement de fichier19 peut comprendre : 15 - un moteur d'extraction de données 162 configuré pour extraire des caractères dans le fichier non structuré 190 (p. ex. une image de reçu correspondant par exemple à une image scannée ou à une photo d'un reçu) en utilisant au moins un algorithme d'extraction tel qu'un algorithme de lecteur de caractères optiques OCR (Optical Character Reader) ; le moteur 5 d'extraction de données 192 peut donc extraire les données du fichier joint reçu comme entrée dans un mode de réalisation et fournir des données numériques qui peuvent être stockées dans une mémoire 193 (mémoire de données extraites) ; - un mappeur 194 configuré pour mapper aux moins certaines clés d'un ensemble prédéfini de clés 196 à un ou plusieurs éléments de données numériques saisies, dans le fichier 10 non structuré 190 reçus comme des entrées par le dispositif de traitement de fichier 190; le mappeur 194 fournit donc un ensemble de clés, chacune étant associée à une ou plusieurs valeurs correspondant aux éléments de données qui y sont mappés. - un générateur de fichiers de description 198 configuré pour générer un fichier de description 191 à partir du fichier d'entrée 190, avec le fichier de description comprenant 15 l'ensemble de clés prédéfinies 196, chaque clé étant associée à zéro, une ou plusieurs valeurs déterminées à partir des éléments de données du fichier d'entrée 190 mappés à la clé. Dans un mode de réalisation, l'ensemble de clés 196 devant être mappé aux éléments de données fichier joint peut être filtrée précédemment selon le type de fichiers joints ou reçus du dispositif orchestrateur 18, le dispositif orchestrateur 18 ayant précédemment récupéré 20 l'ensemble de clés du dispositif de traitement cible 2 en fonction du type de fichier joint détecté. Dans une application de gestion/rapport de frais de l'invention, en considérant les fichiers joints de sous-reçus, un reçu peut avoir plusieurs sous-types tels que le sous-type taxi, le sous-type hôtel, le sous-type restaurant, chaque reçu d'un sous-type étant associé à un ensemble prédéfini de clés (par exemple un reçu de sous-type taxi peut être associé à un ensemble de 25 clés qui incluent la date, le montant, l'itinéraire [origine/destination], le nom de la société de taxi, etc.). Le fichier de description peut avoir tout format faisant usage de texte pour transmettre des objets de donnée qui consistent en des paires valeur attribut et éventuellement de types de donnée de réseau ou autre valeur pouvant être sérialisés tels que la notation d'objet JavaScript 30 ou JSON. 16 Tel qu'il est utilisé dans les présentes, un « fichier une description » fait référence à un document qui utilise du texte pour transmettre des objets de donnée qui consistent en des paires valeur-attribut. Dans un mode de réalisation, le dispositif de traitement de fichier 19 peut comprendre 5 par ailleurs une unité de détermination de données de positionnement (PDDU) configurée pour déterminer l'ensemble des données de positionnement à partir du fichier d'entrée 190. L'ensemble des données de positionnement peut être déterminé par le moteur d'extraction de données 192 et utilisé par le mappeur 194 pour identifier la position d'un élément de donnée mappé à une clé de l'ensemble prédéfini de clés 196 dans une image représentant le fichier 10 joint 190. Chaque ensemble de données de positionnement qui identifie la position un élément de donnée du fichier joint peut être mappé à une clé dans le fichier de description 191 (fichier JSON par exemple) associé à la clé. Dans un mode de réalisation, chaque ensemble de données de positionnement peut comprendre des coordonnées de positionnement (x, y) dans un référentiel donné, tel qu'un 15 référentiel 2D (X, Y) défini par le fichier non structuré d'origine. Dans un mode de réalisation, le dispositif de traitement de fichier 19 peut comprendre une unité 197 de détermination de notation configurée pour déterminer une notation pour les valeurs candidates mappées à certaines clés par le mappeur 194. Par conséquent, pour une clé donnée associée à plusieurs valeurs candidates, une notation peut être attribuée à chaque 20 valeur. Le dispositif de traitement de fichier 19 peut être par ailleurs configuré pour inclure la notation déterminée pour chaque valeur associée à une clé donnée dans le fichier de description 191. Autrement, le dispositif de traitement de fichier 19 peut présenter la valeur candidate selon un ordre de pertinence en fonction de la notation. Dans certains modes de réalisation, la notation peut être déterminée pour les clés qui 25 sont considérées comme étant obligatoires afin de déclencher un traitement par le dispositif de traitement de données cible 2. Par exemple, dans une application de l'invention pour la gestion/le rapport de frais, le fichier joint d'un type de reçu est exigé afin d'obtenir au moins une date clé et un montant clé. La Figure 5 montre une représentation schématique du moteur d'extraction de 30 donnée 192 du dispositif de traitement de fichier 19 selon un exemple d'application de l'invention pour la gestion ou le rapport de frais. 17 Chaque fichier joint reçu par le dispositif de traitement de fichier 19 peut donc être un reçu. Dans certains modes de réalisation, le dispositif de traitement de fichier 19 peut recevoir tous les fichiers joints ou autrement inclus par un utilisateur dans un courriel, traiter chaque fichier et déclencher une erreur si un fichier n'appartient pas à un type de reçu. Dans un autre 5 mode de réalisation, chaque fichier joint peut être traité dans une phase initiale de traitement pour vérifier s'il a un format de reçu et/ou détecter le type de reçu et/ou récupérer les clés associées au type de reçu. Le moteur d'extraction de donnée 192 peut comprendre un convertisseur 1921 configuré pour évaluer initialement un ou plusieurs attributs du fichier joint requis pour appliquer l'OCR 10 et/optimiser la performance de l'extraction de donnée. Les valeurs de ces attributs peuvent être vérifiées et/ou normalisées si leurs valeurs ne sont pas optimales par exemple : - en effectuant une rotation de l'image ; ou - en vérifiant et corrigeant la résolution de l'image (points par pouce) dans le cas où la résolution indiquée par la caméra est plus basse que la véritable résolution. 15 Le moteur d'extraction de données 192 peut par ailleurs comprendre un classificateur de fichiers 1922 configuré pour identifier le type d'un fichier joint (p.ex. facture électronique, reçu, etc.) afin d'optimiser l'extraction de donnée à partir du fichier joint. Ces types de documents peuvent fournir des informations sur la présentation du fichier joint et identifier le type d'information qui doit être extraite. 20 Le classificateur de fichiers 1922 peut être configuré pour identifier le type de fichier joint (p. ex. taxi, hôtel, etc.) en comparant le fichier joint à un autre ensemble connu de documents de référence similaire (p. ex. texte TAXI). Un document est considéré comme étant similaire à un fichier joint s'il comprend un ensemble d'attributs qui sont comparables aux attributs du fichier joint. Ces documents de référence peuvent être déterminés à partir de rapprochements 25 passés, fixés par une saisie d'utilisateur et/ou n'ayant pas été invalidés par un seuil d'utilisateurs. Le classificateur de fichiers 1922 peut être configuré pour convertir l'image représentant l'image du fichier joint dans un vecteur de caractéristiques en utilisant des transformations et des filtres pour fournir une entrée normalisée. Dans certains modes de réalisation, cela peut 30 créer une image beaucoup plus petite en matière de taille de fichier et/ou de dimension, dont 18 l'échelle peut être réduite, avec des contours intensifiés, monochromes et une luminosité équilibrée. Le classificateur de fichiers 1922 peut extrapoler le type de fichier sur la base du vecteur de caractéristiques ainsi obtenu. Dans un mode de réalisation, une approche basée sur 5 l'apprentissage automatique peut être utilisée pour inférer une plusieurs propriétés du fichier joint à partir du vecteur de caractéristiques, par exemple le nombre de colonnes, le ratio de la page, la localisation du corps principal du texte, la localisation de l'en-tête et ainsi de suite. Dans un mode de réalisation, si le fichier d'entrée 190 est reçu en format image, le moteur d'extraction de donnée 192 peut comprendre un scanner OCR 1924 configuré pour 10 effectuer une numérisation OCR afin de produire un texte à partir du fichier joint et extraire des mots. Autrement, toute technique d'extraction de donnée peut être utilisée en fonction du format du fichier d'entrée 190 (par exemple HTML et fichier texte PDF). Le moteur d'extraction de données 192 peut comprendre un classificateur de langage 1925 configuré pour utiliser la donnée extraite (par exemple extraites par le scanner 15 OCR 1924) afin de générer des trigrammes représentant des groupes de trois lettres qui se chevauchent. La répétition et l'existence de ces trigrammes peuvent être utilisées pour déterminer la ou les langue(s) avec un certain niveau de confiance (par exemple le trigramme « LAN » et plus présent en espagnol qu'en anglais). Le moteur d'extraction de données 192 peut par ailleurs utiliser des données contextuelles pour améliorer la fiabilité de l'extraction de 20 données ou déterminer certaines valeurs clés sans avoir besoin de les déterminer à partir de la numérisation OCR (p. ex. la localisation connue de l'utilisateur, les itinéraires de voyage, les coordonnées GPS à partir de photographies, etc.). Dans des modes de réalisation où les fichiers joints comprennent plusieurs langues, la langue prédominante peut être sélectionnée : un niveau de prédominance peut être attribué à chaque langue en fonction du niveau 25 d'utilisation de la langue à travers le fichier. Les langues ayant un niveau de dominance en dessous d'un certain seuil peuvent être ignorées (par exemple, si le fichier joint est un reçu comprenant un nom de restaurant en français alors que le reçu est en allemand, l'allemand serait la langue prédominante). En identifiant les langues d'un document, le classificateur de langues 1925 permet au moteur d'extraction de donnée 192 de mieux identifier le texte et la 30 langue lui appartenant, en utilisant un algorithme d'extraction tel qu'un algorithme OCR. Cela écarte le besoin de numérisation pour détecter toutes les langues possibles et permet l'utilisation de dictionnaires spécifiques à une langue. 19 Le classificateur de langues 1925 peut par ailleurs utiliser la langue de localisation des données qui peut être fournie par les algorithmes d'extraction (algorithme OCR par exemple) pour chaque langue détectée en identifiant la localisation ou la région du fichier joint dans laquelle la langue détectée est utilisée (p. ex. l'indication que la ligne du haut est en bulgare 5 alors que la ligne du bas est en anglais). Cela permet de mieux interpréter le contenu du fichier joint en utilisant un algorithme d'extraction (algorithme OCR). Dans un autre mode de réalisation, au lieu d'utiliser le classificateur de langue 1925, le moteur d'extraction de données peut être configuré pour traduire le texte dans la langue prise 10 en charge par les algorithmes d'extraction. Le moteur d'extraction de données 192 peut par ailleurs comprendre un extracteur d'information 1926 utilisant un algorithme d'extraction pour extraire les caractères dans le fichier joint 121, par exemple un algorithme OCR. L'extracteur d'information 1926 peut par ailleurs extraire les ensembles de données de positionnement (p. ex. les coordonnées) à partir du 15 fichier joint 121. L'homme de métier comprendra aisément que l'invention ne se limite pas à l'utilisation des extracteurs d'information OCR, en fonction du type de fichier d'entrée 190 reçu par le dispositif de traitement de fichier 19. En particulier, dans un certain mode de réalisation le dispositif de traitement de fichier 19 peut recevoir un fichier d'entrée 190 dans un quelconque 20 format incluant un texte autochtone pour lequel il n'y a pas besoin d'OCR. La description suivante de certains modes de réalisation de l'invention sera faite en référence aux algorithmes d'extraction OCR à titre d'illustration uniquement, l'extracteur d'information 1926 étant alors désigné comme l'extracteur d'information OCR. L'extracteur d'information OCR 1926 peut être configuré pour sérialiser les données 25 OCR de la façon suivante. L'extracteur d'information OCR 1926 peut d'abord lire le résultat de la numérisation OCR 1924 caractère par caractère avec des coordonnées et du formatage. L'extracteur d'information OCR peut comprendre un « concaténateur » 21 pour transformer ces caractères dans un format cible. Le format cible peut par exemple être une chaîne devant alimenter les 30 grammaires utilisées pour l'analyse du document et/ou un index de mappage des caractères à leurs coordonnées et une information de formatage. La « concaténation » initiale peut suivre 20 l'ordre « naturel » de lecture du texte. Cependant, des concaténations additionnelles peuvent être fournies pour permettre la reconnaissance de phrases qui ne suivent pas nécessairement cet ordre initial. Par exemple, dans une présentation de document sur deux colonnes, la concaténation peut d'abord renvoyer le texte dans la colonne de gauche, puis le texte dans la 5 colonne de droite. Cependant, à la réception des pièces jointes, les éléments de ligne peuvent être traités dans une colonne à gauche et les prix dans la colonne de droite. Par conséquent, une concaténation de lignes renvoyant des lignes qui couvrent toute la largeur du document peut être apportée. Des informations importantes concernant la mise en page du document peuvent être 10 encodées comme caractères spéciaux dans la chaine renvoyée pour faciliter l'interprétation de la chaine. Des marqueurs pour « le début de la zone de texte », des « ruptures de ligne », des « fins de paragraphe », des « sauts de page », et ainsi de suite peuvent être inclus. Par conséquent, l'information concernant la structure à 2 dimensions du document peut être mise à disposition pour les grammaires et expressions régulières alors que ce ne serait possible 15 autrement que pour des flux de caractères à 1 dimension. L'extracteur d'information OCR 1926 peut par ailleurs être configuré pour extraire les valeurs candidates en utilisant des grammaires et des expressions régulières. Des grammaires libres de tout contexte et des expressions régulières peuvent ensuite être utilisées pour rechercher une information pertinente dans le texte. Les grammaires peuvent par exemple être 20 basées sur le contexte de grammaire Unitex (http://unitexgramlab.org/). La chaine peut être lue pour produire un résultat XML pour les correspondances. Ce résultat XML peut ensuite être lu et transformé en représentation d'objets. En utilisant l'index fourni par le « Concaténateur », chaque objet peut faire l'objet d'une attribution de données de positionnement telles que des données de coordonnées dans un référentiel donné. 25 Cela permet de déterminer les valeurs candidates pour un traitement ultérieur et d'enrichir les informations sur les valeurs candidates sur la base du contexte. Par exemple, tous les montants peuvent être extraits (sous-chaînes du document qui pourraient être des montants, par ex., (( 12.00 »). Si cette chaîne est suivie de « E », il s'agit alors de la devise d'un montant qui peut être signalé comme étant l'Euro. S'il est précédé du mot « Gesamtbetrag », il 30 peut être marqué comme étant un bon candidat pour le montant total. Les grammaires peuvent être écrites de telle façon qu'elles correspondent à la chaîne minimale de caractères constituant le montant, mais également le texte pertinent précédent ou suivant, le cas échéant. 21 L'extracteur d'information OCR 1926 peut en plus effectuer des vérifications de plausibilités et/ou des tests de validation. Par exemple, les IBANS ont une vérification de somme intégrée qui peut être utilisée pour filtrer les fausses correspondances ou les correspondances OCR comportant des erreurs. 5 Dans une application de l'invention pour un rapport de frais, l'extracteur d'information OCR 1926 peut par ailleurs être configuré pour effectuer une extraction d'adresse en recherchant des « ancres » qui représentent la combinaison du code postal et de la ville (p.ex. «81593 München »). Les correspondances pour ces ancres permettent de restreindre la zone de recherche pour les grammaires plus complexes recherchant des adresses complètes. Ces 10 correspondances d'ancres peuvent aussi avoir des applications supplémentaires, par exemple pour déterminer le pays/la ville du document sans tenir compte de l'adresse détaillée. Pour mapper certaines clés particulières obligatoires du reçu, un certain traitement peut être mis en oeuvre par le dispositif de traitement de fichier 19. Par exemple, l'extracteur d'information OCR 1926 peut être encore configuré pour 15 effectuer une validation du montant détecté (correspondant à une clé de montant) dans un fichier joint (un reçu) en utilisant des arbres de sommation. Dans certains cas, les montants pertinents d'un reçu donné peuvent ne pas être listés seuls, mais ensemble avec d'autres montants qui contribuent aux valeurs cibles. Par exemple, le montant brut peut être la somme des montants nets et des montants de TVA. Des combinaisons de valeurs possibles peuvent 20 être additionnées pour aboutir à des valeurs plus élevées également trouvées dans le document et un ensemble de règles peut être appliqué pour essayer de trouver des relations entre ces éléments. Ces règles peuvent attribuer des rôles aux montants correspondants, par exemple : net, brut, total, en espèces, etc. 25 La validation de montant peut être utilisée en combinaison avec d'autres stratégies d'extraction ou dans un contexte particulier tel que pour des reçus similaires. La validation de montant peut apporter un paramètre additionnel pour une estimation de confiance. Elle peut être indépendante des autres stratégies d'extraction et peut ne pas tenir compte des propriétés utilisées par ces stratégies d'extraction, telles que la localisation sur le document, la taille de 30 police, etc. 22 Le processus de validation de montant peut commencer par l'ensemble complet de montants candidats A extraits d'un fichier joint reçu par le dispositif de traitement de fichier 19. Ensuite, un algorithme de sous-ensemble de sommes peut être appliqué produisant pour chaque montant a dans A toutes les combinaisons d'autres montants dans A qui s'additionnent 5 au montant a. Les combinaisons peuvent être transformées en arbres de sommation. La valeur de chaque noeud dans ces arbres de sommation peut être la somme des valeurs de ses enfants directs. Des règles peuvent ensuite être appliquées qui tiennent compte de la structure de l'arbre, des valeurs des montants et des balises d'itérations précédentes. Les règles peuvent être appliquées à ces arbres en multiples itérations, permettant l'accès aux résultats d'itérations 10 précédentes. Certaines règles peuvent utiliser une certaine information contextuelle par exemple le pays et le taux d'imposition. Les règles peuvent affecter des balises marquant le rôle des candidats. Par exemple, un montant (1,19E) est la somme de deux autres montants trouvés dans le document (1,00E et 0,19E). La connaissance du pays où le reçu a été émis (l'Allemagne) et du taux de TVA (taxe sur la valeur ajoutée) dans ce pays (19 %) permet de 15 marquer ces trois montants comme brut, net et montant de TVA, respectivement. Il peut y avoir d'autres montants dans la pièce jointe (p. ex. 0,70E, 0,20 et 0,10E) pouvant être additionnés pour obtenir le montant brut. On peut ensuite supposer que ces autres montants sont les éléments du reçu. Il n'est pas nécessaire que les balises résultantes soient correctes, puisqu'elles sont 20 utilisées comme une caractéristique parmi d'autres par le service de notation qui suit. Pour noter les valeurs candidates des montants correspondants à la clé de montant obligatoire d'un reçu, l'unité de détermination de notation 197 du dispositif de traitement de fichier peut attribuer une probabilité à chaque montant correspondant à la probabilité que ce montant représente le « montant total » du reçu en utilisant un composant de notation de montant. Le 25 composant de notation 197 peut utiliser des propriétés pour chaque montant extrait basé sur les résultats précédents. Chaque propriété d'un montant peut être « vraie » ou « fausse », en fonction de certaines conditions et des résultats de validation. Par exemple, cette propriété peut être « un montant brut » ou « avoir de multiples occurrences dans le document » ou « avoir une taille de police plus large ». Des poids peuvent ensuite être attribués à ces valeurs en fonction 30 de la fréquence de ladite propriété (ou de ladite combinaison de certaines propriétés) qui a été observée pour le total, la TVA ou les montants nets. En utilisant ces poids, la notation de confiance peut être calculée. 23 Vu que ces poids sont basés sur des observations dans le passé, ils peuvent être générés en utilisant des données historiques ou des exemples créés manuellement. Le moteur d'extraction 192 peut par ailleurs être configuré pour effectuer une identification du vendeur permettant d'identifier le vendeur émetteur du reçu correspondant au 5 fichier joint actuel afin de mapper les valeurs candidates à la clé d'identification du vendeur. Plutôt que de reconnaitre le vendeur directement à partir du fichier joint, le moteur d'extraction 192 peut être configuré pour extraire l'information afin d'inférer l'identité des vendeurs, par exemple les numéros de téléphone/télécopie, les numéros d'immatriculation des sociétés, les identifiants de WA, les URLs et ainsi de suite. Avec une base de données 10 appropriée, de telles informations peuvent être utilisées pour inférer l'identité du vendeur. Dans certains modes de réalisation, ladite une ou plusieurs identités de vendeur candidat (valeurs candidates pour la clé d'identité du vendeur) qui sont déterminées peuvent être pondérées selon le type d'information utilisé pour l'inférence, il est supposé que l'identité du vendeur ayant la notation la plus élevée est l'identité du vendeur. 15 Le fichier de description 191 ainsi généré par le dispositif de traitement de fichier 19 peut être renvoyé directement au dispositif de traitement de données cible 2. Autrement, dans un mode de réalisation préféré, le fichier de description 191 peut être renvoyé au dispositif orchestrateur 18 pour être affiné. Le dispositif orchestrateur 18 peut transmettre un fichier de description 181 correspondant au fichier de description lui-même 191, 20 ou au fichier de description déterminé à partir du fichier de description 191, à l'application 15 montrée dans la Figure 1. À titre d'exemple uniquement, la spécification suivante sera faite en référence à ce mode de réalisation où le fichier de description est renvoyé au dispositif orchestrateur 18 pour affinement. 25 Lorsque le fichier de description 181 est renvoyé à l'application 15 via le dispositif orchestrateur, l'extension d'application 152 peut être configurée pour rendre le fichier de description extrait 180 dans la surface dédiée 5 de l'interface d'application 150, par exemple dans la seconde partie 52 en utilisant un formulaire de vérification comprenant un ensemble de champs, chaque champ correspondant à une des clés du fichier de description 181 et chaque 30 champ ayant une des valeurs affectées à la clé dans le fichier de description 181 ou pas de valeur si aucune valeur candidate n'a été trouvée par le dispositif de traitement de fichier 19. La 24 valeur attribuée à un champ correspondant à une clé du fichier de description 181 peut être initialement la valeur qui a été attribuée à la notation la plus élevée pour la clé dans le fichier de description. L'utilisateur peut ensuite corriger la valeur manuellement ou en utilisant des outils visuels. Cela permet d'affiner des fichiers de description en interagissant avec le dispositif client 5 14 pour augmenter la fiabilité du fichier de description 181 par rapport au fichier joint d'origine 121. La Figure 6 représente une vue de l'interface application 150 en réponse à la réception du fichier de description 181 en provenance du dispositif orchestrateur 18, selon certains modes de réalisation. 10 Dans un mode de réalisation, l'extension d'application 152 peut par ailleurs être configurée pour générer un affichage d'un élément sélectionnable pouvant être mis en évidence ou de la case 53 pour chaque valeur candidate différente trouvée pour une clé (p. ex. la clé de montant) de chaque fichier joint traité 121 (p. ex.) à partir du fichier de description 181 afin de faciliter la vérification du formulaire par l'utilisateur. Chaque case 53 mise en évidence peut être 15 affichée à une position du fichier 121 déterminée à partir d'un ensemble de données de positionnement qui identifient la position de la valeur candidate dans le fichier de description 181. Les cases 53 mises en évidence peuvent avoir des formes différentes telles que des rectangles et/ou être associées à une couleur de code en fonction de la valeur de notation 20 attribuée à la valeur candidate afin de mettre en avant la pertinence de la valeur candidate telle qu'elle a été évaluée par le dispositif de traitement de fichier 19. Par exemple, un code de couleur verte peut être utilisé pour mettre en avant les valeurs qui ont été sélectionnées pour compléter le formulaire (notation la plus élevée) et la couleur rouge peut être utilisée pour mettre en avant les autres valeurs candidates. Si l'utilisateur clique sur un élément mis en 25 évidence en rouge, la valeur correspondante peut être utilisée pour actualiser la forme, et l'élément mise en évidence peut devenir vert alors que l'élément mis en évidence qui était vert peut devenir rouge. Autrement, des événements visuels différents peuvent être utilisés pour mettre en évidence la pertinence d'une valeur candidate clé du fichier de description 181 à partir de la 30 notation attribuée à la valeur. Dans un exemple de mode de réalisation, une traduction superposée peut par ailleurs être affichée sur l'image pour les reçus qui ne sont pas dans la langue maternelle de l'utilisateur. 25 L'utilisateur peut cliquer sur une des cases de mise en évidence associées à une valeur candidate pour une clé afin de la sélectionner plutôt que sur celle qui est associée à la notation la plus élevée dans le fichier de description, ou au contraire pour confirmer la valeur candidate associée à la notation la plus élevée. Cela peut entrainer une actualisation du formulaire de 5 vérification affiché dans la troisième partie 52 de la zone dédiée 5 de l'interface d'application 150 et/ou à une actualisation de la notation de la valeur candidate qui peut impliquer un changement de couleur des cases de mise en évidence 53 utilisées pour les valeurs candidates déterminées pour la clé envisagée en fonction du code de couleur. Dans certaines implémentations, l'extension d'application 152 peut comprendre un 10 traceur de progrès pour permettre à un utilisateur de suivre le progrès du traitement du fichier sélectionné (non illustré). Ledit traçage peut être stocké dans le contexte de l'application. Si l'utilisateur interrompt son activité et par la suite revient à l'extension d'application 152, l'utilisateur peut reprendre son activité ou être informé si des pièces jointes ont été soumises. L'utilisateur peut itérer le processus pour chaque clé et faire des corrections si 15 nécessaire. Lorsque l'utilisateur a terminé le processus de vérification, l'utilisateur peut sélectionner le bouton de validation 520 fourni en association avec le formulaire pour déclencher l'envoi du formulaire au dispositif orchestrateur 18. Le dispositif orchestrateur 18 peut transmettre un fichier affiné de description 182 (tel qu'un formulaire) au dispositif de traitement de données cible déterminé à partir d'une version 20 actualisée du fichier de description intermédiaire 181 dans lequel les valeurs corrigées par l'utilisateur ont été mises à jour. Dans un mode de réalisation, le fichier de description affiné 182 peut comprendre une seule valeur par clé, la valeur attribuée à une clé étant soit la valeur corrigée pour cette clé par l'utilisateur (manuellement par une saisie directe ou par la sélection par exemple d'une valeur mise en évidence) ou la valeur ayant la notation la plus élevée, si 25 l'utilisateur n'a pas corrigé la valeur confirmée activement cette valeur. Dans un mode de réalisation, le dispositif orchestrateur 18 peut par ailleurs transmettre un fichier de description 183 au dispositif de traitement de fichier 19 déterminé à partir d'une version actualisée du fichier de description intermédiaire 181 ou d'un signal pour informer le dispositif 19 qu'aucune actualisation n'a été effectuée. Le fichier de description 183 transmis au 30 dispositif de traitement de fichier 19 peut être le même fichier de description que le fichier de description 182 transmis au dispositif de traitement de données cible 2 ou inclure des informations supplémentaires. Cela permet de collecter des données pour l'apprentissage 26 automatique par le dispositif de traitement de fichier 19 ou pour l'intégration subséquente de fichiers joints et en particulier pour le mappage subséquent et les opérations de notation effectuées par le dispositif de traitement de fichier 19 pour chaque intégration subséquente de fichiers joints. 5 La Figure 7 est un organigramme décrivant le procédé d'intégration d'au moins une partie du contenu de message reçu dans un dispositif de traitement de données cible 2, selon certains modes de réalisation. À l'étape 700, un message électronique 12 est reçu à partir d'un dispositif client de messagerie 14 exécutant l'application de messagerie 15, le message électronique 12 10 comprenant un contenu de message sous forme d'un ou de plusieurs fichiers joints 121 au message 12. Le contenu de message (p. ex. les fichiers) peut être relatif à une opération ou à une transaction donnée, telle qu'une même dépense pour l'implémentation d'un rapport de frais de l'invention. La description suivante de certains modes de réalisation du procédé sera faite en référence au contenu de message représenté par les fichiers joints d'un courriel, à titre 15 d'illustration uniquement. Chaque fichier 121 a un format de fichier donné tel que PDF, GIF, JPEG, etc. Chaque message électronique peut être associé à un identifiant de message 123. À l'étape 702, le message 12 peut être stocké dans une base de données avec les fichiers. 20 À l'étape 705, chaque fichier attaché 121 du message 12 peut être converti ou transformé en un fichier de description 191, tel qu'un fichier JSON, comprenant un ensemble de clés dont au moins certaines des clés sont associées à une ou plusieurs valeurs, tel qu'un fichier JSON. À l'étape 706, un fichier saisi extrait 182 déterminé à partir du fichier de description 191 25 peut être transmis au dispositif de traitement de données cible 2. La figure 8 est un organigramme décrivant le processus d'initialisation effectué par l'extension d'application 152 et le dispositif orchestrateur 18, selon certains modes de réalisation. À l'étape 800, un courriel comprenant un ou plusieurs fichiers joints 121 peut être reçu, 30 chaque fichier joint ayant un format prédéfini (p. ex. un fichier JPEG, GIF, PDF, HTML). 27 À l'étape 802, l'extension d'application 152 peut être activée, par exemple en réponse à la sélection d'un bouton d'activation dans l'interface d'application 150. Autrement, elle peut être activée de façon dynamique ou automatique sur la base d'un courriel ou des attributs de pièces jointes (émetteur, objets, fichiers de format, taille de fichier...). 5 À l'étape 804, l'application de messagerie 15 du dispositif client peut se connecter au serveur de messagerie 11 afin de requérir la charge de l'extension 152. À l'étape 806, une initialisation peut être affichée dans une fenêtre ouverte ou une trame-i ouverte dans une zone dédiée 5 de l'interface application 150. La vue d'initialisation peut par exemple comprendre une vignette pour chaque fichier joint sélectionné dans la 10 partie 51, une vue d'un premier fichier joint dans la partie 50 et un formulaire d'initialisation dans la partie 52 de la zone dédiée 5. le formulaire d'initialisation dans une partie de l'interface application 150, le formulaire d'initialisation comprenant un ensemble de champs tels que par exemple les champs d'une application pour un rapport de frais : « date », « pays », « adresse », « sous-type de reçu », « prix total », « devise ». Dans un mode de réalisation, les champs du 15 formulaire d'initialisation peuvent être générés de façon dynamique comme une fonction de données d'initialisation comprenant un ensemble de clés extraites à partir du dispositif de traitement de données cible 2 par le dispositif orchestrateur 18 et/ou à partir du sous-type de reçu correspondant au fichier joint actuel 121 (celui qui est affiché dans la partie 50). Autrement, le formulaire d'initialisation peut être un formulaire par défaut défini par le dispositif de 20 traitement cible 2. Dans un mode de réalisation, le dispositif orchestrateur 18 peut se connecter à une étape initiale du traitement au dispositif de traitement de données cible 2 pour récupérer une liste des sous-types de fichiers joints pris en charge par le dispositif de traitement de données cible 2 et/ou des transactions en cours relatives à l'utilisateur afin d'adapter les champs du 25 formulaire de façon dynamique. Par exemple, si le dispositif de traitement de données cible 2 est un outil de rapport de frais, le dispositif orchestrateur peut comprendre la récupération de la liste des sous-types de reçus pris en charge (ou nécessaires ou configurés selon le besoin) par l'outil de rapport de frais et/ou l'ensemble des relevés de frais en cours de l'utilisateur. À l'étape 808, le dispositif orchestrateur 18 peut se connecter au serveur de 30 messagerie 11. Dans d'autres modes de réalisation, l'orchestrateur 18 peut être connecté automatiquement au serveur messagerie sans nécessiter la mise en oeuvre de l'étape spécifique 808. 28 À l'étape 809 le serveur de messagerie 11 peut transmettre au moins un sous-ensemble des fichiers joints 121 au dispositif orchestrateur 18. Dans un mode de réalisation, le serveur de messagerie 11 peut seulement transmettre au dispositif orchestrateur les fichiers ayant un format non structuré parmi les fichiers joints 121. Dans un autre mode de réalisation, 5 le serveur de messagerie 11 peut transmettre au dispositif orchestrateur 18 tous les fichiers joints 121, les fichiers joints étant ensuite filtrés par le dispositif orchestrateur 18 pour filtrer uniquement un sous-ensemble de fichiers joints selon des critères prédéfinis, les critères de filtrage comprenant au moins le filtrage des fichiers joints ayant un format non structuré parmi les fichiers joints 121. 10 Dans une application de rapport de frais de l'invention, chaque fichier joint d'un sous- ensemble peut être un reçu (p. ex. une photo ou le résultat d'une numérisation) tel qu'un reçu de taxi ou d'hôtel ou un reçu pour des dépenses non liées au voyage (p. ex. un ordinateur, un dîner avec des clients, un lot de photocopies). À l'étape 810 le dispositif orchestrateur 18 peut convertir chaque fichier joint dans un 15 format cible par exemple pour fournir un fichier joint dont la taille est la plus petite et/ou des poids pour optimiser leur affichage par l'application. Par exemple, un fichier joint au format PDF peut être converti en fichier JPEG. À l'étape 811, le dispositif orchestrateur 18 peut envoyer chaque fichier joint dans un ce format cible à l'application de messagerie 15 fonctionnant sur le dispositif client 14. 20 L'extension d'application 152 peut ensuite afficher une vue d'initialisation dans la zone dédiée 5 de l'interface application 150, la vue d'initialisation comprenant un affichage de chaque fichier joint reçu par le dispositif orchestrateur 18 sous forme de vignette dans la partie 51 de la zone dédiée, chaque vignette étant une image sur laquelle on peut cliquer. La vue d'initialisation peut par exemple comprendre une vignette pour chaque fichier 25 joint sélectionné dans la partie 51, une vue d'un des fichiers joints dans la partie 50 et un formulaire d'initialisation dans la partie droite de la zone dédiée. Le formulaire d'initialisation peut comprendre un ensemble de champs tels que par exemple les champs d'une application de rapport de frais : « date », « pays », « sous-type de reçu », « prix total », « devise ». Dans un mode de réalisation, les champs du formulaire d'initialisation peuvent être générés de façon 30 dynamique comme une fonction de données d'initialisation comprenant un ensemble de clés extraites à partir du dispositif de traitement de données cible 2 par le dispositif orchestrateur 18 29 et/ou à partir du sous-type de reçu correspondant au fichier joint actuel 121 tel qu'il est affiché dans la partie 52 de la zone dédiée 5. Autrement, le formulaire d'initialisation peut être un formulaire par défaut défini par le dispositif de traitement cible 2. Le fichier joint affiché dans la partie gauche peut être sélectionné au hasard par l'extension d'application 2 ou correspondre à 5 la première vignette affichée dans la partie du milieu de l'interface d'application ou correspondre à une vignette sélectionnée par l'utilisateur dans la partie 51 de la zone dédiée 5 (lorsqu'il clique dessus). Le traitement du fichier joint affiché dans la partie 50 par le dispositif orchestrateur 18 peut être déclenché automatiquement. 10 La Figure 9 est un organigramme décrivant le processus d'intégration d'un fichier joint 121 dans le dispositif de traitement cible 2 mis en oeuvre par le dispositif orchestrateur 18 conformément à certains modes de réalisation. À l'étape 900 le traitement du fichier joint actuel est demandé par l'application, par exemple en réponse à la sélection d'un fichier dans la partie 51 de la zone dédiée ou 15 automatiquement par une sélection d'un fichier par l'extension d'application 152 ou par le dispositif orchestrateur 18. À l'étape 902, pour le fichier joint actuel, le dispositif orchestrateur 18 peut demander le fichier joint correspondant au serveur de messagerie 11 si le dispositif orchestrateur 18 ne l'a pas stocké précédemment. 20 À l'étape 904, le dispositif orchestrateur 18 reçoit l'image correspondante. À l'étape 905, le dispositif orchestrateur 18 transfère le fichier joint au dispositif de traitement de fichier 19. Dans des modes de réalisation, plutôt que de transmettre le fichier joint tel qu'il est récupéré à partir du serveur de messagerie 11 ou à partir d'une mémoire conservée par le dispositif orchestrateur 18, le dispositif orchestrateur 18 peut antérieurement appliquer un 25 prétraitement pour récupérer l'image et adapter son format ou sa qualité. La Figure 10 est un organigramme décrivant le processus mis en oeuvre par le dispositif de traitement de fichier selon certains modes de réalisation. À l'étape 1000, un fichier joint dans un format pris en charge par le dispositif de traitement de fichier est reçu en provenance du dispositif orchestrateur 18 (p. ex. pdf, format 30 d'image). Dans des modes de réalisation, le fichier joint 190 peut être préalablement traité pour optimiser son traitement. À l'étape 1001, au moins un algorithme d'extraction, OCR par exemple, est appliqué au fichier joint pour extraire des caractères et/ou les données de positionnement du fichier 190. 5 Aux étapes 1002 à 1005, les données extraites du fichier joint sont analysées et structurées en un fichier de description conforme à une structure de donnée prédéfinie comprenant un ensemble de clés. Spécifiquement, l'étape 1002 peut comprendre l'analyse des données extraites pour mapper chaque clé d'un ensemble prédéfini de clés à un ou plusieurs éléments de donnée des 10 données extraites à partir du fichier joint reçu, chaque élément de donnée mappé représentant une valeur candidate pour une clé. L'étape 1003 peut comprendre le calcul d'une notation pour chaque valeur candidate attribuée à une clé. Dans des modes de réalisation, l'étape de mappage et/ou l'étape de notation peuvent 15 être réalisées en utilisant l'apprentissage automatique des données. Dans un mode de réalisation, l'étape 1004 peut comprendre le calcul d'un ensemble de données de positionnement pour chaque valeur candidate déterminée pour une ou plusieurs clés, l'ensemble de données de positionnement déterminé pour une valeur candidate représentant la position de la valeur candidate dans le fichier joint. Les données de 20 positionnement déterminées pour un élément de donnée donné peuvent inclure les coordonnées dans un référentiel donné défini par rapport au fichier non modifiable. À l'étape 1005, le fichier de description tel qu'il est généré peut être renvoyé au dispositif orchestrateur 18. La Figure 11 est une vue d'un extrait d'un exemple de fichier de description 190 au 25 format JSON (pseudocode). Tel qu'il est présenté, le fichier de description 190 comprend un ensemble de clés, chacune ayant une ou plusieurs valeurs candidates déterminées par le dispositif de traitement de fichier 19, chaque valeur candidate étant associée à une notation représentant le niveau de pertinence de la valeur candidate déterminée par le dispositif de traitement de fichier. Chaque 31 clé est par ailleurs associée à un ensemble de données de positionnement représentant la position de l'élément de donnée correspondant dans le fichier joint d'origine 121. La Figure 12 est un organigramme décrivant le processus d'affinement d'un fichier de description selon des modes de réalisation. 5 À l'étape 1200, le fichier de description 191 est reçu par le dispositif orchestrateur 18 à partir du dispositif de traitement de fichier 19. À l'étape 1202, un fichier de description 181 déterminé à partir du fichier de description 191 peut être transmis à partir du dispositif orchestrateur 18 à l'application 15 du dispositif client 14 (le fichier de description 181 peut être le fichier de description 191 lui-même, 10 ou une version transformée du fichier de description 191). Dans certains modes de réalisation, le fichier joint correspondant 121 peut être transmis simultanément à l'application. À l'étape 1204, un affichage du fichier de description 181 peut être généré par l'extension d'application 152 sous la forme d'un formulaire de vérification, dans la partie 52 de la zone dédiée 5. Le fichier joint correspondant 121 (p. ex. un reçu) peut être affiché sous forme 15 d'image dans la partie 50 de la zone dédiée pour permettre une vérification par l'utilisateur s'il n'a pas été affiché pendant la phase d'initialisation. Le formulaire comprend un ensemble de champs, chaque champ correspondant à une clé du fichier de description. Si une vue initiale du formulaire était affichée au lancement de l'extension d'application 152, les champs du formulaire peuvent être mis à jour à partir du contenu du fichier de description de contenu 181 à 20 l'étape 1204. Pour chaque champ du formulaire, la valeur candidate ayant la notation la plus élevée pour la clé correspondant au champ du formulaire dans le fichier de description 181 peut être attribuée à la valeur du champ. Dans certains modes de réalisation, les autres valeurs candidates peuvent être mises en évidence ou affichées en utilisant des éléments visuels dans la zone dédiée pour mettre en avant la pertinence de la valeur candidate en fonction de la 25 notation déterminée pour cette valeur. Dans un mode de réalisation, les éléments visuels peuvent être les cases de mise en évidence 55 cliquables qui sont superposées directement sur l'image représentant le fichier joint dans la partie 50 de la zone dédiée 5, la position de la case de mise en évidence étant déterminée à partir de l'ensemble de données de positionnement associé à la valeur candidate dans le fichier de description 181. 30 À l'étape1205, l'extension d'application peut mettre à jour la valeur d'un champ donné du formulaire dans la partie 52 de la zone dédiée 5, en réponse à la sélection d'une autre valeur 32 candidate par l'utilisateur qui utilise les éléments visuels 55, par exemple en cliquant sur une des cases de mise en évidence dans la partie RO de la zone dédiée 5 en réponse à une correction faite par l'utilisateur (par saisie textuelle) directement dans le formulaire de vérification affiché dans la partie 52 de la zone dédiée 5. L'utilisateur peut par ailleurs saisir des 5 valeurs pour les champs vides si aucune valeur n'a été déterminée pour une clé. L'étape 1205 peut être itérée pour une ou plusieurs clés jusqu'à ce que l'utilisateur valide le formulaire par exemple en cliquant sur un bouton de validation (520). La saisie de l'utilisateur peut aussi faire l'objet des mêmes vérifications que les vérifications effectuées par le dispositif de traitement de fichier 19 pour les données extraites. Par exemple, le numéro d'IBAN saisi par l'utilisateur 10 subira la même somme de vérification que celle effectuée par le dispositif de traitement de fichier 19. À l'étape 1206, l'extension d'application peut se connecter au serveur de messagerie 11 pour requérir les données d'authentification, telles qu'un mot de passe et un identifiant, donnant accès au dispositif de traitement de données cible 2 dans les modes de 15 réalisation où ces données d'authentification sont stockées dans le serveur de messagerie 11 ou dans une base de données externe. Autrement, ces données d'authentification peuvent être demandées par le dispositif orchestrateur 18 directement. À l'étape 1208, le formulaire, éventuellement avec les données d'authentification, peut être soumis au dispositif orchestrateur 18 avec les valeurs de champ actualisées. 20 À l'étape 1210, le fichier de description 191 peut être mis à jour en utilisant les valeurs corrigées ou en sélectionnant la valeur ayant la notation la plus élevée pour chaque clé pour laquelle l'utilisateur n'a pas corrigé les valeurs ce qui permet d'obtenir un fichier de description affiné. Un fichier de description 182 déterminé à partir du fichier de description affiné peut être 25 généré par le dispositif orchestrateur 18. Le fichier de description déterminé 182 (également désigné comme ( REVENDICATIONS1. Un système d'intégration de contenu d'un message dans un dispositif de traitement cible (2), ledit dispositif de traitement cible (2) étant configuré pour traiter une donnée de saisie ayant une structure de donnée prédéfinie, le système comprenant un serveur de messagerie (11) configuré pour recevoir un message provenant d'un dispositif client de messagerie (14) qui exécute une application de messagerie (15) ledit message comprenant un contenu de message, dans lequel le système comprend par ailleurs un dispositif de traitement de fichier (19) et un dispositif orchestrateur (18) configuré pour intégrer au moins une partie du contenu du message dans le dispositif de traitement de données cible (2), ledit dispositif orchestrateur (18) étant par ailleurs configuré pour : - recevoir la partie du contenu de message du serveur de messagerie (1) ; et - transmettre un fichier déterminé à partir de ladite partie du contenu du message vers un dispositif de traitement de fichier (19), ledit dispositif de traitement de fichier étant configuré pour transformer chaque fichier reçu (190) en un fichier de description (191) comprenant un ensemble de clés prédéfinies, aux moins certaines des clés étant associées à une ou plusieurs valeurs, le dispositif orchestrateur (18) étant configuré pour déterminer un fichier d'entrée (190) ayant la structure de donnée prédéfinie à partir dudit fichier de description (191) et pour transmettre le fichier d'entrée déterminé (182) vers le dispositif de traitement de données cible (2) pour traitement du fichier d'entrée déterminé par le dispositif de traitement cible. 2. Le système selon la revendication 1, dans lequel le dispositif orchestrateur (18) est connecté au serveur de messagerie (11) selon un premier protocole de communication, à l'application de messagerie (150) selon un second protocole, et au dispositif de traitement de données cible (2) selon un troisième protocole de communication. 3. Le système selon la revendication 2, dans lequel l'application de messagerie (15) comprend une interface d'application (150) et une extension d'application (152) configurée pour générer une restitution d'un fichier d'entrée déterminé du fichier de description (191) fourni par le dispositif de traitement de fichier (19) dans une zone dédiée (5) de l'interface d'application (150). 4. Le système selon l'une quelconque des revendications précédentes, dans lequel le dispositif de traitement de fichier (19) est configuré pour mapper un ou plusieurs éléments de donnée de ladite partie du contenu du message à au moins certaines clés d'un ensemble prédéfini de clés, 40 le dispositif de traitement de fichier étant configuré pour générer ledit fichier de description à partir de ladite partie du contenu du message, ladite description de fichier comprenant ledit ensemble de clés prédéfinies, ladite une ou plusieurs valeurs associées auxdites clés du fichier de description déterminé à partir des éléments de donnée qui y sont mappés. 5 5. Le système selon la revendication 4, dans lequel le dispositif de traitement de fichier (19) est par ailleurs configuré pour déterminer des ensembles de données de positionnement à partir dudit fichier reçu du dispositif orchestrateur (18), chaque ensemble de données de positionnement identifiant la position d'un élément de donnée du fichier en mappant une clé dudit ensemble de clés prédéfinies, chaque ensemble de données de positionnement étant 10 inclus dans ledit fichier de description qui est associé à la clé mappée à l'élément de donnée. 6. Le système selon la revendication 5, dans lequel chaque ensemble de données de positionnement comprend des coordonnées de positionnement dans un référentiel donné. 7. Le système selon l'une quelconque des revendications précédentes 3 à 6, dans lequel ladite interface d'application (150) est une application de l'interface graphique, ladite extension 15 d'application (152) étant configurée pour rendre le fichier de description dans une zone dédiée de ladite interface d'application (150). 8. Le système selon l'une quelconque des revendications précédentes 4 à 7, dans lequel le dispositif de traitement de fichier (19) est par ailleurs configuré pour déterminer une notation pour chaque valeur associée à une clé donnée dudit ensemble prédéfini de clés, le dispositif de 20 traitement de fichier étant par ailleurs configuré pour inclure la notation déterminée pour la valeur associée à ladite clé donnée dans le fichier de description. 9. Le système selon la revendication 8, dans lequel ladite extension d'application (152) est par ailleurs configurée pour afficher une image de la partie de contenu du message dans ladite zone dédiée et pour générer l'affichage d'un ou de plusieurs éléments sélectionnables de mise 25 en évidence des éléments pour chaque élément de donnée de la partie de contenu du message en mappant une clé, chaque élément de mise en évidence pour un élément de donnée donné étant affiché sur une position dans l'image affichée qui est déterminée à partir de l'ensemble des données de positionnement identifiant la position dudit élément de donnée. 10. Le système selon l'une quelconque des revendications précédentes, dans lequel le 30 dispositif orchestrateur (18) est configuré pour utiliser un identifiant de message associé au message pour chaque échange entre le dispositif orchestrateur (18) et le serveur de 41 messagerie (11), et/ou l'extension d'application (152), et/ou le dispositif de traitement de fichier (19) et/ou le dispositif de traitement de données cible (2). 11. Un procédé pour intégrer du contenu de message dans un dispositif de traitement cible (2), ledit dispositif de traitement de données cible (2) étant configuré pour traiter une donnée 5 d'entrée ayant une structure de donnée prédéfinie, le procédé comprenant la réception d'un message provenant d'un dispositif client de messagerie (14) qui exécute une application de messagerie (15), ledit message comprenant le contenu du message ; dans lequel le procédé comprend l'intégration d'au moins une partie de contenu du message dans ledit dispositif de traitement de données cible (2), ledit procédé étant par ailleurs configuré 10 pour déterminer un fichier déterminé à partir de ladite partie de contenu du message et pour transformer ledit fichier (190) en un fichier de description (191) comprenant un ensemble de clés prédéfinies, au moins certaines des clés étant associées à une ou plusieurs valeurs, le procédé comprenant la dérivation d'un fichier d'entrée (190) ayant ladite structure de donnée prédéfinie à partir dudit fichier de description (191) et transmettre ledit fichier d'entrée déterminé 15 (182) au dispositif de traitement de données cible (2) pour traitement du fichier d'entrée déterminé par le dispositif de traitement cible. 12. Un produit-programme d'ordinateur comprenant : un support non transitoire de stockage lisible par ordinateur ; et des instructions stockées sur un support de stockage non transitoire, lisible par ordinateur qui, 20 lorsqu'il est exécuté par un processeur, amène le processeur à intégrer du contenu de message dans un dispositif de traitement de données cible (2), ledit dispositif de traitement de données cible (2) étant configuré pour traiter la donnée d'entrée ayant une structure de donnée prédéfinie, le processeur étant par ailleurs amené à: - recevoir un message en provenance d'un dispositif client de messagerie (14) qui exécute une 25 application de messagerie (15), ledit message comprenant un contenu de message ; - intégrer au moins une partie du contenu de message dans ledit dispositif de traitement de données cible (2), le processeur étant par ailleurs amené à déterminer un fichier déterminé à partir de ladite partie de contenu de message et à transformer ledit fichier (190) en un fichier de description (191) 42 comprenant un ensemble de clés prédéfinies, au moins certaines des clés étant associées à une ou plusieurs valeurs, - déterminer un fichier d'entrée (190) ayant ladite structure de données prédéfinie à partir dudit fichier de description (191) et transmettre ledit fichier d'entrée déterminé (182) au dispositif de 5 traitement de données cible (2) pour traitement du fichier d'entrée déterminé par le dispositif de traitement cible.