Project

General

Profile

Development #5505

Apprentissage de données de références à partir des formulaires (base de contacts)

Added by Victor Claudet about 5 years ago. Updated almost 5 years ago.

Status:
Nouveau
Priority:
Bas
Assignee:
-
Category:
-
Target version:
-
Start date:
15 Sep 2014
Due date:
% Done:

0%

Patch proposed:
No
Planning:
No

Description

Pour discussion

L'idée est la suivante. Une base de données est enrichie lors d'une saisie de formulaire et permet de faire de l'assistance à la saisie pour le demandeur (agent principalement).

Dans un premier temps je vois ça uniquement appliqué à des formulaires réservés aux agents.

1) Un usager vient faire une demande (guichet, téléphone, courrier...).
2) L'usager saisit la demande dans laquelle se trouve une page "demandeur"
3) à la soumission de la demande la page "demandeur" est conservée en base (nom, prénom, adresse...) et enrichit une base de contact
4) l'usager revient au guichet, l'agent saisit une nouvelle demande et voit ressortir le contact
5) il le sélectionne et auto-complète les champs connus correspondants
6) si modification dans des renseignements de contact, mise à jour de l'entrée dans la base.

History

#1 Updated by Frédéric Péters about 5 years ago

  • Description updated (diff)

#2 Updated by Victor Claudet almost 5 years ago

  • Due date set to 23 Sep 2014
  • Priority changed from Normal to Haut
  • Tracker changed from Development to Project management

Je le passe en haut et project management pour que ce soit abordé pendant la réunion hebdo. Donzere me demande de le chiffrer très rapidement.

#3 Updated by Frédéric Péters almost 5 years ago

  • Patch proposed set to No
  • Tracker changed from Project management to Development
  • Due date deleted (23 Sep 2014)
  • Priority changed from Haut to Normal

On a dit en réunion que j'écrivais une proposition dans ce ticket.

#4 Updated by Frédéric Péters almost 5 years ago

1) Un usager vient faire une demande (guichet, téléphone, courrier...).
2) L'usager saisit la demande dans laquelle se trouve une page "demandeur"

L'usager dans le 1) est un usager, l'usager dans le 2) est l'agent qui encode la demande; correct ?

2) L'usager saisit la demande dans laquelle se trouve une page "demandeur"

En fait l'agent complète un formulaire dans lequel il y a des champs marqués comme étant préremplis par des données de l'utilisateur (c'est comme ça qu'on peut déterminer "voici une donnée qui correspond au profil du demandeur"), appelons-les "champs demandeur". Un truc ici c'est que le préremplissage ne doit pas se faire avec les données perso de l'agent.

3) à la soumission de la demande la page "demandeur" est conservée en base (nom, prénom, adresse...) et enrichit une base de contact

La "base de contacts", ça doit simplement être la base des utilisateurs, on peut alors avoir une action dans le workflow qui récupère les différents champs "demandeur" et crée un User avec celles-ci, peut aussi modifier un utilisateur existant au cas où (il y a alors à déterminer quel utilisateur modifier).

4) l'usager revient au guichet, l'agent saisit une nouvelle demande et voit ressortir le contact
5) il le sélectionne et auto-complète les champs connus correspondants

Donc l'agent encode, il y a un premier "champ demandeur", mettons "nom", à ce moment il y a une boite de dialogue qui apparait listant les utilisateurs existant dans le système avec ce nom et quand l'agent en choisi un les autres champs qui devraient être préremplis le sont.

6) si modification dans des renseignements de contact, mise à jour de l'entrée dans la base.

On doit mémoriser d'une manière ou d'une autre l'utilisateur qui a été sélectionné dans l'étape précédente, pour modifier le bon utilisateur.

Et puis un 7), pour Thomas, qui a écrit quelque part qu'à ce moment-là, paf, numéro de suivi, pour permettre à l'usager de retrouver sa demande; mais c'est un autre ticket.

Comme on aborde quelque chose de nouveau, un fonctionnement particulier pour le remplissage d'un formulaire par un agent, je me dis que ce qu'il faudrait c'est dupliquer dans le backoffice les pages de création d'une demande, on pourrait alors avoir la barre latérale pour permettre à l'agent de choisir l'usager concerné.

Faire correctement tout ça, c'est donc quand même pas mal de boulot, je mettrais allègrement une dizaine de jours.

#5 Updated by Thomas Noël almost 5 years ago

Ca me parait être l'idée.

Un truc à voir : dans le cadre d'un wcs connecté via SAML (ou autre), la base des utilisateurs, elle est ailleurs (derrière IdP qui ne la diffusera pas). Plus généralement, avoir une "base de contact" séparée me semblerait mieux (alimentée par plusieurs sources, pas que des User, utilisable indépendamment, à base de webservice, etc). Genre elasticsearch, s'il faut dire des gros mots.

#6 Updated by Frédéric Péters almost 5 years ago

Je trouvais mes trucs bien carrés, sans fantaisie, et puis paf, elasticsearch, web services et cie, ça complique quand même pas mal les choses. Je monterais alors le temps de travail, parce qu'on étend le travail à authentic, peut-être passerelle, etc. mais combien, 20 jours ?

#7 Updated by Thomas Noël almost 5 years ago

Disons entre 10 et 20 jours :
  • 10 jours pour une version "simple" qui reste wcs, avec un pré-remplissage évolué et éventuellement
  • 20 jours pour un système plus complexe, capable d'aller chercher des infos ailleurs ; et l'ajout de cet ailleurs, une base de contacts avec moteur de recherche un peu solide.

#8 Updated by Victor Claudet almost 5 years ago

Merci pour le chiffrage.

Bon j'ai décidé de faire le mort pour le moment. je reviendrais sur le sujet avec le prospect si j'ai la possibilité d'aller leur faire une démo. Je ne connais pas leur budget donc je veux pas les effrayer avec ça. Si je le sens j’essaierai surtout de les convaincre que c'est pas utile (ce que je pense réellement dans leur cas).

#9 Updated by Frédéric Péters almost 5 years ago

  • Priority changed from Normal to Bas

Also available in: Atom PDF