WO2015049472A1 - Method of computerizing a procedure - Google Patents

Abstract

Method of computerizing an administrative procedure comprising the following steps: - allocating an identifier to the procedure in a procedure database, - creating at least one digital form associated with the procedure via the identifier of the procedure, the form comprising at least one form identifier, - defining at least one control comprising: - a unique control identifier for the procedure, - association of the at least one control with the form-defining of at least one data stream associated with the procedure, the data stream comprising at least one identifier of a previously defined control and a recipient identifier, - defining a send rule associated with the procedure, the triggering of which send rule is equivalent to the sending of a message to a recipient and comprising: - a triggering condition, - an identifier of a previously defined stream, - publication of the procedure, - instantiation of the procedure for a user identified by a user identifier, the instantiation being the recording in a database of instances of n-tuples comprising at least the following data: -user identifier, -procedure identifier -controller identifier -value.

Description

 Process of dematerialization of an approach TECHNICAL FIELD OF THE INVENTION

 The invention relates to the dematerialization of the process and more specifically to the dematerialization of documents related to administrative procedures.

STATE OF THE PRIOR ART

 It is common to have to apply to an administration or an organization to meet a mandatory administrative process: obtaining an identity document, tax return ...

 In this case it is usually necessary to build a file and go on site, to a counter of the administration or organization, hoping not to have forgotten anything.

On the spot then we must wait, sometimes for a long time, and come back if a document is missing.

 This therefore poses several technical problems:

 Find time,

 Manage queues

 - Materialize documents and be able to keep them.

 In the state of the art it is known websites, more or less dynamic, which can support part of the dematerialization. But in this case, there is as much website to create as steps. This is like writing html pages and managing their webs. In addition, these sites use the notion of session to preserve the data. This means that once the browser is closed, everything is erased, which does not leave much room for mistakes and that requires to have everything available when you start the process. SUMMARY OF THE INVENTION

The invention aims to remedy all the drawbacks of the state of the art identified above, and in particular to propose means for dematerializing, via an Internet type network, steps administrative. One approach is to enter one or more forms that will automatically be submitted to the right interlocutor of the right organization or administration. On the other hand the data are persisted a reasonable time to allow a user to complete an approach already started.

In this purpose, one aspect of the invention relates to:

 A process of dematerialization of an administrative procedure comprising the following steps:

 - Assigning an identifier to the approach in a gait database,

 - Creation of at least one digital form associated with the approach via the identifier of the approach the form including at least one form identifier,

 - Definition of at least one control comprising:

 - A unique control identifier for the process,

 -Association of at least one form check

- Definition of at least one data flow associated with the approach, the data flow comprising at least one identifier of a previously defined control and a recipient identifier,

 - Definition of an emission rule associated with the approach, transmission rule whose triggering is equivalent to sending a message to a recipient and comprising:

 - a trigger condition,

 An identifier of a previously defined flow,

 - Publication of the approach,

 Instantiation of the approach for a user identified by a user identifier, the instantiation being the recording in a database of instances of n-tuplets including at least the following data:

 - User ID,

 - Approach identifier

 - Control ID

- Value. In addition to the main features which have just been mentioned in the preceding paragraph, the method / device according to the invention may have one or more additional characteristics among the following, considered individually or according to the technically possible combinations:

 the gait identifier is complex and comprises:

 A login,

 A version number,

 the instantiation is always done according to the most recent version. - the procedure includes dates (1052, 1053) of validity.

 an instance of the process can only be created during the validity of the process.

 an instance of the process can only be validated during the validity of the process.

 the instantiation step includes a step of producing a step instance identifier, said identifier being unpredictable. a trigger condition relates to a value of a control. a trigger condition is a validation of a form. the approach comprising several forms also includes at least one linking rule defining a sequence of sequence of the forms.

 one of the preceding claims characterized in that the method comprises a verification step before the instantiation step the verification being:

 - Is there an instance of the active approach for the user:

 - If yes, then use this instance,

 - If no, then continue the instantiation.

 an instance of a process has a creation date.

a step instance and the associated data are automatically erased when they reach a predetermined age, a recipient identifier identifies a routing rule, the method comprises a step of recording a message associated with a procedure instance, the message being at least searchable by the user associated with the instance of the approach,

 an approach is published by piece.

 - a piece of gait is validated before being published.

 The invention also relates to a digital storage device comprising a file corresponding to instruction codes implementing the method according to a combination of the preceding features.

The invention also relates to a device implementing a method according to a combination of the preceding claims.

BRIEF DESCRIPTION OF THE FIGURES

 Other features and advantages of the invention will emerge on reading the description which follows, with reference to the appended figures, which illustrate:

 - Figure 1, an illustration of means for implementing the invention;

 Figure 2, an illustration of steps of the method according to the invention.

For clarity, identical or similar elements are identified by identical reference signs throughout the figures.

The invention will be better understood on reading the description which follows and the examination of the figures that accompany it. These are presented as an indication and in no way limitative of the invention.

DETAILED DESCRIPTION OF AN EMBODIMENT

Server is a term used in the field of the invention. A server is also a computer in that it has all the characteristics. It is considered in this document that the terms computer and server are equivalent.

For the description of the process, steps or actions are assigned to computer-type machines. Such a machine comprises at least one microprocessor and a storage memory. The storage memory makes it possible to record instruction codes whose interpretation allows the implementation of the steps or actions. So, when we assign an action to a machine, this is actually performed by a microprocessor of the machine interpreting instruction codes stored in a memory of the machine.

For the description of the process, communications are assigned to computer-type machines. These communications are performed via message exchanges according to a predetermined protocol implemented at least by a network card, wired or without cable. Each machine involved in the communication has its network card connected via a bus to a microprocessor of the machine. This allows the microprocessor to take into account the received messages and to emit them. The network cards are also connected to a network, for example of the Ethernet type. There are other types of networks, such as fiber optic networks, InfinBand networks, or wireless networks.

 When we say that an action is performed by an operating system, an application, a process, or an instruction code area, this action corresponds to the implementation, by a microprocessor, of instruction codes. corresponding, as described in the preceding paragraphs.

By instruction code is meant both native binary codes, intermediate codes interpreted by a virtual machine, for example Java, or scripts interpreted by interpretation engines, for example Python, PERL, ... the list is not exhaustive. This includes the built-in instructions of the operating system.

 In FIG. 1 is illustrated a first server 1000 of steps comprising at least:

 A microprocessor 101 0,

 A 1020 network interface,

 1030 storage means, for example a hard disk.

Those skilled in the art will readily understand that this is a practical description of a storage means. In practice the storage means can be composed of several physical components, hard disks according to several connectors (I DE, SCSI, eSCSI, ATA, SATA, eSATA, USB, ...) and several configurations (JBOD, RAI D0, RAI D1, RAI D5, ...), memory disk, ... the list is not exhaustive. These notes apply for all described computers. The elements of the server 1000 of steps are interconnected by a bus 1 040. The elements of the server 1000 of steps interconnected by the bus 1 040 are:

 The microprocessor 101 0,

 - The interface 1 020 network,

 The storage means 1030.

The storage means 1030 comprise several zones:

 A data area 1032

 A program area 1031 corresponding, inter alia, to instruction codes corresponding to the implementation of the method according to the invention.

 For the purposes of the description, it is described that the data zone 1032 comprises two databases:

 A 1033 database of process data

 - A 1034 basis of proceedings.

 In practice it could be just one database. It is convenient here for the sake of clarity to describe two databases. A database is described here as a set of tables and relationships. A table has rows, or records, with each row divided into columns or fields. A relation allows to link, to put in relation, recordings. This is a description of a relational implementation mode of a database, but the invention is not limited to this type of database. It is compatible with object databases, hierarchical or NoSql to name only the most well-known database systems.

The database 1033 of data includes:

 A table 1050 of steps including at least:

 A column 1 051 gait identifier

 A table 1060 of forms comprising at least:

 A column 1,061 form identifier

 - A column 1 062 gait identifier to link a form to a procedure

 A control table 1070 comprising at least:

A column 1,071 control identifier A column 1,072 form identifier for attaching the control to a form.

We see here that we describe links 1 - N between the tables. In practice one can also have links N - N by adding tables of relations, for example in table which would include identifiers of steps and identifiers of forms to allow to associate a form with several steps.

 In practice a control is comparable to an input area that includes a type. The most common types are: text, check box, list. The list is not exhaustive.

 [0028] Figure 1 also shows that the base 1034 gait also includes:

 a flow table 1080 comprising at least:

 A column 1,081 stream identifier

 - A column 1 082 gait identifier

 A column 1083 recipient identifier, for example an email or an identifier for determining an email.

In a variant of the invention the base 1033 of steps also includes a table 8010 flow routing rules. The table 801 0 comprises at least:

 A column 801 1 routing rule identifier,

 A column 801 2 routing rule.

In a variant of the invention the base 1033 of steps also includes a table 8020 of components. The component table 8020 comprises at least:

 A column 8021 component identifier,

 A column 8022 nature of component.

 A column 8023 content.

 A column 8024 gait identifier.

A component is therefore associated with an approach. In a variant, the component table can be implemented via the control table 1070. In this case the control table 1070 would include, for example, a column of nature to specify the nature of the record. One of the natures would be control, the other natures correspond to natures of component. In this case a component can also be linked to a form.

A nature of a component is, for example:

 Graphic theme, for example a set of CSS style sheets used to change the appearance of a form,

 A web service, used to validate a user input,

A data source used to populate a selection type control from a list

 An XSLT file for filtering and / or formatting data, for example when processing a send record.

 A routing rule is a decision tree, for example a selector, which makes it possible to determine an address from the value of a control. In this variant, the destination identifier column 1083 registers a routing rule identifier.

[0034] Figure 1 also shows that the base 1033 of steps also includes:

 A table 1090 of flow contents comprising at least:

 A column 1,091 flow identifier,

 A column 1 092 control identifier. Here column 1 092 control identifier can be:

 An identifier such as the control identifier of the control table 1070

 -composite, that is, the concatenation of a control identifier from the control table 1070 and a form identifier from the form table 1060.

[0035] FIG. 1 also shows that the base 1033 of steps also includes:

 - A 2000 table of mailing rules including at least:

 A 2001 Shipping Rule Identifier column

A column 2002 trigger condition, A column 2003 flow identifier, in a variant a rule may include more than one flow identifier.

For the case of the mailing table 2000 a link with an approach is achieved via the flow identifier that identifies a flow that is linked to a process. In practice, such a link between a flow and an approach could be established either directly via a column of the rule table or indirectly via a specialized join table.

 In the case of the sending rule table the sending rule identifier is structural, that is to say not necessary for the implementation of the invention. The link between a send rule and a feed is made via a feed ID stored in the rule record. In a variant, it is possible to use a link table whose records include a rule identifier and a stream identifier.

 In a variant of the invention, in a case in which an approach comprises several forms, the database 1033 form data includes one or more tables for defining an order in which to link the forms of the approach. These additional tables, which can be extensions of existing tables, include, for example, the following information:

 - First form of the process: identifier of the first form used when creating a new instance of the approach

 For each form what is the following form, the following form may depend on a condition based, for example, on the value of a control of the current form that is left to move to the next form.

 [0039] FIG. 1 also shows that the database 1034 of instance instance data comprises:

 A table 201 0 of gait instances comprising at least:

 A column 201 1 gait instance identifier, - a column 201 2 user identifier,

 A 2009 column identifying the approach.

In a variant of the invention, the gait instance table 201 0 comprises: A starting column 201 3 of the approach,

 A 2014 status column of the instance of the process,

[0041] A status of a procedure instance is, for example:

 - Created: at the moment of its creation,

 Submitted: sent to the recipient or recipients,

 Accepted: the recipient has agreed to handle the case because the file is complete

 Refused: the recipient refused the procedure.

 - ... The list is not exhaustive.

 [0042] A procedure authority status allows, at least, to inform a user creator of a process of an advancement of its approach within an organization or administration to which it is addressed through a publication server. The concept of publication server is described later in the description.

 [0043] FIG. 1 also shows that the database 1034 of instance instance data comprises:

 A 2020 instance instance data table with at least:

 A step instance identifier column 2021,

 A column 2022 of control identifier,

 A 2023 column of value.

From there, by the relationship game, in the relational database system sense, it is easy to compose a view, from the 2010 table of gait instances and the 2020 data table. gait instances, to expose n-tuples:

 - User ID,

 - Approach identifier

 - Control ID

 - Value.

Here it is a quadruplet. In general, a tuple is an association of n values. In a variant of the invention, the base 1034 of gait instance data comprises:

 A table 2030 of messages comprising at least:

 A 2031 step instance identifier column

 - A 2032 column of message.

 In a variant of the invention, the base 1034 of gait instance data comprises:

 A 2040 mailing table comprising at least:

 A 2041 step instance identifier column

 - A 2042 column of data to send

 A column 2043 of stream identifier.

FIG. 1 shows that, via the network interface 1020, the step 1000 server is connected to a network 2000 of the Internet or Intranet type, which enables a client computer 3000 to send requests to the server 1,000 steps.

 In a variant of the invention a gait instance identifier is a character string calculated to be unique and not predictable by a person unfamiliar with the production method. This then makes it possible to use the step instance identifier to directly consult an approach on the publication server. Since the publisher is an http server, we are talking about a recovery URL, which includes a gait instance identifier. A recovery url allows the person who knows it to take back, and / or consult, the corresponding procedure. In this case a simple counter is not suitable as a process instance identifier, anyone can query the publisher with a random number. In other words, an unpredictable identifier does not belong to a sequence but is produced by a calculation other than a simple incrementation. In practice the calculation depends on a time marker also known as timestamp.

[0050] Figure 2 shows a first step 5000 of creating a process. This creation is done via a man-machine interface which includes, for example, a "new approach" button. Activation of such a button causes the creation of a new record in table 1050 of procedures and the assignment of an identifier to this new registration. This attribution is either automatic, for example by identity management mechanisms of a database engine (Identity for Sql Server (registered trademark), Sequence for Oracle (registered trademark) ...), or manual by a solicitation of the user via an input area. In this last case it will be necessary to validate the identifier by ensuring that it is very unique in the table 1050 of steps.

 In a variant of the invention the gait identifier is structured, it is also said complex or composite. In this variant, the gait identifier comprises:

 A general identifying field of approach,

 A version identifier field.

Figure 2 shows that the step 5000 of creating a new form is followed by a step 501 0 of creation of a form. This creation is done via a man-machine interface that includes, for example, a "new form" button. Activation of such a button causes the creation of a new record in the forms table 1060 as well as the assignment, as previously described, of an identifier to this new record. To the extent that one comes, just before this step, to create an approach, the creation of the form is done in this context and the value of the step identifier column of the new form record is the value of the identifier of approach of the process ID of the new process registration.

 More generally, during the creation of an object, columns identifying the new object are initialized according to the context in which the object is created. A context can also be activated by opening to modify an existing element. For example, opening to modify a form will cause the creation of a context linked to the open form and all the controls created in this context will be linked to this form.

From step 501 0 form creation we go to a step 5020 creation, or definition, of a new control record that is associated with the new form record. This association is done naturally because the control is created in the context of the new form record. This creation is done via a man-machine interface that includes, for example, a "new control" button. The activation of such a button causes the creation of a new record in the control table 1070 as well as the allocation, as previously described, of an identifier to this new record.

 A control is also called an input area and can be, conventionally:

 A text entry area,

 A selection box in a list,

 - A selection area of a file,

 A button allowing, for example, to trigger a submission of the form,

The list is not exhaustive. To complete it one could, for example, use the documentation of the tag named input (input in French) of the HTML language.

 It is recalled that the submission of a form is the fact of transmitting the data of a form to a processing server.

 Such a creation of form, by creating control, is also known in other environment, such as Visual Studio (trademark) of Microsoft (trademark) or SmartGuide (trademark) of the company Alphinat.

 The invention resides here in associating the result of the creation of the form and the controls it includes with a gait identifier.

In a preferred embodiment, a control identifier is unique for a form. That is, if all the controls of a form are selected in the control table 1070, then each of the rows resulting from this selection can be uniquely identified by the value of the control identifier column. This result is obtained automatically if the aforementioned identity mechanisms are used. Otherwise you must prohibit the creation, that is to say the updating of the database, as long as the user has not entered an identifier satisfying the uniqueness constraint. Figure 2 shows a step 5030 of definition, or creation of a data stream. This creation is done via a human machine interface which includes, for example, a button "new flow". Activation of such a button causes the creation of a new record in the table 1 080 flows as well as the allocation of an identifier to this new record. This new record is, due to its creation context, linked to the new record of procedure.

 Step 5030 of creating a data stream is followed by a step 5040 of association of at least one control to the new flow record. This is accomplished by inserting in the table 1 090 flow data of a line including the identifier of the newly created flow record and an identifier of a control associated with the step to which the flow is associated. In the embodiment, the association between a control and an approach is achieved via the form on which the control depends. The form on which the control depends is identified by the form identifier column of the control record. The process on which the form depends is identified by the process identifier of the form record. This chain of dependency makes it possible to determine which approach depends on a control. In a variant of the invention the control table includes a gait identifier column which allows a control to be directly attached to a gait.

 In step 5030 of creating a stream, a user also enters a recipient identifier for the stream. A recipient identifier is either an email address or an identifier in a not shown electronic address book, the resolution of the identifier to obtain an email address. An email address is, for example: an email address, an address of an FTP server, or more generally an address of a web service. Therefore we can assimilate a stream to an envelope to the extent that a flow includes a recipient and the description of a content.

FIG. 2 shows a step 5050 of definition of a transmission rule. In step 5050, a user creates a new record in the Send Rules Table 2000. For this creation, via an interface, graphical or on the command line, the user enters a gait identifier, a condition and a flow identifier. This creates a rule. A condition is for example: Validation of the form x,

 Control value x equals y.

The conditions are structured. For example in two fields:

 A field identifying a control

 - A trigger value for this control.

 In general, the rules associated with an approach are evaluated with each submission of a form of the approach.

The rule is validated, evaluated to true, when, in an instance of approach the value entered control is equal to the trigger value.

In a variant of the invention, the processing of a stream, following the validation of a rule causes the creation of at least one new record in the table 2040 of mailings. This new record includes, as previously described:

 a procedure instance identifier: that of the active procedure, - a stream identifier: one of those of the validated sending rule

 data: the one described by the previously identified flow.

In practice there are as many new records of mail items created as flows associated with the validated sending rule.

 In this variant, with mailing table, the actual shipments are made from the mailing table. The principle is that an autonomous process periodically traverses the send table to select records that have not been issued or that have not been successfully issued. For these records the stand-alone process uses the stream identifier to determine a recipient, and the data to produce a message to be sent. Depending on how the communication with the recipient took place, the stand-alone process marks the sending record as treated or in error.

The description has described a certain sequence of steps. In practice this order is not fixed, it could be other.

 At this stage the approach is ready to be published, that is to say made available via a network type Internet or intranet. The figure shows a step 6000 of publication.

The solutions for the publication are multiple. The principle is that there is a server capable of interpreting a request as a request instantiation of a form. This server, called the publisher, can be the 1,000-step server or another server.

 When publishing, we can for example associate a name to a process. This amounts to having an additional column in the table 1050 of the steps. The server, for example the gait server 1000, then receives a request comprising:

 An instruction code corresponding to an order to instantiate a procedure

 A name.

In the case described the server 1000 of steps also plays the role of publication server in the sense that it is also he who responds to requests from users wishing to undertake a process. In practice it should be two different servers for classic reasons of security and data isolation between development and production.

The publication server then searches the name received by request in the table 1050 steps, if an approach is found, and if a status of the approach is "published", then the server responds with a form of the approach . Otherwise the server returns an error message. One can also consider a production server on which all the steps have by default a status allowing their publication. It is therefore useless to manage such a status.

 In this case, a possible implementation is to use as a general gait identifier a name that may be the one used in the request.

 In practice, the publication server is an http server. This server transforms the description of a form, as registered in the database 1033 of steps, in whole or part of a html page. We note here that there is no html in the model of the approach recorded in the database. It is the Publisher that formats the description of the form to produce html.

For example, we add in the control table 1070, a type column that can store a type. This type is used by the Publisher to determine how to "render" the control. Here rendering means using the type to determine a html code sequence. This process allows create forms without knowing the html language. To achieve this, table 1070 may contain other columns, such as columns for storing location, dimension, and label information. The same is true for the 1,060 table of forms.

Before responding positively to the server created, in a step 6010 of instantiation, an instance of the approach. In the described implementation, instantiating a request consists at least in registering in the instance table 2010 a new record. This assumes that the user has authenticated to the server, in a previous step not described, which allowed him to obtain a user ID. It is thus possible to create a new record from the user ID and the step find identifier from the name provided by the previously described request. A step instance identifier is automatically calculated, for example by an identity mechanism already described. In a variant of the invention, there is no authentication by the publication server, in which case the identification is done via an email address provided by the user. In this case we speak of anonymous user.

 In a variant of the invention the step instance identifier is composite and composed of the column 201 1 gait identifier and the column 201 2 user identifier. This is a way to force the uniqueness of a gait instance for a user, the gait instance ID must be unique.

 Here, instantiating means at least the fact of recording data according to a model. The data is in the instance database, the templates are in the process database.

In a variant of the invention, before instantiating a new approach, the publication server performs an existing process instance search. This is a step 6005. This search is performed in the table 201 0 of instances of approach with as selection criterion the gait identifier and the user identifier. If this search finds a record then there is no new created instance, it is the one that has been found which is used. Once a form is filled, it is validated by an action of the user which causes its submission to the server. Submission involves two things:

 Updating the 2020 Instance Data Table: For each control of the submitted form, the Publisher updates or creates a row in the table, the value column of this row recording the values that were entered by the publisher. user before submitting the form

 An evaluation of the trigger conditions of the sending rules associated with the procedure. If a condition of a rule is validated, then a message is formed. This message contains the data described for the flow associated with the rule, rule whose triggering condition has been validated. It will be recalled that this data description comprises a control identifier. The data included in the message is read from the 2020 instance data table from the control IDs and the ID of the process instance corresponding to the validated form. The message once constituted is sent to the designated recipient by the flow associated with the validated rule.

In a multi-version variant of the invention, an approach, that is to say a record in the table 1050 of steps, includes a version column. When publishing, the response to the user's request depends on the available versions of the process. We then have the decision tree for the selection of a following procedure:

 Is there an instance of the active approach for the user?

 - Yes: then we use this instance

 No: Among all the steps corresponding to the name used in the query, the one with the highest version number, that is the most recent version, is used.

The multi-version variant makes it possible to simultaneously have several versions of a published approach. This case occurs, for example, when a user starts a process on a D0 date but does not even finish it. At a date D1 after the date D0 a new version of the procedure is published. The user returns to a date D2 after the date D1 and can continue with the decision tree previously described for the multi-version variant.

 In another variant of the invention, an approach includes validity dates that are stored in:

 - A column 1,052 date of beginning of validity of the procedure in the table 1050 of steps,

 A column 1053 end date of the validity of the approach in the table 1050 of steps.

 In this variant, the selection decision tree of a step includes a test comparing the current date to the validity dates. If the current date is not between the validity dates, then the procedure can not be selected.

 In this variant the validity dates of the approach are also used during the validation of a form of the approach. If the date on which validation is performed is outside the validity period, then validation is blocked.

 In another variant with purge is used the value of the column 201 3 date of departure, that is to say, creation of the step instance to delete instances of gait. In this variant, all gait instances whose age is greater than a predetermined value are erased. Age is the difference between the current date and the date of departure. Deletion consists of deleting the corresponding rows in the 201 0 table of gait instances and in the 2020 gait instance data table, as well as in table 2030 and table 2040.

This variant with purge ensures the confidentiality of the data. Data is not persisted beyond a certain time.

FIG. 2 shows a step 7000 of inputting a message by a user. This entry is made via a specific form that is linked at the time of its use to a procedure instance. Validation of this specific form causes message 2030 to create a new record. This allows messages to be associated with a process instance. This allows different stakeholders interested in the process of communicate beyond the actual process. These stakeholders are, for example:

 The user, or administered, having caused the creation of the instance of the approach,

 - A representative of the administration for whom the procedure is intended.

 In a variant of the invention, a step is published per piece. The forms served by the publisher are from a copy of the process database. This copy is powered by update packages. An update package is produced from the process database. A user selects, in the procedure database elements: form, control, component, stream ... to include them in a package and produce said package. Each element is a piece of gait. The package is received by the production server that uses the contents of the package to update the copy of the gait database. This is referred to as a packet integration step 5095 preceding the publication step 6000.

 In a variant of the piecewise variant, before the integration, the publication server checks the coherence of a received packet. This check is at least a validation of the dependencies of the elements contained in the received packet. For example, if a package has a form that references a style sheet component (CSS) that is not in the package and has not already been integrated through a previous package, then package integration is denied. This checks each element of the received packet to ensure that the publisher has all the elements to publish each element of the package.

Claims

1. Method of dematerializing an administrative procedure comprising the following steps:  - Assignment (5000) of an identifier to the approach in a gait database,  - Creation (5010) of at least one digital form associated with the approach via the identifier of the approach the form comprising at least one form identifier,  - Definition (5020) of at least one control comprising:  - A unique control identifier for the process, -Association (5020) of the at least one form control  - Definition (5030) of at least one data flow associated with the approach, the data flow comprising (5040) at least one identifier of a previously defined control and a recipient identifier,  - Definition (5050) of a transmission rule associated with the approach, transmission rule whose triggering is equivalent to the sending of a message to a recipient and comprising:  - a trigger condition,  An identifier of a previously defined flow,  - Publication (6000) of the approach,  Instantiation (6010) of the approach for a user identified by a user identifier, the instantiation being the recording in a database of instances of n-tuplets including at least the following data:  - User ID,  - Approach identifier  - Control ID  - Value. 2. Dematerialization method according to the preceding claim, characterized in that the gait identifier is complex and comprises:  A login, A version number. 3. Method according to claim 2, characterized in that during the instantiation of the gait, this instantiation is always carried out according to the most recent version.  4. Method according to one of the preceding claims, characterized in that the approach includes dates (1052, 1053) of validity.  5. Method according to claim 4, characterized in that an instance of the approach can be created only during the validity of the approach.  6. Method according to claim 4, characterized in that an instance of the approach can be validated only during the validity of the approach. 7. Method according to one of the preceding claims, characterized in that the instantiation step comprises a step of producing a step instance identifier, said identifier being unpredictable.  8. Method according to one of the preceding claims characterized in that a trigger condition relates to a value of a control. 9. Method according to one of the preceding claims characterized in that a trigger condition is a validation of a form. 10. Method according to one of the preceding claims, characterized in that the approach comprising several forms it also comprises at least one concatenation rule defining a sequence of linking forms. 1 1. Dematerialization method according to one of the preceding claims, characterized in that the method comprises a step (6005) of verification before the instantiation step the verification being:  Is there an instance of the active procedure for the user: - If yes, then use this instance,  - If no, then continue the instantiation.  12. Method according to one of the preceding claims, characterized in that a gait instance includes a creation date.  13. Method according to one of the preceding claims, characterized in that a gait instance and associated data are automatically erased when they reach a predetermined age. 14. Method according to one of the preceding claims, characterized in that a recipient identifier identifies a routing rule. 15. Method according to one of the preceding claims, characterized in that it comprises a step (7000) for recording a message associated with a gait instance, the message being at least searchable by the user associated with the instance of the process. 16. Method according to one of the preceding claims, characterized in that a validation of a sending rule causes the creation of a record in a table (2040) of items.  17. Method according to one of the preceding claims, characterized in that a step is published by piece. 18. The method of claim 17, characterized in that a gait piece is validated before being published.  19. Digital storage device comprising a file corresponding to instruction codes implementing the method according to one of the preceding claims. 20. Apparatus implementing the method according to one of the preceding claims.