EP1676233A2 - Procede d'enquete electronique - Google Patents

Procede d'enquete electronique

Info

Publication number
EP1676233A2
EP1676233A2 EP04816236A EP04816236A EP1676233A2 EP 1676233 A2 EP1676233 A2 EP 1676233A2 EP 04816236 A EP04816236 A EP 04816236A EP 04816236 A EP04816236 A EP 04816236A EP 1676233 A2 EP1676233 A2 EP 1676233A2
Authority
EP
European Patent Office
Prior art keywords
electronic
data
equipment
recipient
survey
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP04816236A
Other languages
German (de)
English (en)
Inventor
Sébastien PANCHER
Nicolas Durand
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Calame Software
Original Assignee
Calame Software
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Calame Software filed Critical Calame Software
Publication of EP1676233A2 publication Critical patent/EP1676233A2/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail

Definitions

  • the present invention relates to the field of online survey solutions.
  • the present invention relates more particularly to a technical process comprising different technical steps consisting in generating an electronic form, distributing and informing said form, transmitting data from said informed form and then automatically consolidating the data collected.
  • the invention lies in the field of data transfers and is specifically intended to facilitate the establishment of computerized data cycles.
  • a data cycle being defined by the request for information from a requesting user to recipient users, the supply of the information requested by said recipients, the return of the information provided to the requesting user, the consolidation and the provision of consolidated information to the requesting user.
  • the data cycle is considered to have been successfully completed when the following conditions are met: All of the recipient users have provided the required information
  • the consolidated data are consistent with the information system of the requesting user and can be entered there as is
  • the entire cycle must be capable of being implemented by a business user, whose IT skills do not exceed knowledge of a basic office environment.
  • none of the operations necessary for the implementation of the cycle should require the writing of any line of code.
  • the requested information must be able to be supplied by the users requested without this requiring training on their part.
  • the information provided by the users requested must be verified in real time.
  • the implementation of the cycle must be non-intrusive. In particular, the cycle must not mobilize a server or any other device dedicated exclusively to the execution of one or more tasks necessary for its implementation.
  • the implementation of the cycle as well as its update must be able to be carried out in extremely short time ( ⁇ 1 day / man for a user whose computer skills do not exceed the knowledge of a basic office environment) in order that the information collected reflects as closely as possible the situation whose analysis is the subject of the cycle.
  • the present invention relates to a method allowing the implementation of data cycles in accordance with the prerequisites given above.
  • the problem set out above is today mainly dealt with by one or other of the 3 means set out below:
  • Web form The Web is a good way to provide requested users with input forms.
  • the HTML language natively assigns a certain number of instructions for this use and the major advantage of this solution is a deployment as a real thin client: no application is installed on the workstation of the users requested.
  • HTML forms as a data cycle support reveals several drawbacks.
  • HTML language content language
  • a programming language is then required (Javascript is frequently used) for this task, but the programming of information transmission directives is not within the reach of an office user.
  • HTML technology does not easily make it possible to carry out validity and consistency checks in real time on the data entered by the users requested.
  • Such controls can possibly be introduced by programming in an appropriate language but in this case, a verification of exhaustive consistency across all input sessions requires a great deal of information exchange with the data server, resulting in disabling bandwidth consumption
  • Distributed architecture By “Distributed architecture”, we mean any database supplied in particular by input interfaces distributed to the users requested. (It also appears, according to this acceptance, that Web forms are a special case of distributed architecture.)
  • the advantage of this configuration lies in the fact that the database whose accesses are distributed can be an integral part of the company's information system (IS) and that the data thus collected can be immediately made available to classical information processing processes (decision-making tools in particular)
  • IS company's information system
  • the distribution of access requires the installation of an input software component at each of the users requested, this installation requiring a dedicated skill and specific training so that the requested user can perform their input task.
  • Shared files are also a frequently used means of creating data cycles.
  • the requesting user creates a document with fields to fill in and then distributes this document to the users requested. It is their responsibility to complete the document they have received and then return it to the requesting user, who then gathers the information thus collected.
  • the requesting user most often creates a document in a standard office format, thus guaranteeing that the users requested can use it without installing any additional component and a priori without prior training.
  • the prior art also knows, from PCT patent application WO 02/25486 (Interquest), a method for collecting and processing information.
  • the invention presented in this PCT application relates to a method of collecting information from users of terminals connected to a data network, which consists in using the terminals via the network, and in submitting to the users of the terminals one or more questions from the list of questions.
  • the degree of disturbance affecting users can be kept as low as possible by defining a maximum number of questions to be answered by a single user.
  • For each question at least one statistical characteristic is determined on the basis of the responses received, when one or more responses to a given question are obtained.
  • the selection of questions may be based at least in part on said characteristic.
  • the present invention provides a software solution that meets the requirements of the context of using data cycles. It consists of four software modules, each serving one of the stages of a cycle: • Creation of the interrogation document; • Determination of the sub-populations of recipients, personalization of the interrogation document according to the recipients in transmission of this document to the recipients concerned; • creation of the desired data using said document; • consolidation and provision of the data collected.
  • the present invention relates, in its most general sense, to an electronic survey method comprising • a first step of generating an electronic form; • a step of distributing said electronic form on a plurality of recipient devices; • a step of informing said form, on each of said destination equipment; • a step of transmitting data from said form filled in from said recipient equipment to a mail server in the form of an electronic message according to the SMTP protocol; and • a step of automatic consolidation of said data collected on said messaging server by collection equipment.
  • the method further includes a step of producing a file in .csv format.
  • the method further comprises a step of sending an acknowledgment of receipt to said recipient equipment.
  • the method further comprises a step of statistical processing.
  • the method comprises an additional step of sending data from said statistical processing to said recipient equipment.
  • the method comprises an additional campaign management step consisting in monitoring the progress of the survey and possibly in issue reminders to said recipients.
  • the method further includes a compression step.
  • said compression applies to said form.
  • said compression applies to the data collected.
  • the method further includes a step of encrypting the collected data.
  • the step of generating an electronic form includes the use of filters allowing personalization according to characteristic data of the recipient.
  • the present invention also relates to an online survey system for implementing the method comprising at least means for generating electronic forms and means for transmitting data.
  • the electronic survey essentially consists of: • developing a questionnaire; • informing said questionnaire by a plurality of people; • automatic processing of responses.
  • the first phase of the process according to the invention consists in creating a questionnaire.
  • the questionnaire being in an electronic format, it is easy to add to it, by means of an adapted interface, hypertext links, buttons and additional fields ... It is essential, during this phase to provide an email address electronic system that will collect the responses.
  • the questionnaire is then completed by the respondents.
  • the filling of said questionnaire is carried out using downloaded client software.
  • a click sends the formatted responses in the form of a digital file to the predetermined email address.
  • This file can advantageously be compressed and / or encrypted before sending.
  • an additional module installed on a server, examines the emails intended for said email address responsible for collecting the responses.
  • the responses are processed, consolidated and results files are produced.
  • Personalized emails can be sent to people who answered.
  • statistical or reporting tools can be used in combination before the data is consolidated.
  • the interrogation document is a file intended to be read by an appropriate executable on the station of the recipient to whom it is transmitted and on which it organizes the collection of the data that the sender wishes to obtain.
  • This data can be of any type and must be able to be collected by any means that the recipient's workstation can understand. In a nonlimiting manner, it may in particular be data entered on the part of the user, data present on the user's workstation or in the environment accessible to him or data describing the workstation of the user or the environment accessible to him.
  • the implementation of the module for creating the interrogation document will call on the one hand for an object structuring defining the attributes of the document and the structure of the data storage before referral for consolidation and on the other hand has object classes defining the interaction components with the recipient's station.
  • object classes are mainly divided into 2 categories: o
  • objects whose role is to collect data In order to facilitate the implementation of cycles, MCDI will make extensive use of the usual widgets defined by the operating system of the workstation on which it is installed, as well as advanced support for the most frequent file formats, optionally.
  • the MCDI directly calls on the database drivers present on the computer on which it is installed, via high-level interfaces, ADO type.
  • the MCDI also integrates a certain number of application control interfaces so as to allow the integration into the document of files intended to be used dynamically, in particular for interacting with the tools associated with the data intended to be collected. on the recipient's workstation.
  • These interfaces which can in particular be of the COM or OLE type, provide intuitive access for the recipient to the local applications managing said files, said applications appearing to the user as integrated into the document, with all or part of their properties. and available functions.
  • MCDI allows the user to manage the granularity of the data collected by the various components used in the document.
  • each unitary data of each of the components is extracted by disregarding its collection context.
  • a given response from a given user is always represented by a line in the final CSV file, regardless of the structure of the document.
  • plans for consolidation by sets, in which data from objects with identical granularity are grouped together.
  • the MCDI allows the designer user to create a fully personalized consolidation model ex nihilo.
  • the query document is then created.
  • This document is mainly intended to be transmitted by email, two imperatives must be reconciled: o
  • the document must not be able to be altered by the mail servers.
  • the messaging servers can, depending on the case, receive a specific configuration affecting the messages they convey.
  • the interrogation document is in the form of a binary file itself composed of 2 stream files containing the two object classes described above: document structure and dependencies on the one hand, data objects on the other.
  • the document must be as light as possible so as not to be pushed back by the mail servers, which are often limited in volume. For this purpose, the final document is compressed, which also has the effect of encrypting the resulting file.
  • segmentation In order to send each recipient a document related to the information they have, it is necessary to personalize the query document according to one (or more) segmentation (s) that we will call “sub-populations" ". Said segmentations are frequently contained in the company's information system, as are the coordinates of the recipients of the document, frequently found in an LDAP-type directory.
  • the first task therefore consists in bringing these two pieces of information together. To do this, a certain number of requests are placed on the aforementioned systems. So that the demand on the servers hosting these systems is minimal, the information thus collected is gathered in a specific directory which can be refreshed field by field at the request of the user.
  • An interrogation cycle combines three elements: o An interrogation document created by the MCDI o A parameter file specifying on the one hand, the personalizations assigned to the interrogation document according to the sub-populations and on the other hand, information inherent to the course of the cycle such as its expected duration, the organization of recovery phases, the visualization of the degree of progress, etc. This file behaves like a script, allowing the re-execution of an entire cycle on refreshed parameters. o A set of sub-populations defined in the directory. The selection criteria are specified either absolutely (query on fixed parameters) or relative so as to envisage the automation of the selection process and these criteria are saved in the parameter file.
  • the user can browse it and perform the requested data supply operations. Some of these operations are manual (entry, selection %) others are automatic, either in that they arise from the entry operations, or in that they are carried out without the knowledge of the user ( system information requests, data embedded in the document, etc.)
  • the user can, at any time, save the state of his entry.
  • a file is then produced containing the structure of the responses: the data supplied are virtually attached to the class identifiers of the objects of the interrogation document which contained them.
  • the responses provided by the user can be stored on his workstation as a base. In this case, an additional interface is available, allowing you to browse this database, recall or delete all or part of the responses stored there and export this database to an ASCII data file.
  • the data creation module performs all the validation checks specified by the MCDI.
  • the execution of the control procedures can take place at three times: o When entering (by analyzing the data entered, selections made ...) o When the entry in a given object can only be checked once that - done, the control takes place when the object loses focus o During the request for data transmission (overall consistency, completeness)
  • the email is sent transparently and the destination address is never exposed to the user.
  • a configuration is made during installation, indicating the protocol to be used.
  • Operating system environment variables provide default messaging settings that can be changed by the user. Three levels of interaction with messaging are possible: o The very high level protocols provided by the OS, MAPI type. In this case, it is verified that the messaging support software is activated, on the one hand so that the sending is transparent to the user and on the other hand hides the destination address. o Intermediate level protocols provided by messaging, VIM type o Direct addressing of an SMTP server
  • the user is also asked for an identifier. This, compared to one or more environment variables, will allow the responses to be discriminated during consolidation.
  • a procedure for sending data by file is also available if the connection to the mail service fails.
  • the purpose of this operation is to supply data files containing the responses provided by the users. These files are created in .CSV format in order to be completely standard and usable in any context
  • This module performs the following tasks: 1) Searching in the environment variables for information relating to the cycles in progress 2) For each of the cycles, retrieving the information then connecting to the specified mail server. The connection is always made via the POP protocol 3) For each of the mails present on the mail server, verification of the fact that this mail does indeed contain an authentic data file as an attachment 4) Possibly, deletion of unauthenticated mails 5) For each authenticated email, download of the attached data file, decompression, structural and logical verification, possibly request for arbitration by the user of the consolidation module, addition to the data of information relating to the progress of the cycle then addition of the data to the appropriate data file. If the file does not exist, it is created at this time. 6) Possibly, deletion of the processed mails.

Abstract

La présente invention se rapporte à un procédé d'enquête électronique comportant . une première étape de génération d'un formulaire électronique ; . une étape de diffusion dudit formulaire électronique sur une pluralité d'équipements destinataires ; . une étape de renseignement dudit formulaire, sur chacun desdits équipements destinataires ; . une étape de transmission des données issues dudit formulaire renseigné depuis ledit équipement destinataire vers un serveur de messagerie sous la forme d'un message électronique selon le protocole SMTP ; . et une étape de consolidation automatique desdites données collectées sur ledit serveur de messagerie par un équipement de collecte. La présente invention se rapporte également à un système d'enquête en ligne pour la mise en oeuvre du procédé.

Description

PROCEDE D'ENQUETE ELECTRONIQUE
La présente invention se rapporte au domaine des solutions d'enquête en ligne. La présente invention se rapporte plus particulièrement à un procédé technique comportant différentes étapes techniques consistant à générer un formulaire électronique, diffuser et faire renseigner ledit formulaire, transmettre des données issues dudit formulaire renseigné puis consolider de façon automatique les données collectées .
L'invention se situe dans le champ des transferts de données et est spécifiquement destinée à faciliter la mise en place de cycles de données informatisés. Un cycle de données étant défini par la demande d'information d'un utilisateur requérant auprès d'utilisateurs destinataires, la fourniture de l'information demandée par lesdits destinataires, le retour, de l'information fournie vers l'utilisateur requérant, la consolidation et la mise à disposition des informations consolidées auprès de l'utilisateur requérant.
Le cycle de données est considéré comme achevé avec succès lorsque les conditions suivantes sont réunies : L'ensemble des utilisateurs destinataires a fourni l'information requise Les données consolidées sont cohérentes avec le système d'information de l'utilisateur requérant et peuvent y être introduites en l'état
En outre, les cycles de données étant destinés à recueillir de l'information ayant un sens métier, il importe que les conditions suivantes soient réunies : Le cycle dans son intégralité doit pouvoir être mis en œuvre par un utilisateur métier, dont les compétences informatiques n'excèdent pas la connaissance d'un environnement bureautique de base. En particulier, aucune des opérations nécessaires à la mise en œuvre du cycle ne doit nécessiter l'écriture de la moindre ligne de code. L'information demandée doit pouvoir être fournie par les utilisateurs sollicités sans que cela ne nécessite de formation de leur part. - Afin de minimiser le nombre de cycles nécessaires à l'obtention d'une information formellement satisfaisante, les informations fournies par les utilisateurs sollicités doivent être vérifiées en temps réel. La mise en œuvre du cycle se doit d'être non intrusive. En particulier, le cycle ne doit pas mobiliser de serveur ou tout autre appareillage dédié exclusivement à l'exécution d'une ou plusieurs tâches nécessaires à sa mise en place. La mise en œuvre du cycle ainsi que sa mise à jour doivent pouvoir s'effectuer dans des délais extrêmement courts (<1 jour / homme pour un utilisateur dont les compétences informatiques n'excèdent pas la connaissance d'un environnement bureautique de base) afin que l'information recueillie reflète au plus près la situation dont l'analyse fait l'objet du cycle.
En d'autres termes, la présente invention se rapporte à un procédé permettant la mise en place de cycles de données en accord avec les pré-requis donnés ci-dessus. La problématique énoncée ci-dessus est aujourd'hui principalement traitée par l'un ou l' autres des 3 moyens énoncés ci-après :
• Formulaire Web Le Web est un bon moyen de mettre à disposition des utilisateurs sollicités des formulaires de saisie. Le langage HTML affecte nativement un certain nombre d'instructions à cet usage et l'avantage majeur de cette solution est un déploiement en véritable client léger : aucune application n'est installée sur le poste des utilisateurs sollicités. Cependant, l'utilisation de formulaires HTML comme support de cycle de données fait apparaître plusieurs inconvénients .
Tout d'abord, si le langage HTML, langage de contenu, prévoit l'affichage de composants de saisie (listes déroulantes, zones d'édition, boutons radio, etc.), il ne permet pas de transmettre les données saisies par l'utilisateur. Un langage de programmation est alors requis (Javascript est fréquemment utilisé) pour cette tâche, mais la programmation des directives de transmissions d'informations n'est pas à la portée d'un utilisateur bureautique .
De plus, la réception des données transmises par les utilisateurs sollicités nécessite la maintenance d'une base de données sur un serveur dédié, gérant la consolidation des informations reçues. Là encore, ces tâches ne sont pas à la portée d'un utilisateur bureautique et de plus, nécessitant des composants logiciels et matériels dédiés, elle n'est pas non intrusive.
Il est également à noter que la technologie HTML ne permet pas aisément d'effectuer en temps réel des contrôles de validité et de cohérence sur les données saisies par les utilisateurs sollicités. De tels contrôles peuvent éventuellement être introduits par programmation dans un langage approprié mais dans ce cas, une vérification de cohérence exhaustive sur l'ensemble des sessions de saisie nécessite de très nombreux échanges d'informations avec le serveur de données, entraînant une consommation de bande passante handicapante
• Architecture distribuée Par « Architecture distribuée », nous entendons toute base de données alimentée notamment par des interfaces de saisie distribuées aux utilisateurs sollicités. (Il apparaît d'ailleurs selon cette acceptation que les formulaires Web sont un cas particulier d'architecture distribuée.)
L' intérêt de cette configuration réside dans le fait que la base de donnée dont les accès sont distribués peut être partie intégrante du système d'information (SI) de l'entreprise et que les données ainsi recueillies peuvent être immédiatement mises à la disposition des processus classiques de traitement d'information (outils décisionnels, notamment)
L' inconvénient de ce type de solution découle de son intérêt : toute modification d'une architecture distribuée peut impacter l'ensemble du SI et doit donc être envisagée globalement afin de ne pas mettre en péril l'intégrité du SI.
De plus, la distribution des accès nécessite l'installation chez chacun des utilisateurs sollicités d'un composant logiciel de saisie, cette installation nécessitant une compétence dédiée et une formation spécifique afin que l'utilisateur sollicité puisse effectuer sa tâche de saisie.
L'utilisation d'architectures distribuées à des fins de cycles de données est donc peu appropriée car la réactivité permanente exigée est très coûteuse en termes de ressources mobilisées.
• Fichiers partagés Les fichiers partagés sont également un moyen fréquemment utilisé pour créer des cycles de données . L'utilisateur requérant créé un document comportant des zones à renseigner puis diffuse ce document aux utilisateurs sollicités . Charge à eux de compléter le document qu' ils ont reçu puis de le renvoyer à l'utilisateur requérant, lequel rassemble alors les informations ainsi recueillies.
L'intérêt de cette solution est sa facilité de mise en œuvre, pour laquelle l'utilisateur requérant a la possibilité d'agir en toute autonomie.
De plus, l'utilisateur requérant créé le plus souvent un document sur un format bureautique standard, garantissant ainsi que les utilisateurs sollicités pourront l'utiliser sans installation d'un quelconque composant additionnel et a priori sans formation préalable.
Cependant, le revers de cette facilité de création est un manque global de fiabilité. En effet : o L'utilisation d'un document comme support d'information ne garantit pas l'intégrité des données saisies . o Les informations souhaitées n'étant pas organisées sous forme de base, aucune cohérence n'existe a priori avec le modèle de données du SI : les données recueillies ne peuvent y être réintégrées en l'état. o Une fois les documents remplis et retournés à l'utilisateur requérant, la consolidation de l'ensemble des informations collectées n'est pas automatisée et se révèle donc longue, fastidieuse et source d'erreurs.
La programmation de tâches d'exécutions (macros) permet de combler en partie certaines lacunes du processus mais dans ce cas, les coûts de développement et de maintenance de ces tâches applicatives empêchent d' atteindre la réactivité attendue. Ces 3 méthodes confrontées à la présente invention voient leur qualification à la création de cycles de données schématisées sur la Figure 1.
L'art antérieur connaît également, par la demande de brevet PCT WO 02/25486 (Interquest) , un procédé pour collecter et traiter des informations. L'invention présentée dans cette demande PCT concerne un procédé de collecte d'informations à partir d'utilisateurs de terminaux reliés à un réseau de données, qui consiste à utiliser les terminaux via le réseau, et à soumettre aux utilisateurs des terminaux une ou plusieurs questions figurant dans la liste de questions établie. Ainsi, on peut maintenir à un niveau aussi faible que possible le degré de perturbation affectant les utilisateurs en définissant un nombre maximum de questions auxquelles doit répondre un utilisateur unique. Pour chaque question, au moins une caractéristique statistique est déterminée sur la base des réponses reçues, lorsqu'une ou plusieurs réponses à telle ou telle question sont obtenues . La sélection des questions peut reposer au moins en partie sur ladite caractéristique.
On connaît dans l'art antérieur peu de procédés ou systèmes d'enquête électronique. Le but de ce type de solution est, bien entendu, de remplacer les formulaires de type « papier », ce qui permet de réaliser des gains de temps significatifs .
La présente invention propose une solution logicielle satisfaisant aux exigences du contexte d'utilisation des cycles de données . Elle se compose de quatre modules logiciels, chacun servant l'une des étapes d'un cycle : • Création du document d' interrogation ; • Détermination des sous-populations de destinataires, personnalisation du document d' interrogation en fonction des destinataires en transmission dudit document aux destinataires concernés ; • création de la donnée souhaitée à l'aide dudit document ; • consolidation et mise à disposition des données recueillies .
À cet effet, la présente invention concerne, dans son acception la plus générale, un procédé d'enquête électronique comportant • une première étape de génération d'un formulaire électronique ; • une étape de diffusion dudit formulaire électronique sur une pluralité d'équipements destinataires ; • une étape de renseignement dudit formulaire, sur chacun desdits équipements destinataires ; • une étape de transmission des données issues dudit formulaire renseigné depuis ledit équipement destinataire vers un serveur de messagerie sous la forme d'un message électronique selon le protocole SMTP ; et • une étape de consolidation automatique desdites données collectées sur ledit serveur de messagerie par un équipement de collecte. De préférence, le procédé comporte en outre une étape de production d'un fichier au format .csv. Avantageusement, le procédé comporte en outre une étape d'envoi d'un accusé de réception à destination desdits équipements destinataires Selon un mode de mise en œuvre, le procédé comporte en outre une étape de traitement statistique. De préférence, le procédé comporte une étape additionnelle d'envoi de données issues dudit traitement statistique à destination desdits équipements destinataires Selon une variante, le procédé comporte une étape additionnelle de gestion de campagne consistant à suivre l'avancement de l'enquête et éventuellement à émettre des relances auprès desdits destinataires . De préférence, le procédé comporte en outre une étape de compression. Selon une première variante, ladite compression s'applique audit formulaire. Selon une seconde variante, ladite compression s'applique aux données collectées. Avantageusement, le procédé comporte en outre ' une étape d'encryptage des données collectées. De préférence, l'étape de génération d'un formulaire électronique comporte l'utilisation de filtres permettant une personnalisation en fonction de données caractéristiques du destinataire. La présente invention se rapporte également à un système d'enquête en ligne pour la mise en œuvre du procédé comprenant au moins des moyens de génération de formulaires électroniques et des moyens de transmission de données.
On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées : • la Figure 1 représente l'état de la technique ; • la Figure 2 illustre un mode de mise en œuvre du procédé selon l'invention.
L'enquête électronique consiste essentiellement en : • l'élaboration d'un questionnaire ; • le renseignement dudit questionnaire par une pluralité de personnes ; • le traitement automatique des réponses .
La première phase du procédé selon l'invention consiste en la création d'un questionnaire. Le questionnaire étant sous un format électronique, il est aisé d'y ajouter, au moyen d'une interface adaptée, des liens hypertextes, des boutons et champs complémentaires ... Il est essentiel, lors de cette phase de fournir une adresse de courrier électronique qui permettra de recueillir les réponses .
Le questionnaire est ensuite renseigné par les personnes interrogées. Le remplissage dudit questionnaire est réalisé au moyen d'un logiciel client téléchargé. À la fin du remplissage, un clic permet d'envoyer les réponses formatées sous forme d'un fichier numérique à l'adresse de courrier électronique prédéterminée. Ce fichier peut avantageusement être compressé et/ou encrypté avant l'envoi.
Enfin, un module complémentaire, installé sur un serveur, examine les courriers électroniques destinés à ladite adresse électronique chargée de recueillir les réponses. Les réponses sont traitées, consolidées et des fichiers de résultats sont produits . Des courriers électroniques personnalisés peuvent être envoyés aux personnes qui ont répondu. Éventuellement, des outils statistiques ou de reporting peuvent être mis en œuvre en combinaison avant la consolidation des données . Le procédé selon l'invention sera maintenant décrit plus en détail.
I . Création du document d' interrogation Le document d' interrogation est un fichier destiné à être lu par un exécutable approprié sur le poste du destinataire à qui il est transmis et sur lequel il organise la collecte de la donnée que l'expéditeur souhaite obtenir. Cette donnée peut être de tout type et doit pouvoir être collectée par n'importe quel moyen que le poste de travail du destinataire peut appréhender. De façon non limitative, il peut notamment s'agir de donnée saisie de la part de l'utilisateur, de donnée présente sur le poste de l'utilisateur ou dans l'environnement qui lui est accessible ou de donnée décrivant le poste de l'utilisateur ou l'environnement qui lui est accessible.
De façon préférentielle, l' implémentation du module de création du document d'interrogation (MCDI) fera appel d'une part à une structuration objet définissant les attributs du document et la structure du stockage de données avant renvoi pour consolidation et d'autre part a des classes d'objets définissant les composants d'interaction avec le poste du destinataire. Ainsi, de ces ensembles de classes prédéfinies peuvent être dérivés un nombre infini de composants d'interaction en fonction des besoins. Les classes d'objets se divisent principalement en 2 catégories : o D'une part les objets définissant l'habillage du document, les aspects graphiques et multimédia. Ces objets définissent également la structure du document et sa logique de visualisation. o D'autre part les objets dont le rôle est de collecter la donnée. Afin de faciliter la mise en place des cycles, MCDI fera un usage extensif des widgets usuels définis par le système d'exploitation du poste de travail sur lequel il est installé, ainsi qu'un support poussé des formats de fichiers les plus fréquents, le cas échéant.
Parmi les objets dont le rôle est de collecter de la donnée, certains d'entre eux se présentent à l'utilisateur destinataire sous forme de listes d' items . A ce groupe appartiennent notamment les listes déroulantes, cases à cocher, boutons radio, etc. Afin de garantir la cohésion des données recueillies en fin de cycle avec le système d'informations présent dans l'entreprise, ces composants peuvent être alimentés par des requêtes sur ce même système d' informations . Afin d' éviter toute programmation pour l'utilisateur concepteur, le MCDI fait directement appel aux drivers de bases de données présents sur le poste sur lequel il est installé, via des interfaces de haut niveau, type ADO. Le MCDI intègre également un certain nombre d'interfaces de contrôle d'applications de façon à permettre l'intégration dans le document de fichiers destinés à être utilisés de façon dynamique, notamment pour interagir avec les outils associés à la donnée destinée à être collectée sur le poste de travail du destinataire. Ces interfaces, qui peuvent notamment être de type COM ou OLE permettent d'accéder de façon intuitive pour le destinataire aux applications locales gérant lesdits fichiers, les dites applications apparaissant à l'utilisateur comme intégrées dans le document, avec tout ou partie de leurs propriétés et fonctions disponibles.
Le MCDI permet à l'utilisateur de gérer la granularité des données collectées par les différents composants utilisés dans le document.
Par défaut, chaque donnée unitaire de chacun des composants est extraite en faisant abstraction de son contexte de collecte. Ainsi, lors de la consolidation, une réponse donnée d'un utilisateur donné est toujours représentée par une ligne dans le fichier CSV final, quelle que soit la structure du document. Néanmoins, il est également prévu des modes de consolidation par ensembles, dans lesquels sont regroupées les données issues des objets adressant une granularité identique. Enfin, le MCDI permet à l'utilisateur concepteur de créer un modèle de consolidation ex nihilo, totalement personnalisé .
Une fois la conception achevée, le document d'interrogation est alors créé. Ce document étant principalement destiné à être transmis par mail, deux impératifs doivent être conciliés : o Le document ne doit pas pouvoir être altéré par les serveurs de messagerie. Les serveurs de messagerie peuvent, suivant le cas, recevoir un paramétrage particulier affectant les messages qu'ils véhiculent. L'atteinte la plus fréquente concerne les sauts de lignes, qui peuvent être gérés de façon très diverse d'un serveur à l'autre. Afin d'éviter cet écueil, le document d'interrogation se présente sous forme d'un fichier binaire lui-même composé de 2 fichiers-flux (streams) contenant les deux classes d'objets décrites ci-dessus : structure et dépendances du document d'une part, objets de données d'autre part. o Le document doit être aussi léger que possible afin de ne pas être refoulé par les serveurs de messagerie, fréquemment limités en volumetrie. À cet effet, le document final est compressé, ce qui a également pour effet de crypter le fichier résultant.
II. Détermination des populations de destinataires, personnalisation et transmission du document d'interrogation
Afin d'adresser à chaque destinataire un document en rapport avec l'information qu'il possède, il est nécessaire de personnaliser le document d'interrogation en fonction d'une (ou plusieurs) segmentation (s) que nous appellerons « sous-populations ». Les dites segmentations sont fréquemment contenues dans le système d' information de l'entreprise, de même que les coordonnées des destinataires du document, fréquemment présentes dans un annuaire type LDAP.
La première tache consiste donc à rapprocher ces deux informations . Pour ce faire, un certain nombre de requêtes sont mises en places sur les systèmes précités. Afin que la sollicitation sur les serveurs hébergeant ces systèmes soit minimale, les informations ainsi recueillies sont rassemblées au sein d'un annuaire spécifique pouvant être rafraîchi champ par champ à la demande de l'utilisateur.
À partir des données de cet annuaire seront créés les cycles d'interrogation. Un cycle d'interrogation combine trois éléments : o Un document d' interrogation créé par le MCDI o Un fichier de paramètres spécifiant d'une part, les personnalisations affectés au document d' interrogation en fonction des sous-populations et d'autre part, des informations inhérentes au déroulement du cycle telles que sa durée prévue, l'organisation de phases de relances, la visualisation du degré d'avancement, etc. Ce fichier se comporte comme un script, permettant la ré-exécution de l'ensemble d'un cycle sur des paramètres rafraîchis. o Un ensemble de sous-populations définies dans l'annuaire. Les critères de sélection sont spécifiés de façon absolue (requête sur paramètres fixes) ou relative de façon à envisager l'automatisation du processus de sélection et ces critères sont enregistrés dans le fichier de paramètres .
L'exécution du fichier de paramètres se décompose comme suit :
1) Rafraîchissement éventuel de l'annuaire 2) Requête sur l'annuaire et extraction de sous- populations 3) Pour chaque individu de chaque sous-population, création d'un document d'interrogation basé sur le document d'interrogation principal et affecté des modifications spécifiées pour la sous-population en cours 4) Envoi des documents d'interrogations personnalisés aux individus composant les sous-populations . Afin d'optimiser la phase d'envoi, celle-ci se fait par groupe, un unique mail étant effectivement transmis à l'ensemble des individus composant une sous-population donnée 5) Création de variables d'environnement destinées, en rapprochant la configuration du cycle aux informations issues de la consolidation des données renvoyées, au pilotage du cycle.
III. Création de la donnée La création de la donnée s'opère sur le poste de l'utilisateur sollicité. Celui-ci reçoit le document d'interrogation et l'ouvre avec le module dédié.
Il est à noter que, fréquemment, les utilisateurs possèdent des droits d'accès limités, notamment en ce qui concerne la création de fichiers . Afin de pallier cet écueil, toutes les opérations de décompression du document d'interrogation et de ses dépendances s'effectuent en mémoire vive à l'aide de flu -mémoire (memorystreams)
Une fois le document ouvert, l'utilisateur peut le parcourir et effectuer les opérations de fourniture de données demandées . Certaines de ces opérations sont manuelles (saisie, sélection...) d'autres sont automatiques, soit en ce qu'elles découlent des opérations de saisie, soit en ce qu'elles s'effectuent à l'insu de l'utilisateur (demandes d'informations système, données intégrées au document, etc.) L'utilisateur peut, à tout moment, sauvegarder l'état de sa saisie. Un fichier est alors produit contenant la structure des réponses : les données fournies y sont virtuellement rattachées aux identificateurs de classe des objets du document d'interrogation qui les ont contenues. Ainsi il est possible d'une part de fractionner la saisie et d'autre part d'utiliser les données ainsi enregistrées sur d'autres documents similaires formellement. Si cela est spécifié dans le MCDI, les réponses fournies par l'utilisateur peuvent être stockées sur son poste sous forme de base. Dans ce cas, une interface supplémentaire est disponible, permettant de parcourir cette base, de rappeler ou d'effacer tout ou partie des réponses qui y sont stockées et d'exporter cette base vers un fichier de données ASCII.
Le module de création de donnée exécute tous les contrôles de validation spécifiés par le MCDI. L'exécution des procédures de contrôle peut avoir lieu à trois moments : o Lors de la saisie (par analyse des données saisie, des sélections effectuées...) o Lorsque la saisie dans un objet donnée ne peut être contrôlée qu'une fois celle-ci effectuée, le contrôle a lieu lorsque l'objet perd la focalisation o Lors de la requête de transmission des données (cohérence d'ensemble, exhaustivité)
Lorsque l'utilisateur effectue une requête de transmission de données, une vérification globale est effectuée puis les données sont organisées en mémoire suivant le modèle spécifie dans le MCDI . Enfin, un fichier est créé contenant les données réagencées au format CSV, puis ce fichier est compressé et envoyé par mail l'adresse spécifiée dans le MCDI en tant que fichier joint.
Pour des raisons évidentes de sécurité, l'envoi du mail se fait de façon transparente et l'adresse de destination n'est jamais exposée à l'utilisateur.
Afin d'assurer l'envoi des réponses par mail, un paramétrage est effectué lors de l'installation, indiquant le protocole à utiliser. Les variables d'environnement du système d'exploitation fournissent des paramètres de messagerie par défaut qui pourront être modifiés par l'utilisateur. Trois niveaux d'interaction avec la messagerie sont possibles : o Les protocoles de très haut niveau fournis par l'OS, type MAPI. Dans ce cas, il est vérifié que le logiciel de support de messagerie est activé, afin d'une part que l'envoi soit transparent pour l'utilisateur et d'autre part de masque l'adresse de destination. o Les protocoles de niveau intermédiaire fournis par la messagerie, type VIM o L'adressage direct d'un serveur SMTP
Un identifiant est de plus demandé à l'utilisateur. Celui-ci, comparé à une ou plusieurs variables d'environnement, permettra de discriminer les réponses lors de la consolidation.
Une procédure d' envoi des données par fichier est également disponible en cas d'échec de la connexion à la messagerie.
IV. Consolidation et mise à disposition des données recueillies La consolidation et la mise à disposition des données recueillies sont effectuées à l'aide d'un module dédié.
Le but de cette opération est l'alimentation de fichiers de données contenant les réponses fournies par les utilisateurs. Ces fichiers sont créés au format .CSV afin d' être totalement standard et utilisable dans n' importe quel contexte
Ce module effectue les tâches suivantes : 1) Recherche dans les variables d'environnement des informations relatives aux cycles en cours 2) Pour chacun des cycles, récupération des informations puis connexion au serveur de messagerie indiqué. La connexion s'effectue toujours via le protocole POP 3) Pour chacun des mails présents sur le serveur de messagerie, vérification du fait que ce mail comporte bien un fichier de données authentique en pièce jointe 4) Éventuellement, suppression des mails non authentifiés 5) Pour chaque mail authentifié, téléchargement du fichier de données attaché, décompression, vérification structurelle et logique, éventuellement demande d'arbitrage de l'utilisateur du module de consolidation, ajout aux données d'informations relatives à l'avancée du cycle puis ajout des données au fichier de données adéquat. Si le fichier n'existe pas, il est créé à ce moment. 6) Éventuellement, suppression des mails traités. 7) Éventuellement, envoi à l'expéditeur des données d'un mail comportant les informations relatives à ses données (intégration avec succès, refus pour cause technique (doublon...), etc.). Ce mail est personnalisé à l'aide de variables fournies par le fichier de données d' une part et les paramètres du cycle d'autre part. 8) Éventuellement, déclenchement d'une tâche externe en fonction des paramètres du cycle. Cette tâche externe peut être de tout type (EXE, BAT, COM...) et est activée par le shell de l'OS. 9) Éventuellement, maintien d'un fichier d'événements (log) au format CSV. II est à noter que le module de consolidation peut être intégralement utilisé en mode ligne de commande (batch) dans le cadre d'une intégration de processus de production.
L' invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est à même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet.

Claims

REVENDICATIONS
1 - Procédé d'enquête électronique caractérisé en ce qu'il comporte la succession d'étapes suivantes : • une étape préalable de téléchargement d'un module applicatif spécifique pour chaque équipement d'une pluralité d'équipements destinataires ; • une étape de génération d'un formulaire électronique ; • une étape de détermination de sous-populations de destinataires et de personnalisation dudit formulaire en fonction des destinataires ; • une étape de diffusion dudit formulaire électronique sur chaque équipement de la pluralité d' équipements destinataires ; • une étape de décompression dudit formulaire électronique en mémoire vive à l'aide de flux-mémoire ; • une étape de renseignement dudit formulaire, sur chacun desdits équipements destinataires ; • une étape de traitements de données numériques issues de l'étape de renseignement au moyen dudit module applicatif spécifique installé sur chaque équipement destinataire, lesdits traitements comprenant notamment l'exécution locale de procédures de contrôle ; • une étape de transmission des données issues dudit formulaire renseigné depuis ledit équipement destinataire vers un serveur de messagerie sous la forme d'un message électronique selon le protocole SMTP ; et • une étape de consolidation automatique desdites données collectées sur ledit serveur de messagerie par un équipement de collecte. 2 - Procédé d'enquête électronique selon la revendication 1, caractérisé en ce qu'il comporte en outre une étape de production d'un fichier au format .csv. 3- Procédé d' enquête électronique selon la revendication 1 ou 2, caractérisé en ce qu'il comporte en outre une étape d' envoi d'un accusé de réception à destination desdits équipements destinataires 4 - Procédé d'enquête électronique selon la revendication 1, 2 ou 3, caractérisé en ce qu'il comporte en outre une étape de traitement statistique.
5 - Procédé d' enquête électronique selon la revendication 4, caractérisé en ce qu'il comporte une étape additionnelle d'envoi de données issues dudit traitement statistique à destination desdits équipements destinataires
6 - Procédé d'enquête électronique selon l'une quelconque des revendications précédentes, caractérisé en ce qu' il comporte une étape additionnelle de gestion de campagne consistant à suivre l'avancement de l'enquête et éventuellement à émettre des relances auprès desdits destinataires .
7 - Procédé d'enquête électronique selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte en outre une étape de compression. 8 - Procédé d' enquête électronique selon la revendication 7, caractérisé en ce que ladite compression s'applique audit formulaire. 9 - Procédé d'enquête électronique selon la revendication 1, caractérisé en ce que ladite compression s'applique aux données collectées. 10 - Procédé d'enquête électronique selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte en outre une étape d'encryptage des données collectées . 11 - Procédé d'enquête électronique selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape de génération d'un formulaire électronique comporte l'utilisation de filtres permettant une personnalisation en fonction de données caractéristiques du destinataire .
12 - Système d'enquête en ligne pour la mise en œuvre du procédé selon l'une quelconque des revendications précédentes comprenant au moins des moyens de génération de formulaires électroniques et des moyens de transmission de données .
EP04816236A 2003-09-25 2004-09-24 Procede d'enquete electronique Ceased EP1676233A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0311255A FR2860318A1 (fr) 2003-09-25 2003-09-25 Procede d'enquete electronique
PCT/FR2004/050461 WO2005031620A2 (fr) 2003-09-25 2004-09-24 Procede d’enquete electronique

Publications (1)

Publication Number Publication Date
EP1676233A2 true EP1676233A2 (fr) 2006-07-05

Family

ID=34307164

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04816236A Ceased EP1676233A2 (fr) 2003-09-25 2004-09-24 Procede d'enquete electronique

Country Status (3)

Country Link
EP (1) EP1676233A2 (fr)
FR (1) FR2860318A1 (fr)
WO (1) WO2005031620A2 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102955846B (zh) * 2012-10-25 2015-11-25 北京奇虎科技有限公司 文件收集方法与装置
CN102968449B (zh) * 2012-10-25 2015-11-25 北京奇虎科技有限公司 文件收集系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0995163A1 (fr) * 1998-05-13 2000-04-26 Customer Cast, Inc. Systeme de sondage aupres de la clientele et procede correspondant
US6236975B1 (en) * 1998-09-29 2001-05-22 Ignite Sales, Inc. System and method for profiling customers for targeted marketing
US6431875B1 (en) * 1999-08-12 2002-08-13 Test And Evaluation Software Technologies Method for developing and administering tests over a network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005031620A2 *

Also Published As

Publication number Publication date
WO2005031620A2 (fr) 2005-04-07
WO2005031620A3 (fr) 2005-06-09
FR2860318A1 (fr) 2005-04-01

Similar Documents

Publication Publication Date Title
US9514239B2 (en) System and method for managing content on a network interface
US20070157096A1 (en) GUI modeling of web services
EP2404433A1 (fr) Procédé et système de gestion multicritères de notifications de présence
WO2005109814A2 (fr) Systeme et procede de traçabilite de contenus sur internet
US20070156868A1 (en) Efficient dynamic discovery of web services
EP2179538A2 (fr) Procede de gestion d&#39;un processus collaboratif au moyen de messages electroniques
EP1422872A1 (fr) Procédé et dispositif modulaire de traçage d&#39;un message multimédia à travers un réseau de télécommunications
WO2002087191A2 (fr) Système et procédé pour la distribution dynamique de données et/ou de services
EP2187321B1 (fr) Procédé et dispositif d&#39;édition d&#39;un objet représenté dans une page web
EP1559258A2 (fr) Architecture informatique en reseau multi-etages
EP0755001A1 (fr) Architecture d&#39;habillage d&#39;applications pour une plate-forme informatique
WO2009121808A1 (fr) Procede de gestion de messages electroniques a partir d&#39;un client de messagerie et systeme pour mettre en oeuvre le procede
EP3506566B1 (fr) Procédé et dispositif pour la surveillance à distance d&#39;objets connectés multiples
EP1676233A2 (fr) Procede d&#39;enquete electronique
CA2380297A1 (fr) Procede de transmission d&#39;un message entre deux ordinateurs relies a un reseau et systeme de messagerie correspondant
WO2008050042A2 (fr) Procede et systeme de gestion des capacites informatiques d&#39;un terminal
EP1658561A1 (fr) Procede et dispositif pour l interfacage graphique
WO2020136126A1 (fr) Reseau de communication securisee et tracee
EP3475847B1 (fr) Serveur de statistiques pour optimisation de requêtes client-serveur
FR3128840A1 (fr) Supervision du fonctionnement d’un service de transmission de données mis en œuvre selon au moins deux technologies différentes
FR3025625A1 (fr) Generation et partage d&#39;applications personnalisees de communication
WO2023169922A1 (fr) Procede de partage de documents electroniques energetiquement sobre et systeme associe
EP1295203A1 (fr) Procede de structuration, de transfert et d&#39;interpretation d&#39;un ensemble d&#39;informations destinees a la conception d&#39;interfaces graphiques
FR2813476A1 (fr) Reseau externe d&#39;aide a la vente et au conseil pour des produits et articles
FR3014624A1 (fr) Procede de traitement de donnees multivaluees

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060421

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: DURAND, NICOLAS

Inventor name: PANCHER, SEBASTIEN

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20090518

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20130618