• Connecteur Maarch
• Réflexions fonctionnelles sur le mode guichet et critiques de l'existant
• Refonte de welco - approche fonctionnelle
• Wiki

Connecteur Maarch¶

Fonctionnalités¶

Le connecteur est capable de récupérer les courriers dans un certain statut, permettant de lui associer des demandes. Le courrier peut aussi être refusé s'il est jugé qu'il n'est finalement pas du ressort de la GRC. En fin de traitement de la demande il sera possible de lui apporter une réponse, pour l'instant une simple réponse sous forme de texte injecté dans l'historique du courrier.

Scénario détaillé¶

• un courrier, enregistré dans Maarch, est déposé dans une bannette spécifique, bannette "GRU", par exemple
• ce courrier est alors présenté dans Publik (écran Welco)
• il faut l'associer à un (ou plusieurs) formulaire existant
• compléter le formulaire avec les informations présentes dans le courrier
  traitement classique de la demande via le workfow de Publik
• en cours de traitement (appel webservice) possible
  • d'informer Maarch que le courrier, lié à la demande, a été "traité"
  • de transférer à Maarch un chemp texte pour insertion de celui-ci dans un éventuel courrier réponse construit dans Maarch

Cf. recette complète sur Ville d'Avray : https://dev.entrouvert.org/projects/ville-d-avray/wiki/Sc%C3%A9nario_de_recette_du_connecteur_Maarch%3EPublik

Limitations¶

1. On ne peut pas répondre à un courrier par un document
2. Coté Publik nous pouvons associer plusieurs démarches à un courrier ce qui dans Maarch ne sera pas possible puisque les champs external_id et external_link n'accepte qu'une unique valeur,
3. La création d'une demande pour un courrier fait passer le statut du courrier dans Maarch dans le statut "GRC_TRT" (voir plus bas), de même on ne peut faire ça qu'une seule fois pour que cela ait un sens,
4. De la même manière le fait de produire plusieurs réponses à un courrier dans Maarch obligera à passer plusieurs fois dans le statut "Réponse émise par la GRC" rendant l'historique peu cohérent.

Pour le deuxième point le ticket #30046 évoque un contournement possible.

Configuration de Maarch¶

• external_id : pour stocker le numéro d'une demande dans w.c.s.
• external_link : pour stocker un lien direct vers la demande dans w.c.s.

Un utilisateur est créé sur Maarch ayant accès aux web-services REST, il servira à welco pour moissonner l'instance de Maarch.

• Courrier à traiter par la GRC : "GRC"
• Courrier injecté dans la queue de courrier de la GRC : "GRC_TRT"
• Demande créé pour le courrier : "GRC_SENT"
• Erreur d'aiguillage, la demande n'est pas à traiter par la GRC : "GRCREFUSED"
• Une réponse à été apportée par la GRC : "GRC_RESPONSE"
  • ce dernier statut devrait toujours être accompagné d'une note dans l'historique du courrier, contenant le message réponse de la GRC (une simple chaîne de caractère)

Configuration du connecteur (de la brique welco)¶

La configuration se fait via la clé de configuration Django MAARCH_FEEED, comme cela (à configurer par exemple via hobo en créant une variable SETTING_MAARCH_FEED dans le service courrier)

MAARCH_FEED = {
   'ENABLE': True  # optionnel, permet de désactiver le raccordement, par défaut à True
   'URL': 'https://maarch-api-endoint' # Maarch API endpoint 
   'USERNAME': 'xxx'  # obligatoire, username de l'utilisateur dans Maarch
   'PASSWORD': 'yyy':  # obligatoire, mot de passe de l'utilisateur dans Maarc
   'STATUS_GRC': 'GRC'  # optionnel, voir plus haut, valeur par défaut identique
   'STATUS_RECEIVED': 'GRC_TRT'  # optionnel, voir plus haut, valeur par défaut identique
   'STATUS_SEND': 'GRC_SENT'  # optionnel, voir plus haut, valeur par défaut identique
   'STATUS_REFUSED': 'GRC_REFUSED'  # optionnel, voir plus haut, valeur par défaut identique
   'STATUS_RESPONSE': 'GRC_RESPONSE'  # optionnel, voir plus haut, valeur par défaut identique
}

Utilisation dans un workflow w.c.s.¶

On retrouvera dans le contexte de soumission de la demande le numéro du courrier dans Maarc via la variable form_submission_context_external_id sour la forme 'maarch-%(res_id)s'.

Envoyer une réponse depuis w.c.s.¶

• URL: {{courrier_url}}api/mail/response/
• Méthode: POST
• Données à envoyer dans le corps de la requête

  Nom de la clé	Valeur
  content	le message que l'on souhaite envoyer, une chaîne de caractère simple
  mail_id	{{ form_submission_context_external_id }}

Description du code dans welco¶

Le numéro du courrier dans Maarch (le res_id) est conservé sous la forme formatée 'maarch-%(res_id)s' dans le champ external_id (à ne pas confondre avec l'external_id dans Maarch) du modèle Mail (dans weco/sources/mail/models.py). C'est la seule donnée venant de Maarch qui soit conservée dans welco.

Description des WS Maarch utilisés¶

• rest/res/list pour obtenir la liste des courriers dans un certain statut avec leur contenu (withFile=true)
  • dans welco.sources.mail.maarch.MaarchCourrier.get_couriers(clause, fields=None, limit=None,·include_file=False,·order_by=None)
• rest/res/externalInfos pour modifier le statut d'un courrier et définir les attributs external_id et external_link
  • dans welco.sources.mail.maarch.MaarchCourrier.update_external_infos(self, courriers, status)
• rest/res/resource/status pour modifier le statut d'un courrier et ajouter un message à son historique
  • dans welco.sources.mail.maarch.MaarchCourrier.update_status(self, courriers, status, history_message=None)

Documentation : https://docs.maarch.org/gitbook/html/MaarchCourrier/18.10/guat/guat_architecture/API_REST/home.html

Quelques requêtes :

# Courriers en statut GRC
curl -u 'login:passwd' -d "select=*&clause=status='GRC'&orderBy[]=res_id" -H "Content-Type: application/x-www-form-urlencoded" -X POST https://maarch-api/rest/res/list

# Courriers en statut  GRC*
curl -u 'login:passwd' -d "select=*&clause=status like 'GRC%'&orderBy[]=res_id" -H "Content-Type: application/x-www-form-urlencoded" -X POST https://maarch-api/rest/res/list

# Tous les courriers
curl -u 'login:passwd' -d "select=*&clause=1=1&orderBy[]=res_id" -H "Content-Type: application/x-www-form-urlencoded" -X POST https://maarch-api/rest/res/list

Admin système¶

Récupération des courriers :

sudo -u welco welco-manage tenant_command feed_mail_maarch --domain nom_du_tenant -v2 

Réflexions fonctionnelles sur le mode guichet et critiques de l'existant¶

• L'idée est de se mettre d'accord sur des besoins fonctionnels avant de faire des wireframes.
• Tout le long, je parle de welco, étant entendu qu'il s'agit du mode guichet intégré dans Combo.
• Par ailleurs, dans ce doc je souligne essentiellement ce qu'il convient d'améliorer (et donc le doc est très critique par rapport à l'existant). Ceci dit, l'existant fonctionne et remplit son rôle, il convient donc se faire attention à ne pas régresser (d'un point de vue ergonomique , l'écran welco actuel est perturbant au début mais permet finalement aux agents de traiter les demandes existantes).
• Les commentaires ci-dessous sont basés sur l'expérience de Grenoble², mais il serait vraiment intéressant que les CPF utilisant Welco viennent compléter ce doc avec leur propre expérience.
• En complément, des éléments de cas d'usage sont présents ici sur la page Rochefort : https://dev.entrouvert.org/projects/rochefort/wiki/Mise_en_place_de_la_brique_multi-canal

Limites du fonctionnement actuel : remarques basées sur l'expérience de Grenoble¶

• La recherche usager
  • Lorsque aucun compte usager n'a été précédemment créé, Welco actuel ne permet pas de rechercher un usager sur la base de son nom, du N° de la demande ou même du N° de suivi
  • Il faudrait permettre une recherche sur l'ensemble des démarches, y compris celles réalisées par des usagers sans compte (nom, tel, code de suivi, N° de la demande, le mail...)
  • et utiliser une recherche telle zoo (plus puissante pour retrouver un usager sur nom approchant)

• Autres points soulevés :
  • Il faudrait pouvoir intégrer des référentiels adresse dans la procédure de création de compte lorsque la collectivité l’exige sur les formulaires citoyen [note Brice : question plus globale que Welco = utilisation d'un référentiel dans les attributs d'un compte]
  • Mettre en cohérence les éléments constitutifs de compte usager dans Welco avec ceux qui sont paramétrés, si non c'est inutilisable
  • Welco doit également être compatible avec un mode multi-collectivités (normalement fin mars pour GL)

Réflexions sur le fonctionnement souhaité (scénario)¶

Un usager appelle ou vient au guichet, soit pour une nouvelle démarche, soit pour le suivi d'une démarche existante (cas sans liaison avec CTI)

Trouver ce que l'on cherche¶

• Nom, prénom, mobile, tel fixe, mail, date naissance, N° de demande, code de suivi...

La recherche va renvoyer 2 types de résultats qui pourraient présenter dans 2 blocs de résultats, à séparer si possible (explications plus bas)

• Visu sur la fiche usager (le compte citoyen) et les démarches associées (proche de l'existant)

• éléments pris en compte dans la recherche : nom, prénom, mobile, mail, code de suivi, N° demande (en fait ce qui correspond à la recherche "Texte" dans la vue globale dans l'interface de traitement)
• ne pas afficher dans ce bloc les démarches qui sont rattachées à un compte, les afficher dans le bloc 1 (?)
• Visu : catégorie, nom du formulaire, N° demande, nom, prénom, mail, mobile, date demande, statut

Important : Exclure les comptes agents de la recherche sur les citoyens (devraient pouvoir se régler avec la gestion des OU)

• Cas particulier pour le suivi d'une demande existante (l'usager appelle pour savoir où en est sa demande)
  • Difficultés actuelles : un compte usager n'a pas forcément été créé lors de la demande initiale (il arrive aussi souvent pour les accueils téléphoniques que l'usager n'ait pas de mail) et l'usager n'a pas forcément son code de suivi ou le n° de la demande si sa demande initiale a été faite par téléphone (et n'a souvent aucun moyen de le retrouver).
  • Que font les agents aujourd'hui ? Après avoir vainement essayé de trouver la demande dans Welco, ils vont dans l'interface de traitement et recherche la demande en tapant le nom de l'usager ou son N° de tel dans le bloc "texte" (et donc ils sortent de Welco, ce qui est ergonomiquement pas bon du tout)
  • il faudrait donc pouvoir réaliser cette recherche dans Welco, c'est le sens des deux blocs de résultats mentionnés plus haut.

1/ Si l'agent trouve la fiche usager (= l'usager a un compte)

• L'agent sélectionne la fiche et remplit un formulaire (un seul, pas la peine d'avoir un "panier de démarches")
• Les donnés du formulaires sont alors pré-remplies avec celle du compte usager, celles-ci sont modifiables par l'agent, en fonction des infos données par l'usager
• L'agent doit pouvoir indiquer DANS le formulaire que les informations du compte modifiées devront mettre à jour les données du compte usager (en demandant oralement l'accord à l'usager : celui-ci pouvant recevoir une notification)

2/ Si l'agent ne trouve pas l'usager (= l'usager n'a pas de compte)

• L'agent peut ou pas créer un compte facilement (avec les référentiels associés)
• l'agent initie un formulaire correspondant à ce que souhaite l'usager
  => fonctionnement proche de l'existant.

Liste des formulaires¶

• Ne lister que les formulaires pour lesquelles l'agent a les droits pour la saisie back-office

Si liaison CTI (Couplage Téléphonie-Informatique)¶

Fonctionnement comme guichet : recherche manuelle toujours possible mais sur appel entrant, pré-sélection du ou des comptes ayant le n° de tél entrant en donnée du compte

Fonctionnement à prévoir : clic-to-call = initier un appel depuis une fiche usager

la création de compte usager¶

• Rendre plus fluide
• Rendre plus plus efficace pour l'agent et l'usager
• Ne pas tout baser sur le mail (certains vieux n'ont pas forcément de mail, les jeunes ne savent même plus ce que c'est !), par contre ils ont quasiment tous un N° de tel mobile;
• Préserver le consentement explicite de l'usager pour la création de compte avec un processus de validation du compte, par mail mais aussi par SMS

• rendre obligatoire un identifiant +/- unique pour la création du compte : le mail ou le N° de tel mobile
• interdiction de doublon sur le mail de l'usager lors de la création de compte
• interdiction de doublon sur le N° de tel mobile lors de la création de compte
  => Cela suppose de fait d'adapter la création de compte actuelle, car on doit par exemple vérifier (en sortie de page ?) la présence obligatoire d'un mail OU d'un n° de mobile

Si aucun de ces éléments n'est disponible (ce qui est rarissime), alors on ne crée pas de compte.

• Création de compte avec FC
  Concernant la création de compte avec FC, je ne connais pas assez le fonctionnement de FC pour en parler (-> Mik ?)

Sur le contenu de la fiche Usager¶

• être orientée agent traitant
• ne pas exposer des boutons d'action comme dans A2 aujourd'hui qui ne concernent pas les agents traitants
• être plus lisible

• Exemple inspirant (?) : Fiche RSU Nanterre : https://agents-preprod-moncompte.nanterre.fr/?rsu_adult=61722

Si on est ok sur le principe, à savoir l'agent traitant doit pouvoir accéder à une fiche usager, je pourrai avancer sur des spec plus détaillées sur la composition de cet écran et sur la réflexion de ce que peut / doit voir un agent.

Sur la base de connaissance¶

Constat : une utilisation limitée (mais réelle à Grenoble par exemple) : est-ce que c'est parce que ce module ne sert à rien, ou est-ce que c'est parce qu'il est largement perfectible ?

Quelques commentaires sur l'existant :

• La recherche par mots clés est primordiale, il faut la garder et éventuellement l'améliorer avec un nuage de mots clés.
• Il faudrait pouvoir catégoriser les fiches, pour les rendre par exemple cohérente avec les catégories des formulaires
• Mieux associer base de connaissance et démarches : trouver une solution pour pouvoir faire monter des liens vers une fiche lors du traitement d'une demande (ou mieux la fiche elle-même) en fonction de données saisies dans le formulaire. Exemple : les fiches sur le tri des déchets lorsque l'usager fait une demande sur le tri des déchets (infos connues dans le formulaire), ne serait-ce que pour indiquer à l'agent qu"une fiche existe
• Possibilité d'indexer le contenu des PDF ?

Welco courriers (ou welco mail) : hors scope pour le moment¶

• Peut-on traiter un courrier entrant sans le rattacher à un compte usager ?
  Brice ?

• Si la création de compte est obligatoire, comment le rattacher à un compte existant ou comment créer facilement un compte ?

• Quels sont les éléments obligatoires pour la création de compte (plus haut il est mentionné la présence obligatoire d'un mail ou d'un numéros de mobile)

• Quid du rattachement à un compte usager dont on ne connait ni le mail, ni le mobile

=> je laisse s'exprimer ici les personnes qui savent de quoi elles parlent

² Au vu de l'expérience à Grenoble, le point de tension principal n'est finalement pas dû à l'écran Welco mais au fait que les formulaires WCS ne son pas optimisés pour une saisie par le guichet.

• Un agent peut difficilement passer plusieurs pages pour remplir un formulaire (temps d'attente, aller-retours) alors que son attention est à la fois prise par ce qu'il saisi et par l'usager qu'il a au téléphone ou en face de lui. La logique de WCS interdisant les champs optionnels est particulièrement pénalisante dans le cadre du guichet ; obligeant à passer par des solutions de contournement qui ne sont pas satisfaisantes.

Refonte de welco synchrone - approche fonctionnelle¶

• Saisie d'une démarche
• Recherche d'une demande / d'un usager
• Possibilité de création d'un compte usager
• Recherche dans la base de connaissance
• En tant qu'agent, je ne dois voir que les démarches pour lesquelles j'ai un droit de saisie

• La recherche
  • 1 champ de recherche unique avec la possibilité de sélectionner le périmètre de la recherche (tout / usagers / demandes existantes)
  • L'élément "tout" peut intégrer des contenus assez larges comme ceux stockés dans passerelle
  • Recherche par code de suivi, qui renvoie vers l'interface de traitement en backoffice
• Les résultats de recherche :
  • Attention à pouvoir bien identifier ce que l'on trouve (avec des icônes par exemple pour les démarches, les usagers, les factures, les fiches de la base de connaissance, ...)

Note Fred : L'idée ici c'est qu'on a différentes sources pour la recherche et un champ de recherche unique, 
il s'agit d'éteindre la cellule recherche de combo pour permettre l’agrégation de résultats de différentes sources.

Comme sources il y aurait :
* les demandes w.c.s. (l'API pour faire une recherche full text existe),
* les utilisateurs (il s'agirait dans authentic d'ajouter un filtre full text à /api/users/)
* la base de connaissance (l'API existe également, mais on reparle de la base de connaissances plus loin)
On pourrait également avoir une source "code de suivi", je tape un code de suivi et dans les résultats de recherche ça matche et ça permet d'ouvrir la demande, 
alors que la recherche sur les demandes, elle va aussi matcher sur le code de suivi mais cliquer dessus ne fera pas le nécessaire (donner les autorisations à l'agent).
Et des sources de recherche qui seraient fournies par des connecteurs, pour permettre par exemple de retrouver une facture à partir de son numéro.

• A intégrer dans Combo - Différents blocs à prévoir :
• bloc Profil usager
• bloc demandes en cours / finies (l'agent ne peut cliquer que sur les demandes lesquelles il a des droits de traitement)
• Autres éléments liés à faire afficher dans des blocs (ou onglets?) : factures, abonnement corbo (pour un éventuel désabonnement), éléments stockés dans passerelle Store (ex. associations à Tournai)...
  L'affichage de ces blocs peut être contrôlé par des rôles.

• Doit être cohérente avec la page de création d'A2 (les attributs du profils paramétrés dans A2, le mieux c'est que ce soit directement la page de création de compte de A2)
• Doit pouvoir intégrer un référentiel adresse (BAN, SIG, fichier csv...)
• Comment faire apparaître cette page ? Il semblerait plus simple de ne pas la faire apparaître en lightbox mais d'afficher une page A2, pour autant attention au fonctionnement du menu gauche pour ne pas perdre l’agent
• Une fois la fiche créée, on édite la fiche de l'usager dans combo
• Le plan est donc de faire d'A2 le référentiel usager, ce qui implique :
  • la gestion d'attributs supplémentaires et des types de champs, (date, N° de tel)
  • pas de création de doublons sur l’émail et / ou le tel portable (qui devient un identifiant)

• Garder la prévisualisation directe de la fiche comme aujourd'hui dans welco (Pour préciser les choses, en passant d'une fiche à l'autre dans la barre latérale, on voit son contenu dans la zone centrale sans avoir à changer de page.)
• La base de connaissance serait indépendante (module spécifique avec un nom en 0, on a pensé à Cervo)
• Mieux lier les démarches et la base de connaissance : pouvoir démarrer une démarche à partir d'une fiche de la base de connaissance (associer des fiches de BD à des démarches)

• Un modèle "Welco" sera réalisé avec Combo, celui-ci disponible sur Matrik, pourrait être facilement exporter et ré-importer sur une instance de Publik.

Welco courrier : pas le sujet ici

Réflexions fonctionnelles¶

Refonte de welco - approche fonctionnelle

Old :
Réflexions fonctionnelles sur le mode guichet et critiques de l'existant

Connecteur Maarch