FR2942335A1 - Procede et systeme d'information pour traiter des requetes au sein d'une entite incluant une pluralite de services - Google Patents

Abstract

Procédé pour traiter des requêtes au sein d'une entité incluant une pluralité de services, comprenant des étapes de collecte d'une requête via un canal de communication sélectionné parmi une pluralité de canaux de communication disponibles, d'analyse préalable de la requête collectée, pour identifier un service cible parmi la pluralité de services, de transfert de cette requête ainsi analysée vers une application logicielle associée au service cible identifié, de traitement de la requête par cette application logicielle, de génération d'un document de réponse à cette requête, et une émission de ce document de réponse via un canal de communication sélectionné parmi la pluralité de canaux de communication. Ce procédé met en oeuvre au moins un objet logiciel d'information constituant un parapheur numérique, ce parapheur numérique étant accédé et activé au cours des étapes de collecte et de traitement. La réalisation des étapes de génération et/ou d'émission de document est conditionnée par l'état du parapheur numérique.

Description

Procédé et système d'information pour traiter des requêtes au sein d'une entité incluant une pluralité de services La présente invention concerne un procédé pour traiter des requêtes au sein d'une entité incluant une pluralité de services. Elle vise également un système d'information mettant en oeuvre le procédé selon l'invention. Le domaine de la présente invention est plus particulièrement celui des administrations publiques, municipales ou territoriales, et des plus généralement celui des organisations confrontées au traitement d'un grand nombre de requêtes émises par des citoyens, des usagers ou utilisateurs de ces entités. Le traitement des requêtes dans une entité structurée en services, groupes ou départements, suit une tendance générale d'informatisation et d'automatisation que l'on observe dans l'ensemble des administrations et organisation. Toutefois, cette informatisation croissante s'effectue de manière relativement désorganisée dans la mesure ou les solutions informatiques proposées aux administrateurs sont associées à des métiers ou des services particuliers, ce qui a pour conséquence de multiplier le nombre de solutions dites métier de type vertical avec pour fonction de traiter l'ensemble des requêtes correspondant à un métier particulier. Ainsi, il n'est pas rare de rencontrer dans une administration municipale plusieurs dizaines de solutions métier complètement indépendantes. Ceci a pour conséquence de conduire à un système d'information disparate impliquant une maintenance coûteuse et présentant des performances médiocres dans le traitement des requêtes. Par ailleurs, l'organisation verticale du traitement des requêtes rend très difficile une gestion rationalisée et sécurisée des requêtes. D'autre part, cette gestion est rendue complexe par la multiplication des canaux de communication : ainsi un usager peut saisir l'administration par courrier postal, par courrier électronique, par un formulaire en ligne, par téléphone, par télécopie ou en s'adressant naturellement au guichet ou à un accueil physique. Les requêtes sont donc enregistrées sur des supports ou avec des outils très différents et ne communiquant pas. - 2 Le but de la présente invention est de proposer une nouvelle approche dans le traitement des requêtes qui assure à la fois une rationalisation des processus de traitement et une traçabilité de ce traitement dans le contexte d'une pluralité de services équipés de solutions logicielles spécifiques, tout en prenant en compte l'aspect multicanal du problème. Cet objectif est atteint avec un procédé pour traiter des requêtes au sein d'une entité incluant une pluralité de services, comprenant des étapes suivantes : - une collecte d'une requête transmise via un canal de communication employé parmi une pluralité de canaux de communication disponibles, - une analyse préalable de la requête collectée, pour identifier un service cible parmi ladite pluralité de services, - une redirection de ladite requête vers ledit service cible identifié, - un traitement de la requête par une application logicielle associée audit service cible, - une génération d'un document de réponse à ladite requête, et - une émission dudit document de réponse via un canal de communication sélectionné parmi ladite pluralité de canaux de communication. Suivant l'invention, ce procédé met en oeuvre au moins un objet logiciel d'information constituant un parapheur numérique, ce parapheur numérique étant accédé et activé au cours des étapes de collecte et de traitement, et en ce que la réalisation des étapes de génération et/ou d'émission de document est conditionnée par l'état dudit parapheur numérique. Ainsi, avec la présente invention, il devient possible de procurer à une administration ou une organisation abritant de multiples services un procédé de traitement de requêtes conciliant automatisation et homogénéisation des traitements, tout en assurant les fonctions de validation et de traçabilité procurées par un parapheur. 2942335 -3 De plus, la collecte des requêtes peut être effectuée avec redirection automatique vers le service cible quel que soit le canal de communication employé parmi une pluralité de canaux. Plus particulièrement, lorsque le procédé selon l'invention est mis en 5 oeuvre dans des services administratifs municipaux, il contribue à la proposition d'une réelle gestion des relations avec les citoyens (GRC). On dispose ainsi d'un procédé de traitement procurant une amélioration de la qualité du service rendu aux citoyens, de la productivité des agents et de respect de l'environnement par la dématérialisation des 10 flux. De plus, comme le procédé selon l'invention prévoit d'une part une collecte de requêtes reçues via d'une pluralité de canaux de communication et d'autre part une émission de documents de réponse vis l'une de ces canaux de communication, il contribue à une homogénéisation du processus 15 de traitement. Le parapheur numérique activé pour le traitement d'une requête peut être avantageusement extrait d'une pluralité de parapheurs numériques disponibles au sein du système d'information. Il peut par exemple être réalisé sous la forme d'une table dans une base de données au sein du 20 système d'information. En effet, le fait de disposer au sein d'un même système d'information d'une pluralité de parapheurs permet d'assurer une plus grande fluidité des traitements, contribuant ainsi à une minimisation des délais de traitement. De plus, la dématérialisation procurée par le procédé de traitement 25 selon l'invention induit en elle-même de profondes économies, notamment avec les parapheurs numériques qui véhiculent les requêtes des citoyens à travers le réseau et sont moins coûteux que le vrais parapheurs transportés par un huissier avec un chariot. Par ailleurs, le procédé de traitement selon l'invention permet de limiter le nombre de courriers 30 postaux sortants au profit de courriers électroniques ou de messages SMS ( Short Message System ). Enfin, la suppression des courriers électroniques en provenance des citoyens, au profit de formulaires électroniques gérés par le procédé de traitement selon l'invention réduit sensiblement le temps passé par les 2942335 -4 agents devant leur messagerie et élimine les risques de messages non désirés à diffusion massive ( SPAM ). La mise en oeuvre du procédé de traitement selon l'invention contribue aussi à la réduction des imprimés et au respect de 5 l'environnement, du fait notamment de la réduction sensible du nombre de courriers postaux sortants et du nombre de photocopies, puisque les pièces jointes sont scannées. Une requête peut être collectée à partir d'un formulaire de saisie qui peut comprendre une sélection de thèmes et de sous-thèmes. 10 Dans une version particulière de l'invention, l'étape d'analyse exploite le thème et le sous-thème sélectionnés par un requérant sur le formulaire de saisie. Ainsi, le fait d'orienter, au moment de la saisie de leur requête, les requérants vers des thèmes et sous-thème particuliers contribue 15 grandement à faciliter le traitement des requêtes, puisque ces requêtes sont alors orientées directement vers des services ou des applications logicielles concernées par ces requêtes. Le procédé selon l'invention peut en outre comprendre, à la suite d'une étape de collecte d'une requête, une étape pour placer ladite requête 20 collectée dans une file d'attente préalablement à son analyse, une étape pour créer une table d'état de ladite requête dans une base de données, ainsi qu'une une recherche de données d'un compte d'utilisateur correspondant à ladite requête collectée, dans une base de données. Ces étapes de traitement correspondent aux fonctions de type back 25 office du procédé selon l'invention. Les étapes préalables de collecte des requêtes par saisie sur des formulaires en ligne correspondent aux fonctions de type front office . Suivant un autre aspect de l'invention, il est proposé un système d'information prévu pour traiter des requêtes vers une entité incluant une 30 pluralité de services, mettant en oeuvre le procédé selon l'invention, ce système comprenant : - des moyens pour collecter une requête transmise via un canal de communication employé parmi une pluralité de canaux de communication disponibles, - 5 - des moyens pour analyser la requête collectée, de façon à identifier un service cible parmi la pluralité de services, - des moyens pour rediriger cette requête vers le service cible identifié, - des moyens d'application logicielle associés au service cible pour traiter la requête, - des moyens pour générer un document de réponse à ladite requête, et - des moyens pour émettre ledit document de réponse via un canal de communication sélectionné parmi ladite pluralité de canaux de communication, caractérisé en ce qu'il comprend en outre des moyens pour générer un objet logiciel d'information constituant un parapheur numérique, ce parapheur numérique étant stocké dans des moyens de base de données, et étant activé au cours du traitement de ladite requête. Ce système selon l'invention peut en outre comprendre une première base de données prévue pour contenir des données de comptes d'utilisateurs requérants et une seconde base de données prévue pour contenir des tables d'état de requête et des tables de parapheurs numériques. Il peut par exemple être organisé en un premier étage logiciel ( front office ) prévu pour collecter des requêtes et identifier des comptes d'utilisateur requérant, et en un second étage logiciel ( back office ) prévu pour analyser et traiter lesdites requêtes collectées et pour générer et émettre des documents de réponse auxdites requêtes. D'autres avantages et caractéristiques de l'invention apparaîtront à l'examen de la description détaillée d'un mode de mise en oeuvre nullement limitatif, et des dessins annexés sur lesquels : - la figure 1 illustre schématiquement un système d'information mettant en oeuvre le procédé de traitement selon l'invention, - la figure 2 illustre les étapes du procédé selon l'invention et des flux d'information mis en oeuvre dans le procédé selon l'invention, et - la figure 3 représente un exemple d'interface graphique agent mis en oeuvre dans le procédé de traitement selon l'invention. 2942335 -6 On va maintenant décrire, en référence aux figures précitées, un exemple de mise en oeuvre du procédé de traitement de requêtes selon l'invention. Un système d'information S selon l'invention comprend, en référence 5 à la figure 1, un étage frontal Front Office FO conçu pour recevoir des requêtes émises via plusieurs canaux C1...Cn sur une interface graphique IG. Les informations reçues sont prétraitées (PT) en utilisant des accès à une première base de données B1 citoyens ou clients contenant notamment des données d'adresse postale. 10 Le système d'information S comprend aussi un second étage de type back office BO comprenant une file d'attente ou tampon FA prévu pour stocker des requêtes reçues de l'étage frontal FO, un module AN d'analyse des requêtes coopérant avec une seconde base de données B2 et un ensemble d'applications logicielles métier A1,...Ak via un connecteur CO. 15 La seconde base de données B2 est prévue pour contenir un ensemble de tables d'état et des parapheurs numériques. On va maintenant décrire, en référence à la figure 2, un exemple de fonctionnement du procédé selon l'invention. Celui-ci se décompose en deux étapes. L'innovation du procédé selon l'invention réside 20 en une gestion particulière des flux permettant au parapheur numérique de se comporter comme un objet autonome. Ainsi, le parapheur ne se déplace plus. Il est stocké en un lieu unique, stocke les informations nécessaires au traitement de la demande ainsi que les différents états de ladite demande, au fur et à mesure du traitement de celle-ci par les agents. 25 En une première étape, un citoyen émet une requête via un formulaire dématérialisé stocké dans un référentiel de requêtes préparamétrées. Cette action a pour conséquence de générer un formulaire rempli. Lors de cette étape, il peut avantageusement être procédé à une comparaison avec un référentiel de population (Base de données 30 Population ). Le formulaire rempli intègre un parapheur numérique. En une deuxième étape, un agent effectue dans le parapheur une action de nature à modifier les informations contenues dans ledit parapheur. Le parapheur modifie alors l'état de la demande et peut avantageusement renseigner un compte permettant au citoyen de suivre 2942335 -7 l'état de sa demande. Lors de cette deuxième étape, il peut avantageusement être procédé à un contrôle d'habilitation de l'agent effectuant les actions (au moyen d'un corpus de règles d'actions. Le nombre d'actions effectuées par l'agent n'est pas limitatif. Une fois 5 effectuée la première action, une nouvelle action peut être effectuée, par le même agent ou tout autre agent habilité. La plate-forme logicielle GRC permet à une collectivité d'optimiser la gestion de la relation avec les citoyens, en traitant dans une même plate-forme collaborative toutes les demandes, quelle que soit leur nature et 10 notamment un guichet, un courrier électronique ou une téléprocédure par Internet, un courrier postal, un appel téléphonique ou un SMS, ou toute autre requête. Une mise en oeuvre particulière du procédé selon l'invention peut avantageusement permettre la réception de demandes émises en mode 15 automatisé par le biais de messages EDI ( Echange de Données Informatisées ), de web services ou toute autre forme de communication par lot de type machine-to-machine. Cette plateforme permet à une collectivité de mettre en ligne simplement et rapidement une solution d'administration électronique gérant 20 les flux entre les citoyens et ses services, notamment les courriers électroniques ou SMS entrant/sortant ou tout autre moyen de relation dématérialisée. Elle comprend une première base de données, dite base population et une seconde base de données contenant notamment des tables d'état, 25 des parapheurs numériques et des enregistrements des requêtes. La plate-forme GRC peut être proposée en mode hébergé sur le site de la collectivité locale. Dans une mise en oeuvre particulière, la plate-forme peut avantageusement être déployée en mode locatif hébergé (ASP : Active Server Pages ) avec accès via Internet et sécurisation des 30 données par tout moyen (notamment chiffrement des communications, système à clé physique, authentification par tiers certificateur, etc.) En entrée, un requérant, par exemple un citoyen, peut contacter les services d'une collectivité équipée d'un système d'information selon l'invention, par tout moyen et notamment les moyens suivants : - 8 - courrier électronique : depuis le site Internet de la collectivité, il saisit un message entrant dans la plate-forme ; il a préalablement sélectionné le service destinataire parmi une liste fermée ; - formulaire électronique : depuis le site Internet de la collectivité, il remplit en ligne un formulaire qui va être transmis en message entrant dans la plate-forme ; - SMS entrant ; le citoyen envoie un SMS à un numéro qui a été préalablement communiqué par la collectivité par voie d'affichage, de publication dans le journal d'information et sur le site Internet ; - appel téléphonique : le citoyen appelle le standard de la collectivité et fait part de son message; l'agent qui traite l'appel téléphonique saisit la requête sur la plate-forme ; - courrier postal : le citoyen envoie un courrier par la poste à la collectivité ; le service courrier numérise le courrier et saisit une requête sur la plate-forme; - guichet : le citoyen se présente physiquement auprès des services de la mairie ; l'agent saisit la requête du citoyen sur la plate-forme ; - tout moyen de communication adapté, notamment XML ( Extensible Markup Language ), EDI ou web service.

En sortie, la collectivité peut répondre au citoyen par : - courrier électronique : la plate-forme envoie un courrier électronique au citoyen ; - formulaire électronique : la plate-forme envoie un formulaire électronique au citoyen ; - SMS sortant : la plate-forme envoie un SMS au citoyen ; - courrier postal : la plate-forme génère une réponse qui sera transmise par courrier postal au citoyen ; - tout moyen de communication adapté, notamment XML, EDI ou web service. Le citoyen choisit le moyen qu'il préfère utiliser pour joindre la collectivité. La collectivité choisit le moyen qu'elle préfère pour répondre au citoyen. - 9 On va maintenant décrire, en référence aux figures précitées, les flux d'information traités par le procédé selon l'invention. La plate-forme GRC gère des flux de toute nature. Ces flux peuvent être classés en cinq types : • message entrant : Le citoyen pose une question par courrier postal, courriel, SMS, appel téléphonique ou même directement à un agent de la collectivité en se présentant à un guichet. • demande de document personnalisé : Le citoyen souhaite obtenir un document administratif le concernant (ex : certificat de naissance, de mariage, documentation touristique...) et recevoir ce document par courrier postal ; la demande est traitée au guichet ou via un formulaire Web avec des champs obligatoires et des tests de cohérence des informations saisies. • demande d'inscription à un service : Le citoyen remplit en ligne un formulaire intelligents pour s'inscrire à un service proposé par la collectivité locale (ex : inscription à un centre aéré ou à une activité sportive). Le formulaire est envoyé au service concerné qui le traite. Les données contenues dans ce formulaire peuvent être exportées dans une base de données ou un progiciel existant (ex : le service petite enfance dispose d'un progiciel de traitement des demandes d'inscription en crèche : les demandes d'inscription transmises par Internet sont directement exportées dans le progiciel). • abonnement à un service : Le citoyen souhaite recevoir une information en fonction d'une périodicité ou de la survenance d'un événement (par exemple: abonnement aux menus de la cantine scolaire, à des flashs d'informations locales ou à une infolettre, à des messages d'alertes météo...) On va maintenant décrire, à titre d'exemple non limitatif, le processus de traitement d'une requête. 25 30 2942335 - 10 - Le citoyen effectue une requête et attend une réponse. La plate-forme GRC envoie un accusé de réception, par mail ou SMS, ainsi que le lien permettant au citoyen de suivre l'avancement de sa demande. La requête est transmise au service concerné, qui y répond en s'appuyant sur une 5 bibliothèque de réponses-type ou de réponses voisines. Le traitement par un service fait l'objet d'un système de validation interne très précis, qui reproduit les règles en vigueur dans la collectivité. La chaîne de validation est paramétrable sans limite du nombre de circuits. On peut citer des exemples de circuits de validation : 10 - un rédacteur du service répond mais le chef de service doit valider la réponse transmise au citoyen, - la réponse d'un service doit être soumise à validation de la Direction Générale des Services ou d'un adjoint référent, - la réponse est validée par une personne A ou, en cas d'absence de 15 A, par une personne B. Un fil de discussion peut s'établir entre l'agent et le citoyen. L'agent peut notamment répondre au citoyen en lui demandant de compléter un formulaire. A tout moment, le changement de canal est possible.

20 On peut citer des exemples de fil de discussion multi-canal : - le citoyen remplit un formulaire par Internet et le transmet à la collectivité, - une information manque : l'agent de la collectivité envoie un message électronique au citoyen, - la réponse du citoyen s'intègre automatiquement dans le fil de discussion de l'agent qui pourra traiter la requête. - La réponse finale est fournie sous forme d'un courrier postal envoyé au citoyen. Un agent peut transférer une requête à un autre service, en joignant un commentaire à la requête. Tant que le nouveau service n'a pas pris en charge la requête, celle-ci reste dans le parapheur de l'agent. On va maintenant décrire, à titre d'exemple non limitatif, le processus de traitement du courrier postal dans le cadre du procédé selon l'invention. 2942335 - 11 - Le courrier postal est un circuit fonctionnant en général correctement dans une collectivité locale. Certaines collectivités sont équipées d'un logiciel de suivi du courrier, mais l'intérêt du module courrier postal de la plate-forme GRC est d'intégrer les flux courrier entrants avec tous les 5 autres flux. En sortie, on peut répondre par courrier postal à une requête d'un autre canal entrant et inversement. Par exemple : - le citoyen envoie un courrier électronique (en fait une requête GRC-WEB) à un service de la mairie ; 10 - le service peut lui répondre par MAIL, par SMS, ou par COURRIER POSTAL. Le traitement est le suivant : - le service traitant le courrier postal entrant (service courrier, secrétariat général...) ouvre les enveloppes (hors courrier signalé à destination des 15 élus, factures, documentations commerciales) et : - scanne le courrier (la technique de reconnaissance optique de caractères (OCR : Optical Character Recognition ) n'est généralement pas pertinent en raison des nombreux courriers manuscrits) ; 20 - créé une requête GRC en saisissant les noms, adresse (y compris mail et mobile) du citoyen ; - transmet la requête directement au service concerné ou à un service chargé de la redirection ; - stocke le courrier uniquement à des fins d'archivage en 25 joignant la référence chrono attribuée au courrier. La requête courrier est ensuite traitée comme les autres requêtes, avec les circuits de validation prédéfinis pour chaque service et chaque agent. Des contributions à la réponse peuvent être apportées. Certains services ne peuvent recevoir qu'une copie dynamique pour information du 30 courrier qui sera envoyé au citoyen. Le module édition courrier postal permet lors du traitement de toute requête de générer automatiquement un courrier postal. Le corps de la réponse est intégré dans ce courrier, les autres éléments (logo, entête du service, formule de politesse, qualité du 2942335 - 12 - signataire) sont prédéfinis pour chaque service ou utilisateur. Quand la requête a été traitée et validée, il suffit de l'imprimer et de mettre à la signature dans un parapheur. Le courrier peut être envoyé en format PDF ( Portable Document File ) crypté au citoyen.

5 Un système d'information GRC comporte une base de données de personnes physiques (citoyens) ou morales (entreprise ou association). A l'occasion d'une première démarche, les coordonnées du citoyen sont enregistrées dans la base afin de : - mémoriser l'ensemble des démarches liées à un citoyen ; 10 - simplifier les démarches ultérieures (coordonnées déjà pré-enregistrées) ; - sécuriser les procédures (fiabilité des adresses, suivi des demandes multiples...) ; - stocker dans un coffre-fort des documents certifiés ou 15 justificatifs afin de ne pas les demander à nouveau. Cet enregistrement est réalisé par l'agent si la démarche est faite au guichet ou par téléphone ou par le citoyen lui-même en cas de téléprocédure par Internet. L'inscription dans la base n'est pas obligatoire pour faire une 20 démarche, le citoyen pouvant refuser d'être enregistré. Chaque citoyen peut-être lié à un groupe (exemple : association, groupe socioprofessionnel) ou à un autre citoyen avec un lien (par exemple: parenté). Un demandeur , différent du bénéficiaire peut être géré. Le bloc adresse est conforme aux normes postales en vigueur 25 (notamment au fichier de la Poste comportant environ 39.000 localités, 2,4 millions de voies et 18 millions de numéros de rue mis à jour chaque mois) pour permettre notamment à terme une géo-localisation ou le rattachement à un quartier. Le citoyen inscrit dispose d'un identifiant de type login/password 30 pour accéder par Internet à son compte citoyen sur lequel il trouvera : - ses données d'identification ; - l'historique des requêtes formulées par le citoyen (avec la réponse des services de la mairie) ; - des informations locales. 2942335 - 13 - La création de cette base fait l'objet des déclarations en vigueur, notamment en France d'une déclaration auprès de la Commission Nationale Informatique et Liberté (CNIL), précisant la durée d'archivage des informations et la nature des informations personnelles stockées. Les 5 déclarations réglementaires sont du ressort des collectivités locales utilisatrices du procédé selon l'invention. On va maintenant décrire le processus de création et d'utilisateur de parapheurs numériques dans le cadre du procédé de traitement selon l'invention. Il s'agit de créer un parapheur numérique qui va rechercher 10 les validations successives de différents services et/ou utilisateurs et transmettre automatiquement la réponse au citoyen dès validation. Le paramétrage de la plate-forme permet de traiter tous les cas possibles : - validation de la requête par un utilisateur (chef de service ou élu 15 référent) ou par un service ; - définition des chaînes de validation ; - liste des services et utilisateurs de backup pour la gestion des utilisateurs en congés ou indisponibles. L'ensemble des messages entrants doit être défini (formulaires en 20 ligne, écrans de saisie...) ainsi que les messages sortants, automatiques ou non. L'ensemble des textes des messages automatiques (accusés de réception, notifications...) est personnalisable pour chaque collectivité. Le statut des requêtes, qui permet au citoyen de connaître l'état d'avancement de sa demande, est également personnalisable pour chaque 25 collectivité. - administrateur de service (peut, au sein de son service, créer des utilisateurs, traiter les requêtes et valider les réponses des rédacteurs, a accès aux statistiques de son service) ; - rédacteur : peut traiter les requêtes mais ne peut que soumettre à 30 validation sa réponse à la requête. A noter : un utilisateur peut être à la fois administrateur de 1-n services et rédacteur de 1-n autres services. Dans un mode pratique d'implémentation du procédé de traitement de requête selon l'invention, la plateforme logicielle est déployée en mode 2942335 - 14 - ASP et est hébergée dans un centre de données ( Data Center ). Aucun logiciel spécifique n'est installé sur les postes des agents des collectivités. On va maintenant décrire un exemple d'interface utilisateur mis en oeuvre dans le procédé de traitement de requête selon l'invention. Cette 5 interface utilisateur permet : - d'envoyer un message, dont le choix du thème par le citoyen déterminera le service destinataire ; - de remplir un formulaire de demande d'un acte administratif ou d'inscription à une activité ou un service de la collectivité.

10 Dès le message envoyé, le citoyen reçoit une notification par mail ou SMS comportant : - un accusé de réception lui indiquant le délai maximum dans lequel sa demande sera traitée ; - un lien et un code lui permettant de suivre l'état d'avancement de 15 sa demande ou d'accéder à son compte citoyen, regroupant l'ensemble de ses démarches et ses informations personnelles. On va maintenant décrire, en référence à la figure 3, un exemple d'interface agent accessible sur les postes de travail des agents d'une administration pourvue d'une plateforme logicielle GRC.

20 L'agent de la collectivité peut se voir notifier par mail ou SMS l'arrivée de toute nouvelle requête à traiter. Il se connecte par un simple navigateur (aucun logiciel à installer) à la plate-forme GRC. Une console lui permet de visualiser l'ensemble des messages ou demandes à traiter. Tous les messages sont affichés avec un logo indiquant le canal choisi par le citoyen.

25 Chaque service a accès a ses statistiques (nombre et nature des requêtes traitées, délai moyen de traitement). Les administrateurs ont accès à l'ensemble des requêtes traitées par tous les services, et peuvent visualiser les réponses des agents. L'agent visualise simplement les tâches à effectuer des : 30 - requêtes nouvelles à traiter, - requêtes transférées par un autre service à traiter. - requêtes qu'il doit valider parmi les requêtes en cours, comprenant : - celles pour lesquelles un complément a été demandé au citoyen 2942335 - 15 - - celles auxquelles le citoyen a apporté le complément ; - celles en cours de transfert (tant que le service destinataire n'a pas accepté la requête, elle reste dans le portefeuille du service émetteur).

5 On peut aussi prévoir les fonctionnalités suivantes: - moteur de recherche multicritères ; - gestion des profils et des chaînes de validation ; - édition de statistiques : nombre de requêtes, délai moyen de traitement par service, tri par service, par thème ou avec des critères 10 propres à la ville (par exemple: quartier) ; - accès direct aux archives de l'année en cours et de l'année N-1 ; - accès direct au support client par mail ( H24 : 24 heures sur 24) ou téléphone (heures ouvrées). L'agent sélectionne la procédure correspondant à la démarche 15 administrative souhaitée par le citoyen. Ci-dessous, quelques exemples de procédures. La plateforme GRC dispose aussi de fonctionnalités d'export ou d'impression permettant des gains de productivité considérables. Exemple ci-dessous : le bordereau regroupant les demandes de cartes nationales 20 d'identité (CNI) établies en mairie et transmises en Préfecture. Ce document, fastidieux à établir manuellement, est généré en quelques secondes par le système GRC. Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces 25 exemples sans sortir du cadre de l'invention.

Claims (12)

1. REVENDICATIONS1. Procédé pour traiter des requêtes au sein d'une entité incluant une pluralité de services, comprenant des étapes suivantes : - une collecte d'une requête transmise via un canal de communication employé parmi une pluralité de canaux de communication disponibles, - une analyse préalable de la requête collectée, pour identifier un service cible parmi ladite pluralité de services, - une redirection de ladite requête vers ledit service cible identifié, - un traitement de la requête par une application logicielle associée audit service cible, - une génération d'un document de réponse à ladite requête, et - une émission dudit document de réponse via un canal de communication sélectionné parmi ladite pluralité de canaux de communication, caractérisé en ce qu'il met en oeuvre au moins un objet logiciel d'information constituant un parapheur numérique, ce parapheur numérique étant accédé et activé au cours des étapes de collecte et de traitement, et en ce que la réalisation des étapes de génération et/ou d'émission de document est conditionnée par l'état dudit parapheur numérique.
2. 2. Procédé selon la revendication 1, caractérisé en ce que le parapheur numérique activé pour le traitement d'une requête est extrait d'une pluralité de parapheurs numériques disponibles au sein du système d'information.
3. 3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que le parapheur numérique activé pour le traitement d'une requête est réalisé sous la forme d'une table dans une base de donnée au sein du système d'information.
4. 4. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'une requête est collectée à partir d'un formulaire de saisie. 2942335 - 17 -
5. 5. Procédé selon la revendication 4, caractérisé en ce que le formulaire de saisie comprend une sélection de thèmes et de sous-thèmes.
6. 6. Procédé selon la revendication 5, caractérisé en ce que l'étape d'analyse 5 exploite le thème et le sous-thème sélectionnés par un requérant sur le formulaire de saisie.
7. 7. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend en outre, à la suite d'une étape de collecte d'une requête, une étape 10 pour placer ladite requête collectée dans une file d'attente préalablement à son analyse.
8. 8. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend en outre, à la suite d'une étape de collecte d'une requête, une étape 15 pour créer une table d'état de ladite requête dans une base de données
9. 9. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend en outre, à la suite d'une étape de collecte d'une requête, une recherche de données d'un compte d'utilisateur correspondant à ladite requête 20 collectée, dans une base de données.
10. 10. Système d'information prévu pour traiter des requêtes vers une entité incluant une pluralité de services, mettant en oeuvre le procédé selon l'une quelconque des revendications précédentes, ce système comprenant : 25 - des moyens pour collecter une requête transmise via un canal de communication employé parmi une pluralité de canaux de communication disponibles, - des moyens pour analyser la requête collectée, de façon à identifier un service cible parmi la pluralité de services, 30 - des moyens pour rediriger cette requête vers le service cible identifié, - des moyens d'application logicielle associés au service cible pour traiter la requête, - des moyens pour générer un document de réponse à ladite requête, et 2942335 - 18 - - des moyens pour émettre ledit document de réponse via un canal de communication sélectionné parmi ladite pluralité de canaux de communication, caractérisé en ce qu'il comprend en outre des moyens pour générer un objet 5 logiciel d'information constituant un parapheur numérique, ce parapheur numérique étant stocké dans des moyens de base de données, et étant activé au cours du traitement de ladite requête.
11. 11. Système d'information selon la revendication 10, caractérisé en ce qu'il 10 comprend en outre une première base de données prévue pour contenir des données de comptes d'utilisateurs requérants et une seconde base de données prévue pour contenir des tables d'état de requête et des tables de parapheurs numériques. 15
12. 12. Système d'information selon l'une des revendications 10 ou 11, caractérisé en ce qu'il est organisé en un premier étage logiciel ( front office ) prévu pour collecter des requêtes et identifier des comptes d'utilisateur requérant, et en un second étage logiciel ( back office ) prévu pour analyser et traiter lesdites requêtes collectées et pour générer et émettre 20 des documents de réponse auxdites requêtes.