FR3083891A1 - Procede d’echanges de donnees en un serveur et une pluralite de terminaux connectes clients - Google Patents

Abstract

L'invention concerne un procédé d'échanges de données en un serveur et une pluralité de terminaux connectés clients. Ledit procédé comporte a) une étape initiale de définition d'un nouveau formulaire Fx b) des étapes d'enregistrement d'un nouvel utilisateur U consistant à établir une session de communication entre un terminal léger et le serveur et à enregistrer sur le serveur un jeton numérique Tu associé audit utilisateur U c) des étapes de création de formulaires numériques personnalisés Fx,u d) des étapes de renseignement par un utilisateur U dudit formulaire personnalisé Fx,u

Description

PROCEDE D'ECHANGES DE DONNEES EN UN SERVEUR ET UNE PLURALITE DE TERMINAUX CONNECTES CLIENTS

Domaine de 1'invention

La présente invention concerne le domaine des portails et procédés de traitements de formulaires en ligne et plus particulièrement d'échanges d'informations numériques entre un commanditaire public ou privé et des soumissionnaires, dans le cadre d'un appel d'offre, par l'intermédiaire d'une plateforme opérée par le commanditaire, à laquelle les soumissionnaires peuvent accéder pour échanger des données numériques via un réseau informatique, notamment Internet, par l'intermédiaire d'un terminal client équipé d'un navigateur.

Le commanditaire propose aux soumissionnaires de remplir des formulaires numériques pour réduire les coûts de fonctionnement et les délais des traitements administratifs des appels d'offre et pour alléger la gestion de la réponse par les soumissionnaires.

Pendant un appel d'offre, le soumissionnaire peut être conduit à modifier le formulaire, pour tenir compte d'évolution de ses besoins, ou du signalement d'incohérences relevées par un soumissionnaire.

De même, un soumissionnaire peut décider de modifier sa réponse.

La plateforme doit ainsi gérer en toute sécurité de multiples versions en garantissant qu'à l'issue de l'appel d'offre, la version analysée par le soumissionnaire prennent en compte les dernières versions de chacune des parties, en évitant autant que possible les lourdeurs occasionnées par une reformulation intégrale des réponses.

De plus, il est souhaitable que les soumissionnaires puissent utiliser n'importe quel équipement informatique, système d'exploitation et navigateur, sans avoir à installer une nouvelle application informatique, nécessitant souvent un accord préalable d'un responsable de la sécurité informatique voire un audit du code logiciel de l'application à installer.

Etat de la technique

On connaît dans l'état de la technique le brevet français FR2973534 décrivant un procédé d'optimisation de recherche accessible à un utilisateur d'au moins un service web SOAP-WSDL, à travers un système informatique pouvant accéder à une base de données relationnelle et au service web SOAP-WSDL concerné. L'utilisateur définit une requête sur des données accessibles par ce service web SOAP- WSDL.

Le procédé utilise des règles d'écriture préalablement définies, permettant d'exprimer la requête à effectuer, et comporte des étapes suivantes :

- de validation des paramètres d'entrée du procédé constitués d'une part de ou des adresse(s) Internet permettant d'accéder au(x) document(s) WSDL du ou des service(s) web,

- de création de tables dans une base de données relationnelle,

- construction d'une méta-requête SQL impliquant à la fois l'appel à la ou les méthode(s) du ou des service(s) web (SOAP), ainsi que les tables construites précédemment (SQL),

- présentation à l'utilisateur de la requête afin qu'il définisse ses paramètres d'entrée ainsi que les opérations qu'il souhaite réaliser sur les données retournées ; puis validation de cette requête,

- exécution d'une ou plusieurs requête(s) SOAP à effectuer sur le ou les service(s) web,

- récupération de la ou des réponse(s) du ou de(s) service(s) web et de stockage de cette ou ces réponse(s) dans les tables construites précédemment,

- exécution d'une requête SQL à effectuer sur les tables construites précédemment,

- création de la réponse du procédé,

- destruction des tables construites précédemment.

Les règles d'écriture permettant d'exprimer la requête à effectuer utilisent le langage JSON (JavaScript Oriented Notation).

Une autre solution est décrite dans le brevet français FR3027131 décrivant un procédé d'extraction de données standardisées caractérisé en qu'il comporte les étapes suivantes

- lecture d'une requête d'extraction préenregistrée comportant des instructions de nommage explicite de colonnes ;

lecture d'une source de données selon une association de la requête préenregistrée à ladite source de données ;

- exécution de la requête d'extraction lue via une connexion à la source de données lue pour produire un jeu de données extraites ;

- production, à partir du jeu de données extraites d'un message de données selon les noms des données du jeu de données extraites.

On connaît aussi le brevet français FR2923337 décrivant un procédé et un système d'échange de données entre un premier serveur hébergé dans une entité électronique liée à un appareil programmable et un deuxième serveur distant. Lesdits premier et deuxième serveurs sont chacun adressables individuellement par l'appareil programmable au moyen d'adresses cibles respectives et le procédé comprend les étapes suivantes réception par 1'appareil programmable d ' une réponse à une première requête, ladite réponse comprenant les données et une desdites adresses cibles ;

- exécution de ladite réponse par un navigateur mise en œuvre sur 1'appareil programmable de manière à entrainer l'émission des données vers ladite adresse cible.

Inconvénients de l'art antérieur

Les solutions de l'art antérieur présentent plusieurs inconvénients. En premier lieu, la taille des tables est limitée par les principes de fonctionnement des navigateurs. Le nombre de lignes est généralement plafonné, et il n'est donc pas possible de traiter des contenus dont le contenu se traduit par un nombre de ligne dépassant le plafond des outils logiciels courants.

Pour un fichier HTML, la hauteur maximale du bloc de texte est limitée, ainsi que son contenu. Pour des très grands formulaires, le contenu dépasse les limites techniques et empêche l'utilisation des solutions standard.

Pour permettre un fonctionnement avec un client léger (c'est-à-dire un ordinateur de bureau voire une tablette, exécutant une application logicielle constituée simplement par un navigateur universel), les solutions de l'art antérieur imposent une limite technique à la taille du formulaire transmis par la plateforme au client, ainsi que des temps de traitement important sur le terminal client, lorsque la taille du formulaire est importante.

Solution apportée par l'invention

Afin de remédier à ces inconvénients, l'invention concerne selon son acception la plus générale un procédé d'échanges de données en un serveur et une pluralité de terminaux connectés clients, caractérisé en ce qu'il comporte

a) une étape initiale de définition d'un nouveau formulaire F_x consistant à enregistrer sur le serveur :

• un objet numérique O_x au format JSON comprenant :

o Une pluralité d ' identifiants uniques I_x,i associés chacun à un contenu numérique élémentaire L_x,i et à un numéro d'ordre R_x,i o Une pluralité de contenus constitués d'éléments numériques L_x,i comprenant une désignation, une description, un état E _x,i,₀ originel, un statut S _x,i,₀ originel • un fichier contenant un code JavaScript C_x apte à commander, lors de son exécution par un navigateur, la fabrication d'une page constituée par une partie au moins desdits éléments numériques Li ordonnés en fonction de leur numéro d'ordre Ri

b) des étapes d'enregistrement d'un nouvel utilisateur U consistant à établir une session de communication entre un terminal léger et le serveur et à enregistrer sur le serveur un jeton numérique T_u associé audit utilisateur U c ) des étapes de création de formulaires numériques personnalisés F_x,_u consistant à enregistrer une duplication 0_x,_u de l'objet numérique O_x,₀ originel en relation avec un identifiant dudit utilisateur U et à créer un code personnalisé C_x,_u pour ledit utilisateur U en fonction dudit jeton numérique T_u et des fonctionnalités accessibles par ledit utilisateur U

d) des étapes de renseignement par un utilisateur U dudit formulaire personnalisés F_x,_u consistant à :

• télécharger l'objet numérique personnalisé 0_x,_u dudit serveur dans la mémoire dudit terminal client léger • exécuter le code JavaScript personnalisé C_x,_u sur le terminal client pour calculer une page visualisable • générer et afficher une page visualisable sur l'écran dudit terminal • saisir les modifications dans les éléments numériques L_u,_x,i et afficher sur le terminal client une page visualisée modifiée o lors de la validation desdites modifications, exécuter le code personnalisé C_x,_u pour calculer, pour les éléments numériques LM_u,_x,i modifiés, un nouveau contenu comprenant le contenu originel ainsi qu'une désignation, une description, un état E _u,_x,i,j nouveau où j désigne le rang de la modification, un statut nouveau S_u,_x,i,j et optionnellement un delta correspondant à la différence entre l'état E _u,_x,i,j et un état antérieur E _u,_x,i,j__n o et transférer et enregistrer sur le serveur, en relation avec l'utilisateur U, lesdits éléments numériques modifiés LM_u,_x,i.

De préférence, ladite étape de génération de la page visualisable comporte l'exécution du code C_x,_u pour calculer la hauteur des éléments LM_u,_x,i, la taille de la fenêtre de visualisation dudit terminal client et pour sélection un sousensemble d'éléments LM_u,_x,i en fonction de ladite taille de la fenêtre de visualisation et de la position d'un marqueur numérique de défilement.

Avantageusement, ledit procédé comporte en outre, après ladite validation des modifications, une étape d'horodatage des éléments numériques modifiés LM_u,_x,i.

De préférence, ladite étape d'horodatage comporte le calcul de condensais [hash] desdits éléments numériques modifiés LM_u,_x,i et l'enregistrement horodaté desdits condensais.

Selon un mode de réalisation préféré, ladite étape d'horodatage comporte le calcul de condensats [hash] desdits éléments numériques modifiés LM_u,_x,i et l'injection dans une chaîne de blocs [blockchain].

Description détaillée d'un exemple de réalisation

La présente invention sera mieux comprise à la lecture de la description qui suit, se référant à un exemple non limitatif de réalisation illustré par le dessin annexé où :

- la figure 1 représente une vue schématique d'un système informatique pour la mise en œuvre de l'invention

Architecture informatique

L'architecture informatique comprend un serveur (1) associé à une unité de stockage (2) pour l'enregistrement d'une base de données par l'intermédiaire d'un pilote (3).

Le serveur (1) échange par ailleurs des données via un réseau tel qu'internet avec des terminaux clients (4, 5) comportant une application de navigation—

L'invention permet d'utiliser des terminaux légers, c'est-à-dire des ordinateurs ou tablettes courantes destinées à des applications bureautiques, ne nécessitant aucun périphérique ni ressource matérielle additionnelle, et exécutant des applications légères, telles qu'un système d'exploitation standard et un navigateur universel, sans nécessiter de chargement d'une application spécifique associée aux fonctionnalités du serveur (2).

Procédure d'enregistrement d'un utilisateur

Pour l'enregistrement d'un nouvel utilisateur, ce dernier se connecte au serveur (2) par l'intermédiaire de son terminal (4) et d'un navigateur ouvrant la page d'accueil du serveur (1).

Cette page d'accueil propose de manière connue une procédure d'inscription par une interface présentant un formulaire de saisie d'informations d'identification de l'utilisateur telles que son nom, ses coordonnées, ses fonctions ainsi qu'une proposition de mot de passe. Ces données sont transmises au serveur qui calcule un jeton (Token) T_u enregistré dans la base de données (2) en liaison avec les informations transmises par l'utilisateur. Ce jeton est également téléchargé dans une mémoire du terminal (4) de l'utilisateur. Optionnellement, cette procédure d'enregistrement comporte aussi la création de comptes secondaires correspondant à d'autres utilisateurs appartenant à la même entité, et disposant de droits restreints, par exemple seulement la consultation, ou seulement la modification de certaines rubriques. Dans ce cas, chaque utilisateur délégué dispose de son propre jeton.

Procédure de création d'un nouveau formulaire

Lorsque l'opérateur de la plateforme (10), par exemple un commanditaire préparant une nouvelle consultation de type « appel d'offres », il crée un nouveau formulaire F_x dont la structure est commune à tous les formulaires F.

Ce formulaire est un objet numérique divisé en objets éléments d'information correspondant typiquement à une ligne d'information.

Dans un appel d'offres, une ligne correspondra à une prestation élémentaire, et présentera une structure de type « identifiant / désignation / description / unité / quantité / prix unitaire / état / observations ».

Ces prestations élémentaires sont habituellement regroupées en sous-ensembles cohérents appelés « lots ». Un lot comprend une succession, généralement ordonnée, d'objets numériques élémentaires.

Cette étape se traduit techniquement par l'élaboration d'un objet numérique 0_x au format JSON comprenant : o Une pluralité d ' identifiants uniques I_x,i associés chacun à un contenu numérique élémentaire L_Xji et à un numéro d'ordre R_x,i o Une pluralité de contenus constitués d'éléments numériques L_Xji comprenant une désignation, une description, un état E _x,i,₀ originel, un statut S _x,i,₀ originel.

Ces objets numériques sont élaborés à l'aide d'outils éditeurs et d'une interface graphique facilitant la saisie des informations.

Cette étape initiale comprend aussi l'établissement d'un fichier contenant un code JavaScript C_x apte à commander, lors de son exécution par un navigateur, la fabrication d'une page constituée par une partie au moins desdits éléments numériques Li ordonnés en fonction de leur numéro d'ordre Ri. A cet effet, le serveur utilise un code prédéfini paramétrable à l'aide d'un éditeur de code facilitant la personnalisation du code prédéfini.

Cet ensemble d'objets élémentaires L_Xji et le code C_x associé définissent techniquement la « matrice originelle » du formulaire F.

On enregistre ensuite dans la base de données (2), pour chaque utilisateur U souhaitant répondre à l'appel d'offre, un formule F_u,_x personnalisé, associé à l'utilisateur U.

A cet effet, un utilisateur déjà enregistré ou un utilisateur venant de procéder à l'enregistrement accède sur la page d'accueil à une fonction de sélection d'un formulaire F_x et de déclaration par la validation de la sélection.

Cette validation déclenche un traitement par le serveur (2) d'un formulaire numérique personnalisé F_x,_u consistant à enregistrer une duplication O_x,_u de l'objet numérique O_x,o originel en relation avec un identifiant dudit utilisateur U et à créer un code personnalisé C_x,_u pour ledit utilisateur U en fonction dudit jeton numérique T_u et des fonctionnalités accessibles par ledit utilisateur U.

Modification du formulaire F_x,_u

La modification peut intervenir à l'initiative du commanditaire ou du soumissionnaire.

Le commanditaire peut modifier une ou plusieurs lignes L_x,i du formulaire F_x.

Dans ce cas, le serveur (2) télécharge la matrice du formulaire F_à,_x et procède aux modifications, puis exécute un traitement consistant à calculer, pour chaque F_x,_u :

• pour les éléments numériques LM_u,_x,i modifiés ou nouveau, un nouveau contenu comprenant le contenu originel ainsi qu'une désignation, une description, un état E _u,_x,i,j nouveau où j désigne le rang de la modification, un statut nouveau S_u,_x,i,j et optionnellement un delta correspondant à la différence entre l'état E _u,_x,i,j et un état antérieur E _u,_x,i,j__n • transférer et enregistrer sur le serveur, en relation avec l'utilisateur U, lesdits éléments numériques modifiés LM_u,_x,i • notifier automatiquement, à chacun des utilisateurs U, un message l'informant qu'une modification du formulaire F_x est intervenue.

Dans le cas où un utilisateur U souhaite renseigner un formulaire F_x,_u originel, ou modifier une version précédemment enregistrée, il télécharge depuis le serveur (2) sur le terminal (4, 5) le formulaire F_x,_u enregistré dans la base de données (2) et réalise des traitements consistant à :

• télécharger l'objet numérique personnalisé 0_x,_u dudit serveur dans la mémoire dudit terminal client léger • exécuter le code JavaScript personnalisé C_x,_u sur le terminal client pour calculer une page visualisable • générer et afficher une page visualisable sur l'écran dudit terminal • saisir les modifications dans les éléments numériques L_u,_x,i et afficher sur le terminal client une page modifiée o lors de la validation desdites modifications, exécuter le code personnalisé C_x,_u pour calculer, pour les éléments numériques LM_u,_x,i modifiés, un nouveau contenu comprenant le contenu originel ainsi qu'une désignation, une description, un état E _u,_x,i,j nouveau où j désigne le rang de la modification, un statut nouveau S_u,_x,i,j et optionnellement un delta correspondant à la différence entre l'état E _u,_x,i,j et un état antérieur E _u,_x,i,j__n o et transférer et enregistrer sur le serveur, en relation avec l'utilisateur U, ledit éléments numériques modifiés LM_u,_x,i.

Ajustage de l'affichage

Le navigateur exécute, lors de la commande d'affichage d'un formulaire F_u,_x un traitement commandé par une partie du code C_x,_u consistant à :

- ordonnancer les éléments L_u,_x,i en fonction du rang R_u,_x,i

- calculer la hauteur de chaque éléments L_u,_x,i

- déterminer à partir des données du moteur de virtualisation la position du marqueur de position (par exemple position du bouton de « scrolling ») et de la taille de la fenêtre

- calculer le sous-ensemble d'éléments L_u,_x,i compatible avec ces données

- affichage du sous-ensemble d'éléments sélectionnés.

Claims (5)

1. Revendications

   1 — Procédé d'échanges de données en un serveur et une pluralité de terminaux connectés clients, caractérisé en ce gu'il comporte

   a) une étape initiale de définition d'un nouveau formulaire F_x consistant à enregistrer sur le serveur :

   • un objet numérique 0_x au format JSON comprenant :

   o Une pluralité d ' identifiants uniques I_x,i associés chacun à un contenu numérique élémentaire L_x,i et à un numéro d'ordre R_x,i o Une pluralité de contenus constitués d'éléments numériques L_x,i comprenant une désignation, une description, un état E _x,i,₀ originel, un statut S _x,i,₀ originel • un fichier contenant un code JavaScript C_x apte à commander, lors de son exécution par un navigateur, la fabrication d'un page constituée par une partie au moins desdits éléments numériques Li ordonnés en fonction de leur numéro d'ordre Ri

   b) des étapes d'enregistrement d'un nouvel utilisateur U consistant à établir une session de communication entre un terminal léger et le serveur et à enregistrer sur le serveur un jeton numérique T_u associé audit utilisateur U c ) des étapes de création de formulaires numériques personnalisés F_x,_u consistant à enregistrer une duplication 0_x,_u de l'objet numérique O_x,₀ originel en relation avec un identifiant dudit utilisateur U et à créer un code personnalisé C_x,_u pour ledit utilisateur U en fonction dudit jeton numérique T_u et des fonctionnalités accessibles par ledit utilisateur U

   d) des étapes de renseignement par un utilisateur U dudit formulaire personnalisé F_x,_u consistant à :

   • télécharger l'objet numérique personnalisé 0_x,_u dudit serveur dans la mémoire dudit terminal client léger • exécuter le code JavaScript personnalisé C_x,_u sur le terminal client pour calculer une page visualisable • générer et afficher une page visualisable sur l'écran dudit terminal • saisir les modifications dans les éléments numériques L_u,_x,i et afficher sur le terminal client une page visualisée modifiée o lors de la validation desdites modifications, exécuter le code personnalisé C_x,_u pour calculer, pour les éléments numériques LM_u,_x,i modifiés, un nouveau contenu comprenant le contenu originel ainsi qu'une désignation, une description, un état E _u,_x,i,j nouveau où j désigne le rang de la modification, un statut nouveau S_u,_x,i,j et optionnellement un delta correspondant à la différence entre l'état E _u,_x,i,j et un état antérieur E _u,_x,i,j__n o et transférer et enregistrer sur le serveur, en relation avec l'utilisateur U, lesdits éléments numériques modifiés LM_u,_x,i.
2. 2 — Procédé d'échanges de données en un serveur et une pluralité de terminaux connectés clients selon la revendication 1, caractérisé en ce que ladite étape de génération de la page visualisable comporte l'exécution du code C_x,_u pour calculer la hauteur des éléments LM_u,_x,i, la taille de la fenêtre de visualisation dudit terminal client et pour sélectionner un sous-ensemble d'éléments LM_u,_x,i en fonction de ladite taille de la fenêtre de visualisation et de la position d'un marqueur numérique de défilement.
3. 3 — Procédé d'échanges de données en un serveur et une pluralité de terminaux connectés clients selon la revendication 1, caractérisé en ce qu'il comporte en outre, après ladite validation des modifications, une étape d'horodatage des éléments numériques modifiés LM_u,_x,i.
4. 4 — Procédé d'échanges de données en un serveur et une pluralité de terminaux connectés clients selon la revendication précédente, caractérisé en ce que ladite étape
5. 5 d'horodatage comporte le calcul de condensais [hash] desdits éléments numériques modifiés LM_u,_x,i et l'enregistrement horodaté desdits condensais.

   5 — Procédé d'échanges de données en un serveur et 10 une pluralité de terminaux connectés clients selon la revendication 3, caractérisé en ce que ladite étape d'horodatage comporte le calcul de condensats [hash] desdits éléments numériques modifiés LM_u,_x,i—