FR 3131031 A1 20230623 FR 2114185 A 20211221 L’invention se rapporte à un procédé de traitement de données, mis en œuvre au sein d’un dispositif de traitement de données (TERM). Le procédé comprend au moins une itération des étapes suivantes : - obtention (S02) d’une chaîne de caractères (READ_STR) ; - stockage (S04) de la chaîne de caractères dans une mémoire-tampon (DB) accessible à une application de traitement (APP) exécutée par un navigateur (WB) au sein du dispositif électronique (TERM) ; - analyse syntaxique (S06) de la chaîne de caractères par l’application, l’analyse syntaxique (S06) comprenant une détermination (S60) en continu de la présence d’un préfixe (PREFIX) de forme prédéterminée au début de la chaîne de caractères stockée dans la mémoire-tampon (DB) ; et - extraction (S62) d’une sous-chaîne de caractères (AIM_ID, P_STR) à partir de la chaîne de caractères d’entrée à l’aide du préfixe (PREFIX) si ledit préfixe (PREFIX) est présent, sinon vidage (S64) de la mémoire tampon (DB) ; - transmission (S08) de la sous-chaîne de caractères (AIM_ID, P_STR) extraite à une application serveur (SERV). Fig 1. procédé de traitement de données issues de code en une ou deux dimensions, dispositifs et programme correspondant. 1. Domaine de l’invention L’invention concerne le domaine du traitement de données à caractère médical, et plus particulièrement du traitement de données techniques produites dans le cadre d’une implantation d’un dispositif médical implantable (ou DMI) ou d’un dispositif médical (DM) servant à la mise en œuvre d’un dispositif médical implantable. Le terme dispositif médical implantable peut désigner un dispositif médical destiné à être totalement ou partiellement introduit, par voie chirurgicale ou médicale, dans le corps humain, ou par une intervention médicale dans un orifice naturel, et qui est destiné à y demeurer après l’intervention. 2. Art antérieur La traçabilité des DMI et des DM est un impératif, et est sévèrement encadrée. Chaque DMI se doit en effet d’être localisable en tout lieu et en tout temps, de sa fabrication jusqu’à la fin de son cycle de vie, y compris et surtout lors de son implantation – celle-ci étant le stade le plus critique de ce cycle de vie. Cela impose que chaque DMI soit identifié de manière univoque à l’aide d’un identifiant de DMI. Une bonne traçabilité au moment de la pose permet ensuite de gérer les rappels de lots (implantés ou non). En outre, les DMI se complexifient d’année en année, de par leur connectivité croissante, leur fabrication sur mesure, les matériaux de plus en plus techniques et bio compatibles, ou encore leur conception intégrant toujours davantage de capteurs. Cette complexité croissante, tout comme la réglementation extrêmement forte l’accompagnant, impose un suivi riche et précis de chaque DMI implanté. Les constructeurs de DMI doivent identifier, tracer et évaluer la conformité (notamment en PMS de l’anglais pour « Post Market Surveillance ») des DMI produits. En particulier, la collecte de données en PMS est une procédure indispensable dans le cadre de la production d’un DMI donné, afin d’évaluer le rapport bénéfice-risque de ce DMI, indispensable au maintien de la certification autorisant la mise sur le marché de ce DMI. Cette remontée de données et cette traçabilité sont en outre un élément indispensable à la construction et à l’entretien de la confiance entre patients, autorités médicales et fabricants de DMI. Or, à ce jour, il existe un important déficit des organisations et des moyens informatiques pour réaliser une traçabilité des DMI satisfaisante. Les moyens informatiques – matériels comme logiciels – mis en œuvre au sein des établissements de santé sont lacunaires et disparates. Cela concerne l’obtention effective des données (en particulier au moment d’une implantation), leur collecte, leur centralisation et leur traitement, ces différentes étapes servant à établir la traçabilité sanitaire des DMI implantés tout au long de leur cycle de vie. La saisie de données relative à un DMI, telle que réalisée aujourd’hui, est en outre peu ergonomique, car absolument pas adaptée à la saisie au cours d’une implantation, notamment au sein d’un bloc opératoire. Les données relatives à un DMI en cours d’implantation sont en général saisies de manière manuscrite. Cela peut être par exemple réalisé dans un cahier d’opération, dans lequel les identifiants des DMI sont recopiés, et à côté desquels identifiants on rédige de manière manuscrite des informations complémentaires. Ces informations complémentaires peuvent être relatives à un DMI donné ou à son implantation – typiquement en cas de problème lors de l’implantation du DMI ou d’échec de celle-ci. Ainsi, la saisie de ces données (identifiants de DMI et informations complémentaires) est lourde et source d’erreurs. La collecte et le traitement de ces données une fois saisies, pourtant indispensable, est également extrêmement lourde et génératrice d’erreurs. Il faut en effet récolter toutes les données saisies à la main, et les enregistrer dans une base de données adéquate. La conséquence de ces carences de gestion des données relatives aux DMI, à la saisie comme au traitement, est qu’une minorité des patients est en mesure de récupérer les données issues de l’implantation d’un DMI les concernant, et cette récupération n’est par ailleurs pas tracée dans la majorité des cas. En outre, le compte-rendu issu de ces données est en général partiel, avec une saisie de données disparate et présentant un grand nombre d’erreurs. Cela provoque des litiges récurrents entre patients et services hospitaliers. Solder ces litiges nécessite de longues interventions manuelles – en particulier la recherche des données brutes saisies manuellement, lorsqu’elles existent. Ce phénomène est croissant avec l’augmentation du nombre d’implantations de DMI. Il existe ainsi un besoin pour une saisie de données davantage automatisée, et adaptée aux contraintes spécifiques aux interventions médicales. Une première approche pourrait être l’utilisation de codes-barres pour identifier des DMI, moins source d’erreurs qu’une saisie manuscrite. De tels codes-barres sont lus à l’aide d’un lecteur de code-barres appelé couramment « douchette » (« barcode scanner » en anglais). À titre d’exemple, le brevet FR 3053811 décrit un procédé d’identification de dispositifs médicaux à l’aide d’un code-barres. Cela permet d’identifier un dispositif médical, et en particulier un DMI. Le procédé cependant, n’est essentiellement utilisable que pour la gestion de stocks de DMI au sein d’un établissement de santé. Par ailleurs, le procédé décrit dans FR 3053811 ne permet pas de saisir de manière automatisée d’autres données que des identifiants de dispositifs médicaux. Ce procédé n’est en outre pas adapté à l’utilisation dans un bloc opératoire au cours d’une implantation, notamment lorsqu’il faut saisir des informations complémentaires relatives au DMI et à son implantation. Ainsi, lors d’une implantation, le personnel soignant peut certes saisir de manière plus fiable des identifiants en les scannant, mais en revanche, les informations complémentaires nécessaires à la bonne traçabilité du DMI restent toujours saisies manuellement. Cela se traduit dans la pratique par le simple collage, dans un cahier de bloc opératoire, du code-barres identifiant le DMI à implanter. Les informations complémentaires accompagnant cet identifiant sont ensuite saisies de manière manuscrite. Le problème de la saisie et du traitement de ces données reste donc entier. Dans d’autres cas, le code-barres est lu par une douchette (et donc lu indirectement par un ordinateur), mais les informations complémentaires restent toujours saisies manuellement, à l’aide d’un clavier et d’une souris. Cela fluidifie certes la partie traitement des données, puisque les données sont enregistrées directement au sein d’un ordinateur, mais la saisie des données (notamment les informations complémentaires) en tant que telle reste lourde pour les utilisateurs, et source d’erreurs en tout genre. Là encore, les obstacles à la bonne traçabilité des DMI demeurent. Par ailleurs, la saisie des informations complémentaires, que cela soit à l’aide d’un clavier et d’une souris ou d’un stylo, pose de gros soucis d’hygiène au sein du bloc opératoire. Il est nécessaire de désinfecter le clavier et/ou la souris à utiliser en plus de la douchette, puis de protéger ces trois périphériques à l’aide d’un film plastique. Cela alourdit la préparation du bloc opératoire. Malheureusement, le procédé du brevet FR 3053811 repose en outre de manière essentielle sur de la saisie manuelle d’informations dans une base de données, en particulier le code-fabricant du DMI qui identifie le fabricant du DMI. Ainsi, ce procédé reste très lacunaire au niveau de la saisie de données, et suppose par ailleurs de connaitre les codes qui se rapportent effectivement au fabricant, ce qui n’est pas nécessairement le cas compte tenu de la multiplicité des codes 1D ou 2D présents sur une boite de DMI, voire sur le DMI lui-même. Dans les faits, le procédé du brevet FR 3053811 ne simplifie ainsi que marginalement la saisie de données (pour l’essentiel, la saisie des identifiants de dispositifs médicaux), ce qui est très insatisfaisant. 3. Exposé de l’invention L’invention a été conçue pour pallier au moins certains des inconvénients de l’art antérieur. L’invention propose un procédé, mis en œuvre au sein d’un dispositif électronique de traitement de données, comprenant au moins une itération des étapes suivantes : - l’obtention d'une chaîne de caractères d’entrée (« string » en anglais) issue de la lecture d’au moins un code-barres par un appareil optique ; - le stockage de la chaîne de caractères d’entrée dans une mémoire-tampon accessible à une application de traitement exécutée au sein d’un navigateur ; - l’analyse syntaxique de la chaîne de caractères d’entrée par l’application, l’analyse syntaxique comprenant une détermination en continu de la présence d’un préfixe de forme prédéterminée au début de la chaîne de caractères d’entrée stockée dans la mémoire-tampon, et - L’extraction d’une sous-chaîne de caractères à partir de la chaîne de caractères d’entrée à l’aide du préfixe si ledit préfixe est présent, sinon vidage de la mémoire tampon ; - la transmission de la sous-chaîne de caractères extraite à une application serveur. Ainsi, ce procédé permet d’automatiser entièrement la saisie d’informations relatives à une implantation, notamment, particulièrement en améliorant l’interfaçage des données transmises à l’application, sans limiter la réactivité de cette application, notamment lors de frappes effectuées au clavier du dispositif électronique. Ce procédé est d’autant plus avantageux qu’il repose sur des chaînes de caractères de lecture issue de la lecture de différents code-barres. Autrement dit, toute la partie manuelle de la saisie peut être réalisée à l’aide d’un seul périphérique (le lecteur de code-barres), les étapes subséquentes (mise en forme, traitement, analyse…) étant automatisées par l’application « frontend » et l’application serveur. Cela constitue un gain de temps pour les utilisateurs – à la préparation d’une implantation comme à la saisie. En outre, ce procédé permet de saisir une grande variété de codes-barres, en particulier des codes-barres relatifs à des informations complémentaires à saisir et les associer à un DMI. Ainsi, l’ensemble du processus de saisie de données est automatisé, ce qui représente un gain de temps et une source d’erreurs en moins. Enfin, ce procédé est exécuté au sein d’un navigateur. Cela permet de mettre en œuvre ce procédé sur une grande variété de terminaux informatiques et de systèmes d’exploitation, réduisant considérablement les problèmes de compatibilité entre les différents types de terminaux informatiques employés : ordinateur personnel, tablette, smartphone… La transmission des données à une application serveur simplifie en outre la collecte des données et leur centralisation, à des fins de traitement et de traçabilité. La gestion optimisée de la mémoire tampon selon l’invention fluidifie quant à elle la communication entre le terminal informatique et le serveur et permet en outre de distinguer les saisies manuelles des saisies automatiques. Selon une caractéristique particulière, l’extraction de la sous-chaîne de caractères comprend lorsque le préfixe est présent dans la chaîne de caractères d’entrée la détermination de la présence d’un suffixe prédéterminé dans la chaîne de caractères d’entrée, et la détermination de la sous-chaîne de caractères à l’aide du préfixe et du suffixe. L’utilisation conjointe du préfixe déjà identifié et du suffixe permet d’extraire rapidement la sous-chaîne de caractères, la légèreté de l’opération fluidifiant l’ensemble du procédé. Selon une caractéristique particulière l’obtention de la chaîne de caractères d’entrée comprend : - une étape d’acquisition d’une chaîne de caractères brute issue de la lecture du code-barres par l’appareil optique, - une étape d’identification, au sein de la chaîne de caractères brute, de la présence de caractères de contrôle appartenant à un groupe de caractères de contrôle prédéterminé, - une étape de remplacement au sein de la chaîne de caractères brute, de chacun des caractères de contrôle identifié par une chaîne de caractères de substitution prédéterminée respective, délivrant une chaîne de caractères traitée, - une étape de restitution de la chaîne de caractères d’entrée à partir de la chaîne de caractères traitée. Le remplacement des caractères de contrôle par des chaînes de caractères de substitution judicieusement choisies permet d’éviter, au cours d’une transmission du lecteur optique à l’application, que ces caractères de contrôle interfèrent avec la transmission. Par exemple, cela évite le cas où une partie de la chaîne de caractères d’entrée comprenant un de ces caractères de contrôle soit interprétée par l’un des éléments de la pile de transmission (système d’exploitation, driver, navigateur…) comme une instruction et non comme une saisie clavier. Cela évite également les problèmes d’encodage au cours de la transmission. Selon une caractéristique particulière, la chaîne de caractères de substitution d’un caractère de contrôle comprend la concaténation, dans l’ordre, d’un préfixe de caractère de contrôle, d’une chaîne de caractères représentative du caractère de contrôle et d’un suffixe de caractère de contrôle, le préfixe de caractère de contrôle et le suffixe de caractère de contrôle étant communs aux caractères de contrôle. Cet exemple de réalisation présente l’avantage d’avoir des chaînes de caractères de substitution de tailles semblables, standardisant et allégeant leur traitement. La taille de ces chaînes de caractères de substitution peut être réduite, ce qui réduit le temps entre la saisie d’une donnée et l’affichage de cette donnée saisie pour un utilisateur. En outre, ce type de chaînes de caractères de substitution permet d’éviter quasiment toute collision avec un des standards de code-barres préexistant. Selon une caractéristique particulière, la restitution de la chaîne de caractères d’entrée comprend : - obtention d’une chaîne de caractères de symbologie représentative de la symbologie du code-barres dont la chaîne de caractères brute est issue ; - restitution, en tant que chaîne de caractères d’entrée, de la concaténation, dans l’ordre, du préfixe, de la chaîne de caractères de symbologie, de la chaîne de caractères traitée et du suffixe. L’analyse syntaxique de la chaîne de caractères d’entrée résultante est ainsi facilitée, compte tenu de l’indication explicite de la symbologie de la charge utile transportée par la chaîne de caractères d’entrée. Selon une caractéristique particulière le stockage de la chaîne de caractères d’entrée dans la mémoire-tampon comprend, pour chaque caractère lu de la chaîne de caractères d’entrée - émulation d’une frappe clavier représentative du dit caractère lu, et - inscription dans la mémoire tampon du caractère lu à partir de la frappe clavier émulée. L’utilisation d’une émulation de frappe clavier, par exemple du type KeyboardEvent pour le navigateur Mozilla Firefox, permet de transmettre la chaîne de caractères d’entrée à l’application, caractère par caractère. Il est en outre possible d’optimiser cette transmission, en analysant les caractères un à un, comme on le verra ci-après. Selon une caractéristique particulière, on ignore l’inscription du caractère lu si la frappe clavier appartient à un groupe d’évènements prédéterminé. Ce groupe d’évènements, qui peut comprendre par exemple les touches Alt, CapsLock, Control, Fn, NumLock, Process, Shift…, peut interférer avec l’application, car celle-ci est exécutée par un navigateur donné au sein d’un système d’exploitation donné. Cela évite ainsi des incidents de saisie, par exemple la perte du focus sur le navigateur, ou un onglet de ce navigateur, exécutant l’application, ou la fermeture de l’un des éléments de la pile de transmission, … Selon une caractéristique particulière, l’inscription du caractère lu dans la mémoire tampon comprend le vidage de la mémoire tampon avant l’inscription effective du caractère lu si la durée entre la frappe clavier et une frappe clavier précédente excède un seuil prédéterminé. Cette condition supplémentaire permet de distinguer les saisies manuelles effectuées au clavier de l’émulation de frappes clavier induite par l’obtention de la donnée de lecture, une saisie manuelle étant typiquement bien plus lente que l’émulation de frappes clavier. On peut également envisager un seuil adaptatif afin de distinguer les saisies manuelles, au rythme saccadé, du résultat de l’émulation de frappes clavier, bien plus régulier. Dans un exemple de réalisation, le seuil prédéterminé est d’environ 500 ms. Cette valeur de seuil est un compromis entre un seuil trop faible – le moindre ralentissement de la pile de transmission lecteur/application entraînant un vidage indu de la mémoire tampon – et un seuil trop élevé – ce critère ne discriminant plus de manière satisfaisante les saisies manuelles de l’émulation de frappes clavier. Selon une caractéristique particulière, les différentes chaînes de caractères (PREFIX, SUFFIX, C_PREFIX, C_SUFFIX, AIM_ID, SUB_STR) ajoutées au cours du procédé comprennent des caractères inclus dans la table ASCII non-étendue. Ainsi, la chaîne de caractères d’entrée issue des différentes étapes du procédé est encodée sous un format ASCII non étendu, garantissant ainsi une compatibilité avec un très grand nombre de systèmes d’exploitation et de navigateurs. Selon une caractéristique particulière, le préfixe débute par la chaîne de caractères « {@} ». Cette chaîne de caractères particulière présente plusieurs avantages. Le caractère accolade ouvrante « { » (tout comme l’accolade fermante) nécessite usuellement un appui simultané sur deux touches d’un clavier (par exemple AltGr et la touche 4 en disposition AZERTY), ce qui rend improbable une saisie manuelle comprenant ce caractère tout en respectant le critère d’un délai réduit entre deux frappes clavier. Employer ce caractère crochet avant le caractère arobase @ permet d’éviter que la saisie d’une adresse e-mail n’interfère avec l’émulation de frappes clavier, sauf à ce que cette adresse e-mail comprenne une accolade ouvrante juste avant l’arobase. Ce choix de début de préfixe présente également l’avantage de pouvoir saisir des adresses e-mail (avec un arobase) sans interception par le procédé de l’invention (dit autrement, sans annulation de la propagation de l’évènement clavier lié à la frappe sur la touche @, puisqu’elle n’est jamais précédée de l’accolade ouvrante « { »). Si jamais un utilisateur venait à souhaiter entrer une accolade ouvrante, il suffirait à l’utilisateur de frapper deux fois sur la touche (la première frappe verrait sa propagation annulée par le procédé, mais la deuxième non). Cette contrepartie concernant la touche crochet ouvrant (rarement saisie) permet l’intégration transparente du procédé dans un ordinateur et au sein d’un navigateur. Des caractéristiques similaires peuvent être retranscrites pour tout type de disposition de clavier (QWERTY par exemple) avec des caractères différents. Selon une caractéristique particulière, la transmission de la sous-chaîne de caractères à l’application serveur comprend : - une étape de détermination de la présence, au sein de la sous-chaîne de caractères, d’une chaîne de caractères de symbologie représentative de la symbologie du code-barres dont est tirée la sous-chaîne de caractères ; - une étape d’extraction d’une donnée utile à partir de la sous-chaîne de caractères et de la chaîne de caractères de symbologie lorsque présente. Il est ainsi possible, au cours du traitement d’une chaîne de caractères, d’identifier le type d’information transporté. Cela permet en particulier d’identifier le format de la sous-chaîne de caractère, typiquement lorsque le code-barres dont la chaîne de caractères est issu est d’un type standard. Selon une caractéristique particulière la transmission d’une sous-chaîne de caractères courante comprend, si la sous-chaîne de caractères courante est dépourvue d’une chaîne de caractères de symbologie, - l’obtention d’une sous-chaîne de caractères précédente, transmise à l’itération précédente, et - si ladite sous-chaîne de caractères précédente comporte une chaîne de caractères de symbologie relative à un format de code-barres du type identifiant un dispositif donné, association de la sous-chaîne de caractères courante à la sous-chaîne de caractères précédente. Ainsi, il est possible d’utiliser des codes-barres spécifiques qui se distinguent des codes-barres standardisés car dépourvus d’une chaîne de caractères de symbologie. Ces codes-barres spécifiques au procédé permettent de réaliser des actions spécifiques exécutées dans l’application. L’absence de symbologie rend ces codes-barres spécifiques plus légers à transmettre, sans léser l’acquisition et le traitement des codes-barres standards. L’association d’un code-barres spécifique scanné à la suite d’un code-barres standard (identifiant un dispositif donné) permet de réaliser au sein de l’application une action sur le dispositif donné. On peut par exemple réaliser une saisie d’informations complémentaires pour un dispositif scanné par l’intermédiaire du lecteur optique. Selon une caractéristique particulière, la détermination de la présence de la chaîne de caractères de symbologie et l’extraction de la donnée utile sont réalisées au sein de l’application serveur (éventuellement distante). La maintenance des terminaux informatiques présents en implantation est réduite au minimum. Une éventuelle mise à jour des règles de traitement (par exemple en cas d’introduction ou de modification d’un nouveau standard de code-barres) est alors principalement réalisée au niveau de l’application serveur, qui peut être distante ou chargée dynamiquement sur le terminal informatique. Cette centralisation garantit en outre une grande cohérence dans le traitement des données issues des dispositifs médicaux. L’invention propose en outre un dispositif électronique de traitement de données (TERM), caractérisé en ce qu’il comprend : - des moyens pour recevoir une chaîne de caractères d’entrée ; - des moyens pour stocker ladite chaîne de caractères d’entrée dans une mémoire tampon accessible à une application de traitement exécutée par un navigateur au sein du dispositif électronique ; - des moyens d’analyse syntaxique par l’application de la chaîne de caractères d’entrée comprenant des moyens de détermination en continu de la présence d’un préfixe de forme prédéterminée au début de la chaîne de caractères d’entrée stockée dans la mémoire-tampon ; - des moyens d’extraction d’une sous-chaîne de caractères à partir de la chaîne de caractères d’entrée à l’aide du préfixe si ledit préfixe est présent, et des moyens de vidage de la mémoire tampon sinon ; et - des moyens de transmission de la sous-chaîne de caractères extraite à une application serveur. Selon une implémentation préférée, les différentes étapes des procédés selon la présente divulgation sont mises en œuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un terminal d’exécution selon la présente technique et étant conçu pour commander l'exécution des différentes étapes des procédés, mis en œuvre au niveau d’un terminal de communication, d’un serveur distant et/ou d’une chaîne de blocs, dans le cadre d’une répartition des traitements à effectuer et déterminés par un code source scripté ou un code compilé. En conséquence, la présente technique vise aussi des programmes, susceptibles d’être exécutés par un ordinateur ou par un processeur de données, ces programmes comportant des instructions pour commander l'exécution des étapes des procédés tel que mentionnés ci-dessus. Un programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. La présente technique vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou terminal capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un support mobile (carte mémoire) ou un disque dur ou encore un SSD. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon la présente technique peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Selon un mode de réalisation, la présente technique est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels. Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de la présente technique. 4. Liste des figures D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un exemple de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - représente un dispositif mettant en œuvre le procédé de l’invention ; - représente le procédé selon l’invention ; - représente un exemple d’obtention de chaîne de caractères d’entrée du procédé de la ; - représente un exemple de stockage de chaîne de caractères d’entrée du procédé de la ; - représente un exemple de détermination en continu de la présence du préfixe du procédé de la ; et - représente un exemple de structure simplifiée du dispositif de la . 5. Description de modes de réalisation de l’invention 5.1 Principe général On décrit, en référence à la , un dispositif électronique de traitement de données selon l’invention, comprenant un lecteur optique BCS, en communication avec un terminal informatique TERM. Le terminal informatique TERM exécute une application APP dans un navigateur WB. L’application APP communique avec un serveur SERV, par exemple distant du terminal informatique TERM. Le lecteur optique BCS est typiquement un scanner de code-barres, par exemple de type « douchette » (« bar code scanner » en anglais). En fonction des conditions de mise en œuvre opérationnelles, le lecteur optique et le terminal informatique peuvent ne constituer qu’un seul et même dispositif. Le lecteur optique BCS est configuré pour lire un code-barres et en extraire une chaîne de caractères READ_STR. Le lecteur optique BCS peut lire des codes-barres en une dimension (par exemple du type GS1-128, EAN-13, Code 39, Code 93, Codabar…) ou en deux dimensions (par exemple du type QRCode, GS1-Matrix, Datamatrix…). Dans certains cas, un code-barres à scanner peut être très proche d’un autre code-barres. En outre, certains codes-barres utilisés dans le domaine des DMI, en particulier ceux imprimés directement sur un DMI, peuvent être de très petite taille. Afin de pallier ces difficultés de lecture (s’assurer que le bon code-barres est scanné, quelle que soit des dimensions), le lecteur optique BCS peut projeter une mire lumineuse, par exemple en forme de croix, destinée à faciliter la visée du code-barres à scanner. Le lecteur optique BCS est relié au terminal informatique TERM. Le terminal informatique TERM est typiquement un ordinateur personnel, mais pourrait être en alternative une tablette, un smartphone, ou tout autre appareil adapté à la réception de données de lecture. On peut par exemple envisager l’intégration du procédé selon l’invention dans un smartphone, l’appareil photo du smartphone et le logiciel du smartphone pouvant déchiffrer des codes-barres, en particulier du type QRCode. Le terminal TERM exécute une application APP au sein d’un navigateur WB. Le navigateur est un logiciel courant, comme par exemple Mozilla Firefox, Microsoft Edge, Safari ou Google Chrome. L’exécution de l’application APP au sein du navigateur WB offre un cadre très universel que n’offrirait pas une application native – car celle-ci dépendrait bien trop des spécificités du terminal TERM, et notamment de son système d’exploitation. A l’inverse, le navigateur peut être vue comme un cadre générique d’exécution de l’application APP, qui peut donc être utilisé indépendamment du système d’exploitation du terminal TERM. L’application APP est typiquement une application s’exécutant avec les ressources du navigateur, et elle se présente sous la forme d’une application écrite dans un langage scripté, par exemple de type javascript. Cependant, l’utilisation d’un navigateur WB pour exécuter l’application APP soulève des obstacles techniques car la pile de transmission allant du lecteur optique BCS à l’application comprend de nombreux éléments, chacun étant en pratique capable d’interférer avec les données issues de la lecture d’un code-barres d’une part et capable d’interférer avec l’élément auquel il transmet les données qu’il traite d’autre part. En relation avec la , il est décrit un procédé de traitement de données en provenance par exemple d’un lecteur optique. Un tel procédé comprend une étape d’obtention S02 de la chaîne de caractères d’entrée STR_READ issue par exemple de la lecture d’un code-barres BC, une étape de stockage S04 de la chaîne de caractères d’entrée STR_READ, une étape d’analyse syntaxique 06 de la chaîne de caractères d’entrée STR_READ et une étape de transmission S08 du résultat de l’analyse syntaxique S06. La chaîne de caractères d’entrée READ_STR est par exemple issue de la lecture d’au moins un code-barres BC par l’appareil optique BCS, comme décrit ci-avant. La chaîne de caractères d’entrée READ_STR est transmise du lecteur de code-barres BCS à l’application APP. L’application APP stocke la chaîne de caractères d’entrée READ_STR ainsi reçue dans une mémoire tampon DB (« buffer » en anglais) à laquelle l’application a accès, avant traitement. Au moment de l’analyse syntaxique S06, l’application APP détermine dans une étape de détermination S60 la présence d’un préfixe PREFIX en début de chaîne de caractères d’entrée READ_STR. Le préfixe est une chaîne de caractères prédéterminée, connue de l’application APP. Si ce préfixe PREFIX est présent, c’est-à-dire qu’il forme bien le début de la chaîne de caractères d’entrée READ_STR, alors l’application APP réalise, dans une étape S62, l’extraction de la donnée "utile" comprise dans la chaîne de caractères d’entrée READ_STR. Si le préfixe PREFIX ne forme pas le début de la chaîne de caractères d’entrée READ_STR, alors l’application vide la mémoire tampon DB dans une étape de vidage S64. La détermination S60 est réalisée en continu, c’est-à-dire qu’au moment où l’application APP réalise l’absence du préfixe en début de chaîne de caractères, l’application APP vide immédiatement la mémoire tampon DB à l’étape S64. Cela limite la quantité de données qui sont effectivement traitées au cours de la détermination S60 de la présence du préfixe PREFIX, ce qui accélère cette étape. L’extraction S62 a notamment pour objectif d’extraire, de la chaîne de caractères d’entrée READ_STR, une sous-chaîne de caractères, cette sous-chaîne de caractères comprenant entre autres une charge utile (ou « payload » en anglais). L’extraction S62 est réalisée à l’aide du préfixe dont la présence a été détectée, la sous-chaîne de caractères étant située après le préfixe. Une fois l’extraction S62 de la sous-chaîne de caractères réalisée, l’application APP communique dans une étape de transmission S08 cette sous-chaîne de caractères à l’application serveur SERV, lequel pourra réaliser des traitements supplémentaires sur cette sous-chaîne de caractères. 5.2 Traitement des caractères de contrôle Dans un exemple de réalisation, représenté , l’obtention S02 de la chaîne de caractères d’entrée comprend l’acquisition S20 d’une chaîne de caractères brute RAW_STR issue de la lecture du code-barres BC par l’appareil optique BCS, un traitement S24 de cette chaîne de caractères brute RAW_STR produisant une chaîne de caractères traitée P_STR et la restitution S28, en tant que chaîne de caractères d’entrée READ_STR de la concaténation du préfixe PREFIX et de la chaîne de caractères traitée P_STR. Ce traitement S24 a notamment pour objectif d’éviter les interférences entre le contenu de la chaîne de caractères brute RAW_STR et les éléments matériels et logiciels qui forment la pile de transmission de cette chaîne de caractères brute RAW_STR depuis le lecteur optique jusqu’à l’application APP s’exécutant au sein du navigateur. Cette interférence peut par exemple provenir de la présence, au sein de la chaîne de caractères brute RAW_STR, de caractères de contrôle ou de caractères spéciaux. Ces caractères de contrôle peuvent correspondre aux valeurs hexadécimales 0x00 à 0x31 de la table ASCII : NULL, SOH, STX… US. Ce traitement S24 peut comprendre une étape d’identification des caractères de contrôle présents dans la chaîne de caractères brute RAW_STR, et le remplacement de chacun de ces caractères de contrôle par une chaîne de caractères de substitution respective n’interférant pas avec la pile de transmission. Ainsi, un caractère particulier, qui a exemple prend une valeur donnée pour un élément de la pile de transmission et une autre valeur pour un autre élément de la pile de transmission ne sera pas mal interprété et/ou ne sera pas source d’erreur tout au long de la transmission entre les différents éléments de la pile de transmission. Un caractère de contrôle peut par exemple être remplacé par une chaîne de caractères comprenant, dans l’ordre, un préfixe de contrôle, une chaîne de caractères représentative du caractère de contrôle et un suffixe de contrôle. Le préfixe de contrôle et le suffixe de contrôle sont ici communs à tous les caractères de contrôle. La chaîne de caractères représentative du caractère de contrôle peut par exemple être sous la forme de deux à trois caractères désignant le caractère de contrôle. Par exemple, pour le caractère de contrôle NUL, la chaîne de substitution résultante peut être de la forme __OXYS__NUL__OXYE__, où __OXYS__ est le préfixe de contrôle, NUL la chaîne de caractères représentative du caractère de contrôle NUL et __OXYE__ le suffixe de contrôle. Ce choix de chaîne de caractères de substitution présente plusieurs avantages : - la chaîne de caractères de substitution est très rapide à construire, puisqu’il s’agit d’une concaténation de chaînes de caractères, - les chaînes de caractères de substitution des caractères de contrôles font à peu près la même taille (dans l’exemple décrit, 18 à 19 caractères) - la forme générale de ces chaînes de caractères de substitution est suffisamment spécifique pour que la probabilité d’en rencontrer une dans une chaîne de caractères brute RAW_STR soit négligeable en pratique. Ainsi, non seulement les chaînes de caractères de substitution n’interfèrent pas avec les éléments de la pile de transmission, mais ils n’interfèrent pas non plus avec le contenu de la chaîne de caractères d’entrée. Pour la forme de la chaîne de caractères de substitution décrite ci-dessus, cela correspond à une chaîne de caractères de substitution de longueur maximale de 152 bits (18 à 19 octets). Pour une liaison entre le lecteur optique et le terminal informatique ayant par exemple un débit de 9600 bauds (bits par seconde), la transmission d’une chaîne de caractères de substitution prend 16 ms. Si, par exemple, un code-barres comprend trois caractères de substitution, cela revient à allonger la transmission de la chaîne de caractères d’entrée (par rapport à la chaîne de caractères brute RAW_STR) de 52 ms. Les inventeurs ont déterminé en pratique que cette contrainte ajoutée par le procédé de traitement était acceptable pour un utilisateur, en échange de la garantie pour l’utilisateur et pour l’application APP de ne pas avoir d’interférence entre la chaîne de caractères d’entrée et les éléments de la pile de transmission (ou de la charge utile). 5.3 Traitement de la symbologie des code-barres Dans un autre exemple de réalisation, compatible avec le traitement des caractères spéciaux décrit ci-dessus, la chaîne de caractères d’entrée READ_STR est terminée par un suffixe SUFFIX prédéterminé, typiquement de forme analogue au préfixe. L’extraction S06 de la sous-chaîne de caractères de la chaîne de caractères d’entrée comprend alors, lorsque le préfixe est présent, l’identification du suffixe. La sous-chaîne de caractères est alors extraite à l’aide du préfixe et du suffixe. La sous-chaîne de caractères peut typiquement être la chaîne de caractères comprise entre le préfixe et le suffixe. Cette identification simultanée du préfixe et du suffixe accélère l’extraction de la sous-chaîne de caractères, tout en améliorant sa fiabilité. Dans un exemple de réalisation, le procédé comprend, à l’obtention S02 de la chaîne de caractères d’entrée READ_STR, l’identification de la symbologie SYM du code-barres dont la chaîne de caractères brute (ou de lecture) est issue. Sur la base de cette identification, une chaîne de caractères de symbologie AIM_ID est obtenue, et concaténée à la chaîne de caractères traitée P_STR. Suite à cette concaténation, on concatène dans l’ordre le préfixe, la chaîne de caractères traitée P_STR et le suffixe. Synthétiquement, cela donne une chaîne de caractères d’entrée READ_STR de la forme . On peut inverser la place de la chaîne de symbologie et de la charge utile . En variante, on pourrait réaliser cette incorporation de la chaîne de caractères de symbologie directement dans la chaîne de caractères brute RAW_STR, par exemple en l’absence du traitement relatif aux caractères de contrôle. En variante, on peut se passer de l’identification de la symbologie, et restituer uniquement la concaténation du préfixe PREFIX, de la chaîne de caractères traitée P_STR et du suffixe SUFFIX. L’ajout, en plus du préfixe et du suffixe, de la symbologie (sous la forme de la chaîne de caractères de symbologie) améliore le traitement des chaînes de caractères transmises à l’application serveur. La symbologie est typiquement représentative d’un standard de codes-barres préexistant. Il peut par exemple s’agir de de la symbologie GS1-128, EAN-13, Code 39, Code 93 ou Codabar (pour les codes-barres 1D) ou QRCode, GS1-Matrix ou Datamatrix (pour les codes-barres 2D). Dans un exemple de réalisation, la lecture de certains code-barres, d’un type spécifique à l’application, n’entraîne pas l’ajout d’une chaîne de caractères de symbologie. Dit autrement, lorsque la chaîne de caractères traitée P_STR est de ce type de code-barres, la chaîne de caractères de symbologie est vide. Cela permet de réduire la taille d’une chaîne de caractères issue de la lecture d’un code-barres spécifique à l’application, et donc de réduire la latence entre la lecture d’un tel code-barres et le traitement de la chaîne de caractères qui en résulte, sans pour autant devoir sacrifier de l’information charriée par la chaîne de caractères d’entrée. 5.4 Transmission de la chaîne de caractères d’entrée à l’application Dans un exemple de réalisation, représenté , la transmission de la chaîne de caractères d’entrée à l’application, notamment son stockage S04 dans la mémoire tampon DB, est réalisé à l’aide d’une émulation de frappes clavier. Plus précisément, le stockage S04 comprend, pour chaque caractère lu de la chaîne de caractères d’entrée, l’émulation S40 d’une frappe clavier représentative du dit caractère lu, et l’inscription S42 dans la mémoire tampon DB dudit caractère lu à partir de la frappe clavier émulée. L’émulation de la frappe clavier peut être par exemple du type KeyboardEvent lorsque l’application est exécutée dans le navigateur Mozilla Firefox. Cette émulation permet de transmettre la chaîne de caractères d’entrée à l’application, caractère par caractère. Cela permet un certain nombre d’optimisations et de traitements sur cette chaîne de caractères au fil de sa transmission. On peut par exemple déterminer à dans une première étape S44 si la frappe clavier d’un caractère lu appartient à un groupe d’évènements prédéterminé IGN_EVENT. Si c’est le cas, on ignore ce caractère à une deuxième étape S46. Le groupe d’évènements à ignorer peut typiquement comprendre : Alt, AltGraph, CapsLock, Control, Dead, Fn, FnLock, Hyper, Meta, NumLock, Process, ScrollLock, Shift, Super, Symbol, SymbolLock. Ces évènements peuvent en effet interférer avec le bon fonctionnement de l’application, en particulier provoquer la perte du focus du terminal informatique sur l’application (dans un onglet du navigateur), sur le navigateur lui-même, voire fermer le navigateur ou l’onglet exécutant l’application. Comme on l’a dit ci-avant, l’émulation de frappes clavier, caractère par caractère, permet de réaliser plusieurs traitements sur la chaîne de caractères. Cela permet par exemple de bien distinguer une chaîne de caractères issue d’une saisie manuelle, au clavier du terminal informatique, de la chaîne de caractères d’entrée issue de la lecture du code-barres. Dans un exemple de réalisation, à chaque caractère produit par une frappe clavier (émulée ou non), l’application mesure à une troisième étape S48 la durée séparant l’inscription de ce caractère de l’inscription du dernier caractère ayant été inscrit dans la mémoire tampon DB. Si cette durée est supérieure à un certain seuil (dit autrement s’il s’est écoulé trop de temps entre deux frappes clavier, émulées ou non), la mémoire tampon DB est vidée à une quatrième étape S50. En d’autres termes, l’application estime alors qu’il s’agit d’une frappe manuelle (réalisée à un rythme nécessairement plus lent que celui d’une émulation de frappes clavier automatisée) et arrête de prendre en compte les données précédemment acquises pour l’analyse syntaxique. Le seuil prédéterminé peut par exemple être fixé à environ 500 ms. Il s’agit d’un bon compromis entre un seuil trop faible – le moindre ralentissement de la pile de transmission lecteur/application entraînant alors un vidage indu de la mémoire tampon – et un seuil trop élevé – ce critère ne discriminant plus de manière satisfaisante les saisies manuelles de l’émulation de frappes clavier. Selon l’invention, la mémoire tampon est vidée et les caractères présents dans la mémoire tampon sont libérés : ils sont normalement transmis au navigateur pour traitement par celui-ci. Ainsi, il s’écoule peu de temps entre une frappe manuelle, effectuée au clavier du dispositif informatique, et une prise en compte des actions résultant de cette frappe par le navigateur lorsque l’application détermine que les caractères qu’elle reçoit ne sont pas issus de code barre. La condition de durée maximale entre deux frappes au clavier (caractéristique d’une séquence de frappes clavier issue d’une lecture de code-barres) peut être remplacée ou complétée par une condition portant sur la régularité des frappes clavier de la séquence. Cela permet de discriminer les saisies manuelles des saisies automatiques, puisque les frappes clavier produites par l’émulation sont considérablement plus régulières que leur équivalent manuel. Dans un exemple de réalisation, les différentes chaînes de caractères mises en œuvre dans l’invention (PREFIX, SUFFIX, C_PREFIX, C_SUFFIX, AIM_ID, SUB_STR) et incorporées à la chaîne de caractères brute RAW_STR comprennent des caractères inclus dans la table ASCII non-étendue. Dans un exemple de réalisation privilégié, ces différentes chaînes de caractères sont exclusivement constituées de caractères inclus dans la table ASCII non-étendue. Ce choix d’encodage en ASCII non-étendu évite l’essentiel des interférences provoquées d’autres types d’encodage. Cela garantit une compatibilité avec une grande variété systèmes d’exploitation et de navigateurs, plus généralement de briques matérielles et logicielles mettant en œuvre le dispositif. Dans un exemple de réalisation privilégié, le préfixe débute par la chaîne de caractères « {@} ». Ce choix spécifique de chaîne de caractères présente plusieurs avantages. Le caractère accolade ouvrante « { » nécessite usuellement un appui simultané sur deux touches d’un clavier (par exemple AltGr et la touche 4 en AZERTY). Une saisie manuelle impromptue de l’ensemble de cette séquence est ainsi improbable, en particulier en respectant la condition de délai entre deux frappes. En effet, la saisie d’un caractère accolade (ouvrant ou fermant) conjointe à celle d’un arobase est hautement improbable, l’arobase étant essentiellement utilisée pour saisir des adresses e-mail. Ainsi, discriminer la présence d’un préfixe commençant par cette chaîne de caractères « {@} » permet, en analysant seulement trois caractères, de déterminer immédiatement si l’on est en présence d’une séquence de frappes clavier issue d’une chaîne de caractères d’entrée ou non. Dans un exemple de réalisation, la transmission de la sous-chaîne de caractères à l’application serveur comprend la détermination de la présence de la chaîne de caractères de symbologie AIM_ID dans la sous-chaîne de caractères transmise. Le reste de la sous-chaîne de caractères forme alors une charge utile, et comprend la chaîne de caractères traitée P_STR. Lorsqu’une sous-chaîne de caractères courante ne comprend pas la chaîne de caractères de symbologie AIM_ID, cela peut signifier que le code-barres dont est issu la sous-chaîne de caractères courante est relatif à l’une des actions spécifiques à exécuter par l’application. Dans ce cas, on vérifie, au cours de la transmission, si la précédente sous-chaîne de caractères transmise comprend une chaîne de caractères de symbologie AIM_ID. Si cela est le cas, et si sa symbologie est relative à l’identification d’un DMI, on associe la sous-chaîne de caractères courante audit identifiant de DMI. Cela permet de réaliser, via une simple lecture d’un code-barres spécifique à l’application, une action sur un DMI dont le code-barres d’identification a été lu. L’action spécifique à l’application peut être l’ajout d’une information complémentaire relative au DMI. Par exemple, l’information complémentaire peut concerner l’ajout d’un DMI à une base de données, un retour sur l’implantation du DMI (avec succès, avec erreur, ou échec d’implantation), ou l’enregistrement d’un évènement indésirable relatif au DMI (exemple : « vis cassée », « dispositif endommagé », « dispositif non conforme », etc.) durant son cycle de vie. L’absence de symbologie des code-barres spécifiques à l’application rend ces codes-barres plus légers à transmettre. Cette spécificité est transparente vis-à-vis des codes-barres standards et de leur traitement. L’association d’un code-barres spécifique scanné à la suite d’un code-barres standard (identifiant un dispositif donné) permet de réaliser au sein de l’application une action sur le dispositif donné sans avoir à utiliser un périphérique supplémentaire (clavier, souris, écran tactile), ce qui est un avantage particulier dans certaines situations, comme par exemple lorsque l’on éviter des contaminations sur ces périphériques (par exemple dans un bloc opératoire). Dans un exemple de réalisation, la détermination de la présence de la chaîne de caractères de symbologie et l’extraction de la donnée utile sont réalisées au sein de l’application serveur. Cette centralisation de la détection de la symbologie au sein de la sous-chaîne de caractère, et donc des différents traitements réalisés sur celle-ci, garantit la cohérence du traitement des données issues des DMI via l’application, notamment en cas de mise à jour. 5.4 Détermination en continu Dans un exemple de réalisation, représenté , la détermination S60 en continu de la présence du préfixe PREFIX au sein de la chaîne de caractères d’entrée READ_STR est réalisée de la façon suivante : à chaque caractère inscrit dans la mémoire tampon DB : 1. obtention de la chaîne de caractères courante CUR_STR inscrite dans la mémoire tampon DB ; 2. détermination S600 de si la taille L(CUR_STR) de la chaîne de caractères courante CUR_STR est inférieure à la taille L(PREFIX) du préfixe PREFIX, 2a. alors vérification S602 de si la chaîne de caractères courante CUR_STR constitue le début du préfixe PREFIX, 2b. sinon vérification S604 de si le préfixe PREFIX constitue le début de la chaîne de caractères courante CUR_STR. Un retour négatif de l’une de ces deux étapes 2a ou 2b entraine le vidage S64 de la mémoire tampon DB et arrêt S606 de l’analyse de la chaîne de caractères d’entrée READ_STR. Un retour positif de l’une de ces deux étapes 2a ou 2b entraîne l’annulation S608 de la propagation de l’évènement (CANCEL_PROP). Dit autrement, la frappe clavier courante n’est pas traitée comme une frappe clavier manuelle (par exemple l’inscription d’un caractère dans un champ) mais comme une frappe clavier issue de la lecture d’un code-barres. Le reste de l’analyse, dont l’extraction S62, peut alors être réalisé. 5.5 Dispositifs On décrit, en relation avec la , les différents moyens mis en œuvre dans le traitement des chaines de caractères issues de code à barre. L’application APP comprend des moyens APP1 pour recevoir la chaîne de caractères d’entrée en provenance du lecteur optique, des moyens AAP2 pour stocker ladite chaîne de caractères d’entrée dans la mémoire tampon DB, des moyens d’analyse syntaxique APP3 de ladite chaîne de caractères d’entrée et des moyens de transmission APP4 de la chaîne de caractères ainsi analysée au serveur SERV. Les moyens d’analyse APP3 comprennent des moyens de détermination APP30, des moyens d’extraction APP31 et des moyens de vidage APP32. Les moyens de détermination APP30 sont agencés pour déterminer en continu la présence du préfixe de forme prédéterminée au début de la chaîne de caractères d’entrée stockée dans la mémoire-tampon. Les moyens d’extraction APP31 sont agencés pour extraire une sous-chaîne de caractères à partir de la chaîne de caractères d’entrée stockée dans la mémoire-tampon à l’aide du préfixe lorsque la chaîne de caractères d’entrée débute par ledit préfixe. Les moyens de vidage APP32 sont agencés pour nettoyer (ou vider) la mémoire tampon en l’absence du préfixe au début de la chaîne de caractères d’entrée stockée dans ladite mémoire tampon. Les moyens de transmission sont agencés pour transmettre la sous-chaîne de caractères extraite à un serveur distant du terminal informatique. Les moyens précédemment décrits peuvent se présenter sous la forme d’un processeur particulier implémenté au sein d’un terminal, tel qu’un ordinateur personnel, une tablette, un smartphone, ou un module directement intégré au sein d’un lecteur optique. Selon un exemple de réalisation particulier, le terminal informatique TERM met en œuvre l’entièreté des moyens décrits ci-avant. Par exemple, le terminal informatique TERM comprend une mémoire M, comprenant une mémoire tampon DB, un processeur de traitement général P, équipée par exemple d’un microprocesseur, et pilotée par un programme d’ordinateur Pg, et/ou une mémoire sécurisée, ces éléments informatiques mettant en œuvre des procédés de traitement de données tels que décrits précédemment pour traiter les données issues de la lecture d’un code-barres. Afin de communiquer avec le serveur distant, le terminal informatique comprend, outre la mémoire, des moyens de communications, tels que des modules de communication réseau, des moyens de transmission de données et des circuits de transmission de données entre le terminal informatique et le serveur, et entre le terminal informatique le lecteur de code-barres. Selon un exemple de réalisation, le lecteur optique BCS met en œuvre les étapes de traitement de la chaîne de caractères brute, en particulier les étapes de traitement des caractères de contrôle. Cela permet au lecteur optique de délivrer directement au terminal informatique des chaînes de caractères exemptes d’interférences liées à la présence de caractères de contrôle. Procédé de traitement de données, mis en œuvre au sein d’un dispositif électronique de traitement de données (TERM), caractérisé en ce que le procédé comprend au moins une itération des étapes suivantes : - obtention (S02) d'une chaîne de caractères d’entrée (READ_STR) issue de la lecture d’au moins un code-barres par un appareil optique ; - stockage (S04) de la chaîne de caractères d’entrée (READ_STR) dans une mémoire-tampon (DB) accessible à une application de traitement (APP) exécutée par un navigateur (WB) au sein du dispositif électronique (TERM) ; - analyse syntaxique (S06) de la chaîne de caractères d’entrée (READ_STR) par l’application (APP), l’analyse syntaxique (S06) comprenant une détermination (S60) en continu de la présence d’un préfixe (PREFIX) de forme prédéterminée au début de la chaîne de caractères d’entrée (READ_STR) stockée dans la mémoire-tampon (DB) ; et - extraction (S62) d’une sous-chaîne de caractères (AIM_ID, P_STR) à partir de la chaîne de caractères d’entrée (READ_STR) à l’aide du préfixe (PREFIX) si ledit préfixe (PREFIX) est présent, sinon vidage (S64) de la mémoire tampon (DB) ; - transmission (S08) de la sous-chaîne de caractères (AIM_ID, P_STR) extraite à une application serveur (SERV). Procédé selon la revendication 1, dans lequel l’extraction (S62) de la sous-chaîne de caractères (AIM_ID, P_STR) comprend, lorsque le préfixe (PREFIX) est présent dans la chaîne de caractères d’entrée (READ_STR) : - la détermination de la présence d’un suffixe (SUFFIX) prédéterminé dans la chaîne de caractères d’entrée (READ_STR) ; et - la détermination de la sous-chaîne de caractères (AIM_ID, P_STR) à l’aide du préfixe (PREFIX) et du suffixe (SUFFIX). Procédé selon la revendication 1 ou 2, dans lequel l’obtention (S02) de la chaîne de caractères d’entrée (READ_STR) comprend : - l’acquisition (S20) d’une chaîne de caractères brute (RAW_STR) issue de la lecture du code-barres (BC) par l’appareil optique (BCR), - l’identification (S22), au sein de la chaîne de caractères brute (RAW_STR), de la présence de caractères de contrôle (C_CHAR) appartenant à un groupe de caractères de contrôle prédéterminé, - le remplacement (S24), au sein de la chaîne de caractères brute (RAW_STR), de chacun des caractères de contrôle (C_CHAR) identifié par une chaîne de caractères de substitution (SUB_STR) prédéterminée respective, délivrant une chaîne de caractères traitée (P_STR), - la restitution (S28) de la chaîne de caractères d’entrée (READ_STR) à partir de la chaîne de caractères traitée (P_STR). Procédé selon la revendication 3, dans lequel la chaîne de caractères de substitution (SUB_STR) d’un caractère de contrôle (C_CHAR) comprend la concaténation, dans l’ordre, d’un préfixe de caractère de contrôle (C_PREFIX), d’une chaîne de caractères (C_STR) représentative du caractère de contrôle (C_CHAR) et d’un suffixe de caractère de contrôle (C_SUFFIX), le préfixe de caractère de contrôle (C_PREFIX) et le suffixe de caractère de contrôle (C_SUFFIX) étant communs aux caractères de contrôle (C_CHAR). Procédé selon la revendication 3 ou 4, dans lequel la restitution (026) de la chaîne de caractères d’entrée (READ_STR) comprend : - L’obtention (026) d’une chaîne de caractères de symbologie (AIM_ID) représentative de la symbologie (SYM) du code-barres (BC) dont la chaîne de caractères brute (RAW_STR) est issue ; - La restitution (028), en tant que chaîne de caractères d’entrée (READ_STR), de la concaténation, dans l’ordre, du préfixe (PREFIX), de la chaîne de caractères de symbologie (AIM_ID), de la chaîne de caractères traitée (P_STR) et du suffixe (SUFFIX). Procédé selon l’une des revendications précédentes, dans lequel le stockage (S04) de la chaîne de caractères d’entrée (READ_STR) dans la mémoire-tampon (DB) comprend, pour chaque caractère lu (READ_CHAR) de la chaîne de caractères d’entrée (READ_STR) : - émulation d’une frappe clavier (KeyboardEvent) représentative du dit caractère lu (READ_CHAR) ; et - inscription dans la mémoire tampon (DB) du caractère lu (READ_CHAR) à partir de la frappe clavier (KeyboardEvent) émulée. Procédé selon la revendication 6, dans lequel on ignore l’inscription du caractère lu (READ_CHAR) si la frappe clavier (KeyboardEvent) appartient à un groupe d’évènements prédéterminé. Procédé selon la revendication 6 ou 7, dans lequel l’inscription du caractère lu (READ_CHAR) dans la mémoire tampon (DB) comprend le vidage de la mémoire tampon (DB) avant l’inscription effective du caractère lu (READ_CHAR) si la durée entre la frappe clavier (KeyboardEvent) et une frappe clavier précédente excède un seuil prédéterminé. Procédé selon la revendication 8, dans lequel le seuil prédéterminé est égal à environ 500 ms. Procédé selon l’une des revendications précédentes, dans lequel la transmission (S08) de la sous-chaîne de caractères (AIM_ID, P_STR) à l’application serveur (SERV) comprend : - la détermination de la présence, au sein de la sous-chaîne de caractères (AIM_ID, P_STR), d’une chaîne de caractères de symbologie (AIM_ID) représentative de la symbologie du code-barres (BC) dont est tirée la sous-chaîne de caractères (AIM_ID), - l’extraction d’une chaîne de caractères utile (P_STR) à partir de la sous-chaîne de caractères (AIM_ID, P_STR) et de la chaîne de caractères de symbologie (AIM_ID) lorsque présente. Procédé selon la revendication 10, dans lequel la transmission (S08) d’une sous-chaîne de caractères courante comprend, si la sous-chaîne de caractères (AIM_ID, P_STR) courante est dépourvue d’une chaîne de caractères de symbologie (AIM_ID) : - l’obtention d’une sous-chaîne de caractères précédente, transmise à l’itération précédente, et - si ladite sous-chaîne de caractères précédente comporte une chaîne de caractères de symbologie relative à un format de code-barres du type identifiant un dispositif donné, association de la sous-chaîne de caractères courante à la sous-chaîne de caractères précédente. Procédé selon l’une des revendications 10 ou 11, dans lequel la détermination de la présence de la chaîne de caractères de symbologie (AIM_ID) et l’extraction de la chaîne de caractères utile (P_STR) sont réalisées au sein du serveur (SERV). Dispositif électronique de traitement de données (TERM), caractérisé en ce qu’il comprend : - des moyens pour recevoir une chaîne de caractères d’entrée (READ_STR) issue de la lecture d’au moins un code-barres par un appareil optique ; - des moyens pour stocker ladite chaîne de caractères d’entrée (READ_STR) dans une mémoire tampon (DB) accessible à une application de traitement (APP) exécutée par un navigateur (WB) au sein du dispositif électronique (TERM) ; - des moyens d’analyse syntaxique par l’application (APP) de la chaîne de caractères d’entrée (READ_STR) comprenant des moyens de détermination en continu de la présence d’un préfixe (PREFIX) de forme prédéterminée au début de la chaîne de caractères d’entrée (READ_STR) stockée dans la mémoire-tampon (DB) ; - des moyens d’extraction d’une sous-chaîne de caractères (AIM_ID, P_STR) à partir de la chaîne de caractères d’entrée (READ_STR) à l’aide du préfixe (PREFIX) si ledit préfixe (PREFIX) est présent, et des moyens de vidage de la mémoire tampon (DB) sinon ; et - des moyens de transmission de la sous-chaîne de caractères (AIM_ID, P_STR) extraite à une application serveur (SERV). Produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé de communication selon l’une des revendications 1 à 12, lorsqu’il est exécuté par un processeur.