FR2860318A1 - Procede d'enquete electronique - Google Patents

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 30 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: 2860318 2 Le cycle dans son intégralité doit pouvoir être mis en oeuvre 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 oeuvre 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 oeuvre 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 oeuvre 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 2860318 3 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 terme 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 oeuvre, 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 25 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.

2860318 7 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 25 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 30 équipement de collecte.

De préférence, le procédé comporte en outre une étape de production d'un fichier au format.csv.

2860318 8 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 oeuvre, le procédé comporte en 5 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 20 é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 oeuvre 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 ciaprè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 oeuvre du procédé selon l'invention.

L'enquête électronique consiste essentiellement en: 5 ^ 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 oeuvre en combinaison avant la consolidation des données.

Le procédé selon l'invention sera maintenant décrit plus en détail.

1. 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 a ê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 20 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 2860318 13 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 volumétrie. A 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 souspopulations . 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.

A 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 5 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 flux-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 2860318 16 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 25 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 20 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 35 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 5 un fichier de données authentique en pièce jointe 4) Eventuellement, 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) Eventuellement, suppression des mails traités.

7) Eventuellement, 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) Eventuellement, 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) Eventuellement, maintien d'un fichier d'évènements (log) au format CSV.

Il est à noter que le module de consolidation peut 30 ê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 35 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 (9)

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'un pluralité d'équipements destinataires; É une étape de génération d'un formulaire électronique; É 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 20 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 25 é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 30 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. 10 15

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 7, caractérisé en ce que ladite compression s'applique aux données collectées.

- Procédé d'enquête électronique selon l'une 35 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 oeuvre 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.