FR3011661A1 - Procede de dematerialisation d'une demarche - Google Patents

Abstract

Procédé de dématérialisation d'une démarche administrative comportant les étapes suivantes : - Attribution d'un identifiant à la démarche dans une base de données de démarche, - Création d'au moins un formulaire numérique associé à la démarche via l'identifiant de la démarche le formulaire comportant au moins un identifiant de formulaire, - Définition d'au moins un contrôle comportant : - Un identifiant de contrôle unique pour la démarche, -Association du au moins un contrôle au formulaire - Définition d'au moins un flux de données associé à la démarche, le flux de données comportant au moins un identifiant d'un contrôle précédemment défini et un identifiant de destinataire, - Définition d'une règle d'émission associée à la démarche, règle d'émission dont le déclenchement équivaut à l'émission d'un message vers un destinataire et comportant : - Une condition de déclenchement, - Un identifiant d'un flux précédemment défini, - Publication de la démarche, - Instanciation de la démarche pour un utilisateur identifié par un identifiant utilisateur, l'instanciation étant l'enregistrement dans une base de données d'instances de n-uplets comportant au moins les données suivantes : - Identifiant d'utilisateur, - Identifiant de démarche - Identifiant de contrôle - Valeur.

Description

0 1 16 6 1 1 Procédé de dématérialisation d'une démarche DOMAINE TECHNIQUE DE L'INVENTION [0001] L'invention se rapporte à la dématérialisation de démarche et plus 5 précisément à la dématérialisation de documents liés à des démarches administratives. ETAT DE LA TECHNIQUE ANTERIEURE [0002] II est courant de devoir s'adresser à une administration ou à un 10 organisme afin de satisfaire à une démarche administrative impérative : obtention d'un document d'identité, déclaration de revenus... [0003] Dans ce cas il faut en général constituer un dossier et se rendre sur place, à un guichet de l'administration ou de l'organisme, en espérant ne rien avoir oublié. 15 [0004] Sur place il faut alors patienter, parfois longuement, et revenir s'il manque un document. [0005] Cela pose donc plusieurs problèmes d'ordre technique : - Trouver du temps, - Gérer des files d'attentes 20 - Matérialiser des documents et être capable de les conserver. [0006] Dans l'état de la technique il est connu des sites web, plus ou moins dynamiques, qui permettent de prendre en charge une partie de la dématérialisation. Mais dans ce cas, il y a autant de site web à créer que de démarches. Cela revient à écrire des pages html et à gérer leur enchaînement. De 25 plus ces sites utilisent la notion de session pour préserver les données. Cela signifie qu'une fois le navigateur fermé, tout est effacé, ce qui ne laisse pas beaucoup de place pour les erreurs et qui impose de tout avoir à sa disposition lorsque l'on commence la démarche. 30 EXPOSE DE L'INVENTION [0007] L'invention vise à remédier à tous les inconvénients de l'état de la technique identifiés ci-dessus, et notamment à proposer des moyens pour permettre de dématérialiser, via un réseau de type Internet, des démarches administratives. Une démarche revient à la saisie d'un ou plusieurs formulaires qui seront soumis automatiquement au bon interlocuteur du bon organisme ou administration. D'autre part les données sont persistées un temps raisonnable pour permettre à un utilisateur de compléter une démarche déjà entamée. [0008] Dans ce dessein, un aspect de l'invention se rapporte à: - Un procédé de dématérialisation d'une démarche administrative comportant les étapes suivantes : - Attribution d'un identifiant à la démarche dans une base de données de démarche, - Création d'au moins un formulaire numérique associé à la démarche via l'identifiant de la démarche le formulaire comportant au moins un identifiant de formulaire, - Définition d'au moins un contrôle comportant : - Un identifiant de contrôle unique pour la démarche, -Association du au moins un contrôle au formulaire - Définition d'au moins un flux de données associé à la démarche, le flux de données comportant au moins un identifiant d'un contrôle précédemment défini et un identifiant de destinataire, - Définition d'une règle d'émission associée à la démarche, règle d'émission dont le déclenchement équivaut à l'émission d'un message vers un destinataire et comportant : - Une condition de déclenchement, - Un identifiant d'un flux précédemment défini, - Publication de la démarche, - Instanciation de la démarche pour un utilisateur identifié par un identifiant utilisateur, l'instanciation étant l'enregistrement dans une base de données d'instances de n-uplets comportant au moins les données suivantes : - Identifiant d'utilisateur, - Identifiant de démarche - Identifiant de contrôle - Valeur. [0009] Outre les caractéristiques principales qui viennent d'être mentionnées dans le paragraphe précédent, le procédé/dispositif selon l'invention peut présenter une ou plusieurs caractéristiques complémentaires parmi les suivantes, considérées individuellement ou selon les combinaisons techniquement possibles : - l'identifiant de démarche est complexe et comporte : - Un identifiant, - Un numéro de version. - l'instanciation est toujours réalisée selon la version la plus récente. - la démarche comporte des dates (1052, 1053) de validité. - une instance de la démarche ne peut être créée que durant la validité de la démarche. - une instance de la démarche ne peut être validée que durant la validité de la démarche. - l'étape d'instanciation comporte une étape de production d'un identifiant d'instance de démarche, ledit identifiant étant non prédictible. - une condition de déclenchement porte sur une valeur d'un contrôle. - une condition de déclenchement est une validation d'un formulaire. - la démarche comportant plusieurs formulaires elle comporte aussi au moins une règle d'enchaînement définissant un ordre d'enchaînement des formulaires. - une des revendications précédentes caractérisé en ce qu'une le procédé comporte une étape de vérification avant l'étape d'instanciation la vérification étant : - Est-ce qu'il existe une instance de la démarche active pour l'utilisateur : - Si oui, alors utilisation de cette instance, - Si non, alors poursuite de l'instanciation. - une instance de démarche comporte une date de création. - une instance de démarche et les données associées sont automatiquement effacées lorsqu'elles atteignent un âge prédéterminé. - un identifiant de destinataire identifie une règle de routage, - le procédé comporte une étape d'enregistrement d'un message associé à une instance de démarche, le message étant au moins consultable par l'utilisateur associé à l'instance de la démarche. - une démarche est publiée par morceau. - un morceau de démarche est validé avant d'être publié. [0010] L'invention se rapporte également à un dispositif de stockage numérique comportant un fichier correspondant à des codes instructions mettant en oeuvre le procédé selon une combinaison des caractéristiques précédentes. [0011] L'invention se rapporte également à un dispositif mettant en oeuvre un procédé selon une combinaison des revendications précédentes. BREVE DESCRIPTION DES FIGURES [0012] D'autres caractéristiques et avantages de l'invention ressortiront à la lecture de la description qui suit, en référence aux figures annexées, qui illustrent : - la figure 1, une illustration de moyen permettant la mise en oeuvre de l'invention ; - la figure 2, une illustration d'étapes du procédé selon l'invention. [0013] Pour plus de clarté, les éléments identiques ou similaires sont repérés par des signes de référence identiques sur l'ensemble des figures. [0014] L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Celles-ci sont présentées à titre indicatif et nullement limitatif de l'invention. DESCRIPTION DETAILLEE D'UN MODE DE REALISATION [0015] Serveur est un terme usité dans le domaine de l'invention. Un serveur est aussi un ordinateur en ce sens qu'il en a toutes les caractéristiques. On considère dans ce document que les termes ordinateur et serveur sont équivalents. [0016] Pour la description du procédé on attribue des étapes ou des actions à des machines de type ordinateur. Une telle machine comporte au moins un microprocesseur et une mémoire de stockage. La mémoire de stockage permet d'enregistrer des codes instructions dont l'interprétation permet la mise en oeuvre des étapes ou des actions. Donc, lorsque l'on attribue une action à une machine, 3 0 1 1 6 6 1 5 celle-ci est en fait réalisée par un microprocesseur de la machine interprétant des codes instructions enregistrés dans une mémoire de la machine. [0017] Pour la description du procédé on attribue des communications à des machines de type ordinateur. Ces communications sont réalisées via de échanges 5 de messages selon un protocole prédéterminé mis en oeuvre au moins par une carte réseau, câblée ou sans câble. Chaque machine impliquée dans la communication comporte sa carte réseau connecté, via un bus, à un microprocesseur de la machine. Cela permet au microprocesseur de prendre en compte les messages reçus et d'en émettre. Les cartes réseau sont par ailleurs 10 connectées à un réseau, par exemple de type Ethernet. Il y a d'autres types de réseaux, comme les réseaux à fibre optique, les réseaux InfinBand, ou les réseaux sans fil. [0018] Lorsque l'on dit qu'une action est effectuée par un système d'exploitation, une application, un processus, ou une zone de code instructions, 15 cette action correspond à la mise en oeuvre, par un microprocesseur, de codes instructions correspondant, comme décrit aux paragraphes précédents. [0019] Par code instruction on entend aussi bien des codes binaires natifs, que des codes intermédiaires interprétés par une machine virtuelle, par exemple Java, ou des scripts interprétés par des moteurs d'interprétations, par exemple Python, 20 PERL,... la liste n'est pas exhaustive. Cela inclut les instructions intégrées du système d'exploitation. [0020] A la figure 1 est illustré un premier serveur 1000 de démarches comportant au moins : - Un microprocesseur 1010, 25 - Une interface 1020 réseau, - Des moyens 1030 de stockage, par exemple un disque dur. [0021] L'homme du métier comprendra aisément qu'il s'agit d'une description pratique d'un moyen de stockage. Dans la pratique le moyen de stockage peut être composé de plusieurs composants physiques, disques durs selon plusieurs 30 connectiques (IDE, SCSI, eSCSI, ATA, SATA, eSATA, USB,...) et plusieurs configurations (JBOD, RAIDO, RAID1, RAID5,...), disque mémoire,... la liste n'est pas exhaustive. Ces remarques s'appliquent pour tous les ordinateurs décrits. [0022] Les éléments du serveur 1000 de démarches sont interconnectés par un bus 1040. Les éléments du serveur 1000 de démarches interconnectés par le bus 1040 sont : - Le microprocesseur 1010, - L'interface 1020 réseau, - Les moyens 1030 de stockage. [0023] Les moyens 1030 de stockage comportent plusieurs zones : - Une zone 1032 de données - Une zone 1031 de programmes correspondant, entre autre, à des codes instructions correspondant à la mise en oeuvre du procédé selon l'invention. [0024] Pour les besoins de la description on décrit que la zone 1032 de données comporte deux bases de données : - Une base 1033 de données de démarches - Une base 1034 d'instance de démarches. Dans la pratique il pourrait ne s'agir que d'une seule et même base de données. Il est ici commode, pour des raisons de clarté de décrire deux bases de données. Une base de données est ici décrite comme un ensemble de tables et de relations. Une table comporte des lignes, ou enregistrement, chaque ligne étant divisé en colonne ou champ. Une relation permet de lier, mettre en relation, des enregistrements. Il s'agit d'une description d'un mode d'implémentation relationnel d'une base de données, mais l'invention n'est pas limitée à ce type de base de données. Elle est compatible avec les bases de données objets, hiérarchique ou NoSql pour ne citer que les systèmes de base de données les plus connus. [0025] La base 1033 de données de démarches comporte : - Une table 1050 de démarches comportant au moins : - Une colonne 1051 identifiant de démarche - Une table 1060 de formulaires comportant au moins : - Une colonne 1061 identifiant de formulaire - Une colonne 1062 identifiant de démarche permettant de rattacher un formulaire à une démarche - Une table 1070 de contrôles comportant au moins : - Une colonne 1071 identifiant de contrôle - Une colonne 1072 identifiant de formulaire permettant de rattacher le contrôle à un formulaire. [0026] On voit ici que l'on décrit des liens 1 - N entre les tables. Dans la pratique on peut aussi avoir des liens N - N en ajoutant des tables de relations, par exemple en table qui comporterait des identifiants de démarches et des identifiants de formulaires pour permettre d'associer un formulaire à plusieurs démarches. [0027] Dans la pratique un contrôle est assimilable à une zone de saisie qui comporte un type. Les types les plus fréquents sont : texte, case à cocher, liste.

La liste n'est pas exhaustive. [0028] La figure 1 montre aussi que la base 1034 de démarche comporte aussi : - une table 1080 de flux comportant au moins : - Une colonne 1081 identifiant de flux - Une colonne 1082 identifiant de démarche - Une colonne 1083 identifiant de destinataire, par exemple un email ou un identifiant permettant de déterminer un email. [0029] Dans une variante de l'invention la base 1033 de démarches comporte aussi une table 8010 de règles de routage de flux. La table 8010 comporte .au moins : - Une colonne 8011 identifiant de règle de routage, - Une colonne 8012 règle de routage. [0030] Dans une variante de l'invention la base 1033 de démarches comporte aussi une table 8020 de composants. La table 8020 de composant comporte au moins : - Une colonne 8021 identifiant de composant, - Une colonne 8022 nature de composant. - Une colonne 8023 contenu. - Une colonne 8024 identifiant de démarche. [0031] Un composant est donc associé à une démarche. Dans une variante la table de composant peut être mise en oeuvre via la table 1070 de contrôles. Dans ce cas la table 1070 de contrôles comporterait, par exemple, une colonne de nature pour préciser la nature de l'enregistrement. L'une des natures serait contrôle, les autres natures correspondraient à des natures de composant. Dans ce cas un composant peut aussi être lié à un formulaire. [0032] Une nature de composant est, par exemple : - Thème graphique, par exemple un ensemble de feuilles de style de type CSS utilisé pour modifier l'aspect d'un formulaire, - Un service web, utilisé pour valider une saisie d'un utilisateur, - Une source de donnée utilisée pour peupler un contrôle de type sélection parmi une liste - Un fichier XSLT pour faire du filtrage et/ou une mise en forme de données, par exemple lors du traitement d'un enregistrement d'envoi. [0033] Une règle de routage est un arbre de décision, par exemple un sélecteur, qui permet de déterminer une adresse à partir de la valeur d'un contrôle. Dans cette variante la colonne 1083 identifiant de destinataire enregistre un identifiant de règle de routage. [0034] La figure 1 montre aussi que la base 1033 de démarches comporte aussi : - Une table 1090 de contenus de flux comportant au moins : - Une colonne 1091 identifiant de flux, - Une colonne 1092 identifiant de contrôle. Ici la colonne 1092 identifiant de contrôle peut être : - Un identifiant tel que l'identifiant de contrôle de la table 1070 de contrôles -composite, c'est-à-dire être la concaténation d'un identifiant de contrôle de la table 1070 de contrôles et d'un identifiant de formulaire de la table 1060 de formulaires. ^ [0035] La figure 1 montre aussi que la base 1033 de démarches comporte aussi : - Une table 2000 de règles d'envois comportant au moins : - Une colonne 2001 identifiant de règle d'envoi, - Une colonne 2002 condition de déclenchement, - Une colonne 2003 identifiant de flux, dans une variante une règle peut comporter plus d'un identifiant de flux. [0036] Pour le cas de la table 2000 de règles d'envois un lien avec une démarche est réalisé via l'identifiant de flux qui permet d'identifier un flux qui est lui lié à une démarche. Dans la pratique un tel lien, entre un flux et une démarche, pourrait être établi soit directement via une colonne de la table de règle, soit indirectement via une table de jointures spécialisée. [0037] Dans le cas de la table de règles d'envois l'identifiant de règle d'envois est structurel c'est-à-dire non nécessaire à la mise en oeuvre de l'invention. Le lien entre une règle d'envoi et un flux est réalisé via un identifiant de flux enregistré dans l'enregistrement de règle. Dans une variante on peut utiliser une table de liaison dont les enregistrements comportent un identifiant de règle et un identifiant de flux. [0038] Dans une variante de l'invention, dans un cas dans lequel une démarche comporterait plusieurs formulaires, la base 1033 de données de formulaire comporte une ou plusieurs tables permettant de définir un ordre dans lequel enchaîner les formulaires de la démarche. Ces tables supplémentaires, qui peuvent être des extensions des tables existantes, comportent, par exemple, les informations suivantes : - Premier formulaire de la démarche : identifiant du premier formulaire utilisé lors de la création d'une nouvelle instance de la démarche - Pour chaque formulaire quel est le formulaire suivant, le formulaire suivant pouvant dépendre d'une condition basée, par exemple, sur la valeur d'un contrôle du formulaire actuel que l'on quitte pour passer au formulaire suivant. [0039] La figure 1 montre aussi que la base 1034 de données d'instance de démarches comporte : - Une table 2010 d'instances de démarche comportant au moins : - Une colonne 2011 identifiant d'instance de démarche, - Une colonne 2012 identifiant d'utilisateur, - Une colonne 2009 identifiant de démarche. [0040] Dans une variante de l'invention la table 2010 d'instance de démarche comporte : - Une colonne 2013 de départ de la démarche, - Une colonne 2014 de statut de l'instance de la démarche, - [0041] Un statut d'une instance de démarche est, par exemple : - Créée : au moment de sa création, - Soumise : envoyée au destinataire ou aux destinataires, - Acceptée : le destinataire a accepté de traiter le cas car le dossier est complet - Refusée : le destinataire a refusé la démarche. - ... la liste n'est pas exhaustive. [0042] Un statut d'instance de démarche permet, au moins, de renseigner un utilisateur créateur de démarche d'un avancement de sa démarche au sein d'un organisme ou administration à laquelle il s'adresse à travers un serveur de publication. La notion de serveur de publication est décrite plus loin dans la description. [0043] La figure 1 montre aussi que la base 1034 de données d'instance de démarches comporte : - Une table 2020 de données d'instance de démarche comportant au moins : - Une colonne 2021 d'identifiant d'instance de démarche, - Une colonne 2022 d'identifiant de contrôle, - Une colonne 2023 de valeur. [0044] A partir de là, par le jeu des relations, au sens système de base de données relationnelle, il est aisé de composer une vue, à partir de la table 2010 25 d'instances de démarche et de la table 2020 de données d'instances de démarche, permettant d'exposer des n-uplets : - Identifiant d'utilisateur, - Identifiant de démarche - Identifiant de contrôle 30 - Valeur. [0045] Ici il s'agit d'un quadruplet. En général un n-uplet est une association de n valeurs. 3 0 1 1 6 6 1 11 [0046] Dans une variante de l'invention, la base 1034 de données d'instance de démarche comporte : - Une table 2030 de messages comportant au moins : - Une colonne 2031 identifiant d'instance de démarche 5 - Une colonne 2032 de message. [0047] Dans une variante de l'invention, la base 1034 de données d'instance de démarche comporte : - Une table 2040 d'envois comportant au moins : - Une colonne 2041 identifiant d'instance de démarche 10 - Une colonne 2042 de données à envoyer - Une colonne 2043 d'identifiant de flux. [0048] La figure 1 montre que, via l'interface 1020 réseau, le serveur 1000 de démarche est connecté à un réseau 2000 de type Internet ou Intranet ce qui permet à un ordinateur 3000 client d'émettre des requêtes vers le serveur 1000 de 15 démarche. [0049] Dans une variante de l'invention un identifiant d'instance de démarche est une chaîne de caractère calculée de manière à être unique et non prédictible par une personne n'ayant pas connaissance de la méthode de production. Cela permet alors d'utiliser l'identifiant d'instance de démarche pour consulter 20 directement une démarche sur le serveur de publication. Dans la mesure où le serveur de publication est un serveur http, on parle d'une url de reprise, qui inclue un identifiant d'instance de démarche. Une url de reprise permet à celui qui la connaît de reprendre, et/ou consulter, l'instance de démarche correspondant. Dans ce cas un simple compteur n'est pas adapté comme identifiant d'instance de démarche, n'importe qui pouvant interroger le serveur de publication avec un numéro au hasard. Autrement dit, un identifiant non prédictible n'appartient pas à une séquence mais est produit par un calcul autre qu'une simple incrémentation. Dans la pratique le calcul dépend d'un marqueur temporel aussi connu sous le nom de timestamp. [0050] La figure 2 montre une première étape 5000 de création d'une démarche. Cette création est réalisé via une interface homme machine qui comporte, par exemple, un bouton « nouvelle démarche ». L'activation d'un tel bouton provoque la création d'un nouvel enregistrement dans la table 1050 de démarches ainsi que l'attribution d'un identifiant à ce nouvel enregistrement. Cette attribution est soit automatique, par exemple par des mécanismes de gestion d'identité d'un moteur de base de données (Identity pour Sql Server (marque déposée), Sequence pour Oracle (marque déposée)...), ou manuel par une sollicitation de l'utilisateur via une zone de saisie. Dans ce dernier cas il faudra valider l'identifiant en s'assurant qu'il est bien unique dans la table 1050 de démarches. [0051] Dans une variante de l'invention l'identifiant de démarche est structuré, on dit aussi complexe ou composite. Dans cette variante l'identifiant de démarche 10 comporte : - Un champ identifiant général de démarche, - Un champ identifiant de version. [0052] La figure 2 montre que l'étape 5000 de création d'un nouveau formulaire est suivie d'une étape 5010 de création d'un formulaire. Cette création 15 est réalisé via une interface homme machine qui comporte, par exemple, un bouton « nouveau formulaire ». L'activation d'un tel bouton provoque la création d'un nouvel enregistrement dans la table 1060 de formulaires ainsi que l'attribution, comme précédemment décrit, d'un identifiant à ce nouvel enregistrement. Dans la mesure où l'on vient, juste avant cette étape, de créer 20 une démarche, la création du formulaire se fait dans ce contexte et la valeur de la colonne identifiant de démarche du nouvel enregistrement de formulaire est la valeur de l'identifiant de démarche de l'identifiant de démarche du nouvel enregistrement de démarche. [0053] Plus généralement, lors de la création d'un objet, des colonnes 25 identifiant du nouvel objet sont initialisés en fonction du contexte dans lequel l'objet est créé. Un contexte peut aussi être activé par l'ouverture pour modification d'un élément existant. Par exemple l'ouverture pour modification d'un formulaire va provoquer la création d'un contexte lié au formulaire ouvert et tous les contrôles créés dans ce contexte seront lié à ce formulaire. 30 [0054] De l'étape 5010 de création de formulaire on passe à une étape 5020 de création, ou définition, d'un nouvel enregistrement de contrôle que l'on associe au nouvel enregistrement de formulaire. Cette association se fait naturellement car le contrôle est créé dans le contexte du nouvel enregistrement de formulaire.

Cette création est réalisé via une interface homme machine qui comporte, par exemple, un bouton « nouveau contrôle ». L'activation d'un tel bouton provoque la création d'un nouvel enregistrement dans la table 1070 de contrôles ainsi que l'attribution, comme précédemment décrit, d'un identifiant à ce nouvel enregistrement. [0055] Un contrôle est aussi appelé une zone de saisie et peut être, classiquement : - Une zone de saisie de texte, - Une zone de sélection dans une liste, - Une zone de sélection d'un fichier, - Un bouton permettant, par exemple, de déclencher une soumission du formulaire, - [0056] La liste n'est pas exhaustive. Pour la compléter on pourrait, par exemple, utiliser la documentation de la balise nommée input (saisie en français) du langage HTML. [0057] On rappelle que la soumission d'un formulaire est le fait d'émettre les données d'un formulaire vers un serveur de traitement. [0058] Une telle création de formulaire, par création de contrôle, est également connue dans d'autre environnement, comme par exemple Visual Studio (marque déposée) de Microsoft (marque déposée) ou encore SmartGuide (marque déposée) de la société Alphinat. [0059] L'invention réside ici dans le fait d'associer le résultat de la création du formulaire et des contrôles qu'il comporte à un identifiant de démarche. [0060] Dans un mode préféré de réalisation un identifiant de contrôle est unique pour un formulaire. C'est-à-dire que si on sélectionne tous les contrôles d'un formulaire dans la table 1070 de contrôles, alors chacune des lignes résultant de cette sélection peut être identifiée de manière unique par la valeur de la colonne identifiant de contrôle. Ce résultat est obtenu automatiquement si on utilise les mécanismes d'identité précédemment cité. Sinon il faut interdire la création, c'est-à-dire la mise à jour de la base de données, tant que l'utilisateur n'aura pas saisie un identifiant satisfaisant à la contrainte d'unicité. [0061] La figure 2 montre une étape 5030 de définition, ou création d'un flux de données. Cette création est réalisé via une interface homme machine qui comporte, par exemple, un bouton « nouveau flux ». L'activation d'un tel bouton provoque la création d'un nouvel enregistrement dans la table 1080 des flux ainsi que l'attribution d'un identifiant à ce nouvel enregistrement. Ce nouvel enregistrement est, de par son contexte de création, lié au nouvel enregistrement de démarche. [0062] L'étape 5030 de création d'un flux de données est suivie d'une étape 5040 d'association d'au moins un contrôle au nouvel enregistrement de flux. Cela est réalisé par l'insertion dans la table 1090 de données de flux d'une ligne comportant l'identifiant de l'enregistrement de flux nouvellement créé et un identifiant d'un contrôle associé à la démarche à laquelle le flux est associé. Dans le mode de réalisation, l'association entre un contrôle et une démarche est réalisée via le formulaire dont dépend le contrôle. Le formulaire dont dépend le contrôle est identifié par la colonne identifiant de formulaire de l'enregistrement de contrôle. La démarche dont dépend le formulaire est identifiée par l'identifiant de démarche de l'enregistrement de formulaire. Cette chaîne de dépendance permet de déterminer de quelle démarche dépend un contrôle. Dans une variante de l'invention la table de contrôles comporte une colonne identifiant de démarche ce qui permet de rattacher directement un contrôle à une démarche. [0063] Dans l'étape 5030 de création d'un flux, un utilisateur saisie également un identifiant de destinataire pour le flux. Un identifiant de destinataire est soit une adresse mail, soit un identifiant dans un carnet d'adresse électronique non représenté, la résolution de l'identifiant permettant d'obtenir une adresse électronique. Une adresse électronique est, par exemple : une adresse mail, une adresse d'un serveur FTP, ou plus généralement une adresse d'un service web. Dès lors on peut assimiler un flux à une enveloppe dans la mesure où un flux comporte un destinataire et la description d'un contenu. [0064] La figure 2 montre une étape 5050 de définition d'une règle d'émission.

Dans l'étape 5050, un utilisateur crée un nouvel enregistrement dans la table 2000 de règles d'envois. Pour cette création, via une interface, graphique ou en ligne de commande, l'utilisateur saisie un identifiant de démarche, une condition et un identifiant de flux. Cela permet de créer une règle. Une condition est par exemple : - Validation du formulaire x, - Valeur du contrôle x égale y. [0065] Les conditions sont donc structurées. Par exemple en deux champs : - Un champ identifiant un contrôle - Une valeur de déclenchement pour ce contrôle. [0066] D'une manière générale les règles associées à une démarche sont évaluées à chaque soumission d'un formulaire de la démarche. [0067] La règle est validée, évaluée à vraie, quand, dans une instance de démarche la valeur saisie du contrôle est égale à la valeur de déclenchement. [0068] Dans une variante de l'invention, le traitement d'un flux, suite à la validation d'une règle provoque la création d'au moins un nouvel enregistrement dans la table 2040 d'envois. Ce nouvel enregistrement comporte, comme précédemment décrit : - un identifiant d'instance de démarche : celui de la démarche active, - un identifiant de flux : un de ceux de la règle d'envoi validée - des données : celle décrite pas le flux précédemment identifié. [0069] Dans la pratique il y a autant de nouvel enregistrement d'envois créés que de flux associés à la règle d'envoi validée. [0070] Dans cette variante, avec table d'envois, les envois effectifs sont effectués à partir de la table d'envois. Le principe est qu'un processus autonome parcourt régulièrement la table d'envoi pour sélectionner les enregistrements qui n'ont pas été émis ou qui n'ont pas été correctement émis. Pour ces enregistrements le processus autonome utilise l'identifiant de flux pour déterminer un destinataire, et les données pour produire un message à envoyer. Selon la façon dont s'est déroulée la communication avec le destinataire le processus autonome marque l'enregistrement d'envoi comme traité ou en erreur. [0071] La description a décrit un certain enchainement d'étape. Dans la pratique cet ordre n'est pas figé, il pourrait être autre. [0072] A ce stade la démarche est prête pour être publiée, c'est-à-dire rendue disponible via un réseau de type Internet ou intranet. La figure montre une étape 6000 de publication. [0073] Les solutions pour la publication sont multiples. Le principe est qu'il existe un serveur capable d'interpréter une requête comme étant une demande d'instanciation d'un formulaire. Ce serveur, appelé serveur de publication, peut être le serveur 1000 de démarche ou un autre serveur. [0074] Lors de la publication, on peut par exemple associer un nom à une démarche. Cela revient à avoir une colonne supplémentaire dans la table 1050 5 des démarches. Le serveur, par exemple le serveur 1000 de démarche, reçoit alors une requête comportant : - Un code instruction correspondant à un ordre d'instancier une démarche - Un nom. 10 [0075] Dans le cas décrit le serveur 1000 de démarches joue aussi le rôle de serveur de publication au sens où c'est également lui qui répond aux requêtes issues des utilisateurs souhaitant entreprendre une démarche. Dans la pratique ce devrait être deux serveurs différents pour des raisons classiques de sécurité et d'isolation de données entre développement et production. 15 [0076] Le serveur de publication cherche alors le nom reçu par requête dans la table 1050 des démarches, si une démarche est trouvée, et si un statut de la démarche est à « publiée », alors le serveur répond par un formulaire de la démarche. Sinon le serveur renvoie un message d'erreur. On peut aussi envisager un serveur de production sur lequel toutes les démarches ont par défaut un statut 20 permettant leur publication. Il est dès lors inutile de gérer un tel statut. [0077] Dans ce cas, une mise en oeuvre possible est d'utiliser comme identifiant général de démarche un nom qui pourra être celui utilisé dans la requête. [0078] Dans la pratique le serveur de publication est un serveur http. Ce 25 serveur transforme la description d'un formulaire, telle qu'enregistrée dans la base 1033 de démarches, en tout ou partie d'une page html. On note ici qu'il n'y a pas de html dans le modèle de la démarche enregistré dans la base de démarches. C'est le serveur de publication qui met en forme la description du formulaire pour produire du html. 30 [0079] Par exemple, on ajoute dans la table 1070 de contrôle, une colonne de type qui permet de stocker un type. Ce type est utilisé par le serveur de publication pour déterminer comment « rendre » le contrôle. Ici rendre signifie utiliser le type pour déterminer une séquence de code html. Ce procédé permet de créer des formulaires sans avoir connaissance du langage html. Pour parvenir à cette fin la table 1070 peut contenir d'autres colonnes, comme par exemple des colonnes permettant d'enregistrer des informations de positionnement, de dimension et de label. Il en va de même pour la table 1060 de formulaires. [0080] Avant de répondre positivement le serveur créé, dans une étape 6010 d'instanciation, une instance de la démarche. Dans la mise en oeuvre décrite, le fait d'instancier une demande consiste au moins à enregistrer dans la table 2010 d'instance un nouvel enregistrement. Cela suppose que l'utilisateur se soit authentifié sur le serveur, dans une étape préalable non décrite, ce qui lui a permis d'obtenir un identifiant d'utilisateur. Il est ainsi possible de créer un nouvel enregistrement à partir de l'identifiant d'utilisateur et de l'identifiant de démarche trouver à partir du nom fournit par la requête précédemment décrite. Un identifiant d'instance de démarche est calculé automatiquement, par exemple par un mécanisme d'identité déjà décrit. Dans une variante de l'invention il n'y a pas d'authentification par le serveur de publication, dans ce cas l'identification se fait via une adresse mail fournie par l'utilisateur. Dans ce cas on parle d'utilisateur anonyme. [0081] Dans une variante de l'invention l'identifiant d'instance de démarche est composite et composé de la colonne 2011 identifiant de démarche et de la colonne 2012 identifiant d'utilisateur. Cela est une façon de forcer l'unicité d'une instance de démarche pour un utilisateur, l'identifiant d'instance de démarche devant être unique. [0082] Ici, par instancier, on entend au moins le fait d'enregistrer des données conformément à un modèle. Les données sont dans la base d'instances, les 25 modèles sont dans la base de données de démarches. [0083] Dans une variante de l'invention, avant d'instancier une nouvelle démarche le serveur de publication effectue une recherche d'instance de démarche existante. Il s'agit d'une étape 6005. Cette recherche est effectuée dans la table 2010 d'instances de démarche avec comme critère de sélection 30 l'identifiant de démarche et l'identifiant d'utilisateur. Si cette recherche permet de trouver un enregistrement alors il n'y a pas de nouvelle instance créée, c'est celle qui a été trouvée qui est utilisée. [0084] Une fois un formulaire rempli, il est validé par une action de l'utilisateur ce qui provoque sa soumission au serveur. La soumission entraîne deux choses : - Mise à jour de la table 2020 de données d'instance : pour chaque contrôle du formulaire soumis le serveur de publication met à jour ou créée une ligne dans la table, la colonne valeur de cette ligne enregistrant les valeurs qui ont été saisies par l'utilisateur avant la soumission du formulaire - Une évaluation des conditions de déclenchement des règles d'envois associées à la démarche. Si une condition d'une règle est validée, alors un message est constitué. Ce message comporte les données décrites pour le flux associé à la règle, règle dont la condition de déclenchement a été validée. On rappelle que cette description de données comporte un identifiant de contrôle. Les données incluses dans le message sont lues dans la table 2020 de données d'instance à partir des identifiant de contrôle et de l'identifiant de l'instance de démarche correspondant au formulaire validé. Le message une fois constitué est envoyé au destinateur désigné par le flux associé à la règle validée. [0085] Dans une variante multi-versions de l'invention, une démarche, c'est-à- dire un enregistrement dans la table 1050 de démarches, comporte une colonne de version. Lors de la publication, la réponse à la requête de l'utilisateur dépend des versions disponibles de la démarche. On a alors l'arbre de décision pour la sélection d'une démarche suivant : - Est-ce qu'il existe une instance de la démarche active pour l'utilisateur ? - Oui : alors on utilise cette instance - Non : parmi toutes les démarches correspondant au nom utilisé dans la requête, on utilise celle qui a le numéro de version le plus élevé, c'est-à-dire la version la plus récente. [0086] La variante multi-versions permet d'avoir simultanément plusieurs 30 versions d'une démarche publiées. Ce cas se produit, par exemple, quand un utilisateur commence une démarche à une date DO mais ne la même pas à bout. A une date D1 postérieur à la date DO une nouvelle version de la démarche est publiée. L'utilisateur revient à une date D2 postérieure à la date D1 et peut poursuivre sa démarche grâce à l'arbre de décision précédemment décrit pour la variante multi-versions. [0087] Dans une autre variante de l'invention une démarche comporte des dates de validités qui sont stockés dans : - Une colonne 1052 date de début de validité de la démarche dans la table 1050 de démarches, - Une colonne 1053 date de fin de validité de la démarche dans la table 1050 de démarches. [0088] Dans cette variante l'arbre de décision de sélection d'une démarche comporte un test comparant la date courante aux dates de validités. Si la date courante n'est pas entre les dates de validité, alors la démarche ne peut pas être sélectionnée. [0089] Dans cette variante les dates de validité de la démarche sont également utilisées lors de la validation d'un formulaire de la démarche. Si la date à laquelle la validation est effectuée est en dehors de la période de validité, alors la validation est bloquée. [0090] Dans une autre variante avec purge on utilise la valeur de la colonne 2013 date de départ, c'est-à-dire de création, de l'instance de démarche pour effacer des instances de démarche. Dans cette variante, toutes les instances de démarche dont l'âge est supérieur à une valeur prédéterminée sont effacées. L'âge est la différence entre la date courante est le date de départ. L'effacement consiste à supprimer les lignes correspondantes dans la table 2010 d'instances de démarche et dans la table 2020 de données d'instance de démarche, ainsi que dans la table 2030 et la table 2040. [0091] Cette variante avec purge permet de garantir la confidentialité des données. Les données ne sont pas persistées au-delà d'une certaine durée. [0092] La figure 2 montre une étape 7000 de saisie d'un message par un utilisateur. Cette saisie est réalisée via un formulaire spécifique qui est lié, au moment de son utilisation à une instance de démarche. La validation de ce formulaire spécifique provoque la création dans la table 2030 de message d'un nouvel enregistrement. Cela permet d'associer des messages à une instance de démarche. Cela permet à différents intervenants intéressés par la démarche de communiquer au-delà de la démarche proprement dite. Ces intervenants sont, par exemple : - L'utilisateur, ou administré, ayant provoqué la création de l'instance de la démarche, - Un représentant de l'administration à laquelle est destinée la démarche. [0093] Dans une variante de l'invention une démarche est publiée par morceau. Les formulaires servis par le serveur de publication le sont à partir d'une copie de la base de données de démarches. Cette copie est alimentée par des paquets de mise à jour. Un paquet de mise à jour est produit à partir de la base de données de démarches. Un utilisateur sélectionne, dans la base de données de démarches des éléments : formulaire, contrôle, composant, flux... pour les inclure dans un paquet et produire ledit paquet. Chaque élément est un morceau de démarche. Le paquet est reçu par le serveur de production qui utilise le contenu du paquet pour mettre à jour la copie de la base de données de démarche. On parle alors d'une étape 5095 d'intégration de paquet précédant l'étape 6000 de publication. [0094] Dans une variante de la variante par morceau, avant l'intégration, le serveur de publication vérifie la cohérence d'un paquet reçu. Cette vérification est au moins une validation des dépendances des éléments contenus dans le paquet reçu. Par exemple si un paquet comporte un formulaire qui référence un composant feuille de style (CSS) qui n'est pas dans le paquet et qui n'a pas déjà été intégré via un paquet précédent, alors l'intégration du paquet est refusée. On vérifie ainsi chaque élément du paquet reçu pour s'assurer que le serveur de publication comporte bien tous les éléments permettant de publier chaque élément du paquet.

Claims (20)

1. REVENDICATIONS1. Procédé de dématérialisation d'une démarche administrative comportant les étapes suivantes : Attribution (5000) d'un identifiant à la démarche dans une base de données de démarche, Création (5010) d'au moins un formulaire numérique associé à la démarche via l'identifiant de la démarche le formulaire comportant au moins un identifiant de formulaire, - Définition (5020) d'au moins un contrôle comportant : - Un identifiant de contrôle unique pour la démarche, -Association (5020) du au moins un contrôle au formulaire Définition (5030) d'au moins un flux de données associé à la démarche, le flux de données comportant (5040) au moins un identifiant d'un contrôle précédemment défini et un identifiant de destinataire, Définition (5050) d'une règle d'émission associée à la démarche, règle d'émission dont le déclenchement équivaut à l'émission d'un message vers un destinataire et comportant : - Une condition de déclenchement, - Un identifiant d'un flux précédemment défini, - Publication (6000) de la démarche, - lnstanciation (6010) de la démarche pour un utilisateur identifié par un identifiant utilisateur, l'instanciation étant l'enregistrement dans une base de données d'instances de n-uplets comportant au moins les données suivantes : - Identifiant d'utilisateur, - Identifiant de démarche - Identifiant de contrôle - Valeur.
2. 2. Procédé de dématérialisation selon la revendication précédente, caractérisé en ce que l'identifiant de démarche est complexe et comporte : Un identifiant, Un numéro de version. 301 1 6 6 1
3. 3. Procédé selon la revendibation 2,' caractérisé en ce que lors de l'instanciation de la démarche, cette instanciation est toujours réalisé selon la version la plus récente.
4. 4. Procédé selon l'une des revendications précédentes, caractérisé en ce que la démarche comporte des dates (1052, 1053) de validité.
5. 5. Procédé selon la revendication 4, caractérisé en ce qu'une instance de la démarche ne peut être créée que durant la validité de la démarche.
6. 6. Procédé selon la revendication 4, caractérisé en ce qu'une instance de la démarche ne peut être validée que durant la validité de la démarche.
7. 7. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'étape d'instanciation comporte une étape de production d'un identifiant d'instance de démarche, ledit identifiant étant non prédictible.
8. 8. Procédé selon l'une des revendications précédentes caractérisé en ce qu'une condition de déclenchement porte sur une valeur d'un contrôle.
9. 9. Procédé selon l'une des revendications précédentes caractérisé en ce qu'une condition de déclenchement est une validation d'un formulaire.
10. 10. Procédé selon l'une des revendications précédentes caractérisé en ce que la démarche comportant plusieurs formulaires elle comporte aussi au moins une règle d'enchaînement définissant un ordre d'enchaînement des formulaires.
11. 11. Procédé de dématérialisation selon l'une des revendications précédentes caractérisé en ce qu'une le procédé comporte une étape (6005) de vérification avant l'étape d'instanciation la vérification étant : - Est-ce qu'il existe une instance de la démarche active pour l'utilisateur : - Si oui, alors utilisation de cette instance, - Si non, alors poursuite de l'instanciation.
12. 12. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'une instance de démarche comporte une date de création.
13. 13. Procédé selon l'une des revendications précédente, caractérisé en ce qu'une instance de démarche et les données associées sont automatiquement effacées lorsqu'elles atteignent un âge prédéterminé.
14. 14. Procédé selon l'une des revendications précédente, caractérisé en ce qu'un identifiant de destinataire identifie une règle de routage. 301 1 6 6 1
15. 15. Procédé selon l'une des revendications précédentes, caractérisé en qu'il comporte une étape (7000) d'enregistrement d'un message associé à une instance de démarche, le message étant au moins consultable par l'utilisateur associé à l'instance de la démarche.
16. 16. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'une validation d'une règle d'envoi provoque la création d'un enregistrement dans une table (2040) d'envois.
17. 17. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'une démarche est publiée par morceau.
18. 18. Procédé selon la revendication 17, caractérisé en ce qu'un morceau de démarche est validé avant d'être publié.
19. 19. Dispositif de stockage numérique comportant un fichier correspondant à des codes instructions mettant en oeuvre le procédé selon l'une des revendications précédentes.
20. 20. Dispositif mettant en oeuvre le procédé selon l'une des revendications 1 à 18.