Produits Entr'ouvert » w.c.s. » Au quotidien

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.

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.

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 ?

• 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.

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).