Produits Entr'ouvert » Publik

Ces usagers institutionnels peuvent être qualifiés par deux moyens complémentaires :

• les attributs pour l'identité de la personne morale
• un rôle pour le type de la personne morale et la fonction dans celle-ci, 'Président d'association', 'Gérant', etc.. qu'on peut alors associer à des formulaires ciblés

Problèmes identifiés :

• un compte n'est pas Président mais bien Président d'une association, i.e. si un compte est lié à 2 associations, la personne peut très bien être simple adhérent d'un côté et Président d'une autre association par ailleurs, le rôle devrait donc être raccroché à la relation et non au compte. Pour contourner ce problème dans un premier temps, il est proposé que dans ces cas 2 compte soient créés (avec théoriquement 2 adresses différentes car domiciliation à l'organisme).
• dans le cas d'une personne morale les demandes sont bien faites pour le compte de celle-ci et non pour le compte de la personne physique représentative, ainsi, par exemple dans le cas d'une association, les demandes de subventions, d'ouverture de débit de boissons temporaires, ... devraient toutes être raccrochées à l'association, quel que soit le compte personne physique demandeur (peut d'ailleurs être supprimé, et non le compte personne morale).

Demande actuelle d'Alfortville :
Afin de pouvoir gérer les courriers entrants des "usagers institutionnels" (ex : associations, entreprises, administrations telles CAF, DSDEN, ...), il est nécessaire de disposer de champs complémentaires en attribut d'un compte Publik.

Champs complémentaires nécessaires à un compte Publik :

• Organisation (l'intitulé générique qui convient pour entreprises, associations, administrations, ...)
• Service. Dans un champ séparé ou à la suite d'Organisation ??
• Fonction (indispensable car un courrier ne doit théoriquement pas être adressé nominativement)
• SIRET

Tous ces champs seraient facultatifs.
Dans le cas d'usage actuel d'Alfortville, ces champs ne peuvent être complétés qu'en BO (gestion du courrier), sont affichés à l'usager dans ses "Données du compte" mais ne peuvent être modifiés par celui-ci dans "Éditer les données du compte".

Ils viennent donc en plus des attributs actuels :

• Civilité
• Prénom
• Nom
• Adresse (donc professionnelle), y sera ajouté BP XX, si nécessaire
• Code postal
• Commune, y sera ajouté cedex ...., si nécessaire
• Téléphone (donc professionnel si complété)
• Mobile (donc professionnel si complété)

Extrait du CCTP d'Alfortville :
2.1.1.4 Gestion du multi-profils
Ce portail doit permettre de gérer différents profils de connexion, chaque profil donnant accès aux prestations relatives à ce profil :

• Citoyen (un citoyen peut ne pas résider à Alfortville)
• Famille (Un citoyen peut être un membre d’un foyer)
• Agent (Un agent de la collectivité peut être un habitant d’Alfortville)
• Education Nationale (les écoles)
• Association (un citoyen ou un agent peut être membre d’une association et y exercer des responsabilités)
• Une entreprise (un citoyen ou un agent peut être membre d’une entreprise et y exercer des responsabilités)
  Les informations à renseigner par l’Usager pour chaque profil sont associées à des prestations précises et sont donc décrites dans le paragraphe correspondant.

_~~

Opinion de Fred : on ne doit pas passer par des attributs supplémentaires sur le profil de l'usager mais bien arriver à lier un compte à n "collectifs" (entreprise, asso, etc.), qui ait leurs attributs propres, et cela dès la v1 de la fonctionnalité. Dans des versions ultérieures, on verra pour pouvoir qualifier le type de relation (membre de l'association vs directeur de l'association) et tout un tas d'autres choses.

Opinion de Benjamin:

(je brainstorm ne pas prendre ça pour une vision réaliste à court terme, mais au milieu il y a peut être une idée potable) mettre ça dans authentic me parait tordu et un peu dans la même démarche que quand on mettait mailing et paiement dans w.c.s., on transforme authentic en fourre-tout. Un web-service dans passerelle ou peut-être mieux une pseudo application CRM (contacto?) ferait tout aussi bien le job, elle permettrait:

• créer des contacts/personne morales/entités (famille?) avec toutes sortes de champs, on y aurait une notion de type de contact qui disposent d'une liste de champs, tout ça dans un backoffice
• on pourrait y lier des comptes Publik (UUID) à ces contacts via des relations typés "Président d'association", etc...
• le fait d'obtenir une relation donnerait un rôle du même nom dans Authentic (contacto appelerait authentic pour créer/attribuer ce rôle)
• on pourrait créer des formulaires visibles seulement à ces rôles
• dans ce formulaire on pourrait interroger contacto pour lister les entreprises/association dont le compte est représentant

Ça pourrait aussi faire partie de Corbo: il y a une proximité entre les notions de mailing-list et d'entité auxquels sont reliés des comptes, c'est en fait le cas le plus simple: une mailing-liste ou thématique a juste un nom et un seul type de relation "intéressé"; mais on pourrait imaginer un objet "école", qui a plein de champs (adresse, type, etc..) et plusieurs types de relations: élèves, parent d'élève, instituteur, directeur, on pourrait choisir de faire un mailing à tous les directeurs d'école, ou tous les parents d'élèves de l'école X, ou etc..

Pour les aspects familles on pourrait voir à provisionner Corbo en utilisant le connecteur passerelle vers le logiciel famille, en mode moissonnage. Le provisionning des utilisateurs Publik dans Corbo y créerait des contacts au lieu d'y créer des utilisateurs (sauf pour les utilisateurs ayant un compte "backoffice" eux auront aussi un vrai compte sur l'application).

Si on ne va pas jusque là je pousserai sinon pour un plugin passerelle "document store" qui servirait à construire un fonctionnement équivalent sur la base de formulaire w.c.s. qui viendraient lire/modifier les données (à base de JSON Patch/JSONPAth, etc..). Mais ce sera moins joli que si il y a un vrai backoffice et vite n'importe quoi.

Coté w.c.s. le besoin c'est:

• de pouvoir attacher des demandes à ces objets "personnes morales" dans welco, ce qui n'est possible que pour des utilisateurs, et donc ça demanderait de créer des utilisateurs correspondant, ou d'étendre la notion d'utilisateur coté w.c.s
• pour un responsable, de pouvoir créer ces demandes dans une sorte de version front-office des demandes pour le compte de, et pour certains formulaire de n'être utilisable qu'en demande pour le compte de, si on dispobe du lien nécessaire vers la personne morale, "pour faire une demande d'occupation d'espace public, il faut obligatoirement être responsable d'une entreprise, et la demande sera toujours attachée a`l'entreprise, pas à la personne qui demande",
• pour un responsable, devoir toutes les demandes faites au nom d'une personne morale dont il est responsable.

La premier besoin ne nécessite pas de modification il me semble à w.c.s il suffirait que contacto émette des messages de provisionning avec les informations; les deux autres par contre nécessitent que w.c.s. comprenne ces notions de lien/délégation puisqu'on ne peut pas se connecter réellement avec le compte de la personne morale. C'est bien complexe et ça revient à mettre des bouts un peu partout :/

Il reste l'histoire du "Fonction (indispensable car un courrier ne doit théoriquement pas être adressé nominativement)" qui me laisse penser que la donnée qui nous intéresse ce n'est pas la personne morale mais le lien lui même ; i.e. on attache pas la demande à Jean-Pierre Plumeau, ni à SARL Plumeau, mais à 'Gérant de la SARL Plumeau', ou alors c'est secondaire en on prévoit juste dans les modèles de courrier la formulaire "À monsieur le gérant de la SARL Plumeau," sachant que même si c'est la secrétaire qui gère, on écrit toujours au gérant.

A mon sens (Brice), ce n'est pas cela car pour une petite personne morale ne correspond qu'une personne physique mais dans le cas d'une administration, par exemple Education Nationale, une ville va devoir écrire au DSDEN, l'IA de circonscription, le responsable de l'opération "Sport à l'école", ... il y a bien plusieurs personnes physiques et une personne morale (et d'ailleurs dans ce cas il peut y avoir personne morale = EN, Académie, Circonscription, Direction, ...)

( Fred (à nouveau) : attention, il s'agit pour moi de pouvoir recevoir des demandes faites pour une association / entreprise / etc., qu'elles puissent être visualisées ensemble (que ce soit par un agent ou une personne liée à l'entité). Il ne s'agit pas de créer une gestion de courriers ) (si on voulait une gestion de courriers, entrants et sortants, on a un modèle fait pour la GED du PFWB) (mais on ne veut pas)