Index par titre
Nouveau format pour cette 10ème réunion du Club des utilisateurs Publik qui a réuni les deux journées habituellement séparées dans l'année :

Nouveau moyen d'échanges également puisque, en plus des participants réunis en présenciel, une participation à distance via une plateforme de visioconférence était proposée.


11ème réunion

Slides joints à la page.


12ème réunion

Le douzième club utilisateurs Publik a eu lieu à Villejuif le mercredi 7 juin et jeudi 8 juin.
Nous remercions l'équipe de Villejuif pour son accueil et sa belle organisation.

Programme

mercredi 7 juin

L'enregistrement du mercredi 7 juin est disponible sur https://visio.entrouvert.com/playback/presentation/2.3/a003b8d3985bd854c01fecd1ae9fa573e60f3e29-1686118471088

Vous retrouverez le programme de la journée :

jeudi 8 juin

L'enregistrement du jeudi 8 juin est disponible sur https://visio.entrouvert.com/playback/presentation/2.3/a003b8d3985bd854c01fecd1ae9fa573e60f3e29-1686204908378

Vous retrouverez le programme de la journée :

Documents

Les documents supports sont disponibles sur :
https://public.entrouvert.org/club/ClubVillejuif-RetourExperienceVillejuif-RelationsCrep_v01.pdf
https://public.entrouvert.org/club/ClubVillejuif-RetourExperienceLyonMetropole-ZFE.pdf
https://public.entrouvert.org/club/ClubVillejuif-RetourExperienceLyonMetropole-RGS.pdf

https://public.entrouvert.org/club/ClubVillejuif-Roadmap-2024.pdf
https://public.entrouvert.org/club/ClubVillejuif-Mutualiser%20le%20service%20Publik.pdf

Nous vous remercions pour votre participation, et sommes à l'écoute de vos retours et contributions.

Bilan sur le club par EO

Un bilan sur cette édition du club utilisateur a été fait le 9 juin 2023, par EO.

Ce qui était bien

Ce qui est à améliorer

Bilan sur le club par Villejuif

Un bilan sur cette édition du club utilisateur a été fait le 19 juin 2023, par l'équipe de Villejuif.

Suite à notre réunion d'hier, vous trouverez des retours de l'équipe de Villejuif sur le club utilisateurs :


+1 pour les signalements

Mis en place à GL et Nancy, la possibilité pour un usager de faire "+1" sur un signalement existant à proximité de l'endroit où il s'apprêtait à déclarer une anomalie. Ça lui permet de terminer sa demande sans avoir à décrire le problème et de pouvoir suivre la résolution quand même.

Formulaire

Définir un gabarit du résumé.

Ce gabarit apparaîtra comme résumé des demandes à proximité.
Exemple : Signalement au {{ form_var_numero }} {{ form_var_voie }}.

L'identifiant attendu pour le champs Carte où l'usager indique où se situe son signalement est : carte

Ajout de deux pages :

Par défaut les signalements à proximité sont présentés sans le bouton d'action "+1". Pour l'activer la variable activate_plus1_action avec la valeur True doit être définie dans Hobo.

Workflow

Du côté workflow, il y a introduction de deux données de traitement :

et ajout d'une action globale, "plus 1", configurée pour avoir un déclencheur de type "appel externe" (identifiant: plus1), et les actions suivantes :

Dans le workflow sont également à ajouter des mails à destination des abonnés ({{form_var_subscribers}}) et à poser l'action de géolocalisation, si pas déjà fait.

(fichiers .wcs d'exemple pour le formulaire et le worklow joints à cette page - réalisés pour Nancy)

Adaptations à prévoir lors de l'activation de la création de compte avec un numéro de mobile

Dans ce cas l'usager, peut avoir un numéro de mobile et pas de courriel. Donc sur une environnement cela nécessitera de d'abord adapter la fonctionnalité +1 :

[PierreC] Je propose une adaptation un peu différente : l'ajout sur la page des +1 de deux champs facultatifs pré-remplis avec le profil : courriel_follower et mobile_follower (avec un texte au-dessus pour dire que ce seront les coordonnées utilisées pour envoyer les infos de suivi). Plus besoin de popup à mon sens, si je renseigne rien je reçois rien. Ça nécessiterait des adaptations dans le WF bien sûr.

Évolutions

Évolutions faites ici : https://dev.entrouvert.org/projects/marseille/wiki/Signalement_-_%C2%AB_+1_%C2%BB
A retraiter à l'occasion.


Lundi 12 décembre 2016, à l'occasion du salon des Interconnectés, s'est tenue la deuxième réunion du Club utilisateurs de la solution de GRU "Publik".
Cette réunion était également ouverte aux collectivités intéressées par la solution Publik, même si non encore utilisatrices.

Participants et tour de table de présentation

Activités du club utilisateurs

Rappel des axes d'action retenus à la première réunion

Partage d'expériences

Liste de discussion

Rappel de la première réunion : sur la base d'un constat de faible utilisation de la plate-forme Bistro, il fut décidé de mettre en place la liste de discussion "publik-club-utilisateur@listes.entrouvert.com". L'abonnement à cette liste est systématiquement proposé à chaque nouvelle collectivité utilisatrice.

Le bilan d'utilisation de cette liste de discussion est mitigée (40 messages depuis l'ouverture en juin 2016 pour 47 abonnés).

Propositions d'Entr'ouvert pour encourager la participation : Discussion :

Certains demandent à ce que ces échanges se fassent sur Bistro, il est convenu de laisser une chance à la liste de discussion et également à bistro, une solution médiane se dessinera peut-être d'elle même.

Bistro

Entr'ouvert prévoit au minimum de remanier Bistro pour mieux mettre en valeur le catalogue des démarches (formulaires et workflows) disponibles.

Réunions en présenciel

Printemps 2017

Philippe Gippet invitera les membres du club utilisateur pour une journée à Montpellier au printemps (peut-être mai) :

Automne 2017

Organisation par Entr'ouvert sur Paris à l'occasion du Salon des Maires (21 au 23/11/17) sur une journée complète ou une après-midi plus soirée.

Faciliter l'arrivée de nouveaux acteurs autour de Publik

Instaurer un dialogue avec les interlocuteurs nationaux

Cet objectif, fixé lors de la première réunion, a été atteint dans la cadre du projet FranceConnect par des échanges réguliers avec le SGMAP ; de ce fait, contacts établis pour la suite : API données certifiées, FranceConnect agents.

Un écosystème autour de Publik

Entr'ouvert souhaite engager une dynamique autour de la solution Publik en favorisant l'entrée de nouveaux intégrateurs de Publik, c'est une démarche maintenant initiée, notamment avec AtReal avec qui nous partageons notre stand (ainsi qu'avec Maarch).
Nous allons proposer une charte de partenariat pour susciter des coopétiteurs, ce que nous considérons globalement bénéfique à l'écosystème Publik. La charte de partenariat qui leur sera proposée a été transmise aux membres du Club, via la liste de discussion. Cette charte, nous l'espérons, permettra de garantir une offre de qualité (nous conservons l'hébergement et formerons leurs équipes).

Au-delà de ce partenariat de premier cercle, discussion ouverte avec certains éditeurs propriétaires (tel Implicit) qui pourraient utiliser notre portail en frontal de leur propres logiciels métiers (gestion sociale dans le cas d'Implicit).

L'avenir

Réflexion ouverte au sein d'Entr'ouvert pour aboutir à "Publik 2020" : un écosystème de logiciels libres pour les collectivités qu'Entr'ouvert pourrait :

Ceci n'empêchera pas de créer des connecteurs avec des logiciels propriétaires mais l'objectif est bien d'encourager la libération de l'administration locale avec des logiciels se mariant bien.

L'orientation des évolutions

Ce qui a été mis en place depuis la première réunion du Club en juin :

Un consensus se dégage sur la nécessité de disposer d'informations le plus tôt possible, y compris sur des modifications mineures pour les agents. Philippe Gippet souhaite avoir une bonne visibilité sur les options qui sont affichés par défaut ou qui sont seulement activables à la demande.

Le rythme de 15 jours ne pouvant être changé (réactivité pour les projets en cours, sécurisation des développements), Entr'ouvert s'efforcera de plus/mieux communiquer sur les évolutions importantes avant même mise à disposition en recette (textes explicatifs - voir mock-ups - des changements à venir envoyés sur liste de discussion du Club, un mois ou plus à l'avance).

La mutualisation des investissements de développements

Pas beaucoup de temps consacré à ce point !
Sur la base de la discussion antérieure (meilleure visibilité des développements demandés par les uns et les autres), une mutualisation "naturelle" pourrait se mettre en place entre les utilisateurs désireux des mêmes fonctionnalités. Dans ce cas, il sera impératif de discuter sur la base de cas d'usage avant de parler de développements.

Discussion ouverte avec avis divers sur :

Conclusion

Organisation de la prochaine journée du Club

Philippe proposera aux utilisateurs (via la liste) :

Organisation de la communauté des utilisateurs

Il est proposé que certaines villes prennent le "lead" sur une thématique spécifique pour partager vers les autres et animer le débat ; cela pourrait, par exemple, être la thématique SVE pour la Ville de Meyzieu.

Divers

Est abordée la question de SVE dans le domaine de l'urbanisme avec une échéance forte en 2018.

L'intérêt d'un partage/recensement des logiciels métiers utilisés par chacun :

Repose la question, abordée en première réunion, du partage et de la visibilité de ces informations plus sensibles.


Jeudi 7 décembre 2017, lors du salon des Interconnectés, s'est tenue la quatrième réunion du Club utilisateurs de la solution de GRU "Publik", la 3ème réunion s'étant tenue à Alfortville en juin 2017.

Participants et tour de table de présentation

Les participants sont invités à se présenter en mentionnant un aspect spécifique de leur projet et un développement souhaité pour Publik. Présence également

Activités du club utilisateurs

Rappel des objectifs du Club

Partage d'expériences

Liste de discussion

Cette liste est utilisée comme une liste de diffusion (essentiellement des notes de mises à jour, 2 fois /mois) et non pas comme une liste de discussion.
Actions proposées :

Les rencontres en présenciel

Confirmation du rythme initialement proposé : une réunion (3 heures) à l'occasion des Interconnectés en décembre, une journée complète au printemps, à l'invitation d'une collectivité utilisatrice.
Pour ce printemps 2018, se proposent Grand Lyon ou Montpellier Métropole, en juin probablement.

Autres temps d'échange

Il est proposé, en plus de ces deux réunions en présenciel, des échanges à distance, sous forme de groupes de travail sur des sujets précis, tels :

Pour tenir de telles réunions à distance, Entr'ouvert propose d'utiliser sa conférence téléphonique, probablement avec un outil de visioconférence et partage d'écran en parallèle, tel https://appear.in/publik ou https://nextcloud.com/webrtc/
Sera ultérieurement décidé de l'opportunité de tenir un tel groupe de travail en présenciel sur la période du Salon des maires à Paris (novembre 2018), dans nos locaux parisiens.

Faciliter les échanges

Afin de faciliter les échanges entre collectivités, il est souhaité mieux connaître chacun des utilisateurs, les compétences présentes au sein de chacun d'eux, les problématiques abordées sur le territoire concerné. Se pose alors la question de mise en place d'un outil pour connaître la road-map et les développements spécifiques commandés par chaque collectivité, chaque collectivité devant pouvoir éditer sa propre fiche "projet".
En attendant la mise en place éventuelle d'un autre outil plus adapté, Entr'ouvert ouvrira un espace d'échanges (wiki) sur la plate-forme Redmine, plate-forme que chacun d'entre vous utilise déjà pour le suivi de son propre projet.
Les outils qui seront étudiées (liste non limitative) : https://framavox.org, https://decidim.org ...

Orientation des évolutions

Les évolutions souhaitées par les utilisateurs et envisagées par Entr'ouvert sont présentées dans le diaporama (annexé à cette page).

Mutualisation des investissements

Arles annonce la possibilité de participer aux investissements suivants :

Autres projets

Cette réunion a également été l'occasion de présenter deux projets envisagés à moyen-terme par Entr'ouvert :
Lieu de l’événement : Strasbourg.
Date : 30/08/2018 de 9h à 16h.
Participants à cette réunion :

Le 6 novembre 2018, lors du salon des Interconnectés, s'est tenue la sixième réunion du Club utilisateurs de la solution de GRU "Publik", la 5ème réunion s'étant tenue à Strasbourg en août 2018.

Tour de table

Nancy : Strasbourg : Tours : ALPI (syndicat mixe) : Villejuif : Nanterre :

Nouveautés

Évolutions

Remplacement de Bistro Présentation du catalogue :

Échanges à venir

Groupe de travail : pourrait porter sur "trousseau de données"


La 8ème réunion du Club des utilisateurs Publik s'est tenue, le mercredi 4 décembre 2019, au Musée de la Cour d'Or, à l'invitation de Metz Métropole, nous les remercions chaleureusement ; le succès de cette journée tient en bonne partie à la qualité de leur accueil et au lieu mis à disposition.

Matinée

Présentation du projet messin par Anne Adam et Olivier Renard

Présentation très intéressante et complète d'un projet de mutualisation à l'échelle d'un territoire : 37 communes impliquées.
Focus sur Fabrik, un outil méthodologique pour accompagner les communes de la métropole dans la construction de leurs démarches sur Publik : à mettre entre toutes les mains : https://metz.test.entrouvert.org/
NB : c'est fait avec Publik, naturellement.
À noter également, la sobriété et légèreté (600 ko) de la charte graphique utilisée de connectMetz (https://services.metzmetropole.fr/).

Nouveautés 2019

Outils collaboratifs et développements mutualisés

Rappel sur les outils existants (liste de diffusion, https://catalogue.publik.love/) et l'ouverture de Tracim (https://publik.tracim.fr), en conséquence de quoi le Bistro (https://bistro.entrouvert.com) va fermer prochainement.
Intervention de Rouen pour rappeler une demande émise lors du Club de juin 2019 : mettre en place des réunions téléphoniques entre utilisateurs. Réponse d'Entr'ouvert : nous disposons de plusieurs conférences téléphoniques qui peuvent être mises à disposition ; des discussions, par exemple pour échanger sur des cas d'usages, sont donc envisageables facilement.

Après-midi

Atelier connecteurs

Un connecteur : Retour d'expérience de Vénissieux :

Demande des participants : disposer de la documentation des connecteurs directement dans Passerelle, si possible.
Réponse d'Entr'ouvert : nous prévoyons de rajouter un champ dans passerelle permettant d'indiquer directement l'url d'une page wiki sur redmine qui viendra apporter des compléments documentaires sur le connecteur.

Atelier Publik 2020 / Publik Studio

Publik2020 : intégration possible de Tracim parmi les logiciels Publik2020, à noter que le département du Calvados est en cours de test de cette solution, en parallèle avec NextCloud.
Propositions bienvenues d'un nouveau nom pour Publik 2020, ; si vous ne trouvez rien de mieux, du côté d'Entr'ouvert on est assez partant pour "Enlarge your Publik".

Roadmap 2020

La roadmap Publik est visible en ligne : https://dev.entrouvert.org/projects/publik/issues?query_id=241
Cette roadmap est amenée à évoluer en cours d'année en fonction des financements apportés par les utilisateurs actuels et les demandes exprimées dans les documents de marchés publics des nouveaux utilisateurs entrants.

En plus des évolutions proposées par Entr'ouvert, les points suivants ont été évoqués par les utilisateurs présents :

Appréciation

L'équipe Entr'ouvert présente a beaucoup apprécié cette journée, divers retours de votre part nous laisse penser que ce fut partagé. Nous avons constaté une forte augmentation du niveau de compétence moyen des participants, c'est réellement spectaculaire : l'autonomisation, ça marche.
Le partage d'expériences est toujours plébiscité, la longue pause déjeuner était parfaite. Merci de vous être prêté·e·s au jeu de la fiche de présentation complétée à l'avance, ces fiches sont disponibles ci-dessous.

Annexe, fiches de présentation des participants

Département du Calvados

Descriptif (ouverture en décembre 2013) :
- Fin 2013 : APA en ligne sur une plateforme "Au qotidien" (i.e. ancêtre de Publik)
- 2017: Début d'une opération 100% démarches en ligne
- 2017-2018 : mise en ligne de demandes de subvention : APCR (aide aux communes rurales), échanges scolaires (collèges), sport et manifestations, patrimoine, comités de jumelages... en interne : frais de déplacement des élus, adhésion COS
- 2019 : passage à Publik
- 2020 : projet d'ouverture d'un portail de démarches agents

Évolutions envisagées :
- poursuite de notre projet 100% démarches en ligne
- rendre les démarches en ligne plus facilement accessibles en lien avec la mise en conformité et accessibilité (portail de démarches)
- création et mise en ligne d'un portail pour les démarches internes avec Publik (actuellement fait sous Jahia donc pas de workflow)
- poursuite de la mise en conformité RGPD de toutes les démarches : informations aux usagers, politiques de protection des données...

Ville de Nancy

Descriptif (ouverture au printemps 2016) :
- Premiers formulaires mis en ligne en juin-juillet 2016 (environ 30aine), phase préliminaire
- Décembre 2016 : phase opérationnelle avec plus de 60 formulaires
- À ce jour, plus de 180 000 demandes déposés (près de 65 000 par an en moyenne) dans 115 formulaires internes et externes accessibles ; 250 agents formés à Publik.

Évolutions envisagées :
- Interfacer Publik à un parapheur électronique pour développer les formulaires internes à la collectivité qui demandent des visas hiérarchiques.
- Améliorer la partie statistique et rendu graphique

Département du Nord

Descriptif (ouverture en octobre 2017) :
- septembre 2017 : ouverture d'un centre de contact pour les services sociaux (UTPAS) d'un territoire du Département
- novembre 2017: le portail Agent de Publik est utilisé pour l'enregistrement et le suivi des appels reçus par le centre de contact
- octobre 2019 : les compétences du centre de contact sont élargis à d'autres appels et à la prise de rendez-vous "Orientation des allocataires du RSA". Publik aussi !

Évolutions envisagées :
- pour 2020 : amélioration du module RdV de Publik, ouverture d'un autre centre de contact sur un autre territoire.
- ce qui pourrait être fait : élargir le module rdv à d'autres types de rdv, ouvrir un portail Usagers, développer les connexions avec notre progiciel d'action sociale (IODAS)

Ville de Metz

Descriptif (ouverture en janvier 2018), Mise en œuvre de ConnectMetz :
- Reprise de l'existant et développement de formulaires pour des démarches municipales (dont démarches mutualisées avec Metz Métropole, en particulier pour les signalements d'anomalies sur le domaine public).
- Les démarches en place concernent des démarches ponctuelles (inscription à des évènements ou dispositifs) ou permanentes

Évolutions envisagées :
finaliser l’intégration système et mettre Publik au cœur des dispositifs de démarches et d’information dès lors qu’orienté usager (intégration des fonctionnalités des portails annexes dans un espace personnalisé usager) pour faire de ConnectMetz l’espace de référence numérique pour les citoyens/usagers.

Metz Métropole

Descriptif (ouverture en septembre 2018) :
- Créer une plateforme territoriale pour permettre à la métropole et ses 44 communes d'offrir des services en ligne, de se faire le relais l'une l'autre des demandes des usagers.
- Démarches en cours autour du signalement d'une anomalie sur le domaine public, sur les déchets, pour les scolaires de l'Opéra-Théâtre, démarches Ville de Metz.
- Développement en cours sur d'autres démarches Déchets.

Évolutions envisagées :
Développer de nouveaux services, notamment l'offre culturelle pour les scolaires et l'offre communale, avec des services communs aux diverses communes de la métropole.

Toulouse Métropole et Mairie de Toulouse

Descriptif (ouverture en 2018) :
- Migration du portail E-administration citoyen et des téléservices existant montoulouse.fr (Ville de Toulouse) sur Publik
- Ouverture d'un portail de démarches métropolitaines Toulouse Métropole sur Publik (septembre 2019) : demande de composteur, paiement, prise de RdV encombrants.
- Lancement de nouvelles démarches full Publik, mise en œuvre du Portail Agent Métropolitain via le back-office du Portail Publik Toulouse Métropole.

Évolutions envisagées :
- Portail Agent Métropolitain via le back-office de Publik (agents métropolitains et communaux).
- Démarches agents et usagers en mobilité ++ : démarches intégrant cartographie, progressive web app, mode offline, suivi des demandes.
- Avant-vente auprès des petites communes (nouvelles instances Publik pour leurs propres démarches) et organisation d'une structure pour assurer le support.
- Mise en œuvre d'un Allo Métropole et extension de l'offre Publik aux guichets communaux

Ville de Vénissieux

Descriptif (ouverture en 2019) :
- Prises de RDV en ligne
- Location de salles (interface avec logiciel métier, paiement en ligne)
- Gestion des signalements usagers
- Gestion des recrutements (demandes de recrutement, candidatures en ligne et sélection, constitution du dossier administratif)
- Gestion des arrivées, départs et dotations (téléservice interne)
- Demandes de subventions
- Sondages en ligne

Évolutions envisagées :
- Centraliser la relation usager via l'outil Publik
- Développer les téléservices internes (demandes de prestation avec workflow élaboré) afin de rationaliser les processus de la collectivité
- Développer les téléservices gérant les inscriptions des usagers (sports, jeunesse,...)
- Intégrer les circuits de signature (via certificat électronique) concernant les arrêtés
- Intégration des flux d'archivage

Département des Alpes-Maritimes

Descriptif (ouverture en janvier 2019) : à terme, fournir un accès unique pour les usagers du Département afin qu'ils puissent réaliser un maximum de démarches dématérialisés.

Rouen

Descriptif (ouverture en février 2019) :
- Reprise d'une 50aine de démarches déjà en ligne (sur CMS du site web) avec ajout d'un suivi pour l'usager
- Mise en place de démarches emblématiques : subventions aux associations, organisation d'évènements...
- Amélioration de l'efficacité interne et forte conduite du changement dans les services
- Déploiement à terme de 300 démarches en ligne

Évolutions envisagées :
- Mise en ligne de démarches auprès de professionnels à fort impact pour la collectivité
- Industrialisation des process et de grandes familles de démarches

Conseil départemental de la Haute-Garonne

Descriptif (ouverture en juin 2019) :
- Première brique consacrée aux usagers du transport scolaire gratuit (bénéficiaires et professionnels).
- Développements en cours : démarches dans le domaine de la solidarité et de la culture, connecteurs avec les portails métiers existants (fédération d’identité et échanges d'informations).

Évolutions envisagées :
- Analyser la relation usager des différents services pour identifier de nouvelles démarches.
- Renforcer l'articulation entre le déploiement de Publik et la refonte de la politique d'accueil du département.
- Renforcer la communication en interne autour de Publik auprès des décideurs et des acteurs de la relation usager.
- Privilégier Publik pour répondre aux besoins de GRU du département par rapport aux autres solutions (portails métiers, solutions portées par les start-ups d'État, ...).

Clermont Auvergne Métropole

Descriptif (ouverture en juin 2019) : le projet a débuté par la mise en place de Publik afin de gérer les demandes d'urbanisme pour le service mutualisé d'instruction de la métropole, il s'est petit à petit modifié en un réseau de portails pour la métropole et ses communes. L'idée est de mettre en place un compte de territoire porté par une marque neutre sans référence à l'une des collectivités.

Évolutions envisagées : En se basant sur le concept de marque commune, avoir un portail pivot servant d'annuaire de démarches et renvoyant sur le bon portail, quel que soit la collectivité.

CNIL

Descriptif (ouverture en février 2020) : bascule progressive sur Publik de l'ensemble des démarches en ligne (particuliers & professionnels), mise en place d'un portail usager, pré-traitement (complétude) dans Publik avant import dans l'outil métier.

Évolutions envisagées : on continue ce qui est prévu i.e. remplacement des téléservices par Publik, utilisation en interne également (sondages, moyens généraux, processus RH...)

Métropole du Grand Nancy

Descriptif (ouverture prévue en avril 2020) :
- Faciliter les démarches et échanges avec l’administration.
- Simplifier la vie du citoyen dans ses relations quotidiennes avec la collectivité.
- Offrir un service dématérialisé transverse multiple (site Web, applications mobiles…).
- Proposer un point d’entrée unique et sécurisé à un ensemble de e-services (téléservices).
- Remplacement/adaptation des formulaires en place

Évolutions envisagées :
- Mutualisation des GRU présentes en vue de la mutualisation probable entre la ville centre et la métropole.
- Un accès en mobilité plus présent
- Prise en compte de l'inclusion numérique


La 9ème réunion du Club des utilisateurs Publik s'est tenue sur deux matinées (les 2 et 3 décembre 2020) à distance, via une plateforme Big Blue Button (du fait de la pandémie Covid-19, il n'y a pas eu de session du Club tenue au printemps 2020).
Ce format en visio-conférence était une première et nous avons été agréablement surpris par la qualité des échanges qui furent possibles ; de plus ce format à distance favorise la participation puisque nous étions plus de 90 en ligne (en comparaison, nous étions l'année dernière, réunis à Metz, une 40aine).
La remontée des questions par chat s'est révélée très efficace, nous avons ainsi pu répondre, en temps réel, à la quasi-intégralité des questions posées durant les interventions.

Matinée du 2 décembre

Nouveautés 2020

Présentation par Entr'ouvert, Marie Kuntz.

Cette présentation a été l'occasion par les utilisateurs de Publik d'exprimer leurs satisfactions sur ces évolutions récentes mais aussi de réclamer de nouvelles fonctionnalités. Les demandes ayant suscitées le plus de "+1" sur le chat :

Pour action, à suivre

Lors de cette séance, plusieurs utilisateurs ont plébiscité l'idée d'organiser des présentations de fonctionnalités, sur base de cas d'usages, par une collectivité elle-même.
Entr'ouvert mettra à disposition un salon sur la plate-forme Big Blue Button et pour amorcer le mouvement Marie propose une démonstration de réalisation d'une "base de connaissance" :

Accueil et guichet unique

Présentation par Entr'ouvert, Pierre Cros.

Les retours principaux exprimés durant la présentation :

Les séances de partage entre utilisateurs, évoquées lors de la séance précédente, pourraient débuter par une présentation de Publik utilisé pour un accueil au guichet (ou dans un centre d'appels) par les collectivités l'ayant mis en place ; autre sujet possible : expliquer l'intervention du Community Manager de la collectivité : à vous de jouer.

Les retours des utilisateurs pendant cette première matinée

La liste ci-dessous n'a pas vocation à être exhaustive, les échanges sur https://publik.tracim.fr sont bienvenus pour poursuivre la discussion.

Matinée du 3 décembre

Retour d'expérience studio

Présentation par Toulouse, Jérôme Romani

La métropole et la ville de Toulouse ont décidé de ré-internaliser le savoir-faire de création de démarches, pour ce faire l'équipe initiale de de 2 personnes est maintenant constituée de 5 agents. La mise en œuvre de Publik Studio contribue parfaitement à cette stratégie.

Roadmap 2021

Présentation par Entr'ouvert, Pierre Cros

La roadmap Publik est disponible en ligne :
https://dev.entrouvert.org/projects/publik/issues?query_id=268

Cette roadmap est amenée à évoluer en cours d'année en fonction des financements apportés par les utilisateurs actuels et des demandes exprimées dans les CCTP des nouveaux utilisateurs entrants.
Nous lancerons les appels à financements mutualisés prochainement mais si vous êtes d'ors et déjà intéressé·e·s par un développement particulier, n'hésitez pas à vous manifester.
Nota bene : la contribution à un financement mutualisé ne renchérit pas le coût de votre maintenance annuelle car la maintenance de ces nouveaux développements, intégrés dans le cœur de Publik, est mutualisé sur l'ensemble des utilisateurs.

Les retours de la seconde matinée

Vos demandes :

Et un autre sujet pouvant faire l'objet d'un partage entre vous, utilisateurs : la génération d'arrêtés directement depuis Publik (cas d'usages existant à Rouen, Vaulx-en-Velin, Tours...)


Pêle-mêle

Ajout du concept de workflow imbriqué i.e. possibilité de définir un workflow comme sous-tâche d'un workflow principal. Utilisation possible : sous-workflow de "demande d'informations complémentaires auprès de l'usager" intégrable dans plusieurs workflows,
- Statut : réflexion engagée
- Couverture : 0 % de financement acquis

Ajout d'une action retour au statut précédent au sein des workflows (#4228)
- Statut : souhait !
- Couverture : 0 % de financement acquis

Ajout d'une demande de confirmation sur une action de work-flow, tel "Changer de statut" (#6791)
- Statut : souhait !
- Couverture : 0 % de financement acquis

Intégration facilitée avec les services Cloud entreprise (Google Apps, Dropbox…)
- Statut : information needed!
- Couverture : 0 % de financement acquis


Configurer ADFS comme fournisseur d'identités SAML pour Publik

On suppose dans ce qui suit qu'un système Publik est installé sur https://demarches.ville.fr/. Le système de connexion est alors présent sur https://connexion.demarches.ville.fr/ et c'est lui qui doit être référencé comme « Service Provider » dans ADFS.

Ajout du « Relying Party » dans ADFS

La configuration des services ADFS s’effectue via la console « AD FS Management ». Nous créons « relying party trust » à partir des informations présentes dans les metadonnées SAML 2.0 de Publik.

En cliquant sur « Add Relying Party Trust… » on sélectionne le type d’application souhaitée: Claim aware.

Nous allons à présent utiliser la fonction d’import automatique de la configuration Publik présente dans les metadonnées.

L'URL des métadonnées de Publik est de la forme https://connexion.demarches.ville.fr/accounts/saml/metadata/ (à indiquer dans la partie en jaune de la copie d'écran ci-dessous)

Saisir le nom du « Relying Party Trust: », indiquer par exemple connexion.demarches.ville.fr

On choisit ensuite qui aura accès à Publik via ADFS, cela dépend des choix de la collectivité, dans un premier temps choisir everyone (tout le monde) simplifie la configuration

Avant de valider la fin de la configuration, nous allons vérifier que le « Relying party identifier » et bien identique à « ApplicationDefaults EntityID » de Publik :

Nous laisserons la case « Configure claims issuance policy for this application » cochée. La fenêtre nous permettant d’éditer le contenu de notre claim s’ouvre.

Configuration des attributs à envoyer à Publik (claims)

Dans la liste des « Relying Party Trusts » s'affiche désormais celui de Publik qui vient d'être ajouté. Cliquer dessus et choisir l'action « Edit Claim Issuance Policy… »

Le bouton « Add Rules » permet alors de définir les attributs à envoyer.

Dans le cadre d'une connexion à Publik il faut envoyer les attributs suivants :

Attention : La copie d'écran ci-dessous est un exemple qui montre la configuration avec l'envoi de UPN et Display Name ; mais c'est Name, GivenName, Surname et EmailAddress qui devront apparaitre dans le cas d'un Publik.

Configuration côté Publik

La configuration du « Relying Party Trust ADFS » est alors présent terminée sur ADFS, qui reconnait désormais Publik comme service de confiance.

Il faut maintenant configurer Publik pour qu'il utiliser ADFS comme source d'identité possible (en plus des comptes locaux et du connexion FranceConnect éventuelle).

Cas AD "On premise" - hébergé par la collectivité

Pour cela, et si ce n'est pas déjà fait, il faut communiquer à Entr'ouvert l'adresse des métadonnées de l'IdP ADFS SAML, qui est normalement de la forme https://idp.ville.fr/FederationMetadata/2007-06/FederationMetadata.xml (où idp.ville.fr est le nom du serveur ADFS sur Internet).

A toutes fins utiles (surtout en interne pour Entr'ouvert), voici la procédure pour la configuration dans Publik.

1. Création de clés 2048 bits :

openssl req -x509 -sha256 -newkey rsa:2048 -nodes -keyout sp-saml.key -out sp-saml.crt -batch -subj '/CN=connexion.demarches.ville.fr' -days 3652

2. Copier les fichiers sp-saml.key et sp-saml.crt dans le répertoire du tenant /var/lib/authentic2-multitenant/tenants/connexion.demarches.ville.fr/
3. Créer un rôle "Connexion ADFS"
4. Obtenir l'URL des métadonnées, comme dit plus haut de la forme "https://idp.ville.fr/FederationMetadata/2007-06/FederationMetadata.xml" et la mettre dans settings.json (voir plus bas) pour la clé METADATA_URL
5. Ajouter dans settings.json :

{
  "A2_AUTH_SAML_ENABLE": true,
  "MELLON_PUBLIC_KEYS": ["/var/lib/authentic2-multitenant/tenants/connexion.demarches.ville.fr/sp-saml.crt"],
  "MELLON_PRIVATE_KEY": "/var/lib/authentic2-multitenant/tenants/connexion.demarches.ville.fr/sp-saml.key",
  "MELLON_PROVISION": true,
  "MELLON_IDENTITY_PROVIDERS": [
    {
      "METADATA_URL": "https://idp.ville.fr/FederationMetadata/2007-06/FederationMetadata.xml",
      "PROVISION": true,
      "A2_ATTRIBUTE_MAPPING": [
        {"action": "rename", "from": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", "to": "givenname"},
        {"action": "rename", "from": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", "to": "surname"},
        {"action": "rename", "from": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", "to": "name"},
        {"action": "rename", "from": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "to": "email"},
        {"attribute": "first_name", "saml_attribute": "givenname", "mandatory": true},
        {"attribute": "last_name", "saml_attribute": "surname", "mandatory": true},
        {"attribute": "username", "saml_attribute": "name", "mandatory": true},
        {"attribute": "email", "saml_attribute": "email", "mandatory": true},
        {"action": "toggle-role", "role": {"name": "Connexion ADFS"}}
      ],
      "LOOKUP_BY_ATTRIBUTES": [
        {"saml_attribute": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "user_field": "email"}
      ]
    }
  ]
}

Cas où l'IdP n'est pas accessible depuis Authentic

Dans ce cas les métadonnées ne pourront pas être téléchargées par authentic, on modifie donc les étape 4 et 5:

4. Demander les métadonnées de l'ADFS et les copier dans /var/lib/authentic2-multitenant/tenants/connexion.demarches.ville.fr/adfs-metadata.xml
5. Retirer la clé METADATA_URL de la configuration et mettre à la place "METADATA": "/var/lib/authentic2-multitenant/tenants/connexion.demarches.ville.fr/adfs-metadata.xml",

Cas Azure AD "SaaS" - hébergé par Microsoft

La configuration est quasiment la même mais on ne peut pas facilement deviner l'URL des métadonnées, car elle est unique pour chaque fournisseur de service et généralement de la forme suivante :

https://login.microsoftonline.com/180627ee-80c9-4bec-95e6-81b5fecd81ff/federationmetadata/2007-06/federationmetadata.xml?appid=9b9854e3-633c-4124-8040-fe07dd445195

Par contre elle est toujours accessible publiquement et donc la configuration via un fichier ne sera normalement jamais nécessaire. Il est important de passer par une URL car les clés pourraient être souvent mises à jour.


Sauvegarde du Saas Publik Entr'ouvert

Quelles sont les données sauvegardées ?

Toutes les données des différents modules, c'est-à-dire autant les données fichiers que les bases de données associées.

Le(s) lieu(x) de stockage des données sauvegardées ?

Serveur OVH dans le datacenter de Strasbourg (les applications étant elles dans les datacenter de Gravelines et/ou Roubaix).

Quelle est la fréquence des sauvegardes ?

Quotidienne; il est à noter qu'en parallèle existe un archivage à chaud des transactions sur les bases de données, permettant une récupération de la base de données à un instant précis (PITR, Point-in-time recovery).

Les types de sauvegardes ?

Pour les fichiers, sauvegarde incrémentale; pour les bases de données, instantané des données et archivage PITR.

Les types de supports ?

Disques durs.

La durée de rétention des sauvegardes ?

Sauvegardes sur une période de 3 mois, compressées, dédupliquées et conservées: 7 sauvegardes quotidiennes et 4 mensuelles.

Les délais de restauration des données sauvegardées

Deux jours.

Les procédures de test de restauration

Il n'y a pas de tests formalisés, que les sauvegardes sont plutôt validées parce que des collectivités nous demandent régulièrement de récupérer des données qu'elles ont supprimé par mégarde.

Quelle(s) société(s) effectue(nt) les sauvegardes et les restaurations (Soustraitance) ?

Pas de sous-traitance.


Argumentaire sécurité

Contexte

Objectif :

(Version initiale Argumentaire de sécurité)

Autres ressources

Mesures de sécurité

Entr'ouvert s’engage à mettre en œuvre les mesures de sécurité visant apporter une protection suffisante des données à caractère personnel. Ces mesures devront à la fois porter sur les données à caractère personnelles confiées (a) et sur les mesures générales de sécurité du système (b).

Les mesures de protection sur les données à caractère personnel

Les mesures mises en œuvre par Entr'ouvert doivent être adaptées à la sécurité des données confiées. Entr'ouvert détaillera les mesures de protection des données à caractère personnel mises en œuvre au sein de son organisation, le cas échéant parmi les mesures suivantes.

Le chiffrement des données

Moyens mis en œuvre pour assurer la confidentialité des données conservées (en base de données, dans des fichiers plats, dans les sauvegardes, etc.) ainsi que les modalités de gestion des clés de chiffrement (création, conservation, modification en cas de suspections de compromission, etc.).

Nous respectons le principe de base de la protection des données qu'est la proportionnalité des mesures préventives -- l'envergure de ces mesures étant directement liée à la criticité des données à caractère personnel collectées et traitées dans l'environnement Publik.
Notre moteur de base de données est le SGBDR (système de gestion de bases de données relationnelles) PostgreSQL, outil libre, reconnu pour sa robustesse et sa sécurité.
Nos bases de données, comme le reste de l'infrastructure Publik, sont situées sur des machines physiques hébergées par notre sous-traitant OVH, et accessible seulement à l'aide du protocole SSH par clé RSA (pas d'authentification par mot de passe, jugée d'une sécurité trop faible) par les techniciens de l'équipe d'Entr'ouvert.
L'ensemble de clés autorisées est maintenu de façon cohérente.
Par exemple, lorsqu'un technicien quitte l'équipe, sa clé est désactivée.

Nos bases de données sont aussi sauvegardées toutes les nuits et ces sauvegardes sont stockées sur un site tiers.
Des sauvegardes quotidiennes sont conservées une semaine, et des sauvegardes mensuelles quatre mois.
Les sauvegardes sont détruites au delà de ce délai.

Les mêmes critères de conservation sont appliqués à la sauvegarde des fichiers situés sur le système de fichier réseau NFS (Network File System).
Ces sauvegardes nous permettent entre autres de rétablir un état cohérent des bases de données en cas de compromission des données stockées.

Le chiffrement des flux

Description le cas échéant des moyens de chiffrement employés pour les flux de données (VPN, TLS, etc.) intégrés dans le traitement.

Les communication se font en HTTPS (HTTP sur TLS).
Le certificat HTTPS est soit délivré par la collectivité, soit obtenu via une autorité de certification reconnue (LetsEncrypt, par exemple).

D'un point de vue applicatif, l'interface entre logiciels métiers externes et la fabrique de formulaire contenant les données des utilisateurs se fait à l'aide de requêtes nécessairement signées, réduisant les risques d'usurpation d'identité numérique de l'un de ces logiciels.
Les signatures, de type HMAC (Hashed Message Authentication Code), se basent sur la fonction de hachage SHA-256 (Secure Hash Algorithm, produisant des hachés de 256 bits de longueur), considérée cryptographiquement robuste selon les critères en vigueur de nos jours.

Mesures de securité complémentaires

À défaut de procédure de chiffrement, description de l’existence de procédures garantissant que des tiers au contrat ne puissent pas avoir accès aux données confiées.

Outre les procédures de chiffrement décrites plus haut, nous développons nos applications à l'aide du framework Django.
Ce dernier propose des mécanismes de prévention des attaques usuelles sur le Web (notamment la prévention contre injections SQL, les scripts inter-site (Cross site-scripting, XSS), le forgeage de requêtes inter-site (Cross-site request forgery, CSRF)).

Enfin, la partie publique des clés SSH autorisées à accéder aux différents serveurs est centralisée dans notre dépôt utilisé par l'outil de gestion de configuration de serveur Puppet.
Le retrait d'une clé, par exemple lorsque quelqu'un se voit retirer ses accès aux serveurs, se fait de façon directe, et est appliqué à l'ensemble de notre infrastructure.

L’anonymisation des données

Description des mécanismes d’anonymisation, des garanties qu'ils apportent contre une ré-identification éventuelle et à quelle fin ils sont mis en œuvre.
L'anonymisation des données des utilisateurs est paramétrable dans Publik.
Les mécanismes d'anonymisation sont les suivants :

D'une façon générale, le RGPD impose au minimum l'anonymisation (quand ce n'est pas la suppression) des données dès lors que leur conservation n'est plus utile au traitement auquel l'usager a consenti.
Avec l'accord de la CNIL, avec qui nous travaillons, nous nous imposons un délai maximal de trois mois pour l'anonymisation des demandes contenant des données personnelles des usagers.
Les formations données par nos chefs de projets aux agents, formations relatives à la construction des démarches Publik, tiennent compte de cette nécessité d'anonymiser les demandes contenant des données à caractère personnel.

Le cloisonnement des données

Description des méthodes utilisées pour cloisonner le traitement chez Entr'ouvert.

Le cloisonnement des données dans l'architecture Publik repose principalement sur les propriétés de multitenancy de notre moteur de base de donnée relationnelle PostgreSQL.

Le multitenancy (i.e. "multi-hôte") permet à PostgreSQL d'assurer la séparation des données de plusieurs sites d'une même application.
Dans le cadre d'une installation Publik multi-collectivités, le système de contrôle d'accès basé sur les rôles (Role-Based Access Control, RBAC) permet de s'assurer que les données d'une collectivité restent cloisonnées à cette collectivité et aux rôles qui y sont liés (et donc qu'elles ne puissent pas être lues par un membre d'un autre collectivité de l'instance Publik, ce membre ne possédant pas les rôles adéquats).

Le contrôle des accès logiques

Description de la manière dont les profils utilisateurs sont définis et attribués. Il conviendra de détailler les moyens d’authentification mis en œuvre en précisant, le cas échéant précisez les règles applicables aux mots de passe (longueur minimale, structure obligatoire, durée de validité, nombre de tentatives infructueuses avant blocage du compte, etc.).

Le fournisseur et gestionnaire d'identités de Publik, Authentic, reprend et étend les mécanismes de contrôle d'accès de Django.
Ce fournisseur définit un ensemble de rôles techniques, pour sa gestion en interne, et un ensemble de rôles métiers, voués à être approvisionnés dans les autres briques du logiciels Publik.

Authentic assure aussi l'authentification des comptes usagers de Publik.
Il fournit un mécanisme d'authentification modulaire.
Ainsi, l'usager s'identifie par login/mot de passe, ou bien, si Authentic est configuré pour, de recourir à une fournisseur d'identités tiers (lequel proposera alors indépendemment de Publik ses propres moyens d'authentification).

Le choix d'un mot passe pour l'authentification d'un usager doit respecter les contraintes suivantes :
8 caractères au minimum, dont au moins une lettre minuscule, un chiffre et une lettre majuscule.
La politique de complexité des mots de passe est paramétrable.
Il est aussi possible d'activer un temps d'attente exponentiel après chaque tentative d'authentification infructueuse.

Enfin, le support de l'authentification à plusieurs facteurs est en voie de développement dans notre fournisseur d'identités Authentic.

La politique de journalisation

Description de la politique de journalisation des événements et de conservation des traces qui en résultent.

Une fonction de journalisation des actions impliquant les logiciels métiers externes est mise en place directement dans la base de connecteurs Passerelle.
Par ailleurs, une application de journalisation pour le fournisseur d'identité est en cours de développement.

La politique d’archivage

Description de la politique de conservation et gestion d’archives électroniques contenant des données à caractère personnel destinées à garantir leur valeur, notamment juridique, pendant toute la durée nécessaire (versement, stockage, migration, accessibilité, élimination, politique d'archivage, protection de la confidentialité, etc.).

La conservation des données des systèmes de fichiers réseau inclut l'ensemble des logs Web et applicatifs.
Ces données, bien évidemment à caractère personnel, et à valeur juridique potentielle, bénéficient de la même politique de conservation stricte des sauvegardes des données des serveurs de l'architecture Publik.

La politique de sécurisation des documents papiers

Description de la sécurisation de la gestion des documents papiers (de l’impression au stockage jusqu’à la destruction et aux échanges de documents).

Nous ne proposons pas de service impliquant une gestion de documents au format papier.

La politique de minimalisation des données collectées

La sensibilité des données peut être réduite à l'aide des méthodes suivantes : filtrage et retrait, réduction de la sensibilité par transformation, réduction du caractère identifiant des données, réduction de l'accumulation de données, restriction de l’accès aux données.

La réduction de la collecte des données à ce qui est strictement nécessaire pour mener à bien le traitement fait partie de notre activité d'accompagnement à la conception des démarches dans Publik.
Les formation à la conception de ces démarches ont pour objectif majeur la sensibilisation à la nécessite de minimaliser la collecte de données.

Les mesures générales de sécurité du système

Les mesures mises en œuvre par Entr'ouvert doivent être adaptées à la sécurité des données confiées. Entr'ouvert détaillera les mesures générales de sécurité du système mise en œuvre au sein de son organisation, le cas échéant parmi les mesures suivantes.

La sécurisation de l'exploitation

Description de la politique permettant de limiter la vraisemblance et la gravité des risques visant les biens supports utilisés en exploitation (documenter les procédures d'exploitation, inventaire et mise à jour des logiciels et matériels, correction des vulnérabilités, duplication des données, limiter l'accès physique au matériel, etc.).

L'architecture redondée propose une conteneurisation des applications formant l'environnement Publik. Ces applications sont présentes sur chacun des deux serveurs.
La base de données est elle aussi redondée, sur deux serveurs.
La charge des requêtes Web est répartie entre les deux nœuds du système redondé, et l'attribution à l'un ou l'autre des deux nœuds se fait en fonction de l'adresse IP du terminal de l'usager.

Cette répartition de charge est à la fois disponibles sur les plateformes de devéloppement, de recettes et de production, et les spécifications matérielles de celles-ci sont adaptées à cette charge : Les principaux logiciels utilisés et maintenus à jour sont :

Un système de monitorage (Nagios) des serveurs permet de prévenir et détecter les différents pannes envisageables (serveur down ou saturation de l'espace mémoire RAM ou de l'un des disques notamment).

La limitation des accès physiques au matériel est assurée par notre hébergeur sous-traitant OVH, conformément à ses mesures prises pour le respect de la réglementation européenne en vigueur (https://www.ovh.com/fr/protection-donnees-personnelles/securite.xml).

La lutte contre les logiciels malveillants

Description des mesures destinées à protéger les accès vers des réseaux publics (Internet) ou non maîtrisés (partenaires), ainsi que les postes de travail et les serveurs contre les codes malveillants qui pourraient affecter la sécurité les données à caractère personnel.

Nos services sont déployés sur des machines constamment maintenues à jour (via les dépôts officiels Debian) et accessibles pour administration seulement en SSH (avec clé seulement, pas d'authentification par mot de passe acceptée), réduisant ainsi les risques d'attaque par force brute (attaquer par force brute un mot de passe d'une dizaine de caractère de longueur est très largement faisable, mais en faire de même pour la partie privée d'une clé RSA de 2048 ou 4096 octets de longueur est en pratique fantaisiste).
Nous utilisons strictement des logiciels libres reconnus pour leur rigueur dans la prise en compte des principes de sécurité, et notamment pour la rapidité de fourniture de correctifs logiciels en cas de faille nouvellement identifiée (Common Vulnerability Exposures ou CVE)

Par ailleurs, notre hébergeur OVH s'engage aussi à nous envoyer une alerte courriel dès lors qu'un de leurs outils de monitorage, installés sur nos serveurs, requiert une mise à jour de sécurité.

La gestion des postes de travail

Description des mesures prises afin de diminuer la possibilité que les caractéristiques des logiciels (systèmes d’exploitation, applications métiers, logiciels bureautiques, paramétrages…) ne soient exploitées pour porter atteinte aux données à caractère personnel (mises à jour, protection physique et des accès, travail sur un espace réseau sauvegardé, contrôleurs d’intégrité, journalisation, etc.).

Les mêmes critères de sécurité sont appliqués sur les postes de travail : machines à jour, exécutant des logiciels libres reconnus pour leur rigueur dans la prise en compte des principes de sécurité.

La protection des sites web

Description des méthodes et moyens mis en place pour diminuer la possibilité que les sites web soient exploitées pour porter atteinte aux données à caractère personnel (référentiel général de sécurité, chiffrement TLS des flux, politique de dépôt de cookies, audits de sécurité, etc.).

Nous utilisons une version de support à long-terme (LTS) de Django.
Les mesures de sécurité prescrites ici sont gérées par ce framework, qui fonctionne dans une version maintenue à jour sur notre SaaS.
Comme décrit plus haut dans ce document, ce framework inclut les mécanismes de sécurité adéquats pour faire face aux tentatives d'attaque usuelles sur le Web (injections SQL, session-hijacking, XSS, CSRF, etc.)

La sauvegarde des données

Description de l’existence d'une politique de sauvegarde permettant d'assurer la disponibilité et/ou l’intégrité des données à caractère personnel, tout en protégeant leur confidentialité (régularité des sauvegardes, chiffrement du canal de transmission des données, test d'intégrité, etc.).

La haute-disponibilité des services Publik est assurée par la redondance de l'architecture publique sur notre plateforme SaaS, laquelle bénéficie d'un système de répartition de charge (HAProxy).
L'ensemble des services composant l'environnement Publik sont donc redondés, permettant la continuité en cas de panne (logicielle ou matérielle) d'un des services.
Outre les sauvegardes quotidiennes décrites plus haut, la conservation des transactions récentes sur la base de données permet le rejeu de ces transactions sur le serveur Postgres, assurant ainsi, en cas d'attaque ou d'incohérence des données, un rétablissement de la base à l'instant voulu.

Notre hébergeur OVH assure aussi l'intégrité et la disponibilité des services par diverses mesures telles que la redondance des liaisons réseau, leur propre système de backup et la mise en place de groupes électrogènes de secours assurant plusieurs dizaines d'heures d'autonomie pour leurs sites hébergeant leurs salles serveurs.

La maintenance

Description de l’existence d'une politique de maintenance physique des équipements, précisant le recours éventuel à la sous- traitance. Elle devra encadrer la maintenance à distance si elle est autorisée, et préciser les méthodes de gestion des matériels défectueux.

Tout ce qui est de l'ordre de la maintenance physique est assuré par notre hébergeur sous-traitant OVH.
OVH assure une maintenance physique "au mieux", pour assurer une disponibilité des services 24/7.

Les mesures générale de sécurité du système

Description des mesures en fonction du type de réseau sur lequel le traitement est mis en œuvre (isolé, privé, ou Internet), Entr'ouvert doit mettre en place des systèmes de protection adéquats (par exemple pare-feu, sondes de détection d'intrusion ou autres dispositifs actifs ou passifs sont chargés d'assurer la sécurité du réseau).

Notre hébergeur OVH dispose d'un mécanisme de détection et prévention des attaques par déni de service distribuées (DDoS).
Sur l'ensemble de notre serveur, toute opération jugée suspecte provoque l'envoi d'un mail d'alerte à l'administrateur du serveur
Une restriction des adresses IP à une ensemble d'adresses connues ou préalablement déclarées est en place pour l'accès en SSH aux machines.

Les mesures de sécurité physique

Description de l’existence d'un contrôle des accès physique aux locaux hébergeant le traitement (zonage, accompagnement des visiteurs, port de badge, portes verrouillées, etc.) et description le cas échéant des moyens d’alerte en cas d’effraction.

Les mesures de sécurité physiques sont prises par notre hébergeur OVH et sont détaillées sur leur documentation en ligne (https://www.ovh.com/fr/protection-donnees-personnelles/securite.xml).

La mise en place d’une traçabilité

Description de l’existence de mesures mises en place pour être capable de détecter les incidents concernant des données à caractère personnel de façon précoce et de disposer d’éléments exploitables pour les étudier ou pour fournir des preuves dans le cadre d’enquêtes (architecture et politique de journalisation, respect des obligations en matière de protection des données à caractère personnel, etc.).

Les erreurs applicatives ("traces") Django provoquent l'envoi d'un rapport d'erreur à l'adresse électronique de l'administrateur technique de l'application.
En interne, un recueil de fiches post-accident ("postmortem") contenant les mesures correctrices prises est maintenu à jour en continu.

Les mesures de sécurisation des matériels

Description de l’existence de mesures prises pour diminuer la possibilité que les caractéristiques des matériels (serveurs, postes fixes, ordinateurs portables, périphériques, relais de communication, supports amovibles, etc.) soient exploitées pour porter atteinte aux données à caractère personnel (inventaire, cloisonnement, redondance matérielle, limiter l'accès, etc.).

La sécurisation du matériel utilisé par les employés fait écho aux mesures prises en termes de cloisonnement et de traçabilité décrites plus haut.
Une clé SSH par poste et par employé est utilisée pour l'accès aux serveurs, permettant une gestion aisée des accès (octroi ou révocation des droits d'accès aux serveurs, notamment).
Par ailleurs, aucune donnée des usagers n'est stockée sur support amovible.

Notre hébergeur OVH s'engage aussi à maintenir une politique de sécurisation des accès physiques, telle que disponible dans leur documentation (cf https://www.ovh.com/fr/protection-donnees-personnelles/securite.xml → 16. Gestion des accès physiques des tiers → Engagements pris par OVH en sa qualité d'hébergeur).

Les mesures proposées visant à éloigner les risques

Description de l’existence de mesures pour éviter que des sources de risques, humaines ou non humaines, auxquelles il est possible de ne pas être confronté, portent atteinte aux données à caractère personnel (produits dangereux, zones géographiques dangereuses, transfert des données en dehors de l'UE, etc.) Les mesures visant à protéger les données confiées visant à les protéger des sources de risque non humaine (Existence de mesures pour réduire ou éviter les risques liés à des sources non humaines (phénomènes climatiques, incendie, dégât des eaux, accidents internes ou externes, animaux, etc.) qui pourraient affecter la sécurité des données à caractère personnel (mesures de prévention, détection, protection, etc.)

Les mesures de sécurité face à des risques physiques sont prises par notre hébergeur sous-traitant OVH.
Des mesures matérielles telles que la redondance des alimentations électriques, des supports mémoires, des systèmes de refroidissement notamment, sont prises par OVH.

Par ailleurs, notre architecture est redondée sur deux machines physiques différentes, permettant de répondre aux risques d'altération de données ou d'indisponibilité des services sur l'une de ces deux machines.
Les sauvegardes se situent quant à elles sur un autre site géographique encore.


Argumentaire sécurité

Remplacé par Argumentaire sécurité

Mesures de sécurité

Entr'ouvert s’engage à mettre en œuvre les mesures de sécurité visant apporter une protection suffisante des données à caractère personnel. Ces mesures devront à la fois porter sur les données à caractère personnelles confiées (a) et sur les mesures générales de sécurité du système (b).

Les mesures de protection sur les données à caractère personnel

Les mesures mises en œuvre par Entr'ouvert doivent être adaptées à la sécurité des données confiées. Entr'ouvert détaillera les mesures de protection des données à caractère personnel mises en œuvre au sein de son organisation, le cas échéant parmi les mesures suivantes :

Le chiffrement des données : moyens mis en œuvre pour assurer la confidentialité des données conservées (en base de données, dans des fichiers plats, dans les sauvegardes, etc.) ainsi que les modalités de gestion des clés de chiffrement (création, conservation, modification en cas de suspections de compromission, etc.).

Nous respectons le principe de base de la protection des données qu'est la proportionnalité des mesures préventives -- l'envergure de ces mesures étant directement liée à la criticité des données à caractère personnel collectées et traitées dans l'environnement Publik.
Notre moteur de base de données est le SGBDR (système de gestion de bases de données relationnelles) PostgreSQL, outil libre, reconnu pour sa robustesse et sa sécurité.
Nos bases de données, comme le reste de l'infrastructure Publik, sont situées sur des machines physiques hébergées par notre sous-traitant OVH, et accessible seulement à l'aide du protocole SSH par clé RSA (pas d'authentification par mot de passe, jugée d'une sécurité trop faible) par les techniciens de l'équipe d'Entr'ouvert.
L'ensemble de clés autorisées est maintenu de façon cohérente.
Par exemple, lorsqu'un technicien quitte l'équipe, sa clé est désactivée.

Nos bases de données sont aussi sauvegardées toutes les nuits et ces sauvegardes sont stockées sur un site tiers.
Des sauvegardes quotidiennes sont conservées une semaine, et des sauvegardes mensuelles quatre mois.
Les sauvegardes sont détruites au delà de ce délai.

Les mêmes critères de conservation sont appliqués à la sauvegarde des fichiers situés sur le système de fichier réseau NFS (Network File System).
Ces sauvegardes nous permettent entre autres de rétablir un état cohérent des bases de données en cas de compromission des données stockées.

Description le cas échéant des moyens de chiffrement employés pour les flux de données (VPN, TLS, etc.) intégrés dans le traitement.

Les communication se font en HTTPS (HTTP sur TLS).
Le certificat HTTPS est soit délivré par la collectivité, soit obtenu via une autorité de certification reconnue (LetsEncrypt, par exemple).

D'un point de vue applicatif, l'interface entre logiciels métiers externes et la fabrique de formulaire contenant les données des utilisateurs se fait à l'aide de requêtes nécessairement signées, réduisant les risques d'usurpation d'identité numérique de l'un de ces logiciels.
Les signatures, de type HMAC (Hashed Message Authentication Code), se basent sur la fonction de hachage SHA-256 (Secure Hash Algorithm, produisant des hachés de 256 bits de longueur), considérée cryptographiquement robuste selon les critères en vigueur de nos jours.

À défaut de procédure de chiffrement, description de l’existence de procédures garantissant que des tiers au contrat ne puissent pas avoir accès aux données confiées.

Outre les procédures de chiffrement décrites plus haut, nous développons nos applications à l'aide du framework Django.
Ce dernier propose des mécanismes de prévention des attaques usuelles sur le Web (notamment la prévention contre injections SQL, les scripts inter-site (Cross site-scripting, XSS), le forgeage de requêtes inter-site (Cross-site request forgery, CSRF)).

Enfin, la partie publique des clés SSH autorisées à accéder aux différents serveurs est centralisée dans notre dépôt utilisé par l'outil de gestion de configuration de serveur Puppet.
Le retrait d'une clé, par exemple lorsque quelqu'un se voit retirer ses accès aux serveurs, se fait de façon directe, et est appliqué à l'ensemble de notre infrastructure.

L’anonymisation des données : description des mécanismes d’anonymisation, des garanties qu'ils apportent contre une ré-identification éventuelle et à quelle fin ils sont mis en œuvre.

L'anonymisation des données des utilisateurs est paramétrable dans Publik.
Les mécanismes d'anonymisation sont les suivants :

D'une façon générale, le RGPD impose au minimum l'anonymisation (quand ce n'est pas la suppression) des données dès lors que leur conservation n'est plus utile au traitement auquel l'usager a consenti.
Avec l'accord de la CNIL, avec qui nous travaillons, nous nous imposons un délai maximal de trois mois pour l'anonymisation des demandes contenant des données personnelles des usagers.
Les formations données par nos chefs de projets aux agents, formations relatives à la construction des démarches Publik, tiennent compte de cette nécessité d'anonymiser les demandes contenant des données à caractère personnel.

Le cloisonnement des données : description des méthodes utilisées pour cloisonner le traitement chez Entr'ouvert.

Le cloisonnement des données dans l'architecture Publik repose principalement sur les propriétés de multitenancy de notre moteur de base de donnée relationnelle PostgreSQL.

Le multitenancy (i.e. "multi-hôte") permet à PostgreSQL d'assurer la séparation des données de plusieurs sites d'une même application.
Dans le cadre d'une installation Publik multi-collectivités, le système de contrôle d'accès basé sur les rôles (Role-Based Access Control, RBAC) permet de s'assurer que les données d'une collectivité restent cloisonnées à cette collectivité et aux rôles qui y sont liés (et donc qu'elles ne puissent pas être lues par un membre d'un autre collectivité de l'instance Publik, ce membre ne possédant pas les rôles adéquats).

Le contrôle des accès logiques : description de la manière dont les profils utilisateurs sont définis et attribués. Il conviendra de détailler les moyens d’authentification mis en œuvre en précisant, le cas échéant précisez les règles applicables aux mots de passe (longueur minimale, structure obligatoire, durée de validité, nombre de tentatives infructueuses avant blocage du compte, etc.).

Le fournisseur et gestionnaire d'identités de Publik, Authentic, reprend et étend les mécanismes de contrôle d'accès de Django.
Ce fournisseur définit un ensemble de rôles techniques, pour sa gestion en interne, et un ensemble de rôles métiers, voués à être approvisionnés dans les autres briques du logiciels Publik.

Authentic assure aussi l'authentification des comptes usagers de Publik.
Il fournit un mécanisme d'authentification modulaire.
Ainsi, l'usager s'identifie par login/mot de passe, ou bien, si Authentic est configuré pour, de recourir à une fournisseur d'identités tiers (lequel proposera alors indépendemment de Publik ses propres moyens d'authentification).

Le choix d'un mot passe pour l'authentification d'un usager doit respecter les contraintes suivantes :
8 caractères au minimum, dont au moins une lettre minuscule, un chiffre et une lettre majuscule.
La politique de complexité des mots de passe est paramétrable.
Il est aussi possible d'activer un temps d'attente exponentiel après chaque tentative d'authentification infructueuse.

Enfin, le support de l'authentification à plusieurs facteurs est en voie de développement dans notre fournisseur d'identités Authentic.

La politique de journalisation : description de la politique de journalisation des événements et de conservation des traces qui en résultent.

Une fonction de journalisation des actions impliquant les logiciels métiers externes est mise en place directement dans la base de connecteurs Passerelle.
Par ailleurs, une application de journalisation pour le fournisseur d'identité est en cours de développement.

La politique d’archivage : description de la politique de conservation et gestion d’archives électroniques contenant des données à caractère personnel destinées à garantir leur valeur, notamment juridique, pendant toute la durée nécessaire (versement, stockage, migration, accessibilité, élimination, politique d'archivage, protection de la confidentialité, etc.).

La conservation des données des systèmes de fichiers réseau inclut l'ensemble des logs Web et applicatifs.
Ces données, bien évidemment à caractère personnel, et à valeur juridique potentielle, bénéficient de la même politique de conservation stricte des sauvegardes des données des serveurs de l'architecture Publik.

La politique de sécurisation des documents papiers : description de la sécurisation de la gestion des documents papiers (de l’impression au stockage jusqu’à la destruction et aux échanges de documents).

Nous ne proposons pas de service impliquant une gestion de documents au format papier.

La politique de minimalisation des données collectées : La sensibilité des données peut être réduite à l'aide des méthodes suivantes : filtrage et retrait, réduction de la sensibilité par transformation, réduction du caractère identifiant des données, réduction de l'accumulation de données, restriction de l’accès aux données.

La réduction de la collecte des données à ce qui est strictement nécessaire pour mener à bien le traitement fait partie de notre activité d'accompagnement à la conception des démarches dans Publik.
Les formation à la conception de ces démarches ont pour objectif majeur la sensibilisation à la nécessite de minimaliser la collecte de données.

Les mesures générales de sécurité du système

Les mesures mises en œuvre par Entr'ouvert doivent être adaptées à la sécurité des données confiées. Entr'ouvert détaillera les mesures générales de sécurité du système mise en œuvre au sein de son organisation, le cas échéant parmi les mesures suivantes :

La sécurisation de l'exploitation : description de la politique permettant de limiter la vraisemblance et la gravité des risques visant les biens supports utilisés en exploitation (documenter les procédures d'exploitation, inventaire et mise à jour des logiciels et matériels, correction des vulnérabilités, duplication des données, limiter l'accès physique au matériel, etc.).

L'architecture redondée propose une conteneurisation des applications formant l'environnement Publik. Ces applications sont présentes sur chacun des deux serveurs.
La base de données est elle aussi redondée, sur deux serveurs.
La charge des requêtes Web est répartie entre les deux nœuds du système redondé, et l'attribution à l'un ou l'autre des deux nœuds se fait en fonction de l'adresse IP du terminal de l'usager.
Cette répartition de charge est à la fois disponibles sur les plateformes de devéloppement, de recettes et de production, et les spécifications matérielles de celles-ci sont adaptées à cette charge : Les principaux logiciels utilisés et maintenus à jour sont :

Un système de monitorage (Nagios) des serveurs permet de prévenir et détecter les différents pannes envisageables (serveur down ou saturation de l'espace mémoire RAM ou de l'un des disques notamment).

La limitation des accès physiques au matériel est assurée par notre hébergeur sous-traitant OVH, conformément à ses mesures prises pour le respect de la réglementation européenne en vigueur (https://www.ovh.com/fr/protection-donnees-personnelles/securite.xml).

La lutte contre les logiciels malveillants : description des mesures destinées à protéger les accès vers des réseaux publics (Internet) ou non maîtrisés (partenaires), ainsi que les postes de travail et les serveurs contre les codes malveillants qui pourraient affecter la sécurité les données à caractère personnel.

Nos services sont déployés sur des machines constamment maintenues à jour (via les dépôts officiels Debian) et accessibles pour administration seulement en SSH (avec clé seulement, pas d'authentification par mot de passe acceptée), réduisant ainsi les risques d'attaque par force brute (attaquer par force brute un mot de passe d'une dizaine de caractère de longueur est très largement faisable, mais en faire de même pour la partie privée d'une clé RSA de 2048 ou 4096 octets de longueur est en pratique fantaisiste).
Nous utilisons strictement des logiciels libres reconnus pour leur rigueur dans la prise en compte des principes de sécurité, et notamment pour la rapidité de fourniture de correctifs logiciels en cas de faille nouvellement identifiée (Common Vulnerability Exposures ou CVE)

Par ailleurs, notre hébergeur OVH s'engage aussi à nous envoyer une alerte courriel dès lors qu'un de leurs outils de monitorage, installés sur nos serveurs, requiert une mise à jour de sécurité.

La gestion des postes de travail : description des mesures prises afin de diminuer la possibilité que les caractéristiques des logiciels (systèmes d’exploitation, applications métiers, logiciels bureautiques, paramétrages…) ne soient exploitées pour porter atteinte aux données à caractère personnel (mises à jour, protection physique et des accès, travail sur un espace réseau sauvegardé, contrôleurs d’intégrité, journalisation, etc.).

Les mêmes critères de sécurité sont appliqués sur les postes de travail : machines à jour, exécutant des logiciels libres reconnus pour leur rigueur dans la prise en compte des principes de sécurité.

La protection des sites web : description des méthodes et moyens mis en place pour diminuer la possibilité que les sites web soient exploitées pour porter atteinte aux données à caractère personnel (référentiel général de sécurité, chiffrement TLS des flux, politique de dépôt de cookies, audits de sécurité, etc.).

Nous utilisons une version de support à long-terme (LTS) de Django.
Les mesures de sécurité prescrites ici sont gérées par ce framework, qui fonctionne dans une version maintenue à jour sur notre SaaS.
Comme décrit plus haut dans ce document, ce framework inclut les mécanismes de sécurité adéquats pour faire face aux tentatives d'attaque usuelles sur le Web (injections SQL, session-hijacking, XSS, CSRF, etc.)

La sauvegarde des données : description de l’existence d'une politique de sauvegarde permettant d'assurer la disponibilité et/ou l’intégrité des données à caractère personnel, tout en protégeant leur confidentialité (régularité des sauvegardes, chiffrement du canal de transmission des données, test d'intégrité, etc.).

La haute-disponibilité des services Publik est assurée par la redondance de l'architecture publique sur notre plateforme SaaS, laquelle bénéficie d'un système de répartition de charge (HAProxy).
L'ensemble des services composant l'environnement Publik sont donc redondés, permettant la continuité en cas de panne (logicielle ou matérielle) d'un des services.
Outre les sauvegardes quotidiennes décrites plus haut, la conservation des transactions récentes sur la base de données permet le rejeu de ces transactions sur le serveur Postgres, assurant ainsi, en cas d'attaque ou d'incohérence des données, un rétablissement de la base à l'instant voulu.

Notre hébergeur OVH assure aussi l'intégrité et la disponibilité des services par diverses mesures telles que la redondance des liaisons réseau, leur propre système de backup et la mise en place de groupes électrogènes de secours assurant plusieurs dizaines d'heures d'autonomie pour leurs sites hébergeant leurs salles serveurs.

La maintenance : description de l’existence d'une politique de maintenance physique des équipements, précisant le recours éventuel à la sous- traitance. Elle devra encadrer la maintenance à distance si elle est autorisée, et préciser les méthodes de gestion des matériels défectueux.

Tout ce qui est de l'ordre de la maintenance physique est assuré par notre hébergeur sous-traitant OVH.
OVH assure une maintenance physique "au mieux", pour assurer une disponibilité des services 24/7.

Les mesures générale de sécurité du système : description des mesures en fonction du type de réseau sur lequel le traitement est mis en œuvre (isolé, privé, ou Internet), Entr'ouvert doit mettre en place des systèmes de protection adéquats (par exemple pare-feu, sondes de détection d'intrusion ou autres dispositifs actifs ou passifs sont chargés d'assurer la sécurité du réseau).

Notre hébergeur OVH dispose d'un mécanisme de détection et prévention des attaques par déni de service distribuées (DDoS).
Sur l'ensemble de notre serveur, toute opération jugée suspecte provoque l'envoi d'un mail d'alerte à l'administrateur du serveur
Une restriction des adresses IP à une ensemble d'adresses connues ou préalablement déclarées est en place pour l'accès en SSH aux machines.

Les mesures de sécurité physique : description de l’existence d'un contrôle des accès physique aux locaux hébergeant le traitement (zonage, accompagnement des visiteurs, port de badge, portes verrouillées, etc.) et description le cas échéant des moyens d’alerte en cas d’effraction.

Les mesures de sécurité physiques sont prises par notre hébergeur OVH et sont détaillées sur leur documentation en ligne (https://www.ovh.com/fr/protection-donnees-personnelles/securite.xml).

La mise en place d’une traçabilité : description de l’existence de mesures mises en place pour être capable de détecter les incidents concernant des données à caractère personnel de façon précoce et de disposer d’éléments exploitables pour les étudier ou pour fournir des preuves dans le cadre d’enquêtes (architecture et politique de journalisation, respect des obligations en matière de protection des données à caractère personnel, etc.).

Les erreurs applicatives ("traces") Django provoquent l'envoi d'un rapport d'erreur à l'adresse électronique de l'administrateur technique de l'application.
En interne, un recueil de fiches post-accident ("postmortem") contenant les mesures correctrices prises est maintenu à jour en continu.

Les mesures de sécurisation des matériels : description de l’existence de mesures prises pour diminuer la possibilité que les caractéristiques des matériels (serveurs, postes fixes, ordinateurs portables, périphériques, relais de communication, supports amovibles, etc.) soient exploitées pour porter atteinte aux données à caractère personnel (inventaire, cloisonnement, redondance matérielle, limiter l'accès, etc.).

La sécurisation du matériel utilisé par les employés fait écho aux mesures prises en termes de cloisonnement et de traçabilité décrites plus haut.
Une clé SSH par poste et par employé est utilisée pour l'accès aux serveurs, permettant une gestion aisée des accès (octroi ou révocation des droits d'accès aux serveurs, notamment).
Par ailleurs, aucune donnée des usagers n'est stockée sur support amovible.

Notre hébergeur OVH s'engage aussi à maintenir une politique de sécurisation des accès physiques, telle que disponible dans leur documentation (cf https://www.ovh.com/fr/protection-donnees-personnelles/securite.xml → 16. Gestion des accès physiques des tiers → Engagements pris par OVH en sa qualité d'hébergeur).

Les mesures proposées visant à éloigner les risques : description de l’existence de mesures pour éviter que des sources de risques, humaines ou non humaines, auxquelles il est possible de ne pas être confronté, portent atteinte aux données à caractère personnel (produits dangereux, zones géographiques dangereuses, transfert des données en dehors de l'UE, etc.) Les mesures visant à protéger les données confiées visant à les protéger des sources de risque non humaine (Existence de mesures pour réduire ou éviter les risques liés à des sources non humaines (phénomènes climatiques, incendie, dégât des eaux, accidents internes ou externes, animaux, etc.) qui pourraient affecter la sécurité des données à caractère personnel (mesures de prévention, détection, protection, etc.)

Les mesures de sécurité face à des risques physiques sont prises par notre hébergeur sous-traitant OVH.
Des mesures matérielles telles que la redondance des alimentations électriques, des supports mémoires, des systèmes de refroidissement notamment, sont prises par OVH.

Par ailleurs, notre architecture redondée est répartie entre deux sites géographiques différents, permettant de répondre aux risques d'altération de données ou d'indisponibilité des services sur l'un des deux sites.
Les sauvegardes se situent quant à elles sur un autre site géographique encore.


Configurer AzureAD comme fournisseur d'identité pour Authentic

Inspiré par le ticket #54831

Nomenclature

<tenant> le nom de domaine de l'authentic, ex.: connexion-client.test.entrouvert.org

Configuration des clés RSAs

Deviendra obsolète quand cette génération sera entièrement faite dans le backoffice d'authentic.

Configuration AzureAD

Documentation Microsoft: https://learn.microsoft.com/fr-fr/azure/active-directory/develop/active-directory-saml-claims-customization

Nous transmettre ensuite l'information "App Federation Metadata URL" qui devrait avoir la forme suivante:

https://login.microsoftonline.com/180627ee-80c9-4bec-95e6-81b5fecd81ff/federationmetadata/2007-06/federationmetadata.xml?appid=9b9854e3-633c-4124-8040-fe07dd445195

Configuration Authentic


Jeudi 9 juillet, discussion avec Thomas, Naïma, Fred, Sergheï sur base d'un message de Thomas appelant à homogénéiser/rationnaliser les pratiques en termes de conception/réalisation de workflows/formulaires comme on on l'a fait (et continue de le faire) pour le code. Il en ressort un certain nombre d'idées un peu en vrac dont je ne sais pas encore ce qu'on va faire (vu qu'il y a d'autres urgences). Mais il faut qu'on dise à Naïma si elle doit tenir compte de ses potentielles évolutions ou pas dans l'écriture de la doc (a priori pas, elle tient compte uniquement de l'existant).

Généralités

Formulaires

Workflows


Candidature Villejuif

Suite réunion du 31/08/2022 avec

Avancement, côté Villejuif :

Accord à confirmer d'ici fin 09/2022
Dates envisagées : 5-6 juin 2023

Logistique

Sur 3 salles durant les 2 jours :

Matériel audio-visuel dans les 3 salles mais pas libre.
Nous pourrions installer notre matériel dans la grande salle le week-end précédant. Et limiter la diffusion à celle-ci. Ou accepter de diffuser les autres salles également.

Restauration


Délai global, Gestion des relances, #10133

Usagers institutionnels, #10460


Champs lecture seule, cachés, etc.

Cas d'usage

https://dev.entrouvert.org/issues/27429#note-4

Les postes et leur descriptifs sont exposés sur le site de la Ville, le bouton "postuler" renvoie vers Publik avec plusieurs variables de session, dont le libellé du poste (mais également d'autres infos comme la date de réponse minimum et le service en charge du recrutement)
On a besoin du nom du poste dans le formulaire.
Le pré-remplissage d'un champ form_var_poste avec la session_var_ permet de disposer du nom du poste dans une variable de formulaire, et est enregistrée tout de suite. Mais pour cela, il faut soit cacher le champ au candidat, soit lui exposer ce champ en l'empêchant de le modifier (read-only)
Sans le pre-remplissage de cette variable, s'il reprend son brouillon, la variable de session est perdue, et le candidat répond à une offre d'emploi sans que l'on sache à quel poste il répond !

Persistence d'une info passée dans la query string.

https://dev.entrouvert.org/issues/27429#note-7

Saisie d'un point sur un champ carte.

Ce point permet de pré-remplir des champs adresse (numéro, voie, code postal ville) et ces champs devraient ne pas être modifiables (en particulier dans les cas ou le point de carto entraine des automatismes dans le circuit de traitement ensuite => découpage par quartier, responsable de traitement différent suivant la zone de déclaration...)

Peut-être à plutôt rapprocher des questions spécifiques à la carto, quand existe un champ carto et un champ adresse, lequel compte ?

Si c'est la carte qui compte, si l'adresse est juste affichée à titre informatif, peut-être une option sur les champs carte "afficher l'adresse sélectionnée" ?

https://dev.entrouvert.org/issues/27429#note-8

Nanterre / tous les projets qui font des formulaires BO liés à un identifiant externe (dossier, fiches, que sais-je)

Pouvoir persister un paramètre passé en session et le référencer pendant le remplissage du formulaire (appels à la variable webservice notamment) et plus tard dans le workflow, permettre d'ouvrir plusieurs fois le même formulaire avec un paramètre différent (les session_var s'écrasent si même paramètre utilisé dans deux onglets avec des valeurs différentes).

Même situation que le premier, persistence d'une info passée dans la query string

https://dev.entrouvert.org/issues/27429#note-9

Une demande "complexe" d'autorisation de manifestation qui doit être faite en 2 temps :

https://dev.entrouvert.org/issues/27429#note-11

un champ avec une valeur dérivée d'un attribut vérifié du profil (profil vérifié par FranceConnect), il est souhaité que ce champs soit en lecture seule

Approches existantes

Classes CSS

Genre hidden ou readonly, ça donne une fausse impression au créateur du formulaire, qui n'imagine alors pas qu'en fait l'usager garde la main sur ces champs.

Champs alimentés par un attribut vérifié

Ça a été fait pour les attributs de profil, "vérifié" pourrait porter davantage d'information que "lecture seule" (l'idée était que dans le backoffice apparaisse une marque à côté de ces champs).

Paramètres de session

Problème de volatilité (cf note-4 et note-8).


Le club des utilisateurs Publik réunit l'ensemble des utilisateurs de la solution, qu'ils soient clients de la société Entr'ouvert, utilisateurs sans prestataire ou clients d'une autre société. Par ailleurs, les intégrateurs-partenaires Publik (https://www.entrouvert.com/fr/qui-sommes-nous/partenaires/) sont automatiquement membres du club.

Le club a été lancé dans les locaux d'Entr'ouvert en 2016 (https://dev.entrouvert.org/projects/publik/wiki/CR_r%C3%A9union_de_lancement), notamment par la mise à disposition d'outils de communication communs. Le club est un espace d'échanges à distance (liste de discussion, espace d'échange Tracim) toute l'année et en présentiel une ou deux fois par an, avec ou sans Entr'ouvert.

Les objectifs, fixés lors de la réunion de lancement du club, sont :

Depuis l'origine, Publik est développé au plus proche des besoins de ses utilisateurs, le club utilisateurs est un outil supplémentaire pour faire émerger ces besoins. Le club est impliqué directement dans l'élaboration de la roadmap, en relation avec Entr'ouvert. Le Club n'est toutefois pas une instance décisionnelle concernant l'avenir de Publik.

Les développements peuvent être réalisés par Entr'ouvert suivant différentes modalités :

Dans ce dernier cas, le co-financement peut prendre la forme d'une répartition du coût total du développement. Aujourd'hui, la répartition se fait sur une base volontaire mais d'autres mode de mutualisation sont envisageables : commandes unitaires d'un même montant (le nombre de contributeurs est alors fixé à l'avance), commandes de développements complets "à tour de rôle"...

Dans le cadre de son objectif de mutualisation des investissements, le Club est également amené à réfléchir à l'articulation de Publik avec les logiciels métiers :

Contexte

Le portail citoyen (ou front-office) est indépendant techniquement du site web, il possède une url propre qui peut être un sous domaine de celui de la collectivité du type https://demarches.laville.fr (le nom sera choisi par la collectivité), exemple de notre portail de démonstration : https://portail-citoyen-publik.entrouvert.com/
Les urls (pages, sous-pages, téléprocédures..) de l'ensemble du portail citoyen peuvent être pointées depuis une page du site web si nécessaire.
L'ensemble du portail citoyen est full-web, il a été pensé pour permettre aux usagers une prise en main rapide et simple. Les interfaces en front-office sont étudiées pour être légères et pour ne recourir au javascript que lorsque cela est nécessaire. Cela nous permet d'assurer une compatibilité avec l'ensemble des navigateurs web, y compris les navigateurs mobiles (smartphone, tablette).

L’intégration graphique de base consiste à personnaliser les feuilles de style du portail citoyen avec les couleurs et le logo de la ville.
Entr’ouvert pourra travailler en totale autonomie sur la base des éléments webs récupérables en ligne sur le site ou pourra exploiter des éléments transmis par la collectivité (cf. infra).

Éléments pour l'intégration de la Charte graphique dans Publik

Ce dont nous aurons besoin pour adapter la charte graphique de votre portail citoyen Publik : Pour la personnalisation graphique d'un portail citoyen Publik, plusieurs sources peuvent être fournies par la collectivité :

Pour plus de détails sur ce qui peut être fourni, voir également ce document : https://public.entrouvert.org/Entrouvert_Guide-integration-graphique_v1-4_fev21.pdf

Ce dont nous n'aurons pas l'utilité :

Liste des points devant être vérifiées sur l'instance de production, avant ouverture effective au public

  1. Réglages système
    1. les modules prévus sont-ils bien en place ?
      1. dont SSO FranceConnect (car peut être en attente d'un retour de la DINSIC)
    2. adresse courriel d'expédition et signature des courriels
  2. vérification des pages éditoriales
    1. le BO (toutes les pages du portail agent) sont elles biens réservées au rôle "agent" ?
    2. liens effectifs dans le header, dans le footer
    3. navigation entre pages tout public et pages seulement si usager connecté
  3. Vérification, ajustement des
    1. rôles
    2. attributions aux comptes
  4. Vérification, ajustement des formulaires
    1. possible d'ajuster les URLs d'accès directs aux formulaires, via "changer le titre"
    2. régler l' "Affichage dans les listings" pour visibilité , ou pas, dans les écrans de traitement
    3. vérifier le réglage "Page de confirmation" et acter de son activation, ou pas
    4. les champs courriels, destinés à l'usager en ligne, sont-ils bien pré-remplis de l'adresse électronique du profil ?
    5. bonne utilisation des types de liste (boutons radio, liste déroulante ou autocomplétion)
  5. Vérification, ajustement des workflows
    1. par défaut, anonymisation à 3 mois, en général, pourrait être ajusté / validé avec DPD
    2. possible d'affiner réglage d'anonymisation en conservant des champs textes (à manier avec précaution)
    3. Vérification de l'expéditeur des courriels et signature
  6. Suppression des contenus correspondant à des tests.
    1. les demandes effectuées jusqu'alors en vue de tests (préférable de démarrer avec des listes vides pour les agents traitants) : soit démarche par démarche via une action globale "Suppression", soit en masse pour toutes les demandes de toutes les démarches (remarque : seul Entr'ouvert peut réaliser cette opération)
    2. les créneaux, dans les agendas, correspondant à des tests : à annuler via une action ad-hoc dans le WF, soit en direct si créneau découplée d'une demande (remarque : seul Entr'ouvert peut réaliser cette opération)

Procédure de mise en production

Déploiement

Authentic

Chrono

Passerelle (services web)

WCS

Bascule des démarches (WF, formulaires) de pré-prod sur prod

Note : si vous utilisez l'export de wcs, ne cochez pas la case "Paramètres"

Combo

Portail Agents

Portail Citoyens : idem

Hobo (menu : système)

Dernières vérifications


Contribuer à Publik

Pour démarrer

Publik est composé de différents modules, par ordre alphabétique :

À côté de ces modules applicatifs, d'autres modules participent à l'ensemble :

Tout cela peut fonctionner en s'appuyant sur ces projets majeurs que sont Python et Django, et bien sûr différents autres modules, ponctuellement utiles, sur des besoins particuliers.

Ce survol rapide des briques étant réalisé, avant de contribuer à l'un ou l'autre module, il est important de noter qu'une des forces de Publik est dans sa capacité d'interactions avec des applications tierces; ainsi, le développement de celles-ci, pour leur ajouter la prise en charge du protocole OpenID Connect pour le SSO, ou leur ajouter des API, contribue également de manière importante à Publik.

Pour explorer plus avant cet aspect:

Cela posé, ce document se concentre sur la contribution aux modules de Publik.

Pour faciliter le développement local de ces modules, le projet "publik-devinst" existe.

Périmètre de contribution

La contribution ne s'arrête pas au code de Publik et des modules satellites. Vous pouvez également contribuer au développement de connecteurs pour les logiciels métier ou à la rédaction de la documentation. La relecture de correctifs existants est également une contribution très utile.

Obtenir de l'aide

Le développement et le support autour de Publik est centralisé via l'outil redmine, https://dev.entrouvert.org, l'inscription est libre, la création d'un compte se fait à l'adresse https://dev.entrouvert.org/account/register et bien sûr jamais l'adresse électronique mentionnée ne sera utilisée à d'autres fins.

Code de conduite

Dans tous les échanges, une bienséance élémentaire est attendue, soyez poli·e, n'insultez personne.

Où démarrer

Publik en local

Le meilleur endroit pour développer Publik est son propre ordinateur ; un projet et une documentation dédiée à l'installation d'un environnement de développpement local existe.

Découvrir Publik

Équipé d'une installation locale et du guide de l'administrateur fonctionnel, découvrir ce que Publik peut déjà faire, c'est important parce que beaucoup de choses existent déjà et que les connaitre permet d'ajouter une idée au meilleur endroit, et que cet ajout cadre au mieux avec son environnement.

Une première contribution

Important, scratch your own itch. (même si la réalité des contextes sera souvent différente, c'est important à rappeler).

S'il s'agit d'une nouvelle fonctionnalité, il est utile de commencer par ouvrir un ticket, pour qu'elle puisse être validée, guidée, etc.

Ensuite,

Modifier le code

Produire un patch

La première ligne du message d'un commit doit être de la forme : petite description du patch (#XXXXX) où XXXX est le numéro de ticket où le développement est suivi (on notera aussi l'absence d'une majuscule sur la première lettre).

Des indications supplémentaires sont possibles dans le message de commit sans formalisme particulier, laisser cependant une ligne vide entre la première ligne formelle et la suite du message.

Attacher un patch à un ticket

(et avant ça trouver/créer le ticket ?)

Attendre

On essaie de regarder rapidement mais pour autant on peut être occupés sur d'autres projets

Échanger

Une fois une contribution proposée vient le temps de la relecture.

Il n'y a pas de règles définissant précisément comment les relectures de code doivent se faire, la seule règle est qu'elles doivent se faire : une modification doit être validée par au moins une personne avant de pouvoir être intégrée.

Les relectures ont deux rôles importants :

Ressources / pour aller plus loin


Cookies

L'intégralité du contenu a été reporté dans la doc : https://doc-publik.entrouvert.com/guide-de-l-administrateur-systeme/architecture/saas-securite-et-rgpd/cookies-et-traceurs/


Mercredi 1er juin 2016, à l'occasion du salon des maires, s'est tenue la réunion fondatrice du Club utilisateurs de la solution de GRU « Publik ».

Participants

En raison du mouvement de grève dans les transports, de nombreuses personnes n'ont pas pu participer. Étaient présents :

Tour de table

Chaque collectivité à brièvement exposé son utilisation de Publik.

Ville de Vincennes (Isabelle Pourret)

Vincennes a mis en place un compte citoyen dès 2011, et de nouveaux services en ligne progressivement.
Le projet utilise la liaison SSO avec d'autres application, ainsi que des web-services avec la solution ClicRDV.

Montpellier Méditerranée Métropole (Philippe Gippet)

Publik a été découvert via Vincennes, l'aspect mutualisation avec les communes de la métropole est central (aujourd'hui 20 communes).
Lors du passage de Communauté d'Agglomération à Métropole, Publik a réussi à répondre au transfert de compétences (voirie, espace public, ...)
Le nouveau défi consiste en la mise en place d'un schéma directeur de mutualisation en relation avec la ville-centre.
La plate-forme e-services sera le point d'entrée : c'est acté.
Il y a des web-services et du SSO avec la médiathèque, le conservatoire, et la régie des eaux mais il faut aller au-delà.

Ville de Villejuif (Loïc Dayot)

Villejuif utilise w.c.s. (brique principale de Publik) de façon autonome, sans recourir aux services d'Entr'ouvert.
Loïc Dayot est DSI de Villejuif aujourd'hui mais il a découvert et utilisé w.c.s. à Pierrefitte/Seine lorsqu'il y travaillait.
Villejuif : contexte d'un syndicat informatique, le SIIM94 (Ivry, Vitry, ...), qui gère 70 % du système d'information (RH, finances, ...).
Villejuif est la ville la plus volontaire concernant la GRC.
Il y a également un projet de GEC, besoin d'un connecteur avec Publik.

Ville de Nancy (Olivier Simon)

Marché Publik notifié en 2016, CoPil et lancement du projet fin mars.
Le projet est porté par la Direction du Numérique, direction à part entière bien que transverse.
GRC et site internet seront le pivot d'une ré-orientation de l'administration municipale.
Contexte : Il y a par ailleurs une Roadmap sur plusieurs années :

En parallèle, il y aura des raccordements extérieur en SSO, comme par exemple celui de l'ENT.

Activités du club utilisateurs

Objectifs

Fédérer et organiser la communauté des utilisateurs autour d'outil, d'événements ou tout simplement de process de partage d'information pour :

Partage d'expériences

Faciliter l'arrivée de nouveaux acteurs autour de Publik

Entr'ouvert n'est pas le pivot du club utilisateurs

Un "bon" Club utilisateurs est un club dans lequel Entr'ouvert est présent mais sans jouer le rôle central. Il y aura deux réunions annuelles, une dans laquelle Entr'ouvert est présent et l'autre qui se déroulera sans elle. Philippe Gippet propose d'organiser la première réunion sans Entr'ouvert. L'ordre du jour de ces réunions sera, comme pour cette première édition, défini par les utilisateurs et Entr'ouvert via la liste de discussions et/ou Bistro.

Favoriser l'émergence de prestataires Publik

Il faut encourager les contributions aux outils de Publik au delà de la seule équipe d'Entrouvert pour accroître l'effet vertueux d'une communauté de contributeurs élargie.

Le club cherchera à faciliter l'arrivée de nouveaux prestataires susceptibles de fournir du service autour de Publik. Entr'ouvert a parfois eu du mal dans ses discussions avec des "intégrateurs", acteurs de grande taille, peu compatibles avec les aspirations et les méthodes d'Entr'ouvert. Afin d'assurer une qualité et une transparence optimales concernant les services rendus autour de Publik, Entr'ouvert envisage de mettre en place un "label qualité" pour les sociétés qui souhaiteront prester autour de Publik. Le Club utilisateurs pourra participer à l'élaboration / évolution de ce label s'il le souhaite.

Sensibiliser les éditeurs d'application métier

Le Club se propose de mettre en lumière les avantages liés à l'utilisation de produits libres en général, mais concernant Publik en particulier, pour peser dans le dialogue avec les éditeurs d'application métiers (dans le sens de l'ouverture). Dans cet ordre d'idée, il est nécessaire d'afficher plus clairement les éditeurs qui jouent le jeu de l'ouverture et de l'inter-opérabilité et de détailler les web-services existants. Ce message doit être porté par les utilisateurs plutôt que par Entr'ouvert => nécessité tout de même d'une page en ligne affichée par Entr'ouvert, complétée des informations des divers utilisateurs.

Instaurer un dialogue avec les interlocuteurs nationaux.

Parler d'une seule voix avec des interlocuteurs nationaux comme le SGMAP, la DILA ou la DINSIC. Entr'ouvert a répondu à de nombreuses sollicitations (DILA, SGMAP, DGME, DISIC, DINSIC...) par le passé mais n'arrive pas réellement à se faire entendre pour autant. La parole de collectivités sera peut-être reçue différemment de celle d'une société éditrice de logiciel (même s'il s'agit d'une scop de développement autour d'outils libres :-) ).
Actuellement personne n'a de réel point d'entrée ou de réel feed-back mais on peut espérer que cela change quand nous atteindrons une certaine « masse critique ».

L'orientation des évolutions

La mutualisation des investissements de développements

On sait que c'est difficile, mais plus facile si :

Pour pouvoir mutualiser à l'avenir il faut aussi mieux connaître l'existant dans chaque collectivité. Et pour ça il faut échanger lors d'évènements présentiels.


Cycle de mises à jour

Les mises à jour ont lieu les deuxième et quatrième jeudi du mois, en fin de soirée (~ 23h)

J jeudi mise en production de la version N
J+1 vendredi annonce/discussion interne concernant la version N+1
J+4 du lundi au jeudi envoi dans les dépôts des commits, mises à jour régulières des machines de recette
J+7 jeudi soir gel des "pushs", tout ce qui devra arriver en production est disponible en recette
J+8 vendredi écriture et relectures des notes de mise à jour, annonce publique des évolutions de la version N+1 (*)
J+11 du lundi au jeudi midi semaine de recette, tests des nouveautés et vérifications de non-régression
J+14 jeudi mise en production de la version N+1, entre 22h et 24h

Il peut y avoir des mois à cinq semaines, dans ces situations on s'ajoute une semaine de développement : J+8 devient J+15, J+11 devient J+18, J+14 devient J+21.

(*) les annonces publiques des évolutions sont accessibles sur cette page : https://doc-publik.entrouvert.com/notes-de-mises-a-jour/

Développements : code de bonne conduite - respect du cycle de mis à jour

Les mises à jour de la production se font les deuxième et quatrième jeudi.

Sur les jours qui précèdent : les lundi et mardi et mercredi et journée du jeudi de mise en production servent à la recette, à tester une dernière fois en environnement le plus près du réel les changements prévus. Bien sûr des corrections qui ne concernent pas spécifiquement les nouveautés peuvent également être intégrées, jusqu'au dernier moment.

Mais pas besoin d'attendre ces jours-là pour avoir du travail déployé sur les recettes, le plus tôt est le mieux, d'une part le vendredi c'est déjà vraiment important pour pouvoir finaliser les notes de mise à jour. D'autre part même plus tôt c'est utile car ça permet de profiter de l'utilisation "de terrain" des CPF et clients.

À rappeler aussi qu'on développe et que cela signifie également déjà avoir testé dans un environnement Publik local. Puis avoir fait relire et tester et valider par les collègues ; ces derniers jours de recettes, c'est le gel qu'on cherche, pas la succession de hot fixes.

Cela concerne tous les modules et bien sûr il peut y avoir des exceptions et la portée d'un changement est prise en compte à ce moment-là.

Ces exceptions doivent le rester car les marges sont limitées en temps de gel et peuvent empêcher un travail de qualité.

Procédures internes

J+1 : Annonce/discussion interne concernant la version N+1

En allant sur les différentes pages des tickets des projets, filtrés pour afficher les tickets à relire ou déjà validés (il y a un rapport personnalisé "tickets possibles pour le prochain cycle"), https://dev.entrouvert.org/projects/prod-eo/issues?query_id=374, voire étendu pour inclure également les tickets "en cours", il s'agit de compiler une liste de ce qui pourrait de manière crédible arriver d'ici la prochaine mise en production et d'en faire une version intelligible envoyée par email en interne, par exemple :

Subject: Publik du 10 novembre

[...]

Bien visible, l'introduction d'une vue "hebdomadaire" dans les agendas,
  https://dev.entrouvert.org/issues/33404

C'est déjà utilisé pour Publik Famille, et à Nîmes et Quimper, ça
serait activé partout, la possibilité de conditions d'affichage sur
les cellules,
  https://dev.entrouvert.org/issues/70605

[...]

J+8 : Écriture et relectures des notes de mise à jour

Sur base de ce qui est réellement déployé en recette le vendredi matin, qui est repris sur la page https://scrutiny.entrouvert.org/projects/saas2/history, rédaction d'une nouvelle entrée dans les notes de mise à jour (https://doc-publik.entrouvert.com/manage/pages/31/), il s'agit ici de faire une version intelligible par tout le monde des changements, cela a un impact sur la rédaction et peut signifier ajouter des captures d'écran, éliminer des modifications de détails, ou trop techniques.

Par exemple, ticket #33404, titre "Vue hebdomadaire sur l'agenda", devient une entrée disant

Ajout d’une vue hebdomadaire sur les agendas, permettant de voir plusieurs jours tout en affichant davantage d’informations sur les rendez-vous que sur la vue mensuelle.
+ capture du sélecteur de vue

Note : cela devrait avoir eu lieu avant et indépendamment mais il est utile de vérifier qu'il n'y ait pas de commits déjà présents dans les dépôts mais pas encore taggués/déployés, le rapport https://git.entrouvert.org/lag.html permet de voir ça.


Datawarehouse

Le but est de concentrer et rationaliser (simplification des schémas) sur une machine unique, l'expérience est mené sur la vm "bi" de mesclun.

Tout ce qui concerne cubes a été supprimé car obsolète, la démarche adoptée maintenant est l'utilisation d'un outil ETL maison par brique, pour w.c.s. il se nomme wcs-olap et d'une brique de reporting/visualisation nommée bijoe.

La brique bijoe se configure toute seul grâce à des fichiers JSON en .model qui l'informe des schémas des cubes ROLAP (Relational OLAP) constitués. wcs-olap produit à la fois la base (dans un schéma séparé) et le fichier modèle.

wcs-olap

Exemple de fichier wcs-olap.init:

[wcs-olap]                                                                                                                                                                      
cubes_model_dirs = ./

[http://cam.local:3001/]
orig = connexion.montpellier3m.fr 
key = <SNIPPED>
pg_dsn = dbname=wcs-olap-cam
schema = cam

[http://wcs.soft:3001/]
orig = orig
key = x
pg_dsn = dbname=wcs-olap
schema = wcs_local

# slugs = recette-technique-ajout-d-un-enfant # pour ne synchroniser que certains formulaires

[loggers]
keys=root

[formatters]
keys=console

[formatter_console]
format=%(asctime)s %(levelname)s %(message)s

[handlers]
keys=console

[handler_console]
class=StreamHandler
level=NOTSET
args=(sys.stderr,)
formatter=console

[logger_root]
level=DEBUG
handlers=console

À lancer ainsi pour synchroniser toutes les cibles

wcs-olap --all wcs-olap.ini


Souhaité par Alfortville particulièrement pour la logique SVA (Silence Vaut Accord ou Silence Vaut Acceptation) sur les courriers

SVA :
Cas de figure, exemple :

Démarche existante pour Alfortville :
https://demarches2016.alfortville.fr/backoffice/forms/5/
https://demarches2016.alfortville.fr/backoffice/workflows/5/

"Le délai au terme duquel le silence peut valoir acceptation commence à partir de la date de réception de la demande par l'administration compétente."

Des actions globales au choix de la collectivité (alerte courriel, augmentation criticité, ...) passé un délai au choix de la collectivité

3 mois = 90 jours calendaires (ok discussion avec Alfortville le 04/04 : pas de doute sur le fait que 1 mois = 30 jours calendaires)

La notion essentielle : "combien de jours écoulés depuis la réception de cette demande" plus que "combien de jours reste t'il avant échéance SVA".
Ainsi si date d'expiration SVA doit être calculée, suivant indications vues avec Alfortville le 04/04 : date enregistrement du formulaire ou "date de la poste" (canal courrier) + 60 jours calendaires, c'est OK

Au final :
- disposer de dates de départ fiables (pour les quelques cas litigieux)
- la date d'échéance n'est à priori pas indispensable (mais à éprouver avec des collectivités clientes)

Fonctionnement imaginée :

Choix du nom de domaine pour la plate-forme de production

Vous devez, aussi rapidement que possible, choisir un nom de domaine pour votre instance en production. Ce sera presque toujours (mais ce n'est pas obligatoire), un sous-domaine de votre domaine principal et vous avez toute latitude dans le choix de ce sous-domaine. Si la commune de Trifouilly choisit par exemple "demarches" comme sous-domaine, Publik sera joignable sur demarches.trifouilly.fr

Pour que cela fonctionne, vous devez déléguer la gestion du sous-domaine en question à Entr'ouvert au niveau de la configuration de votre DNS.

Voir : https://doc-publik.entrouvert.com/guide-de-l-administrateur-systeme/architecture/resolution-de-noms/


Reporté ici :https://dev.entrouvert.org/projects/interne/wiki/Les_d%C3%A9partements

Recensement effectué en septembre 2019

Département des Alpes-Maritimes

cf. https://mesdemarches06.fr/ et https://mesdemarches06.fr/les-demarches/

Département des Bouches-du-Rhône

https://moncompte.departement13.fr/

Département du Calvados

https://portail.teleservices.calvados.fr/

Allocation personnalisée d'autonomie (APA)

Subventions

Département de la Somme

https://teleservices.somme.fr/

Département de Seine-et-Marne

https://e-service.seine-et-marne.fr/

Département de la Haute-Garonne

https://services.haute-garonne.fr/

Citoyen

Acteur local

Département de la Lozère

https://demarches.lozere.fr/


Déploiement d'une instance en recette

Initier le déploiement

Sur hobo.test.entrouvert.org, créer la recette de déploiement :

{
  "variables": {
    "commune": "XXX" 
  },
  "steps": [
    {"create-hobo": {
      "url": "https://hobo-${commune}.test.entrouvert.org/" 
    }},
    {"create-authentic": {
      "url": "https://connexion-${commune}.test.entrouvert.org/",
      "title": "Connexion" 
    }}, 
    {"set-idp": {
    }},
    {"create-combo": {
      "url": "https://portail-${commune}.test.entrouvert.org/",
      "title": "Portail",
      "template_name": "portal-user" 
    }},
    {"create-combo": {
      "url": "https://agents-${commune}.test.entrouvert.org/",
      "slug": "portal-agent",
      "title": "Portail Agent",
      "template_name": "portal-agent" 
    }},
    {"create-chrono": {
      "url": "https://agendas-${commune}.test.entrouvert.org/",
      "title": "Agendas" 
    }},
    {"create-wcs": {
      "url": "https://demarches-${commune}.test.entrouvert.org/",
      "slug": "eservices",
      "title": "Démarches",
      "template_name": "publik.zip" 
    }},
    {"create-passerelle": {
      "url": "https://passerelle-${commune}.test.entrouvert.org/",
      "title": "Passerelle" 
    }},
    {"create-bijoe": {
      "url": "https://statistiques-${commune}.test.entrouvert.org/",
      "title": "Statistiques" 
    }},
    {"create-fargo": {
      "url": "https://portedoc-${commune}.test.entrouvert.org/",
      "title": "Porte-documents" 
    }},
    {"set-theme": {
      "theme": "clapotis-les-canards" 
    }},
    {"set-variable": {
      "name": "environment_label",
      "value": "[RECETTE]",
      "label": "Bannière" 
    }},
    {"set-variable": {
      "name": "robots_txt",
      "value": "User-agent: *\nDisallow: /",
      "label": "Contenu de robots.txt" 
    }},
    {"set-variable": {
      "name": "meta_robots",
      "value": "noindex, nofollow, noarchive, nosnippet, notranslate, noimageindex",
      "label": "Contenu de meta name=robots" 
    }}
  ]
}

(Un ensemble de paramètres, spécifiés dans des fichiers de configuration peut-être défini lors de la création d'une instance w.c.s.
Une archive zip contenant ses fichiers de configuration doit être placée dans le répértoire /var/lib/wcs/skeletons. Par exemple /var/lib/wcs/skeletons/publik.zip)

Ensuire exécuter :

sudo -u hobo /usr/bin/hobo-manage cook recipe.json --timeout=240

Personnalisation de l'instance

Se connecter au portail, https://XXX.test.entrouvert.org/manage/,

Deploiement Publik multi-collectivités

Déployer le Publik de base (agglomération)

Rien de spécifique à cet instant : déployer un Publik classique.

Déployer le Publik d'une collectivité (ex: commune)

Préparer le recipe des services à deployer pour la commune, la particularité étant qu'il référence d'abord le Hobo du Publik primaire, ensuite qu'il n'y a pas création d'un fournisseur d'identité dédié, celui de l'agglomération étant utilisé.

Le fournisseur d'identité à utiliser existe déjà, seule l'instruction set-idp est nécessaire.

Exemple pour commune1 :

{
  "variables": {
    "commune": "grosboule-les-bains",
    "title": "Grosboule-les-Bains" 
  },
  "steps": [
    {"create-hobo": { "# Ici l'hobo de l'agglo" 
      "url": "https://hobo.example.com/" 
    }},
    {"create-hobo": { "# Et ici l'hobo de la commune" 
      "url": "https://hobo-${commune}.example.org/",
      "title": "${title}",
      "slug": "hobo-${commune}" 
    }},
    {"set-idp": {
    }},
    {"create-combo": {
      "url": "https://portail-${commune}.example.org/",
      "title": "Portail",
      "template_name": "portal-user" 
    }},
    {"create-combo": {
      "url": "https://agents-${commune}.example.org/",
      "slug": "portal-agent",
      "title": "Portail Agent",
      "template_name": "portal-agent" 
    }},
    {"create-passerelle": {
      "url": "https://passerelle-${commune}.example.org/",
      "title": "Passerelle" 
    }},
    {"create-chrono": {
      "url": "https://agendas-${commune}.example.org/",
      "title": "Agendas" 
    }},
    {"create-bijoe": {
      "url": "https://statistiques-${commune}.example.org/",
      "title": "Statistiques" 
    }},
    {"create-wcs": {
      "url": "https://${commune}.example.org/",
      "title": "Démarches",
      "template_name": "publik.zip" 
    }},
    {"set-theme": {
      "theme": "grosboule-les-bains" 
    }}
  ]
}

Lancement du cook

$ sudo -u hobo hobo-manage cook recipe-commune1.json


Dépréciations et aide pour migrer

Le rapport de dépréciations concerne w.c.s, la brique des démarches (cf https://doc-publik.entrouvert.com/admin-fonctionnel/elements-deprecies/ pour voir toutes les dépréciations). Il est accessible à partir du back-office Studio > Rapport sur les dépréciations ou directement avec l'url https://url-de-wcs.portail.fr/backoffice/studio/deprecations/.

Il existe 8 types de dépréciations :

Le bouton "Scanner à nouveau" permet de forcer la génération du rapport, si des corrections ont été effectuées par exemple.

Types de champ dépréciés

Les types de champs dépréciés sont :

La plupart du temps, ils peuvent être remplacés par des blocs de champs.

Textes EZT

Cette dépréciation est probablement la plus simple à traiter.

Il y a fort fort longtemps, les variables devaient être mises entre crochets pour être interprétées.

Par exemple :

[agendas_url]api/booking/[reservation_response_booking_id]/cancel/

Il suffit de remplacer les crochets par des doubles accolades :

{{ agendas_url }}api/booking/{{reservation_response_booking_id }}/cancel/

Il est possible de trouver des textes comme :

[if-any user] ... [else ] ... [endif]
[if-any details] ... [endif]

À remplacer par :
{% if form_user %} ... {% else %} ... {% endif %}
{% if form_details %} ... {% endif %}

Mais aussi :

Texte EZT Gabarit Django
[url] {{ form_url }}
[number] {{ form_number }}
[before] {{ form_previous_status }}
[after] {{ form_status }}

Attention, certaines expressions utilisent des crochets mais il ne s'agit pas de texte EZT ! Par exemple :

form_var_telephone[:2] in ("06", "07")

Ici il s'agit d'une expression Python, à traiter comme indiqué dans la section concernée.

Conditions Python

Transformation/manipulation de valeurs

Les transformations de textes ou de valeurs passent désormais par les filtres Django. Les filtres permettent des opérations plus complexes, comme ajouter des jours ou des années ou encore faire du calcul d'âge. Profitez de repasser sur vos conditions pour les simplifier.

form_var_commune.lower() ==  "Paris" 
devient en Django :
form_var_commune|lower == "Paris" 
int(form_var_besoin_capacite) > 1
==>
form_var_besoin_capacite|decimal > 1
date(form_var_fin_saison) >= date(form_var_date_reprise)
==> 
form_var_fin_saison|date >= form_var_date_reprise|date
utils.age_in_days(form_var_date_debut_travaux) < -9
==>
form_var_date_debut_travaux|age_in_days < -9
(((datetime.datetime.today()-datetime.datetime.strptime(form_var_dn,"%d/%m/%Y")).days/365.25636567)<60)
==>
form_var_dn|age_in_years < 60
int(form_var_nb_organisateurs) + int(form_var_nb_public) <= int(form_var_capacite)
==> 
form_var_nb_organisateurs|add:form_var_nb_public|decimal <= form_var_capacite|decimal
form_var_telephone[:2] in ("06", "07")
==> 
form_var_telephone|startswith:"06" or form_var_telephone|startswith:"07" 
form_var_demandeur not in ["Autre","Son ex-époux ou son ex-épouse"] or (form_var_demandeur in ["Autre","Son ex-époux ou son ex-épouse"] and form_var_type_acte == "Un extrait d'acte sans filiation")
==> 
"Autre" not in form_var_demandeur or "Son ex-époux ou son ex-épouse" not in form_var_demandeur or "Autre" in form_var_demandeur and form_var_type_acte == "Un extrait d'acte sans filiation" or "Son ex-époux ou son ex-épouse" in form_var_demandeur and form_var_type_acte == "Un extrait d'acte sans filiation" 
inscription_response_in_waiting_list and inscription_response_in_waiting_list == True
==> 
form_workflow_data_inscription_response_in_waiting_list

Récupération de valeurs d'un webservice

Par exemple :

webservice.mon_webservice['places']['available'] > 0

Il faut vérifier le format de retour du webservice, les données peuvent être accessibles dans data ou autre :

webservice.mon_webservice.places.available|decimal > 0
webservice.mon_webservice.data.places.available|decimal > 0

La gestion des parenthèses

Les parenthèses ne sont pas prises en charge en Django. Pour remplacer une condition qui utilise des parenthèses, il faut tenir compte des priorités. "and" est prioritaire sur "or". Dans une condition de type :

form_var_foo == "Oui" or (form_var_bar == "Oui" and form_var_truc == "Oui")

Les parenthèses peuvent être enlevées sans problème, car form_var_bar "Oui" and form_var_truc "Oui" sera évalué en premier :

form_var_foo == "Oui" or form_var_bar == "Oui" and form_var_truc == "Oui" 

En revanche, pour :

(form_var_foo == "Oui" or form_var_bar == "Oui") and form_var_truc == "Oui" 

Il faut revoir la condition en :

form_var_foo == "Oui" and form_var_truc == "Oui" or form_var_bar == "Oui" and form_var_truc == "Oui" 

Sources de données Python

Les sources de données python peuvent être remplacées par des sources de données fiches ou par une liste simple. Si vous avez besoin de valeurs fixes indépendantes des libellés, passez par des fiches.

Exemples courants de sources de données python :

[{'id': 'MALE', 'text': 'Masculin'}, {'id': 'FEMALE', 'text': 'Féminin'}]
[{"id":"DEMI_PENSIONNAIRE", "text":"demi-pensionnaire"},{"id":"INTERNE", "text":"interne"},{"id":"EXTERNE", "text":"externe"},{"id":"RPI", "text":"RPI"}]

[{"id": "cni", "text": "carte d'identité"}, {"id": "passeport", "text": "passeport"}, {"id": "cni_passeport", "text": "carte d'identité et passeport"}]
[{"id": "1pers", "text": "une personne", "duree": "30 minutes"}, {"id": "2pers", "text": "deux personnes", "duree": "1 heure"}, {"id": "3pers", "text": "trois personnes", "duree": "1 heure 30"}]

Expressions Python et préremplissages Python

qualification_manuelle_var_quartier_manuel if form_var_avancement == "qualification manuelle du secteur" else form_var_secteur
==>
{% if form_var_avancement == "qualification manuelle du secteur" %}{{ qualification_manuelle_var_quartier_manuel_raw }}{% else %}{{ form_var_secteur_raw }}{% endif %}
"Je souhaite payer au guichet" if form_var_essai == "Oui" else "" 
==>
{% if form_var_essai == "Je souhaite payer au guichet" %}Oui{% endif %}
"Oui" if form_var_envoi_usager == "Oui" else "Non" 
==>
{% if form_var_envoi_usager == "Oui" %}Oui{% else %}Non{% endif %}
vars().get('reponse_var_salle_raw') or form_var_salle_raw
==>
{% firstof form_workflow_data_reponse_var_salle_raw form_var_salle_raw "" %}
str(Decimal(form_option_tarif) * Decimal(form_var_nb_places))
==>
form_option_tarif|multiply:form_var_nb_places

(La chaîne étant le format par défaut dans Publik, il n'est pas nécessaire de forcer son type).

utils.make_date(form_var_enfant_birthdate).strftime('%d/%m/%Y')
==>
form_var_enfant_birthdate|date:"d/m/Y" 
form_var_commune.lower()
==>
form_var_commune|lower
vars().get('form_var_avis', "En attente")
==>
{{ form_var_avis|default:"En attente" }}
date(today) + days(10)
==>
{{ today|add_days:10 }}
int(form_var_nombre_redirections)+1
==>
{{ form_var_nombre_redirections|add:1 }}
rdv_var_heure + "H" + rdv_var_minute
==>
{{ rdv_var_heure }}H{{ rdv_var_minute }}
form_var_cp_ville.split(' - ',1)[0]
==>
form_var_cp_ville|split:' - '|first

Attention, split est une fonction un peu complexe de python. L'exemple ci-dessus ne s'appliquera pas à toute expression l'utilisant.

form_var_event_datetime[:4]
form_var_event_datetime[5:7]
==>
form_var_event_datetime|date:"Y" 
form_var_event_datetime|date:"m" 
form_var_nom+" "+form_var_prenom
==>
{{ form_var_nom }} {{ form_var_prenom }}

Pré-remplissage d'un champ liste à choix multiples

['Banane', 'Poire']

est identique en Django.

Pré-remplissage d'un champ "case à cocher choix unique"

True

est identique en Django.

Les fichiers joints

L'ancienne forme était :

form_attachments.fichier_usager

Ou
getattr(vars().get('form_attachments'), 'fichier_usager', None)

Il faut désormais utiliser la syntaxe :

form_var_fichier_usager_raw

Modèles de document RTF

Dans les actions de workflow "Créer un document", il était possible de mettre un rtf. Il faut désormais utiliser le format odt.

Source de données JSONP

À remplacer par une source de données JSON, mais cela nécessite de bien comprendre le fonctionnement de la source de données utilisée pour récupérer un élément précis ("id") et permettre d'effectuer une recherche ("q").


Agents utilisateurs, base (0,5 jour)

Agents utilisateurs, suivant installations (0,5 jour)

Administrateurs fonctionnels, base (1 jour)

Administrateurs fonctionnels, suite (1 jour, après prise en main)

Administrateurs techniques si hébergement internalisé (durée spécifique à définir)

Déroulement atelier d'installation (1 jour, sur place) Atelier webservices (1 jour ?)

Design

https://styleguide.entrouvert.com/


1er semestre 2016

Gestion de pool de demandes, cela permettra la gestion des demandes par de grandes équipes d'agents traitant les mêmes formulaires, en empêchant des traitements concurrents.
- Statut : réalisé (mi-mars).
- Couverture : 100 % de financement acquis (100 % auto-financés par Entr'ouvert)

Ajout de la notion de criticité dans les workflows, cf. #10134.
- Statut : réalisé (disponible à la demande en béta).
- Couverture : 100 % de financement acquis dans le cadre d'un POC

Ajout d'une fonctionnalité de redirection des demandes (possibilité d'initier une saisie en back-office depuis une demande existante), cf. #9299.
- Statut : Développement en cours.
- Couverture : 100 % de financement acquis dans le cadre d'un POC

Ajout d' actions globales dans les workflows (inclus la notion de délais globaux), cf. #10133
- Statut : Réalisation en cours, à affiner avec cas d'usages.
- Couverture : 50 % de financement acquis (marché Alfortville en cours)
- Échéance envisagée : avril

Nouvelle ergonomie et conception graphique du Front-Office (ergonomie, navigation, charte graphique), mise à disposition des utilisateurs le désirant.
- Statut : Réalisation en cours.
- Couverture : 100 % de financement acquis (100 % auto-financés par Entr'ouvert)
- Échéance envisagée : avril

Évolution du module de Gestion de l'Identité intégré à Publik (aka Authentic) pour prendre en charge l' authentification via des fournisseurs d'identité externes : FranceConnect, CAS, SAML, BeID, session Windows (Kerberos).
- Statut : Réalisation en cours.
- Couverture : 100 % de financement acquis
- Échéance envisagée : mai

Reprise de notre module de paiement en ligne pour une plus grande souplesse d'affichage des factures émanant d'applications tierces.
- Statut : spécification en cours
- Couverture : 100 % de financement acquis (100 % auto-financés par Entr'ouvert)
- Échéance envisagée : mai
https://dev.entrouvert.org/projects/lingo

Géolocalisation des demandes, cf #10581
- Statut : développement en cours.
- Couverture : 100 % de financement acquis (marché Alfortville en cours)
- Échéance envisagée : mai

2ème semestre 2016

Évolution du porte-documents actuel pour en faire également un espace de méta-données certifiées. cf #10444
- Couverture : 100 % de financement acquis (marché Alfortville en cours)
- Échéance envisagée : juin (en attente de plus d'informations sur FranceConnect en tant que fournisseur de données pour finalisation)

Achèvement de la mue de Publik en une solution totalement multi-canal i.e. web, guichet physique, centre d'appels, courriers, courriels.
- Statut : Développé, améliorations en cours ; création du canal de prise en charge des courriels.
- Couverture : 100 % de financement acquis (marché Alfortville en cours)
- Échéance envisagée : août (cas d'usage Alfortville, canal courriel à finaliser si nécessaire)

Nota Bene, liste des mises à jour

Depuis le 15 juin 2016, les modules Publik sont mis à jour 2 fois par mois, tous les développements sont récapitulés dans nos notes de mise à jour


Documentation sur la remontée d'informations vers le portail

~~

Première considération : identifier l'usager concerné.

Un attribut partagé existant désormais entre le portail et l'application métier, on peut avoir un webservice qui sur cette info crée un nouvel attribut, une clé de fédération, qui permettra au reste de changer sans que ça n'ait d'incidence sur la liaison.

(par la suite j'utilise "clé de fédération", ça peut être cette clé dédiée mais ça peut aussi être l'attribut commun préexistant)

~~

Noter une préférence au stateless; c'est-à-dire surtout qu'on préfère passer le paramètre "clé de fédération" à chaque requête plutôt qu'avoir un premier appel établissant une session.

(ou ne pas noter de préférence et dire que les deux sont possibles ?)

~~

Peut-être à ce moment-ci amener des considérations de format.

~~

Considérations de sécurité

~~

À propos d'oauth : on pourrait imaginer quelque chose qui marche très bien mais ça me semble demander plus de boulot du côté de l'application métier, écran de validation de partage d'attribut ("acceptez-vous de fournir la liste des livres en attente à l'application 'GRU' ?") et cie. (ça demande sans doute trop aux applis métiers, passons).

~~

Par série d'application, détailler les webservices attendus.


Ebauche roadmap 2023

Cette page vise à fournir des indications tarifaires hors taxes concernant les différentes évolutions abordées pendant le club. Cela devrait permettre aux membres de budgeter approximativement leur participation à telle ou telle amélioration. Pour pouvoir donner des chiffres rapidement, nous recourrons fréquemment à des fourchettes, parfois importantes quand il s'agit de choses qui peuvent beaucoup varier quand nous commencerons à en discuter en détail pour les confronter à vos cas d'usages.

Évoqué lors de la première journée du club

Évoqué par Entr'ouvert

Chrono

Applications

NB : Une idée de Cédric Lambert que nous trouvons très intéressante : permettre aux collectivités de récupérer tout ou partie de leur investissement dans le développement d'une application en payant moins cher la maintenance de l'application en question. Nous allons proposer un modèle.
Cela aurait le mérite de diminuer des dépenses de fonctionnement au profit de l'investissement et de valoriser les membres qui font des financements qui profitent à toute la communauté.

Autres


Échanges avec un logiciel de gestion de demandes «métier»

Un cas habituel de logiciel tiers est celui qui traite des demandes «métier», par exemple des signalements de problèmes sur la voiries ou des demandes d'intervention concernant la gestion des eaux.

Un tel logiciel être connecté avec Publik afin que :

Pour mettre en place cette connexion, le logiciel doit exposer un certains nombres de webservices à disposition de Publik. Cette documentation les décrit.

Principes des échanges

Publik créé la demande dans le logiciel tiers : les données de la demande et les documents liés si nécessaire.

Publik interroge ensuite le logiciel pour connaître le statut de la demande. Ce statut est éventuellement accompagné d'informations complémentaires.

Selon les informations reçues, Publik informe l'usager de l'avancement de sa demande, par courriel, SMS, message à l'écran ou tout autre moyen.

Publik répète cette interrogation toutes les 6 ou 12h, jusqu'à ce que la demande atteigne un statut «final». Les échanges la concernant s'arrêtent alors.

Création d'une demande dans le logiciel tiers

Une fois la demande saisie par l'usager, Publik l'envoie dans le logiciel métier. Pour cela, un appel HTTP POST est fait vers une URL proposée par le logiciel, dans notre exemple https://logiciel.tiers/api/creation-nouvelle-demande, mais tout autre format d'URL est possible.

Cet appel POST envoie un dictionnaire JSON, à plat, contenant une suite de clés-valeurs :

POST https://logiciel.tiers/api/creation-nouvelle-demande
Content-Type: application/json
Accept: application/json

{
  "info1": "valeur1",
  "info2": "valeur2",
  "info3": "valeur3",
  "info4": "valeur4",
  ...
}

Noter que le formulaire n'est pas envoyé tel quel, tel que saisi par l'usager : certains champs peuvent être modifiés, adaptés, transformés ou normalisés. Par exemple, si l'usager a choisi la ville "Grenoble" dans la liste, c'est son code INSEE qui peut être envoyé dans le logiciel (cf plus bas la gestion des référentiels). C'est donc au logiciel tiers de décrire l'ensemble des données dont il a besoin pour créer une demande : le formulaire Publik sera adapté pour les obtenir de l'usager, et la traduction technique précise sera faire lors de l'appel HTTP POST.

Attention : par défaut pour chaque "valeurX", Publik ne sait envoyer que des chaînes de caractères. Ainsi, si des nombres doivent être transmis, ils le seront sous forme de chaîne de caractère. D'autres types de données peuvent être possibles, mais il convient alors de vérifier que Publik peut les gérér.

En retour, Publik attend un dictionnaire avec deux entrées :

Exemple de réponse attendue :

POST https://logiciel.tiers/api/creation-nouvelle-demande
(... dictionnaire JSON de la demande à créer ...)

200 OK
Content-Type: application/json

{
  "err": 0,
  "data": {
     "numero": "42",
     "url": "https://logiciel.tiers/api/demande/42/",
     "statut": "demande créée",
     "datetime": "2021-09-09T15:20:12" 
  }
}

Publik va stocker toutes ces informations dans la demande. L'élément important et nécessaire ici est numero, qui sera la référence dans le logiciel.

En cas de problème, la réponse sera du même format mais avec un err à 1 (ou toute autre valeur différente du nombre 0) : lire la section sur la gestion de erreur plus bas dans ce document.

Ajout de document sur une demande créée

Une fois la demande créée, Publik peut y joindre les documents. Les documents sont envoyés en dehors de la création de la demande, et un par un : l'objectif est d'éviter tout engorgement, car il s'agit souvent de documents volumineux qui peuvent subir un filtrage par un équipement réseau entre Publik et le logiciel.

Pour chaque document, une requête HTTP POST est effectuée qui contient une référence à la demande créée. Par exemple :

POST https://logiciel.tiers/api/document-pour-demande/42/
Content-Type: application/json
Accept: application/json

{
  "document": {
     "filename": "nomdufichier.pdf",
     "content_type": "application/pdf",
     "content": "Y2VjaSBlc3QgdW4gZXhlbXBsZSBkZSBiYXNlNjQK..." 
  },
  "type": "passeport",
}

Le fichier est sérialisé dans une clé document. Le contenu du fichier est envoyé dans content encodé en base64, le nom du fichier est filename et son type MIME est dans content_type. Ce format filename+content_type+content est imposé par Publik et n'est pas modifiable.

Dans l'exemple ci-dessus, un type est indiqué qui permet au logiciel métier de savoir de quel document il s'agit. D'autres informations peuvent accompagner le document, selon ce qui est nécessaire au logiciel.

Le numéro de la demande pour laquelle le fichier est envoyé (ici 42) peut être indiqué :

En retour de cet appel HTTP POST, Publik attend un dictionnaire avec au moins une entrée err à 0 (le nombre entier), et éventuellement des informations supplémentaires dans une clé data, par exemple :

200 OK
Content-Type: application/json

{
  "err": 0,
  "data": null
}

Comme pour la création de la demande, en cas d'erreur la réponse sera identique mais avec err à 1 (ou toute autre valeur différente du nombre 0) : voire la section sur la gestion d'erreurs plus bas dans ce document.

Remontée du statut d'une demande dans Publik

Une fois la demande créée dans le logiciel, elle va y être traitée.

Publik va régulièrement interroger son statut, par exemple toutes les 6 heures, en effectuant une requête HTTP GET telle que :

GET https://logiciel.tiers/api/statut-demande/42/
Accept: application/json

Le numéro de la demande peut être dans l'URL comme dans cet exemple, ou dans la querystring et on aurait alors par exemple /api/statut-demande/?demande=42.

En retour de cet appel HTTP GET, Publik attend un dictionnaire avec deux entrées err et data : c'est dans data que sont les informations de statut de la demande.

Exemple de réponse attendue :

Content-Type: application/json

{
  "err": 0,
  "data": {
     "statut": "traitement-en-cours",                          # code du statut
     "statut_label": "Demande en cours de traitement"          # nom affiché à l'usager
     "commentaire": "Votre demande sera traitée le 15/01/2021"    
  }
}

Pour savoir réagir dans toutes les situations, Publik devra connaître tous les statuts possibles, pour savoir ce qu'il doit faire de son côté : informer l'usager, clôturer la demande, etc.

Exemples de statuts que l'on peut imaginer (mais c'est le logiciel qui spécifiera la liste exacte selon son «métier») :

Publik interroge régulièrement le statut de la demande, jusqu'à obtenir un statut final (par exemple "clos" ou "refus"). Le délai entre chaque interrogation est paramétrable dans Publik, c'est souvent 6h ou 12h, et ce pour chaque demande qui n'est pas encore clôturée.

Commentaires lors du traitement dans le logiciel tiers

Pendant le traitement de la demande, les agents peuvent éventuellement indiquer des commentaires destinés à l'usager.

Pour faire cela, lors de chaque interrogation du statut de la demande, Publik vérifie si le commentaire a changé. Si oui, alors il le communique à l'usager (par mail, sms, message à l'écran, selon l'action configurée dans Publik).

Système en mode «push» : déclenchements par le logiciel tiers

Dans ce qui est décrit ci-dessus, c'est Publik qui vient régulièrement demander au logiciel tiers le statut des demandes en cours. Cela présente plusieurs inconvénients :

Si le nombre de de demandes est important ou si la réactivité doit être grande, c'est plutôt le logiciel tiers qui doit informer de l'avancement des demandes.

Pour cela, le logiciel tiers peut déclencher des appels «_trigger_» sur Publik, sous forme de requête POST, selon ce format :

POST https://demarches.example.net/<slug-demarche>/<numero-de-demande>/jump/trigger/<declencheur>/
{
  "information": ...
}

Cet appel va demander à Publik que la demande de type <slug-demarche>, numéro <numero-de-demande>, effectue un saut nommé <declencheur>. Ce saut est programmé dans Publik, dans le workflow de la démarche concernée. Au passage, le logiciel pourra fournir des informations supplémentaires dans un dictionnaire JSON, qui seront enregistrée dans la demande Publik. Ces données pourront ensuite être exploitées dans le workflow, par exemple pour alimenter une donnée de traitement.

Plus de détails sur ce principe de traitement : https://doc-publik.entrouvert.com/dev/wcs/api-webservices/traitement-d-un-formulaire/

Ce mécanisme impose que le logiciel tiers détermine les URL à appeler. Pour cela, il devra connaître les codes <declencheur> possibles, et les appeler au moment opportun. Il doit aussi avoir reçu <slug-demarche> et <numero-de-demande> dans le JSON de la création de la demande.

Enfin, en mode «push», le logiciel tiers doit tracer (loguer) les appels qu'il effectue. Il doit savoir retenter un appel qui a échoué sur une erreur non fatale (erreur réseau, DNS, code HTTP 5xx, etc.). Il doit savoir lever une alerte en cas d'erreur fatale afin de pouvoir déboguer les problèmes le plus rapidement possible. (Pour information, comme pour toute requête, Publik ne logue que les métadonnées, donc ni le contenu des appels reçus, ni celui de la réponse envoyée.)

Référentiels, listes de choix

Le formulaire présenté à l'usager par Publik comporte souvent des champs de type listes. L'usager doit choisir un ou des éléments dans ces listes. Ces choix sont nécessaires à la création de la demande dans le logiciel métier, par exemple le type d'intervention, la nature du signalement, etc.

Le logiciel tiers doit fournir à Publik le contenu de ses listes. Comme exemple on imagine le cas d'un formulaire de demande d'intervention dans une école située sur le territoire d'une agglomération : le formulaire affichera les listes suivantes :

Pour chaque liste, Publik interroge un webservice de référentiel, dans cet exemple on aurait :

La réponse à un référentiel est un document JSON de type dictionnaire, avec deux entrées :

Exemple d'une réponse simple pour la liste des villes, avec juste id et text pour chacune :

GET https://logiciel.tiers/api/referentiel/villes

200 OK
Content-Type: application/json

{
  "err": 0,
  "data": [
    {
      "id": "38185",
      "text": "Grenoble",
    },
    {
      "id": "38544",
      "text": "Vienne" 
    }
    (... les autres villes ...)
  ]
}

Mais on peut aussi ajouter d'autres détails sur chaque entrée, par exemple le code postal principal de chaque ville :

GET https://logiciel.tiers/api/referentiel/villes

200 OK
Content-Type: application/json

{
  "err": 0,
  "data": [
    {
      "id": "38185",
      "text": "Grenoble",
      "code_postal": "38000",
    },
    {
      "id": "38544",
      "text": "Vienne" 
      "code_postal": "38200",
    }
    (... autres villes ...)
  ]
}

À noter que les éléments des listes doivent être triés dans l'ordre à afficher aux usagers, Publik ne re-trie pas les listes qu'il reçoit.

Usage des données reçues

Publik affiche sur le formulaire la liste des text, dans l'exemple ci-dessus ça sera Grenoble, Vienne, etc. Quand l'usager fait son choix dans cette liste, alors Publik dispose de toutes les informations liées à ce choix. Par exemple si l'usager choisi Vienne, Publik connaitra les valeurs suivantes :

Toutes ces informations sont stockées et donc partie de la demande Publik. Elles peuvent toutes être utilisées pour communiquer ensuite avec le logiciel tiers lors de la création de la demande.

Ainsi, au lieu d'envoyer le nom "Vienne" au logiciel tiers qui devrait retrouver à quelle ville sa correspond dans sa base, Publik peut lui envoyer directement le code INSEE de la ville concernée "38544". Ce partage de référentiels permet donc une communication plus efficace entre Publik et le logiciel.

Filtrage des éléments d'un référentiel

Pour certaines listes, on voudra les restreindre en fonction de certains critères. Dans notre exemple on cherche à afficher les établissements d'une ville en particulier. Pour faire cela, Publik ajoute un critère dans l'URL lorsqu'il interroge le référentiel des établissements : GET https://logiciel.tiers/api/referentiel/etablissements?code_ville=38000

La réponse obéit strictement au même format que pour la liste complète des établissements, mais seuls les établissements de la ville concernée sont présents dans data.

Liste en mode auto-complétion

Quand une liste contient plusieurs dizaines d'éléments, elle est trop longue à afficher dans un formulaire. Publik peut en proposer l'affichage en mode auto-complétion : l'usager doit taper quelques lettres et Publik affiche les éléments de la liste qui les contiennent.

Pour cela, le webservice référentiel concerné doit réagir à deux paramètres supplémentaires : q pour filtrer en fonction de ce que l'usager a tapé, et id pour remonter les informations du choix fait par l'usager.

Comme pour une requête filtrée, la réponse obéit strictement au même format que pour la liste complète : un dictionnaire avec err à 0 (le nombre entier 0) et data qui contient la liste des éléments.

Format des réponses en cas d'erreur

Lorsque Publik envoie des données mal formatées

Si les données envoyées par Publik ne sont pas dans un format attendu par le logiciel, celui-ci doit renvoyer une erreur avec le détail des incohérences constatées. Le retour est toujours un dictionnaire JSON avec deux entrée "err" et "data", mais cette fois err doit être différent de 0. Attention, erreur fréquente : si err contient la chaine de caractère "0" alors ça sera considéré comme un code d'erreur. Il faut utiliser le nombre entier 0.

Le message technique peut être en anglais (par exemple un retour d'erreur SQL) mais il doit permettre à un technicien de comprendre quel champ est en cause, et si possible le type d'erreur constaté (valeur impossible, mauvais type de donnée, …). Le message doit être contenu dans une clé "err_desc" (description de l'erreur). Si c'est utile, un code type d'erreur peut être retourné dans "err_class".

Le code de retour HTTP peut être 400, mais ce n'est pas obligatoire, le plus important est "err" différent de 0.

Par exemple si Publik envoie une demande avec une mauvaise information "foo" :

POST /api/creation-demande
{
  "foo": "trois" 
}

400 Bad Request
Content-Type: application/json

{
  "err": 1,
  "data": null,
  "err_desc": "valeur de foo non acceptée, doit être un entier",
  "err_class": "bad-request" 
}

Autres erreurs

Pour toutes les autres erreurs, par exemple si une écriture SQL ne se fait pas, ou qu'un autre problème technique survient lors de l'exécution du webservice par le logiciel, ce dernier doit tout de même répondre une réponse JSON (afin que Publik sache qu'il a bien interrogé le webservice mais que celui-ci a eu un problème interne).

Typiquement, il ne fait jamais renvoyer une erreur de type 500 ou une "traceback".

Donc, même en cas d'erreur : Pour aider à la compréhension de l'erreur, on peut ajouter :

Par exemple en cas d'impossibilité de joindre le SGBD :

GET /api/status-demande?id=42

200 OK
Content-Type: application/json

{
  "err": 1,
  "data": null,
  "err_desc": "table form_evolutions inaccessible",
  "err_class": "sql-error" 
}

Sécurisation de la communication entre Publik et les webservices du logiciel

Tous les échanges auront lieux en HTTPS avec un certificat valide. Au cas où le certificat est émis par une autorité de certification locale, il faut fournir le certificat de l'autorité (clé publique).

L'accès peut être reservé aux adresses IP d'hébergement de l'instance Publik qui effecture les requêtes.

Enfin, une authentification de type HTTP Basic peut être ajoutée en sécurité supplémentaire.


Envois de courriels

Publik envoie des courriels aux usagers (création de compte, avancement des demandes, etc.).

Ces courriels sont paramétrés avec : Si la collectivité veut utiliser une adresse d'expédition sur un autre domaine :

Cas particulier : si Entr'ouvert n'a pas la délégation DNS sur le domaine où est hébergé le site Publik, alors il faut vérifier la présence du SPF ci-dessus sur le nom de domaine choisi pour l'adresse mail.


Format de description des web-services

Voir #14174

{

  "<slug-service1>": {

    "type": "family",
    "label": "..." 
    "baseuri": "/...",

    "endpoints": {

      "<slug-endpoint1>": {

        "label": "...",
        "description": "...",
        "endpoint": "create",
        "method": "GET",
        "type": "datasource",        # optionnel ?

        "params": {
          "<varname1>": {
            "label": "...",
            "type": "string",
            "example": "..." 
          },
          "<varname2>": {
            "label": "...",
            "type": "datetime",
            "example": "..." 
          }
        },

        "payload": {
          "<varname1>": {
            "label": "...",
            "type": "float",
            "example": "..." 
          },
          "<varname2>": {
            "label": "...",
            "type": "list",
            "example": "..." 
          },
          "__root__": {             # si le payload est un dictionnaire de type "bien connu" dans Publik, tel que formdata
            "label": "...",
            "type": "formdata",
            "example": "..." 
          }
        },

        "result": {
          "<varname1>": {
            "label": "...",
            "type": "integer",
            "example": "..." 
          },
          "<varname2>": {
            "label": "...",
            "type": "dict",
            "example": "..." 
          }
        },

        "status": {
          "0": "ok",
          "1": "bad parameters" 
        },

        "triggers": {
          "<slug-trigger1>": "...label...",
          "<slug-trigger2>": "...label..." 
        }

      },
      "<slug-endpoint2>": {
      }
  },

  "<slug-service2>": {
  }
}

Formulaires PDF - CERFA

Création

Voir shareware https://code-industry.net/free-pdf-editor/#get

Il permet d'ajouter/éditer/remplir les champs sur un PDF.

Remplissage

Ticket en cours #24364


Geolocation

Sur mobile (android/chrome),

  navigator.geolocation.getCurrentPosition(
     function(a) { alert(a); },
     function(b) { alert(b.code); }, 
     {maximumAge: 60000});

Gestion électronique du courrier

template à remplir

Citations

Thomas Noël

Le 19 mai 2017 à 08h41, Benjamin Dauvergne a écrit :

La partie difficile, et je crois que c'est aussi la position de Thomas,
c'est l'intégration au poste de travail pour la rédaction/l'amendement des
courriers.
(...)

Il y a le détail subtil que maarch ou opencourrier sont des logiciels
installés sur site : ils n'ont pas vraiment ce soucis, ils sont déjà sur le
réseau local.

Et même la partie amont d'avalage du courrier pour l'instant on a réussi à la
déléguer à la ville sous couvert de "c'est pas notre métier".
(...)

Maarch a un partenariat avec fujitsu qui s'occupe de ça.
http://maarch.com/nos-applications/scanners-fujitsu/
Je sais pas comment atReal gère ça pour opencourrier.

A ce sujet de l'avalage : Maarch avale des "dossiers", composés
éventuellement de plusieurs PDF (la demande, la copie de la CNI qui va avec,
la copie des impots). Nous, on a fait le minimum syndical : on avale un seul
PDF par demande. Ca tient pas 2 secondes face à quelqu'un qui parle vraiment
d'une GEC.

Bref, il est sympa Thierry, mais il devrait le savoir : on a 80% du machin,
mais ce sont les deniers 20% qui sont les plus rudes.

Benjamin Dauvergne

Le 05/19, Brice MALLET a écrit :

Le souci c'est que ça va marcher (comme dirait benj) :
- on a 80% d'une GEC mais qui ne peut être utilisée que pour, allez, 30 %
des courriers reçus
- il faut donc une "autre" GEC pour les 70 % autres et il est vraiment trop
tentant d'alors utiliser Publik pour tous les courriers

Fred en dira plus et mieux que moi, c'est lui qui connaît le mieux le bouzin
mais pour moi la partie routage, validatio, des courriers et de leurs réponses
c'est la partie facile (sans dire que c'est pas du boulot à faire, mais qu'une
fois l'implémentation faite/testée/validée ça ne deviendra pas un problème
récurrent). C'est des circuits, on connait bien. Peut-être qu'on serait obligé
d'intégrer une vrai notion d'organigramme et d'escalade mais à part ça je ne
vois pas trop.. La partie difficile, et je crois que c'est aussi la position de
Thomas, c'est l'intégration au poste de travail pour la rédaction/l'amendement
des courriers. Alors peut-être qu'on peut récupérer le travail d'AtReal sur ce
point et s'épargner d'avoir à faire un lien entre le poste de travail
(LibreOffice ou Word) et notre solution mais je n'en suis pas certain.

Et même la partie amont d'avalage du courrier pour l'instant on a réussi à la
déléguer à la ville sous couvert de "c'est pas notre métier". Si on se présente
comme porteur d'une GEC on va nous demander de prendre en charge cette partie
je pense (conseiller un scanner, venir l'installer, le bon logiciel de scan, la
bonne archi pour récupérer les courriers, etc..).


Hub Rdv ANTS

Avoir un service pour servir à l'ANTS les RdV pour les demandes de CNI et passeports disponibles de nos clients. Il doit aussi permettre de lister les RdV pris pour des identifiants de pré-demande ANTS. Il sera alimenté par une application "optionnelle" (activé par la configuration d'une apikey) dans chrono.

Le besoin

API ANTS: https://rendez-vous-api.france-identite.fr/docs

Tous les appels sont authentifiés via un entête HTTP "X-Hub-Rdv-Auth-Token".

Endpoints à exposer :

Le hub

Le but du hub est d'aggréger les données des clients pour :
1. éviter que le hub de l'ANTS ne vienne charger l'infra Publik à moissonner tous nos clients avec beaucoup de requêtes
2. mutualiser les réponses entre clients
3. avoir du code pas tellement pertinent dans Publik
4. avoir un modèle économique pour la fourniture du service (abonnement)
5. permettre au client à nous de ne pas avoir à gérer le raccordement pour chacun d'entre eux (un seul token pour Entr'ouvert)

Modèle de donnée

left to right direction
skinparam linetype ortho

title Modèle de donnée Hub RdV ANTS


class "Raccordement" as raccordement
class "Collectivité" as coll
class "Lieu" as lieu
class "Plage horaire" as plage
class "Type de rendez-vous" as type
class "Rendez-vous" as rdv

raccordement "1" -- "*" coll
coll "1" -- "*" lieu
lieu "1" -- "*" plage
plage "*" -- "1" type
lieu "1" -- "*" rdv
coll "1" -- "*" type
lieu "1" -- "*" type

class raccordement {
  nom* : str, unique
  ==
  apikey : str, unique
}

class coll {
  nom : str, unique in raccordement
  id : slug, unique in raccordement
  ==
  url : url
  logo_url : url
  rdv_url : url
  gestion_url : url
  annulation_url : url
}

class type {
  nom : str -- one of CNI, PASSPORT, CNI-PASSPORT, RETRIEVAL
}


Class "Lieu de RdV" as lieu {
  id : slug, unique in collectivité
  nom : str
  ==
  numero_rue : str
  code_postal : str
  ville : str
  longitude : float
  latitude : float
  url : url
  rdv_url : url
  gestion_url : url
  annulation_url : url
}


class plage {
  date : date
  heure_debut : time
  heure_fin : time
  duree : integer, minutes
  ==
}


class rdv {
  id : str, identifiant de prédemande, unique pour la collectivité
  ==
  date : datetime
  gestion_url : str
  annulation_url : str
}

Implémentation

Fonctionnement

Le hub expose deux blocs d'APIs:

API pour l'ANTS

URL de prise de rendez-vous ou de gestion: le hub fera relai pour ne pas exposer les URLs réelles des raccordements :

https://ants.entrouvert.com/rdv/10-ville-de-machin/11-lieux-truc/CNI/20200110T1200/
https://ants.entrouvert.com/gestion/10-ville-de-machin/11-lieux-truc/CNI/20200110T1200/
https://ants.entrouvert.com/annulation/10-ville-de-machin/11-lieux-truc/CNI/20200110T1200/

API pour les sites de prise de rendez-vous raccordés

Il y a aura deux endpoints :

Application chrono

Nouvelle application dans chrono permettant l'alimentation du HuB. Une nouvelle entrée dans le menu hamburger "RdV ANTS" vers /manage/ants/.

Par défaut l'écran n'affiche rien à part un champ demandant l'API key, si le champ est rempli, on teste l'API key sur l'URL /api/push/ du hub, si ça renvoie {"err": 0}, l'apikey est valide, on l'enregistre en base et on affiche l'écran de configuration.

L'écran de configuration propose :

Modèle de donnée

Le même que plus haut pour la partie configuration des lieux/collectivités/types de RdV, ça se synchronise avec le hub à chaque modification et régulièrement avec en plus :

Fonctionnement


Procédure de raccordement au Fournisseur d'Identités FranceConnect vous incombant

Le raccordement à FranceConnect se fait en plusieurs étapes :

Disposer d'un compte Data Pass

Si vous ne disposez pas d'un compte sur Data Pass, il vous faut le créer sur la page https://datapass.api.gouv.fr/

Vous pouvez alors "Faire votre première demande"

Déclaration en vue de l'accès à l'API FranceConnect

C'est à cette étape que vous allez spécifiquement demander un accès à "FranceConnect et les API FranceConnectées", ceci se fait sur https://api.gouv.fr/les-api/franceconnect

Le projet

Les données nécessaires

Sélectionnez parmi les champs :

Remarque : nous vous encourageons à sélectionner tous les champs, en effet il s'agit d'une liste blanche i.e. ce qui pourra être demandé via l'API FranceConnect ; la récupération effective des données, quant à elle, se paramètre en aval dans Publik. Il est important de savoir que cette liste ne peut pas être modifiée par la suite ; aussi si vous n'autorisez pas tous les champs à cette étape, vous ne pourrez pas récupérer, facilement, les données non sélectionnées dans le futur.

Le niveau de garantie attendu par votre service

Le cadre juridique vous autorisant à traiter les données

En tant que collectivité locale, vous êtes légitime à utiliser le service FranceConnect, ceci en mentionnant l' "arrêté du 8 novembre 2018 relatif au téléservice dénommé FranceConnect". Cela implique que votre DPO a pris connaissance de l'activation de ce téléservice et qu'il est inscrit dans votre registre des activités de traitement tel que prévu par l’article 30 du RGPD.
Nota bene, ne pas oublier de mentionner explicitement l'URL de l'arrêté du 8 novembre 2018 : https://www.legifrance.gouv.fr/loda/id/JORFTEXT000037611479/

Les personnes impliquées

Procédure de raccordement au Fournisseur d'Identités FranceConnect incombant à Entr'ouvert

À partir de cette étape, nous prenons le relais (si vous avez bien saisi "datapass@entrouvert.com" alors nous serons automatiquement informés) et échangerons avec vous via des tickets Redmine, si nécessaire.


Infrastructure nécessaire à un hébergement sur site

Entr'ouvert assure l'installation et la maintenance de la partie applicative. Le reste de l'infrastructure (stockage, sauvegardes, sécurisation réseau, etc) est sous la responsabilité de l'hébergeur.

Les applicatifs Publik fonctionnent sur un serveur Debian. Pour le stockage, Publik a besoin d'accéder à :

Serveur applicatif

Le serveur applicatif qui va contenir les logiciels composant Publik doit avoir les caractéristiques minimales suivantes :

Cela peut tout à fait être une machine virtuelle, nous conseillons même cette approche qui permet d'augmenter les capacités de façon souple.

Ce serveur est infogéré par Entr'ouvert. Cependant, sauvegarde et restauration (PRA) restent à la charge de l'hébergeur.

Un système Debian 9.x minimal doit être installé, en version amd64. Le seul logiciel nécessaire par défaut est le serveur ssh (voir plus bas). Pour simplifier l'installation, pas de partitionnement : une seule partition racine / contiendra système et données.

NB : deux machines de ce type doivent être mise à disposition, production et pré-production (nommée aussi "recette"), les plus identiques possibles, principalement en terme d'environnement réseau.

Composants de stockage

Publik gère des données dans des bases PostgreSQL et dans des répertoires sur le système de fichier. Le serveur applicatif doit donc avoir accès à :

Ces composants sont à la charge de l'hébergeur.

Infrastructure réseau

Idéalement, le serveur d'application est placé derrière un mandataire inverse (reverse-proxy frontal). Ce dernier : Par ailleurs, le serveur d'application doit pouvoir :

Attention : les composants Publik installés sur le serveur application doivent se parler "entre eux", car ils échangent via webservices. Puisque la terminaison SSL se fait sur reverse proxy frontal, toutes les communications repasseront par ce reverse proxy.

Un domaine DNS sera dédié, dont le nom et tous les sous-domaines pointerons vers le reverse-proxy.

Note : si l'hébergeur ne dispose pas d'un reverse-proxy, le serveur d'application Publik devra gérer la terminaison SSL : les certificats seront à fournir à Entr'ouvert et à renouveler avant échéance.

Accès support/maintenance via SSH

Afin d'assurer maintenance et support de Publik, Entr'ouvert doit avoir un accès au serveur via le protocole SSH.

Voir aussi SupportEtInfogerance

George Abitbol


Infrastructure Publik Mutualisée

Voir https://doc-publik.entrouvert.com/guide-de-l-administrateur-systeme/architecture/hebergement-saas/


Note: L'utilisation de cette page est dépréciée, consulter "la nouvelle documentation de référence": https://doc-publik.entrouvert.com/guide-de-l-administrateur-systeme/installation/pre-requis/

Installation d'une machine Publik sur base Debian 8 (Jessie)

Mode d'emploi pour l'installation d'une machine Publik. Il s'agit d'installer la solution sur une seule machine (physique ou virtuelle).

Cependant, sur le canevas de cette documentation, chaque composant peut également être installé sur une machine dédiée : il faut alors ajuster les règles de pare-feu et les connexions AMQP (exercice laissé au lecteur à ce stade).

Prérequis

DNS

Dans la zone DNS choisie, ajouter les noms des différentes briques:

publik         A     a.b.c.d    ; addresse IP de «publik»
portail        CNAME publik    ; portail usage (brique: combo)
backoffice     CNAME publik    ; portail agent (brique: combo)
connexion      CNAME publik    ; fournisseur d'identités (brique: authentic)
demarches      CNAME publik    ; téléservices (brique: wcs)
passerelle     CNAME publik    ; hub de webservices (brique: passerelle)
hobo           CNAME publik    ; système de déploiement (brique: hobo)

Dans la suite du document, l'installation est faite dans la zone example.net

Certificat x509

Publik ne fonctionne qu'en mode HTTPS.

Un ou plusieurs certificats x509 valides et reconnus doivent être disponibles qui couvrent tous les noms des briques qui seront installées.

Dans la suite de la documentation, un certificat est disponible :

Messagerie SMTP

Idéalement la machine doit disposer d'un SMTP local capable d'émettre des courriels. L'installation et configuration de exim4-daemon-light est en général suffisante.

Installation et paramétrage du système d'exploitation Debian 8 (Jessie)

Le système d'exploitation Debian 8.x (Jessie) est installé en mode minimal, i.e. uniquement le choix "utilitaires usuels du système" lors de la sélection des logiciels durant l'installation.

Ajout des depots

Dans les sources APT, ajouter les backports et le depôt Entr'ouvert :

# /etc/apt/sources.list

# Debian 8
deb http://httpredir.debian.org/debian/ jessie main
deb http://security.debian.org/ jessie/updates main
deb http://ftp.fr.debian.org/debian jessie-updates main

# Debian 8 backports
deb http://ftp.fr.debian.org/debian jessie-backports main

# Entr'ouvert
# key: wget -q -O- https://deb.entrouvert.org/entrouvert.gpg | apt-key add -
deb http://deb.entrouvert.org/ jessie main

Installation des composants de base

Publik utilise les composants suivants :

Framework Web Django

Installer la version 1.8 de jessie-backports, en s'assurant au préalable que le depot est bien présent dans sources.list

# apt install -t jessie-backports python-django

Serveur web nginx

# apt install nginx-full

Autoriser l'upload des "gros" fichiers: dans /etc/nginx/conf.d créer un fichier client-max-body-size.conf avec le contenu:

client_max_body_size 10M;

Taille à ajuster en fonction de l'usage prévu.

Les vhosts pour chaque composant Publik seront configurés en utilisant le modèle :

server {
    listen 443 ssl;
    server_name <hostname>;    # indiquer ici le ou les noms des instances prévues

    ssl_certificate /etc/ssl/certs/cert-example.pem;       # un certificat couvrant tous les noms des instances prévues
    ssl_certificate_key /etc/ssl/private/cert-example.key;

    access_log /var/log/nginx/<hostname>-access.log combined;
    error_log /var/log/nginx/<hostname>-error.log;

    location ~ ^/static/(.+)$ {
        root /;
        try_files /var/lib/<application>/tenants/$host/static/$1
                  /var/lib/<application>/tenants/$host/theme/static/$1
                  /var/lib/<application>/collectstatic/$1
                  =404;
        add_header Access-Control-Allow-Origin *;
    }

    location ~ ^/media/(.+)$ {
        alias /var/lib/<application>/tenants/$host/media/$1;
    }

    location / {
        proxy_pass         http://unix:/run/<application>/<application>.sock;
        proxy_set_header   Host $http_host;
        proxy_set_header   X-Forwarded-SSL on;
        proxy_set_header   X-Forwarded-Protocol ssl;
        proxy_set_header   X-Forwarded-Proto https;
        proxy_set_header   X-Real-IP       $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

# catchall http → https
server {
    listen   80;
    server_name  <hostname>;    # indiquer ici le ou les noms des instances prévues
    access_log  /var/log/nginx/<hostname>-access.log combined;
    error_log  /var/log/nginx/<hostname>-error.log;
    return 301 https://$host$request_uri;
}

ou <hostname> est le nom de domaine et <application> le nom de l'application deployée.

Base de données PostgreSQL

# apt install postgresql

En tant qu'utilisateur postgres créer les comptes et les bases pour chaque composant :

postgres@publik8$ createuser -SDR hobo ; createdb -O hobo hobo
postgres@publik8$ createuser -SDR combo ; createdb -O combo combo
postgres@publik8$ createuser -SDR passerelle ; createdb -O passerelle passerelle
postgres@publik8$ createuser -SDR fargo ; createdb -O fargo fargo
postgres@publik8$ createuser -SDR chrono ; createdb -O chrono chrono
postgres@publik8$ createuser -SDR bijoe ; createdb -O bijoe bijoe
postgres@publik8$ createuser -SdR wcs ; createdb -O wcs wcs_demarches_example_net
postgres@publik8$ createuser -SDR authentic-multitenant ; createdb -O authentic-multitenant authentic2_multitenant

Messagerie RabbitMQ

# apt install rabbitmq-server

Configuration de RabbitMQ

Prendre modèle sur l'exemple fourni avec hobo :

# zcat /usr/share/doc/rabbitmq-server/rabbitmq.config.example.gz > /etc/rabbitmq/rabbitmq.config

Modifications des indications SSL dans /etc/rabbitmq/rabbitmq.config :

…
   {ssl_options, [{certfile,             "/etc/ssl/certs/cert-example.pem"},
                  {keyfile,              "/etc/ssl/private/cert-example.key"},
                  {versions, ['tlsv1.2', 'tlsv1.1']}]}
…
   {listener, [{port,     15672},
               {ssl,      true},
               {ssl_opts, [{certfile,   "/etc/ssl/certs/cert-example.pem"},
                           {keyfile,    "/etc/ssl/private/cert-example.key"},
                           {versions, ['tlsv1.2', 'tlsv1.1']}]}]}
…

Puis relancer le service :

root@publik8# service rabbitmq-server restart

Puis ajouter un utilisateur hobo dans rabbitmq (choisir un mot de passe complexe) :

root@publik8# rabbitmqctl add_user hobo <mot-de-passe-complexe>
root@publik8# rabbitmqctl set_permissions hobo ".*" ".*" ".*" 

Les composants Publik

Système de déploiement hobo

Installation du serveur :

# apt install hobo

Lancement de hobo (provoque l'initialisation de la base) :

root@publik8# service hobo restart

Agent de déploiement hobo-agent

Les instances cibles seront déployés sur la machine elle-même, on installe donc l'agent localement :

# apt install hobo-agent

Configurer l'agent afin qu'il puisse se connecter au serveur rabbitmq. Dans /etc/hobo-agent/settings.py, modifier la variable BROKER_URL :

BROKER_URL = 'amqp://hobo:<mot-de-passe-complexe>@<hobo hostname>:5671//?ssl=1'

Pus lancer le service hobo-agent via supervisor (à la première installation, ce dernier est démarré avant l'installation de hobo-agent) :

# supervisorctl update
# supervisorctl restart hobo-agent

Fournisseur d'identités Authentic

Installation :

# apt install authentic2-multitenant

Ajouter une configuration nginx, en se basant sur le modèle et remplaçant <application> par authentic2-multitenant :

Activation du provisionning

Authentic va utiliser RabbitMQ pour diffuser les informations sur les utilisateurs et les rôles. Pour cela, ajouter à la fin du fichier /etc/authentic2-multitenant/config.py :

# extrait de /etc/authentic2-multitenant/config.py
# (une ligne ajoutée fin du fichier)

# Role provisionning via local RabbitMQ
HOBO_ROLE_EXPORT = True

Puis relancer le service pour prendre en compte la nouvelle configuration :

# service authentic2-multitenant restart

Authentification via FranceConnect

Afin de pouvoir utiliser l'authentification via FranceConnect il faut installer le paquet supplémentaire python-authentic2-auth-fc:

# apt install python-authentic2-auth-fc

Portails citoyen et agent Combo

Installation :

# apt install combo

Création d'une configuration nginx en se basant sur le modèle et remplaçant <application> par combo.

Combo est utilisé pour les portails usager et agent, le <hostname> couvrira les deux sites, par exemple :

# extrait de /etc/nginx/sites-available/combo
server {
…
    server_name portail-agent.example.net portail-usager.example.net;
…
}

Démarches w.c.s.

Installation du paquet wcs-au-quotidien :

# apt install wcs-au-quotidien

Un ensemble de paramètres, spécifiés dans des fichiers de configuration peut-être défini lors de la création d'une instance w.c.s.
Un archive zip contenant ses fichiers de configuration doit être placée dans le répértoire /var/lib/wcs/skeletons. Par exemple /var/lib/wcs/skeletons/publik.zip (fichier joint à cette page).

Configuration nginx :

# /etc/nginx/sites-available/wcs
server {
    listen 443 ssl;
    server_name <hostname>; 

    ssl_certificate /etc/ssl/certs/cert-example.pem; 
    ssl_certificate_key /etc/ssl/private/cert-example.key;

    access_log /var/log/nginx/wcs-access.log combined;
    error_log /var/log/nginx/wcs-error.log;

    location ~ ^/static/(.+)$ {
            root /;
            try_files /var/lib/wcs/$host/static/$1
                      /var/lib/wcs/$host/theme/static/$1
                      /var/lib/wcs/collectstatic/$1
                      /var/lib/wcs-au-quotidien/collectstatic/$1
                      =404;
    }

    location /qo { alias  /usr/share/wcs/qommon/; }
    location /apache-errors { alias  /usr/share/auquotidien/apache-errors/; }
    location /themes {
        root /;
        try_files /var/lib/wcs/$host$uri
                 /var/lib/wcs-au-quotidien/$host$uri
                 /usr/share/wcs/$uri
                 =404;
    }

    location /robots.txt {
        alias /usr/local/share/auquo-robots.txt;
    }

    location /rpc_relay.html {
        alias /usr/share/auquotidien/rpc_relay.html;
    }

    location / {
        proxy_pass         http://unix:/run/wcs/wcs.sock;
        proxy_set_header   Host $http_host;
        proxy_set_header   X-Forwarded-SSL on;
        proxy_set_header   X-Forwarded-Protocol ssl;
        proxy_set_header   X-Forwarded-Proto https;
        proxy_set_header   X-Real-IP       $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
    }

}

# catchall http → https
server {
    listen   80;
    server_name  <hostname>;
    access_log  /var/log/nginx/wcs-access.log combined;
    error_log  /var/log/nginx/wcs-error.log;
    return 301 https://$host$request_uri;
}

Hub de webservices Passerelle

Installation :

# apt install passerelle

Création d'une configuration nginx à partir du modèle en remplaçant <application> par passerelle.

Porte document Fargo

Installation :

# apt install fargo

Création d'une configuration nginx à partir du modèle en remplaçant <application> par fargo.

Thèmes de base

Un ensemble de thèmes est fourni par le paquet publik-base-theme, donc le thème de base «publik» utile pour déployer des instances initialement (sans thème spécifique).

Installation :

# apt install publik-base-theme

Création des instances : hobo «cooking»

Créer un fichier «recipe.json» (dans /tmp par exemple) sur ce modèle :

{
  "variables": {
    "hobo": "hobo.example.net",
    "authentic": "connexion.example.net",
    "combo": "portail.example.net",
    "combo_agent": "backoffice.example.net",
    "passerelle": "passerelle.example.net",
    "wcs": "demarches.example.net",
    "fargo": "portdoc.example.net" 
  },
  "steps": [
    {"create-hobo": {
      "url": "https://${hobo}/" 
    }},
    {"create-superuser": {
      "email": "superuser@example.net",
      "password": "example" 
    }},
    {"create-authentic": {
      "url": "https://${authentic}/",
      "title": "Connexion" 
    }},
    {"set-idp": {
    }},
    {"create-combo": {
      "url": "https://${combo}/",
      "title": "Compte citoyen",
      "template_name": "portal-user" 
    }},
    {"create-combo": {
      "url": "https://${combo_agent}/",
      "slug": "portal-agent",
      "title": "Portail agent",
      "template_name": "portal-agent" 
    }},
    {"create-wcs": {
      "url": "https://${wcs}/",
      "title": "Démarches",
      "template_name": "publik.zip" 
    }},
    {"create-passerelle": {
      "url": "https://${passerelle}/",
      "title": "Passerelle" 
    }},
    {"create-fargo": {
      "url": "https://${fargo}/",
      "title": "Porte doc" 
    }},
    {"set-theme": {
      "theme": "publik" 
    }}
  ]
}

L'utiliser sur la commande cook de hobo-manage (à lancer en tant qu'utilisateur hobo !) :

# sudo -u hobo hobo-manage cook /tmp/recipe.json 

Attention : la commande cook arrête d'envoyer des instructions de déploiement au bout d'un timeout de 30 secondes. Sur des systèmes peu véloces, il faudra éventuellement relancer la commande plusieurs fois, jusqu'à ce que son exécution se déroule sans aucune erreur.

Finalisations

Passage de w.c.s. en SQL

!! Cette étape n'est pas nécessaire si le deploiement de l'instance w.c.s a été fait en utilisant un template de configuration (variable template_name dans le fichier recipe) activant le stockage des données en SQL.

Le système de déploiement n'utilise pas automatiquement le stockage SQL de w.c.s. Il faut donc, une fois l'instance créée, la convertir manuellement. Pour cela :

  1. Ajouter « postgresql = true » dans la section « options » du fichiers /var/lib/wcs/demarches.example.net/site-options.cfg :
    # extrait de /var/lib/wcs/demarches.example.net/site-options.cfg
    
    [options]
    postgresql = true
    # …  autres options laissées inchangées
    
  2. Lancer la conversion proprement dite (en tant qu'utilisateur wcs-au-quotidien) :
    # sudo -u wcs wcsctl -f /etc/wcs/wcs-au-quotidien.cfg convert-to-sql --dbname=wcs_demarches_example_net demarches.example.net 
    

Amorce de la configuration de w.c.s. par création d'un premier utilisateur

Se rendre sur https://connexion.example.net/manage/roles/ et créer un premier rôle nommé par exemple «Support et Débogage»

Se rendre sur https://connexion.example.net/manage/users/ et créer un utilisateur :

Après quelques secondes, vérifier que l'utilisateur est bien provisionné sur w.c.s. https://demarches.example.net/backoffice/users/ et qu'il a bien les rôles «Administrateur du site» et «Support et Débogage»

Fin ... et début !

L'installation est prête. Il reste à effectuer le paramétrage de base du système puis à commencer la configuration de Publik.


Installation d'une machine Publik SaaS

Mode d'emploi pour l'installation d'une machine Publik. Il s'agit d'installer la solution sur une seule machine (physique ou virtuelle).

Cependant, sur le canevas de cette documentation,chaque composant peut également être installé sur une machine dédiée : il faut alors ajuster les règles de pare-feu et les connexions AMQP (exercice laissé au lecteur à ce stade).

Pré-requis

Système d'exploitation Debian 7.x (Wheezy) installé en mode minimal.

Sources APT:

deb http://httpredir.debian.org/debian/ wheezy main
deb http://security.debian.org/ wheezy/updates main
deb http://ftp.fr.debian.org/debian wheezy-updates main
deb http://ftp.fr.debian.org/debian wheezy-backports main
deb http://www.rabbitmq.com/debian/ testing main
deb http://deb.entrouvert.org/ wheezy main
Installation des paquets «couches basses» :

Déclarations DNS

Dans la zone choisie :

portail        A     ....
backoffice     CNAME xxx
connexion      CNAME xxx
demarches      CNAME xxx
passerelle     CNAME xxx
hobo           CNAME xxx

Note : dans la suite du document, l'installation est faite dans la zone «example.net»

Préparation PostgreSQL, utilisateurs et base

En tant qu'utilisateur postgres:

postgres@xxx$ createuser -SDR hobo ; createdb -O hobo hobo
postgres@xxx$ createuser -SDR authentic-multitenant ; createdb -O authentic-multitenant authentic2_multitenant
postgres@xxx$ createuser -SDR combo ; createdb -O combo combo
postgres@xxx$ createuser -SDR passerelle ; createdb -O passerelle passerelle
postgres@xxx$ createuser -SdR wcs ; createdb -O wcs wcs_demarches_example_net

Système de déploiement hobo + rabbitmq

Installation des paquets:

Configuration nginx depuis ce modèle :

# nginx template hobo
server {
    listen 443 ssl;
    server_name hobo.*;    # indiquer ici le ou les noms des instances

    ssl_certificate /etc/ssl/certs/cert.pem;    # un certificat couvrant tous les noms
    ssl_certificate_key /etc/ssl/private/cert.key;

    access_log /var/log/nginx/hobo-access.log combined;
    error_log /var/log/nginx/hobo-error.log;

    location ~ ^/static/(.+)$ {
        root /;
        try_files /var/lib/hobo/tenants/$host/static/$1
                  /var/lib/hobo/tnenats/$host/theme/static/$1
                  /var/lib/hobo/collectstatic/$1
                  =404;
    }

    location ~ ^/media/(.+)$ {
        alias /var/lib/combo/tenants/$host/media/$1;
    }

    location / {
        proxy_pass         http://unix:/run/hobo/hobo.sock;
        proxy_set_header   Host $http_host;
        proxy_set_header   X-Forwarded-SSL on;
        proxy_set_header   X-Forwarded-Protocol ssl;
        proxy_set_header   X-Forwarded-Proto https;
        proxy_set_header   X-Real-IP       $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

# catchall http → https
server {
    listen   80;
    server_name  hobo.*;    # indiquer ici le ou les noms des instances
    access_log  /var/log/nginx/hobo-access.log combined;
    error_log  /var/log/nginx/hobo-error.log;
    return 301 https://$host$request_uri;
}

Lancement de hobo (provoque l'initialisation de la base):

root@xxx# service hobo restart

Configuration de rabbitmq

# zcat /usr/share/doc/hobo/rabbitmq.config.example.gz > /etc/rabbitmq/rabbitmq.config

Modifications SSL dans /etc/rabbitmq/rabbitmq.config:

…
   {ssl_options, [{certfile,             "/etc/ssl/certs/wildcard.dev.entrouvert.org.pem"},
                  {keyfile,              "/etc/ssl/private/wildcard.dev.entrouvert.org.key"},
                  {versions, ['tlsv1.2', 'tlsv1.1']}]}
…

Puis relancer le service

root@xxx# service rabbitmq-server restart

Création d'un utilisateur hobo dans rabbitmq:

root@xxx# rabbitmqctl add_user hobo <password>
root@xxx# rabbitmqctl set_permissions hobo ".*" ".*" ".*" 

Agent de déploiement

Les instances cibles sont sur la même machine, on installe donc l'agent :

Configuration dans /etc/hobo-agent/settings.py est laissée telle quelle:

BROKER_URL = 'amqp://'
AGENT_HOST_PATTERNS = None

Fournisseur d'identités (authentic)

Paquets :

Lancement du processus authentic2:

# service authentic2-multitenant restart

Configuration nginx inspirée de celle de hobo : remplacer «hobo» par «authentic2-multitenant»

Démarches (w.c.s.)

Paquets

Désactivation de wcs au profit de wcs-au-quotidien

root@xxx# update-rc.d wcs disable 
root@xxx# update-rc.d wcs-au-quotidien enable 
root@xxx# service wcs stop
root@xxx# service wcs-au-quotidien restart

Configuration nginx, sur modèle hobo mais en mode SCGI au lieu de proxy_pass:

(...)
        location /qo { alias  /usr/share/wcs/qommon/; }
        location /apache-errors { alias  /usr/share/auquotidien/apache-errors/; }
        location /themes {
            root /;
            try_files /var/lib/wcs-au-quotidien/$host$uri /usr/share/wcs/$uri =404;
        }

        location / {
            include scgi_params;
            scgi_pass localhost:3001;
            scgi_param SCRIPT_NAME '';
            scgi_param PATH_INFO $uri;
            scgi_param HTTPS yes;
        }
(...)

Portails citoyen et agent (combo)

Installation du paquet

Création des sites nginx (modèle hobo, s/hobo/combo/)

Démarrage:

root@xxx# service combo restart

Hub de services (passerelle)

Installation du paquet

Création un site nginx (modèle hobo, s/hobo/passerelle/)

Démarrage:

root@xxx# service passerelle restart

Instanciations

Création d'un fichier JSON «recipe»

Créer un fichier «recipe-example.json» qui va décrire les instances à déployer (remplacer les «example») :

{
  "variables": {
    "hobo": "hobo.example.net",
    "authentic": "connexion.example.net",
    "combo": "portail.example.net",
    "combo_agent": "backoffice.example.net",
    "passerelle": "passerelle.example.net",
    "wcs": "demarches.example.net" 
  },
  "steps": [
    {"create-hobo": {
      "url": "https://${hobo}/" 
    }},
    {"create-superuser": {
      "email": "admin@example.net",
      "password": "example" 
    }},
    {"create-authentic": {
      "url": "https://${authentic}/",
      "title": "Connexion" 
    }},
    {"set-idp": {
    }},
    {"create-combo": {
      "url": "https://${combo}/",
      "title": "Compte usager",
      "template_name": "portal-user" 
    }},
    {"create-combo": {
      "url": "https://${combo_agent}/",
      "slug": "portal-agent",
      "title": "Portail agent",
      "template_name": "portal-agent" 
    }},
    {"create-wcs": {
      "url": "https://${wcs}/",
      "title": "Démarches" 
    }},
    {"create-passerelle": {
      "url": "https://${passerelle}/",
      "title": "Passerelle" 
    }},
    {"set-theme": {
      "theme": "publik" 
    }}
  ]
}

Lancement du déploiement

# sudo -u hobo hobo-manage cook /path/to/recipe-example.json

La commande «cook» attend 30 secondes après chaque déploiement : si le déploiement prend trop de temps (machine lente), il faut relancer la commande autant de fois que nécessaire.

Passage en SQL de wcs

Pour l'instant la création d'une instance wcs ne passe pas automatiquement en mode SQL. Pour l'activer :

Finitions (notes)


Intégration graphique

Quelques principes qui nous permettent de réaliser une intégration graphique assez facilement.

Description rapide du fonctionnement de l'affichage Publik

Le système Publik utilise le framework Django, notamment son système de gabarit (templates) : https://docs.djangoproject.com/fr/1.9/ref/templates/

Une instance de Publik définit un thème de base, composé :

Au niveau des portails (portail usager, portail agent), il s'agit de systèmes CMS où chaque page indique le gabarit qu'elle suit. Ensuite, dans chaque zone du gabarit choisi (chaque colonne, souvent) on choisi les cellules de contenu qui seront affichées : un titre, du texte, la liste des démarches, les brouillons de l'utilisateur, les livres empruntés à la médiathèque, afficheur de flux RSS, etc.

Au niveau des applications de Publik (les briques de la solution : gestion des formulaires, porte-document, fournisseur d'identité, etc.) on indique un gabarit à suivre pour chacune. Chaque application affiche alors son contenu dans la zone de contenu du gabarit.

Suivant ces principes, l'ensemble de l'instance Publik suit les mêmes règles de présentation et on a une homogénéité graphique générale de l'instance.

Création du gabarit de base

Le plus souvent on dispose d'un site existant dont on doit copier le design, c'est-à-dire :

Gabarit de base

Pour cela, sur le site existant, on détermine une page qui sera le modèle à suivre et on crée un gabarit de base (theme.html) à partir d'elle. Souvent, ce gabarit de base est créée une fois pour toutes par Entr'ouvert.

Mais il est également possible d'avoir un script qui récupère la page du site existant et la modifie automatiquement, avec quelques règles de chercher/remplacer. Ce script peut alors être lancé selon une certaine fréquence (en général 1 heure) afin que des modifications faites sur le site existant se retrouvent sur Publik. Pour l'anecdote, citons le cas d'une ville qui met à jour la météo sur son site en HTML plusieurs fois par jour : au lieu de dupliquer le système complet de téléchargement de la météo, on duplique directement la base avec le contenu HTML correspondant, 4 fois par jour.

Recommandations concernant le site existant (source) :

Feuilles de style

Les feuilles de style et les éléments statiques liés (fontes, images) proposés par le site existant sont utilisés directement. On évite de les copier sur le site Publik, d'abord parce que ce n'est pas toujours facile à faire (il s'agit souvent de beaucoup d'éléments liés entre eux présents un peu partout sur le site), mais aussi pour permettre à Publik de s'adapter automatiquement à une modification du style du site existant, sans délai.

Cependant la feuille de style du site existant ne couvrira pas tous les besoins en style de Publik. Pour compléter, on ajoute dans le gabarit de base une CSS dédiée (publik.css). Elle est programmée avec Sass (http://sass-lang.com/).

Contraintes sur le site existant (source) : les éléments de style partagés doivent être fournis en HTTPS. Les polices elles doivent être servies avec une entête Access-Control-Allow-Origin.

Règle de bonne conduite

Bien entendu, l'ajout d'un grand nombre de script de mise à jour automatique rend le système fragile.

C'est pourquoi, la règle de bonne conduite reste d'éviter tout ces automatismes, et de parvenir à construire un gabarit de base statique une fois pour toutes au début du projet. En évitant la présence de «gadgets» (tels la météo, les actualités, menus déroulants profonds, etc) on gagne en simplicité, en efficacité et en sécurité.


Internet Explorer

« À compter du 12 janvier 2016, seule la version la plus récente d'Internet Explorer disponible pour un système d'exploitation pris en charge bénéficiera du support technique et de mises à jour de sécurité. Internet Explorer 11 est la dernière version d'Internet Explorer et continuera donc à bénéficier de mises à jour de sécurité, de correctifs de compatibilité et de l'assistance technique pour Windows 7, Windows 8.1 et Windows 10. »
https://www.microsoft.com/fr-fr/WindowsForBusiness/End-of-IE-support

http://caniuse.com/usage-table (relevé du 19 novembre 2016)

Machines virtuelles de test disponibles à partir de IE8 : https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

Backoffice

Un bandeau est affiché pour les versions 8 et inférieures. (sauf dans w.c.s., mais ça ne signifie pas que ces versions y sont prises en charge).

Frontoffice

Pas de bandeau affiché; pour nos thèmes : quelle version annoncer ? (le modèle flexbox qu'on utilise pour les modèles avec une barre latérale est arrivé avec IE10).

Pour les intégrations graphiques tierces, ça dépend de l'intégrateur.


Connexion à l'annuaire LDAP de la collectivité

Nous avons déployé une instance de Publik.

Afin de la connecter à votre annuaire nous avons besoin de connaître :

Pour limiter les comptes importés à un groupe, merci de nous fournir le DN de celui-ci, il sera ajouté au filtre.

Tests

Pour que nous puissions tester le bon fonctionnement de la connexion, il faudra nous fournir un compte de test, voire plusieurs s'il faut tester le bon approvisionnement des groupes.

Sécurisation

Nous devons accéder à l'annuaire de manière sécurisée (c'est à dire chiffrée). Cela s'obtient :

Note : si vous utilisez Active Directory, les deux manières de chiffrer la communication (StartTLS ou LDAPS) sont supportées. Voir https://msdn.microsoft.com/en-us/library/cc223502.aspx et https://www.worteks.com/fr/2020/03/20/signature-ldap-obligatoire-dans-active-directory-ce-qui-change-pour-vos-applications/. Voir aussi https://www.arsouyes.org/blog/2020/35_LDAPs_Active_Directory/ et https://www.arsouyes.org/blog/2020/36_LDAPs_vs_starttls/

L'accès peut être limité aux adresses IP des sites Entr'ouvert :

Certificat serveur

L'utilisation d'un certificat auto-signé est impossible.

Si votre certificat serveur est signé par une autorité locale (non reconnue classiquement), il faudra fournir la chaîne de certification (l'ensemble des certificats des autorités signatrices, jusqu'à la racine).


Migration entre plateforme

1. Supprimer roles et utilisateurs de la plateforme cible, sauf roles techniques
2. Désactiver le WCS cible (<tenant_folde>.invalid), le combo agent et le combo usager
3. Supprimer ou renommer la base de données du WCS cible
4. Exporter roles et utilisateurs de la plateforme source

$ sudo -u authentic-multitenant authentic2-multitenant-manage tenant_command export-roles /tmp/roles.json
$ sudo -u authentic-multitenant authentic2-multitenant-manage tenant_command export-users /tmp/users.json

5. Redéployer le WCS cible et les 2 combos (agent/usager)
6. Convertir le systeme de stockage des données en SQL
sudo -u wcs-au-quotidien wcsctl -f /etc/wcs/wcs-au-quotidien.cfg convert-to-sql --dbname=<tenant_name> <fqdn>

7. Importer les roles sur la plateforme cible
sudo -u authentic-multitenant authentic2-multitenant-manage tenant_command import-roles /tmp/roles.json

8. Verifier les roles dans Authentic et WCS
9. S'assurer d'avoir la meme matrice de permissions sur les 2 plateformes (source et cible)
10. Importer les utilisateurs
sudo -u authentic-multitenant authentic2-multitenant-manage tenant_command import-users /tmp/users.json

11. Exporter le WCS source (formulaires, workflows, categories et sources de donnees)
12. Importer le WCS source sur la plateforme cible
13. Exporter les Combo source
14. Importer les Combo source sur la plateforme cible


Migration Plateforme

Les points ci-dessous sont à suivre lors de la migration d'une plateforme publik

1. Migration des roles et/ou utilisateurs (Authentic)
2. Migration des sources de données (Passerelle)
3. Création des catégories (w.c.s)
4. Migration des formulaires et workflows
5. Migrations du portail citoyen et du portail agent (Combo)
6. Réglage des options de debug (w.c.s.)
7. Réglage profil compte internaute (Authentic)
8. Réglage adresse mail d'expédition


Mise en place d'un SSO avec un portail d'éditeur métier

Cette documentation n'est plus maintenue.
Pour la version actualisée : Raccordement d'un portail métier


Mockups Publik Jarticule 2016

Accueil

Icônes supplémentaires, #10540

Factures

Benjamin (dans #10494, voir le ticket pour l'intégrale) :

J'ai toujours du mal avec une section qui s'appelle "Vos factures à payer" et qui contient des trucs qu'on ne peut pas payer. Pour moi le statut de la facture devrait être donné directement dans le tableau sans click en plus, cette popup ne contient apparemment aucune donnée qu'on aurait pas déjà dans le tableau à part la raison de non-possibilité de paiement (je suppose que montant total = montant à payer dans 99,9% des cas). Je ne vois aucun lien "Payer", on est censé savoir qu'il faut cliquer sur les lignes du tableau ?

Je verrais un truc comme ça:
Vos factures _non payées (en noir italique)_ _toutes (grisé italique)_
[...]

Ajout de Fred :

(C'est un peu ce qu'il y avait dans les mockups d'Orléans.)

Famille

Téléformulaire page 1

Téléformulaire page 2

Téléformulaire page de suivi

Fred :

Elle reprend une barre latérale, avec code de suivi et étapes, ce qu'on n'a pas actuellement. (si on veut faire ça, plutôt que le layout pleine page actuelle, #10567)

Les pages sont reprises côte à côte (ça marche de manière fictive ici parce que les deux pavés ont la même hauteur, dans la pratique ça ne sera jamais le cas).

Les infos des pages sont reprises une fois en alignant les champs et leur valeur sur la même ligne, une fois en les supersposant, une fois sur fond blanc, une fois sur fond de couleur. (bof, je serais pour garder la superposition, parce que c'est vraiment plus facile, mais sur fond blanc).

Plus grande variété d'icônes pour les étapes du workflow (ce serait bien mais c'est compliqué); variation de couleur selon usager/agent.

Espace d'action (commentaire ici) peut-être trop discret.

Porte-doc

Profil


Montée d'un serveur Publik en version Debian 12 (BookWorm)

Cette page explique comment mettre à jour un serveur hébergeant les applications Publik pour passer de la version Debian 11 (Bullseye) à la version Debian 12 (Bookworm).

Préparation de l'environnement

Pensez à vérifier les sauvegardes . Si possible, faire une image (snapshot) ou une sauvegarde juste avant la mise à jour.

S'assurer que les outils de supervision et de gestion de configuration sont compatibles avec Debian 12.

Vérifier que la ou les machines en Debian 11 sont bien à jour :

# apt update
# apt full-upgrade

Mise à jour préalable de PostgreSQL : si le serveur de base de données est séparé, il doit être mis à jour avant les serveurs d'applications Publik. Il faut passer en Postgresql version 13 au minimum. Voir plus bas dans ce document pour une procédure si la machine est une Debian.

Préparation de la mise à jour

Dans le cas d'une configuration à plusieurs nœuds, faire un serveur après l'autre. Ne jamais faire de mise à jour simultanée sur plusieurs nœuds.

Arrêter le système de cron :

# systemctl stop cron

Modifier les dépôts APT pour y indiquer "Bookworm" comme base. Il s'agit typiquement de mettre à jour le fichier /etc/apt/sources.list et ceux contenus dans le répertoire /etc/apt/sources.list.d/. Exemple de manipulation pour faire cette modification :

# sed -i 's/Bullseye/Bookworm/g' /etc/apt/sources.list
# sed -i 's/Bullseye/Bookworm/g' /etc/apt/sources.list.d/*

Prise en compte de ces nouveaux dépôts :

# apt update

Installation des dépôts et fichiers de préférences APT relatifs à Publik sur les environnements de production :

# apt install entrouvert-repository entrouvert-repository-hotfix && sudo apt update

S'il s'agit d'un environnement de test / pré-production, et uniquement pour ceux-là :

# apt install entrouvert-repository entrouvert-repository-testing && sudo apt update

Lancement de la mise à jour

Très classiquement :

# apt update
# apt full-upgrade

Passage en PostgreSQL version 15

Si le serveur d'application héberge aussi la base de données, après la montée de version vers Debian 12 il faut lancer la montée de version de PostgreSQL. En effet, deux clusters subsistent à la suite de la mise à jour, un actif en version 13 (venant de Debian 11) et l'autre en version 15 (installé par la mise à jour Debian 12).

Il s'agit de basculer vers le cluster en version 15 et de désactiver celui en version 13.

La documentation pour cela est sur /usr/share/doc/postgresql-common/README.Debian.gz. De façon pratique, la procédure revient à ces commandes :

# sudo -u postgres pg_dropcluster --stop 15 main
# sudo -u postgres pg_upgradecluster -m upgrade -k -j 4 13 main
# sudo -u postgres reindexdb --concurrently --all -j 4
# systemctl disable postgresql@13-main.service

Le 4 dans le « -j 4 » de la réindexation est à adapter selon le nombre de CPU.

Attention : le « -k » du pg_upgrade accélère la migration et fait gagner de l'espace, mais rends le cluster 13 hors d'usage. Si vous souhaitez conserver le cluster 13, ne l'utilisez pas. Dans tous les cas vérifier vos sauvegardes avant la mise a jour.

Nettoyage

À la suite de la mise à jour, un nettoyage des paquets inutiles peut être fait.

# apt autoremove

Puis un redémarrage complet de la machine est nécessaire pour passer sur le dernier noyau et réactiver les crons.


Montée d'un serveur Publik en version Debian 11 (Bullseye)

Cette page explique comment mettre à jour un serveur hébergeant les applications Publik pour passer de la version Debian 10 (Buster) à la version Debian 11 (Bullseye).

Préparation de l'environnement

Pensez à vérifier les sauvegardes . Si possible, faire une image (snapshot) ou une sauvegarde juste avant la mise à jour.

S'assurer que les outils de supervision et de gestion des configuration sont compatibles avec Debian 11.

Vérifier que la ou les machines en Debian 10 sont bien à jour :

# apt update
# apt full-upgrade

Mise à jour préalable de PostgreSQL : si le serveur de base de données est séparé, il doit être mis à jour avant les serveurs d'applications Publik. Il faut passer en Postgresql version 13 au minimum. Voir plus bas dans ce document pour une procédure si la machine est une Debian.

Préparation de la mise à jour

Dans le cas d'une configuration à plusieurs nœuds, faire un serveur après l'autre. Ne jamais faire de mise à jour simultanée sur plusieurs nœuds.

Arrêter le système de cron :

# systemctl stop cron

Modifier les dépôts APT pour y indiquer "bullseye" comme base. Il s'agit typiquement de mettre à jour le fichier /etc/apt/sources.list et ceux contenus dans le répertoire /etc/apt/sources.list.d/. Exemple de manipulation pour faire cette modification :

# sed -i 's/buster/bullseye/g' /etc/apt/sources.list
# sed -i 's/buster/bullseye/g' /etc/apt/sources.list.d/*
# sed -i 's!bullseye/updates!bullseye-security!g' /etc/apt/sources.list

Prise en compte de ces nouveaux dépôts :

# apt update

Installation des dépôts et fichiers de préférences APT relatifs à Publik sur les environnements de production :

# apt install entrouvert-repository entrouvert-repository-hotfix && sudo apt update

S'il s'agit d'un environnement de test / pré-production, et uniquement pour ceux là :

# apt install entrouvert-repository entrouvert-repository-testing && sudo apt update

Lancement de la mise à jour

Très classiquement :

# apt update
# apt full-upgrade

Passage en PostgreSQL version 13

Si le serveur d'application héberge aussi la base de données, après la montée de version vers Debian 11 il faut lancer la montée de version de PostgreSQL. En effet, deux clusters subsistent à la suite de la mise à jour, un actif en version 11 (venant de Debian 10) et l'autre en version 13 (installé par la mise à jour Debian 11).

Il s'agit de basculer vers le cluster en version 13 et de désactiver celui en version 11.

La documentation pour cela est sur /usr/share/doc/postgresql-common/README.Debian.gz. De façon pratique, la procédure revient à ces commandes :

# sudo -u postgres pg_dropcluster --stop 13 main
# sudo -u postgres pg_upgradecluster -m upgrade -k -j 4 11 main
# sudo -u postgres reindexdb --concurrently --all -j 4
# systemctl disable postgresql@11-main.service

Le 4 dans le « -j 4 » de la réindexation est à adapter selon le nombre de CPU.

Attention : le « -k » du pg_upgrade accélère la migration et fait gagner de l'espace, mais rends le cluster 11 hors d'usage. Si vous souhaitez conserver le cluster 11, ne l'utilisez pas. Dans tous les cas vérifier vos sauvegardes avant la mise a jour.

Nettoyage

À la suite de la mise à jour, un nettoyage des paquets inutiles peut être fait.

# apt autoremove

Puis un redémarrage complet de la machine est nécessaire pour passer sur le dernier noyau et réactiver les crons.


Multipages

Pages des formulaires multipages en prod actuellement (3/5/2015), en italique les pages conditionnelles, entre parenthèses le nombre de page sans condition / le nombre de page total.


Paiement

Voir aussi le laïus standard sur le paiement.

Configuration du service de paiement

Cette partie devrait aller dans la documentation Publik de l'administrateur technique.

Dans Combo, dans le menu sur la page d'accueil du /manage/, "Paiement en ligne", ajouter une régie, les paramètres varient d'un fournisseur à l'autre.

PayZen

Pour la recette :

{
  "secret_test": "xxx", 
  "site_id": "xxx", 
  "ctx_mode": "TEST" 
}

Et pour la prod :

{
  "secret_production": "xxx", 
  "site_id": "xxx", 
  "ctx_mode": "PRODUCTION" 
}

SIPSv2 (Atos en Belgique)

{
  "platform": "test", 
  "secret_key": "002001000000001_KEY1", 
  "merchant_id": "002001000000001", 
  "key_version": "1" 
}

Ingenico (ex Ogone)

Attention ils demandent configuration dans leur backoffice de l'adresse de callback. (https://combo.example.net/lingo/callback/&lt;numéro de la régie>/).

Dans leur backoffice également, il faut choisir « Vente » sous l’onglet « Paramètres de transaction globaux », dans la rubrique « Code d’opération par défaut » de la page d’Information technique. (sinon la notification annonce les paiements comme "acceptés" et non "payés" et ils ne sont pas pris en compte).

{
  "sha_out": "XXX", 
  "environment": "TEST", 
  "sha_in": "XXX", 
  "pspid": "XXX" 
}

(environment est à mettre à "PROD" pour utiliser leur environnement de production)

Remarque de Daniel (IMIO) :

Dans le backoffice Ingenico, les URL de callback se paramètrent dans "Configuration > Technical information > Transaction feedback" sous "HTTP request for status changes", sous "Direct HTTP server-to-server request".

Lors du paramétrage de la plateforme dans Publik :

Le SHA-out est une passphrase définie dans "Configuration > Technical information > Transaction feedback > Security for request parameters".
Le SHA-in est une passphrase définie dans "Configuration > Technical information > Data and origin verification > Checks for e-Commerce".

Enfin, si je ne me trompe, "Nom d'affiliation dans le système" correspondrait au PSPID, et ce PSPID figure notamment, et parmi d'autres informations relatives au compte, dans le pied de page du backoffice Ingenico. Et si c'est bien ça, ce serait probablement utile de l'indiquer en remarque du champ, au niveau du paramétrage de la plateforme.

PayFiP Régie / Régie web-service (ex-TIPI)

La collectivité (le régisseur ou son service financier) doit prendre contact avec le correspondant monétique de la trésorerie dont elle dépend, suite à la signature d'une convention ils obtiendrons un identifiant, le NUMCLI.

Il y a uniquement du paramétrage à faire dans lingo; le paramétrage à mettre en place est :

PayFip/TIPI et SNI

Pour pouvoir utiliser PayFiP sur un SaaS il faut modifier les URLs, avec le paramétrage suivant :

Workflow de paiement dans w.c.s.

Cette partie devrait aller dans la documentation Publik de l'administrateur fonctionnel (en cours).

Il faut dans le workflow une étape "en attente de paiement" qui contienne :

Le montant du paiement est calculé en prenant dans l'URL les paramètres "amount" (on pourrait donc ajouter &amount=[form_var_amount]) et le paramètre "amount" qui peut être présent dans "Données à envoyer (POST)", les différents montants sont additionnés.

Pour avoir un workflow unique associé à des demandes dont le montant varie, on peut passer par une variable de workflow, qui sera ensuite configurée formulaire par formulaire.

Pour permettre à l'usager d'annuler depuis le panier (ce qui par défaut est autorisé, cf cancellable=no plus haut pour le refuser), il faut également un saut sur le déclencheur adéquat ("cancelled").

Pour retirer un élément du panier :


Paiement (Laïus standard)

Publik permet :

Publik supporte la quasi-totalité des opérateurs de paiements :

Une régie est un compte en banque géré par un agent de la collectivité, le régisseur.

Les systèmes de paiement sont de deux types :

Pour le paiement par opérateur, nous recommandons un autre système que PayFiP/Tipi Régie/Régie web-service même si le service est gratuit - donc plutôt un service payant comme Payzen, Paybox, etc. - car avec PayFiP/TIPI Régie/Régie-webservice :

La collectivité souhaitera se prémunir du délit de concussion : permettre aux gens de payer n'importe quel montant pour n'importe quoi, sans pouvoir relier cela à une dette particulière.


Plan d'Assurance Qualité des projets Publik gérés par Entr'ouvert
Plan d'Assurance Sécurité de la plate-forme Publik gérée par Entr'ouvert

Version octobre 2018
Version originale disponible sur : https://dev.entrouvert.org/projects/publik/wiki/PAQ-PAS

Plan d'Assurance Qualité

Environnement du projet

Présentation et but du projet client

Le projet de [...], [...] habitants, a pour objectif la mise en place d'une solution de Gestion de la Relation Citoyen. La solution doit permettre d’atteindre concomitamment trois grands objectifs :

Équipe Entr’ouvert

L’équipe projet Entr'ouvert est composée des personnes suivantes :

Rôles

Voici les rôles qui sont attribués aux membres de l’équipe :

Coordonnées de l’équipe

Afin de faciliter la communication avec le client, une adresse e-mail unique redirigeant vers les adresses e-mail des membres de l’équipe a été créée : [...]@listes.entrouvert.com. Si besoin les membres de l'équipe sont joignables par messagerie instantanée (protocole jabber/XMPP).
Pour un contact urgent, le chef de projet est disponible dans la mesure du possible pour répondre aux demandes par téléphone.

Lieu de développement

L’équipe projet se trouvera dans les locaux de la société Entr'ouvert et/ou en télé-travail à domicile, joignables en permanence par mail ou messagerie instantanée. Locaux de la société Entr'ouvert :
Entr'ouvert SCOP ARL
169 rue du Château
75014 Paris
+33 (0)1 43 35 01 35

Site (extranet) projet

Entr'ouvert utilise une forge logicielle (http://dev.entrouvert.org) pour l'ensemble de ses projets depuis sa création.
Pour chaque projet, il est mis à disposition un espace sur cette forge, comprenant :
composition de l'équipe et rôles ;

Pilotage du projet

Phases

Le projet se découpe en deux phases principales.
En phase 1, seront mis en œuvre des démarches simples, sans connexion avec les applications métiers. Cette phase va permettre aux services de s’approprier la solution, aux directions d’envisager concrètement l’organisation et l’affectation des ressources. Lors de cette phase nous travaillons uniquement sur Publik, sans connecteur. Cela permet de faciliter l’adhésion des services en leur montrant que la solution fonctionne parfaitement et en les préservant des phases de tâtonnement qui existent toujours lorsqu’on l’on fait des connecteurs avec des applications tierces.
Une fois les aspects organisationnels traités, les complexités techniques, essentiellement la connexion aux applications tierces, sont traitées en phase 2. En réalité, les échanges avec les éditeurs, le développement des connecteurs et les tests auront commencé dès le début du projet mais le travail se fera exclusivement sur notre plate-forme de développement pour ne pas perturber la prise en main par les administrateurs fonctionnels et les agents.

Si les phases de réflexion et de modélisation sont un préalable indispensable aux développements proprement dits, nous savons d'expérience que des spécifications pléthoriques ne sont pas la garantie d'une solution adaptée. Il arrive fréquemment que l'on perde en épaisseur de la réalité des usages, ce que l'on gagne en modélisation théorique.
Nous proposons donc un développement itératif : c'est une forme de développement dans laquelle on crée rapidement un prototype de l'application pour le soumettre aux utilisateurs et les autoriser ainsi à préciser ses spécifications. Ceci permet de fournir un prototype plus élaboré, pour converger vers l'application finale. Les projets informatiques ont tendance à se tourner trop tard vers leurs utilisateurs, à un stade du développement où les changements possibles sont souvent d'ordre « cosmétique », ce que nous voulons d'éviter.
Ainsi, le planning de développement sera composé de plusieurs étapes, définies par des jalons qui permettront de voir l’état d’avancement du projet. Ce planning est visible sur le site projet.
Des tests – unitaires et fonctionnels – seront effectués tout au long du développement par l’équipe projet.

Organisation des réunions

À la fin de chaque module de développement ou en fin de phase dans le projet, une réunion jalon sera faite et un compte rendu sera dressé sous format électronique. Ce compte rendu sera disponible pour le client. Le contenu des réunions portera sur :

Livrables

Chaque document et module terminé devra être validé par le client en personne (par compte rendu de réunion validé). La documentation ainsi validée sera immédiatement livrée sous forme électronique via le site projet.
À la fin du projet tous les documents seront consolidés sur le site projet et toutes les sources seront livrées.
Récapitulatif des livrables :

Travail collaboratif

L’équipe projet travaille sur le site projet. Les tickets (demandes) et l'espace « wiki » permettent une grande partie des échanges et sont les outils de base du travail collaboratif.
Le code source est disponible via le site projet et également par le protocole git directement.

Suivi et sauvegarde des documents

Le site projet permet de suivre les modifications apportées aux documents créés via le wiki ou placés sur le dépôt de documents. Pour les documents créés hors wiki, lors des modifications importantes le rédacteur informera le reste des membres du projet des modifications apportées et demandera le cas échéant une validation de ces modifications.
Le site projet et l'intégralité de ses contenus sont sauvegardés chaque nuit sur une machine hors- site.

Communication

La communication entre l’équipe projet et le client est primordiale pour le bon déroulement du projet. Chaque partie s’engage à répondre à une demande de l’autre sous deux jours ouvrés.
L’équipe projet enverra régulièrement des emails (compte-rendus, jalons) au client pour le tenir informé du déroulement du projet.
Le client doit de son côté intervenir le plus rapidement possible s’il détecte un problème sur le projet.
Après envoi d’un document ou d’une demande de validation au client, l’absence de réponse après 3 jours ouvrés est considérée comme une validation. Toute validation au-delà de ces 3 jours sera traitée comme un risque critique.

Gestion des risques

Méthode

Dès la détection d’un risque qui pourrait compromettre le bon déroulement du projet, l’équipe classe le risque selon deux catégories :

Cycle de vie des fiches

Les fiches risques seront mises à jour au cours de leur résolution ou après une réunion jalon.
De manière exceptionnelle, un risque « à surveiller » peut devenir « critique », et réciproquement, ce qui entraînera la mise à jour de sa fiche risque.
Les « fiches risques » sont placées sur le site projet et font donc partie du plan de sauvegarde général du projet.

Plan d'Assurance Sécurité

Audits de sécurité

Publik a déjà fait l'objet de plusieurs audit de sécurité. Citons ceux conduits par le ministère de l'intérieur et par Montpellier Métropole.
Des audits pourront être réalisés par le maître d'ouvrage ou délégués à un tiers. Le contrôle prendra notamment la forme de tests d’intrusions ou d’audits de code.

Exigences de sécurité concernant les développements

Normalisation du code source

Chaque fichier source commencera par un descriptif de ses fonctionnalités, ainsi que la date de sa conception et l’identité de son créateur.
Chaque fonction commencera par un descriptif de sa ou ses fonctionnalités, ses entrées et ses sorties. Chaque nom de variable sera explicite sur la fonction qu’elle aura dans le programme.
Les codes source respecteront les bonnes pratiques associées au langage concerné, par exemple :

Utilisation de composants externes

Les composants externes utilisés par l'application seront issus de site réputés fiables, par rapport aux systèmes cibles, aux technologies et aux langages utilisés.
Par exemple :

Tests des sources

Des tests unitaires seront fournis pour les parties jugées les plus risquées du code, et notamment sur les APIs. Les tests fonctionnels sont réalisés si possible en utilisant des framework tels que :

Intégration continue

Les tests les plus pertinents sont intégrés à des outils de supervision (nagios) afin de vérifier le fonctionnement permanent de l'application et l'absence de régression.
Ils peuvent aussi faire partie d'étapes de benchmark pour valider des tests de montée en charge.

Procédures d’installation

Les procédures d'installation sont décrites ici : https://doc-publik.entrouvert.com/guide-de-l-administrateur-systeme/installation/pre-requis/

Sécurisation des infrastructures

Protection antivirale

Nous appliquons quotidiennement les correctifs de sécurité sur nos serveurs et sur nos postes de travail. Tous les logiciels sont installés et maintenu via des paquets et procédures Debian.

Mises à jour, correctifs de sécurité

Entr'ouvert assure la veille et applique les correctifs recommandés par les fournisseurs de solutions matérielles ou logicielles (logiciels système ou applicatifs, logiciels embarqués) sur tous les matériels dont nous avons la charge et plus particulièrement nous suivons les mise à jour de sécurité du système GNU/Linux Debian.
En cas d’alerte grave (attaque virale, faille critique) annoncée par le CERT-FR (Centre d’Expertise Gouvernemental de Réponse et de Traitement des Attaques informatiques), le correctif sera appliqué dans un délai de 24 heures sur les infrastructures hébergeant nos logiciels (serveurs, pare-feux, routeurs ouverts vers l’extérieur).
Lorsqu’aucun correctif n’est disponible, nous suivrons les recommandations du CERT-FR dans le cadre d’un contournement provisoire.

Gestion des incidents

L’ouverture d’un incident se fera dès que celui-ci est constaté par Entr'ouvert ou signalé par le Client. Entr'ouvert informera le Client de l’incident dès qu’il le constatera (dans un délai de 1h ouvrée) et établira un premier diagnostic indiquant l’impact (indisponibilité partielle ou totale des services, perte de performances…) avec une durée estimée d’indisponibilité ou de dégradation des services.
Entr'ouvert informera le Client de l’état d’avancement du traitement du problème et des mesures prises pour le résoudre.
Entr'ouvert privilégiera la messagerie électronique pour avertir le Client des incidents et des opérations de maintenance éventuelles, n'utilisant d'autres moyens qu'en cas d'urgence.
Le support est dispensé par Entr'ouvert via la plate-forme de dépôt d’incidents, par courriel ou par téléphone de 9h30 à 12h30 et de 14h à 19h, du lundi au vendredi.

Haute disponibilité, plan de continuité d’activité

L'infrastructure de l'hébergement mutualisé de Publik consiste en une série de services répartis sur 3 sites en France (Roubaix, Gravelines et Strasbourg). Les données sont répliquées en continu entre ces sites. En cas de dysfonctionnement
d'un site, la continuité du service et l'intégrité des données sont assurées.

Surveillance et contrôle des accès aux locaux

Les serveurs d'Entr'ouvert sont installés dans les data-centers, localisés en France, de la société OVH dont l'accès physique est très contrôlé (uniquement personnel OVH qualifié). La climatisation et la protection électrique sont assurés 24*7.
Une protection contre les attaques DoS et DDoS est intégrée.
Les machines disposent de disques redondés (RAID5) et les disques détectés trop âgés ou commençant à avoir des problèmes sont remplacés sans délais.
Les données de chaque client sont hébergées dans des espaces isolés, notamment dans des bases de données distinctes. Deux instances ne peuvent pas accéder au même données (codes d'accès différents). Les composants logiciels sont isolés dans des machines virtuelles (containers OpenVZ).
L'accès Internet est garanti par OVH avec un taux de disponibilité supérieur à 99,9 %. Sur le matériel comme sur l'accès réseau, OVH garantit un GTI de 1h et GTR de 4h.

Gestion des habilitations

Les comptes administrateurs des machines serveurs sont gérés de façon centralisée via un annuaire et des outils de gestion de configuration. Les connexions et les modifications sont journalisées et surveillées.

Sécurisation des données et des flux

Sauvegardes, restauration et effacement des données

Entr'ouvert gère la sauvegarde de toutes ses installations sur un système hébergé. Nous gardons des sauvegardes quotidiennes sur une période de 3 mois.
Un système d'archivage continu permet de revenir à n'importe quel instant précis de l'état des bases de données.

Confidentialité et intégrité des flux

Les connexions administratives sont réalisées exclusivement via le protocole SSH.

Contrôle et filtrage des flux

Seuls les flux de services web, de connexion postgresql et rabbitmq et de surveillance sont ouverts sur les machines Publik. Les connexions entre serveurs sont limitées à une liste restreinte de machines identifiées.

Exigences de sécurité concernant les personnels

Il n'y a chez Entr'ouvert que du personnel hautement qualifié puisque nous sommes tous pairs (nous possédons tous l'entreprise à parts égales et nous percevons tous le même salaire). Deux personnes s'occupent spécifiquement de l’administration système.

L'ensemble des coopérateurs d'Entr'ouvert sont pleinement conscients des impératifs de sécurité en tant qu'actionnaires et travailleurs au sein de l'entreprise.


Paramétrage d'un formulaire de réservation d'activité en lien avec du paiement en ligne

Pour ce tutoriel nous utiliserons une régie Factice

Paramétrage d'une régie Factice

Pour créer une nouvelle régie, rendez-vous dans le back-office dans l'onglet d'édition du portail citoyen (CMS).
Cliquez en haut à droite sur l'icône de menu
Sélectionnez "paiement en ligne".
Sur la page suivante cliquez sur l'icône "Régies"

Vous avez maintenant la possibilité de créer une nouvelle régie. Si aucune régie factice n'existe déjà, cliquez en haut à droite sur "nouvelle".

Saisissez ensuite une libellé de régie, un identifiant (l'identifiant est destiné à la création des url, il ne doit contenir ni caractères accentués, ni espaces, ni caractères spéciaux autres que "_" ou "-"), une description.
Pour le service de paiement choisissez "Factice". Pour créer une régie en lien avec un prestataire bancaire, reportez vous à la section de paramétrage des régies. [fixme lien vers section de la doc paiement]

Les options de paiements doivent être pour cette régie :

{
  "siret": "siret_num" 
}

Nous n'avons pas besoin de fournir un webservice de récupération de factures dans notre exemple.
Le montant minimum est laissé à 0.

Saisissez un texte à afficher à l'usager lors du retour, suite à la validation du paiement.

Validez, la régie est maintenant créée.

Mettre en place les éléments front office d'affichage de panier et transactions pour l'usager

Dans la partie Édition du portail citoyen, choisissez la page sur laquelle vous souhaitez exposer ces blocs.
Dans la zone choisie, ajoutez une nouvelle cellule de type panier et une cellule de type transactions récentes.

Vous pouvez en régler la visibilité suivant le besoin. Temps qu'aucun élément ne sera présent dans le panier et qu'aucune transaction n'aura eu lieu pour l'usager, ces blocs luis seront invisibles en front office.

Les étapes de paiement dans le workflow.

création du paiement

Créez un nouveau workflow paiement.
Le moment de la création du panier de l'usager dépend de vos règles de gestion, le plus simple pour l'usager est de pouvoir payer instantanément après validation du formulaire et donc le panier est créé dès cet instant, mais dans certains cas une médiation sera nécessaire avant de lui permettre de payer (pour des tarifs liés à des quotients par exemple).

Ici nous déclenchons la création des éléments de panier à la soumission du formulaire, nous créons dons le panier dans le premier statut du workflow.

Créez un statut "création du panier" et un statut "En attente de paiement".

Conseil :
Pour optimiser l'utilisation de votre workflow et le relier éventuellement à plusieurs formulaires de paiements différents, il est conseillé de créer un certains nombre de variables 
de workflows afin de rendre votre paramétrage le plus flexible possible.

Par exemple, une variable Régie vous permettra de définir une régie différente suivant le formulaire en utilisant un seul workflow.
Une variable tarif unitaire, vous permettra de définir un tarif au niveau du formulaire...

Dans le statut "création du panier" ajoutez un élément de type "Appeler un webservice". C'est lui qui nous permet de communiquer avec le module de paiement et donc de créer un panier.
Donnez lui un libellé (facultatif) et founissez lui l'url d'appel :

[portal_url]/api/lingo/add-basket-item?NameId=[form_user_name_identifier_0]&regie_id=[form_option_regie]

ici [form_option_regie] correspond à une variable de workflow, si vous préférez vous pouvez saisir ici directement l'identifiant de la régie.

Dans la zone "envoyer les données" vous devez préciser le montant du panier qui va être créé. Ce montant est envoyé dans une valeur amount.

Ce montant peut être un montant fixe lié à un tarif défini dans le formulaire, il peut également être calculé.

Montant fixe :

Montant fixe issu d'une variable de workflow :

Montant calculé à partir d'une ou plusieurs variables (par exemple achats de plusieurs activités) :

Donnez ensuite un nom de variable à cet appel. Cette variable est importante car elle nous permettra ensuite l'annulation du panier si besoin.

Nous ne détaillons pas ici toutes les options de l'appel webservice (vous pouvez gérer les erreurs comme vous le souhaitez et les afficher si besoin). Pour plus d'information rendez-vous dans la section concernée : [fixme lien vers l'action appeler un webservice]

À la suite de cette action d'appel webservice, ajoutez une action de changement de statut automatique qui pointe vers le statut en attente de paiement.

Dans le statut en attente de paiement créez une action "afficher un message" dans lequel vous pouvez expliquer à l'usager qu'il doit régler sa commande pour la valider définitivement et lui afficher un lien vers le panier (page du CMS qui contient le panier).

validation du paiement

Lors de la création d'un élément dans le panier, l'usager doit payer sa commande pour finaliser la procédure, il faut donc pouvoir faire avancer la demande dans le workflow en parallèle de la réception du paiement.

Commencez par créer un statut "paiement reçu".

Nous allons maintenant placer dans le statut "en attente de paiement" un changement de statut automatique basé sur un déclencheur.

Dans le statut "en attente de paiement", ajoutez une action "changer de statut automatiquement". Cette action pointe vers le statut paiement reçu et possède dans le champ déclencheur la valeur suivante : paid

Lorsque l'élément du panier correspondant sera payé, la demande liée basculera automatiquement dans le statut "paiement reçu".

Annulation du paiement depuis une action de workflow

Créez un statut "Annulation du panier". Dans le statut en attente de paiement créez une action de changement de statut intitulée "Annuler ma commande" qui sera affichée à l'usager et lui permettra de basculer vers le statut "Annulation du panier".

Dans le statut Annulation du panier, déclarez une action "Appeler un webservice".

L'url d'annulation d'un panier est la suivante :

[portal_url]/api/lingo/remove-basket-item?NameId=[form_user_name_identifier_0]

Il faut ensuite décocher la case "Envoyer les données du formulaire".

Et renseigner manuellement l'envoi des données :

La variable [panier_response_id] correspond à l'identifiant de création du panier renvoyé lors de l'appel webservice de création dans le statut correspondant. la racine "panier" variera donc en fonction du nommage que vous aurez choisi.

Suite à l'annulation, il est possible de prévoir l'affichage d'un message à l'usager via l'action "afficher un message".

Annulation du paiement depuis le panier

Lors de la création d'un élément dans le panier, l'usager à la possibilité de supprimer celui-ci depuis le panier, il faut donc pouvoir annuler en parallèle la demande correspondante.
Nous allons donc placer dans le statut "en attente de paiement" un changement de statut automatique basé sur un déclencheur.

Dans le statut "en attente de paiement", ajoutez une action "changer de statut automatiquement". Cette action pointe vers le statut annulation du panier et possède dans le champ déclencheur la valeur suivante : cancelled

Annuler un paiement à l'issue d'un délais

Vous pouvez également annuler un paiement à l'issue d'un délais d'inaction de l'usager (s'il n'a pas validé son panier au bout de 24 heures par exemple).

Pour cela placez dans le statut en attente de paiement une action de changement de statut automatique vers le statut "annulation du panier" en donnant un délais d'expiration, par exemple "24 heures"

L'issue de ce délai la demande sera annulée et la commande supprimée du panier.


Spécification QRCode signés

Historique

Version Auteur(s) Commentaire Date
0.1 bdauvergne cadrage 10/06/2022
0.2 mates relecture 10/06/2022

Aperçu

Cette spécification définit un encodage simplet et sécurisé d'un certificat électronique dans un QRCode. Elle est fortement inspirée du schéma européen pour les certificats sanitaires1. Les points particuliers :

1 https://github.com/ehn-dcc-development/eu-dcc-hcert-spec/blob/main/hcert_spec.md

2 https://www.rfc-editor.org/rfc/rfc8949.html

3 https://en.wikipedia.org/wiki/NaCl_%28software%29

4 https://datatracker.ietf.org/doc/draft-faltstrom-base45/

Sécurité

Le contenu des QRCodes est signé avec un algorithme de signature à clé publique basé sur les courbes elliptiques, utilisant la courbe Ed25519 et l'algorithme de la bibliothèque NaCl2 (état de l'art), protégeant l'intégrité du certificat.

Schéma des données

Exemple

En pseudo JSON :

[1, "99c6875c467e402b884ce3918ef482a7", "2022-06-10T10:00:34.34343Z", "AMP", {"immat": "AZ1234ZH", "deb": "2022-06-10", "fin": "2023-06-10"}]

Résultat après sérialisation :

print(cbor2.dumps([1, uuid.UUID('99c6875c467e402b884ce3918ef482a7').bytes, datetime.datetime.utcnow(), 'AMP', {'immat': 'AZ1234ZH', 'deb': datetime.date(2022, 6, 10), 'fin': datetime.date(2023, 6, 10)}], timezone=datetime.timezone.utc, datetime_as_timestamp=True, date_as_datetime=True))
b'\x85\x01P\x99\xc6\x87\\F~@+\x88L\xe3\x91\x8e\xf4\x82\xa7\xc1\xfbA\xd8\xa8\xcb_\x8a\xc5\xfccAMP\xa3eimmathAZ1234ZHcdeb\xc1\x1ab\xa2\x89\x80cfin\xc1\x1ad\x83\xbd\x00'

Contenu:

Signature électronique

Se référer à une implémentation quelconque du schéma de signature à clé publique de NaCl, comme libsodium.

Initialement, la paire (une secrète, une publique) de clés de l'émetteur est générée via crypto_sign_keypair() et stockée. La clé publique est diffusée et configurée dans le lecteur de QRCode.

L'encodage CBOR est ensuite signé avec la fonction crypto_sign() par la clé privée de l'émetteur.

Pour la lecture, le contenu signé est vérifié via crypto_sign_open() et la clé publique de l'émetteur.

Encodage en Base45

L'encodage Base45 convertit une chaîne d'octets libre en une chaîne limitée à l'alphabet 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ·$%*+-./: (donc plus longue). C'est un encodage analogue à Base64 mais adapté au fonctionnement des QRCodes.

Encodage dans le QRCode

Inspiré du paragraphe équivalent dans la spécification hcert5.

In order to better handle legacy equipment designed to operate on ASCII payloads, the compressed CWT is encoded as ASCII using Base45 before being encoded into a 2D barcode.

The QR format as defined in (ISO/IEC 18004:2015) SHALL be used for 2D barcode generation. An error correction rate of ‘Q’ (around 25%) is RECOMMENDED. The Alphanumeric (Mode 2/QR Code symbols 0010) MUST be used in conjunction with Base45.

In order for Verifiers to be able to detect the type of data encoded and to select the proper decoding and processing scheme, the base45 encoded data (as per this specification) SHALL be prefixed by the Context Identifier string "HC1:". Future versions of this specification that impact backwards-compatibilty SHALL define a new Context Identifier, whereas the character following "HC" SHALL be taken from the character set [1-9A-Z]. The order of increments is defined to be in that order, i.e., first [1-9] and then [A-Z].

Ici l'encodage sera Base45, préfixé de la chaîne EO0:@.

5 https://github.com/ehn-dcc-development/eu-dcc-hcert-spec/blob/main/hcert_spec.md#422-qr-2d-barcode


Raccordement avec un portail métier (SSO)

Objectif de cette note : rappeler à l'éditeur d'un portail métier les standards SSO et plus précisément les impératifs pour se raccorder à un portail Publik. Ce texte pourra être inclus avec profit par les collectivités directement dans leur CCTP afin qu'il s'impose à l'éditeur métier.
Entr'ouvert ne fournit pas de base d'assistance à l'intégration ou à la spécification fonctionnelle d'un SSO. Si souhaité, cette assistance nécessitera un contrat de prestation auprès de la collectivité ou de l'éditeur/intégrateur du portail de l'éditeur métier.

Les fonctionnalités prévus lors d'un raccordement métier seront :

Authentification unique

Publik propose un seul mode de raccordement via le protocole OpenID Connect (OIDC), les spécifications à respecter sont :

Les spécifications désignées DOIVENT être respectées à la lettre, le nommage des attributs ("claim") et des scopes peut, par contre, être adapté.

Des implémentations de référence du protocole OpenID Connect pour différents langages et cadriciels sont disponibles sur https://openid.net/developers/libraries/

Le portail métier et ses éventuels web-services DOIVENT absolument être diffusés via le protocole HTTPS://.

Une authentification réussie fournit au portail un pseudonyme opaque appelé "sub" dans le jargon OpenID Connect, c'est une chaîne UTF-8 qui devra être conservé dans le schéma de donnée du portail et lié au compte du portail métier. La relation entre ce pseudonyme et les comptes du portail métier pourra être : Ce choix dépendra des usages et de la possibilité pour l'éditeur du portail de gérer les parcours de connexion nécessaire avec par exemple : La processus de raccordement à des comptes existants (nommé aussi appairage), ou de création d'un nouveau compte suite à une authentification unique (SSO) réussie, relève de la seule responsabilité du portail métier mais on notera les cas suivants :

Pré-requis

L'intégrateur du portail métier devra fournir à un administrateur de la plateforme Publik les informations suivantes :

Attention : si les URLs de redirection ont des domaines différents et l'UUID n'est pas utilisé comme identifiant, penser à définir une URL de secteur.

L'administrateur de la plateforme Publik transmettra à l'intégrateur du portail métier :

Toutes les opérations de connexion ou déconnexion se font via des appels au fournisseur d'identité de la plateforme Publik de la collectivité, on désignera son URL par IDP_URL.

Description technique non-exhaustive de l'authentification unique

Une authentification unique débutera comme suit :
1. déclenchement de l'authentification sur le portail (appui sur un bouton, appel à une URL particulière, protection de toutes les pages du portail, c'est un point d'implémentation qui relève de l'éditeur du portail métier)

2. redirection du navigateur de l'utilisateur sur l'URL d'autorisation OpenID Connect du fournisseur d'identité de la plateforme Publik:
IDP_URL/idp/oidc/authorize/?client_id=...&...&redirect_uri=...&state=...&...

3. le fournisseur d'identité de la plateforme Publik procède à l'authentification de l'usager, s'il n'est pas déjà authentifié, puis s'il n'a pas encore donné son autorisation lui présente un formulaire lui demandant de confirmer sa volonté de s'authentifier auprès du portail en fournissant un certain nombre d'attributs.

4. le fournisseur d'identité Publik redirige le navigateur de l'utilisateur sur l'URL de retour (ou de callback) déclaré par le portail métier par exemple,

https://portail-metier.collectivite.fr/oidc/callback/?code=xxx&state=yyy

5. le portail métier à la réception de cette requête doit :
5.1. éventuellement utiliser le paramètre state pour retrouver un état conservé (URL de retour sur le portail, identifiant métier de la personne demandé préalablement, jeton transmis par mail ou SMS permettant l'appairage, etc...) en session
5.2. appeler le web-service token (IDP_URL/ipd/oidc/token/) du fournisseur d'identité en s'authentifiant avec son client_id et son client_secret (fourni lui aussi par l'administrateur de la plateforme Publik) permettant d'échanger code contre un access_token ; l'access token est un jeton qui permettra d'appeler le web-service fournissant les informations sur l'utilisateur. Le web-service token fournit aussi le sub ou identifiant unique de l'utilisateur, c'est cet identifiant qui sert de clé à la liaison entre Publik et le portail-métier. Enfin, le web-service token fournit deux valeurs iss (identifiant de l'émetteur) et sid (identifiant de la session) qui doivent être enregistrés dans la session créée sur le portail métier, en vue d'assurer la mécanique de déconnexion (voir plus bas).

5.3. appeler le web-service user-info (IDP_URL/idp/oidc/user_info/) pour obtenir les attributs de l'utilisateur qui lui sont autorisés.

5.4. déterminer si le sub est connu

Description technique non-exhaustive de la déconnexion unique

La déconnexion pourra avoir lieu :

SLO initié par Publik (Frontchannel Logout)

Voir http://openid.net/specs/openid-connect-frontchannel-1_0.html#RPLogout

La plateforme Publik procédera à une re-direction sur l'URL frontchannel_logout_uri via une iframe invisible, le portail métier devra procéder à la déconnexion de la session en cours sur toute requête à cette URL et faire en sorte qu'elle ne puisse jamais être mise en cache par le navigateur.

Deux paramètres sont envoyés dans la query-string de l'URL frontchannel_logout_uri : iss et sid. Ce sont ceux qui ont été reçus lors de l'appel au web-service token au début de la création de la session (voir plus haut). Ces deux paramètres permettent de retrouver la session en jeu sur le portail métier, et de la détruire afin d'assurer la déconnexion.

Note : il convient de régler les entêtes de sécurité de l'URL pour que celle-ci soit utilisable dans une iframe. Notamment il ne faut pas renvoyer d'entête de restriction X-Frame-Options, ni de limitation via Content-Security-Policy.

SLO inité par le portail métier (RP initiated Logout)

Voir https://openid.net/specs/openid-connect-rpinitiated-1_0.html

Le portail-métier devra rediriger le navigateur de l'utilisateur sur l'URL IDP_URL/idp/oidc/logout/, il pourra passer une URL de retour via le paramètre post_logout_redirect_uri. Cette URL devra être préalablement déclarée auprès de l'administrateur Publik.

Remontée d'information

Publik propose un point d'entrée unique pour la gestion de la relation usager, à ce titre il est important que Publik puisse centraliser toutes les informations importantes des portails métiers tiers. Pour cela nous proposons la possibilité d'appeler des web-services portés par les portails métiers en vue d'afficher des informations dans les pages du portail citoyen de Publik.

Pré-requis

Affichage de demandes en cours dans le portail-métier

Publik étant spécialisé dans la mise en place de télé-services, il y a un formalisme particulier à adopter pour faire remonter des demandes dans le portail Publik.

Ce téléservice devra répondre sur un GET et prendre en entrée le sub comme paramètre de l'URL (le chemin de l'URL n'est pas imposé). La réponse devra avoir la forme exacte suivante :

GET /api/demandes/?sub=xxx

{
  "err": 0,
  "data": [
     {
        "datetime": "2018-03-04 12:34:32",
        "name": "Demande de carte de stationnement",
        "status": "En attente d'information",
        "form_number": "1234",
        "form_status_is_endpoint": false,
        "url": "https://portail-metier/demandes/1234/",
        "draft": false
     }
  ]
}
Champ Type Obligatoire Description
datetime string, la date au format ISO8601 YYYY-MM-DD HH:MM:SS Oui la date de création de la demande
name string Oui le nom du type de demande
form_number string Oui l'identifiant de la demande (numéro ou autre)
url string Oui lien profond vers la demande, si une URL par demande n'est pas disponible le portail métier peut se contenter de renvoyer l'URL d'une page affichant toutes les demandes en cours
status string Oui le statut actuel de la demande, "Nouvelle", "En cours", "En attente d'information", à définir par le portail mais la chaîne doit être présentable directement à l'usager, ce ne doit pas être un code
form_status_is_endpoint booléen Non vrai si le statut de la demande indique qu'elle est terminée
draft booléen Non vrai si la demande est un brouillon

Affichage des factures en cours venant du portail-métier

Publik contient nativement un système de remontée et paiement de factures, pour permettre une intégration des factures exposées par un portail métier tiers, il y a là aussi un formalisme particulier à respecter.

Le portail métier DOIT fournir un web-services porté par une URL de base que nous nommerons BASE_URL, de la forme BASE_URL/invoices/, le dernier élément du chemin est obligatoire.

Ce téléservice devra répondre sur un GET et prendre en entrée le sub comme paramètre de l'URL (le chemin de l'URL n'est pas imposé). La réponse devra avoir la forme exacte suivante :

GET /api/invoices/?sub=xxx

{
   "err": 0,
   "data": [
              {
            "id": "939456",
            "label": "restauration août 2015",
            "amount": "37.26",
            "total_amount": "37.26",
            "created": "2015-08-01",
            "pay_limit_date": "2015-09-29",
            "paid": false,
            "no_online_payment_reason": "litigation",
            "payment_url": "https://portail-metier/factures/934395/pay/",
            "pdf_url": "https//portail-metier/factures/934395/pdf/F20180192.pdf",
             ... (autres informations si le logiciel backend en donne) 
        },
   ]
}
Champ Type Obligatoire Description
id string, libre Oui identifiant interne au portail métier de la facture, uniquement pour debug
amount string, décimal Oui montant du reste à payer, nombre décimal formaté avec un point décimal et non une virgule décimale (à l'anglaise)
total_amount string, décimal Oui montant total de la facture, format identique à amount
created string, date ISO Oui date de création de la facture, format ISO8601 YYYY-MM-DD
pay_limit_date string, date ISO Oui date limite de paiement de la facture, date exlue (i.e. à partir de cette date le paiement n'est plus possible), format ISO8601 YYYY-MM-DD
payment_url string, URL Non l'URL pour payer la facture si celle-ci est payable en ligne
pdf_url string, URL Non l'URL vers le PDF de la facture si celle-ci est téléchargeable
non_online_payment_reason sttring, enum Non si payment_url est absent, la raison éventuelle de la non-possibilité de paiement en ligne (contestation, prélèvement, délai dépassé), voir plus loin les valeurs possibles
Les valeurs actuellement possibles pour no_online_payement_reason sont :
Valeur Description
litigation la facture pose un problème
autobilling la facture est payée par prélèvement automatique
past_due_date il n'est plus possible de payer cette facture en ligne car un délai est dépassé

Remontée d'autres informations1

Pour tout autre type d'information nous imposons le formalisme générique suivant, en plus des pré-requis donnés plus haut : Ce web-service retournera une description du formatage attendu pour ces donnés selon le formalisme suivant :
Type Description
block un bloc composé d'autres éléments, permet de grouper
text un paragraphe, peut contenir un texte simple, pré-formaté ou formaté en HTML, en utilisant uniquement les balises autorisés dans un noeud <p> du HTML (balises inline, <em/>, <i/>, <b/>), ainsi qu'un lien d'édition (pictogramme stylo dans le coin haut-droit du contenu)
table un tableau, contenant des lignes qui contiennent soit des entête header soit des cellules de contenu text
Tous les types acceptent les attributs suivants :

Exemple de présentation d'un profil famille venant d'un portail famille :

{
  "err": 0,
  "data": {
     "type": "block",
     "label": "Ma famille",
     "edit_url": "https://portail-famille/ma-famille/edit/",
     "content": [
         {
            "type": "text",
            "id": "adresse",
            "label": "Adresse",
            "pre": true,
            "content": "1 rue du calvaire\nXX100 MAVILLE" 
         },
         {
            "type": "text",
            "id": "parent1",
            "class": "parent",
            "label": "Premier parent",
            "html": true,
            "content": "Jean-Michel <b>DUPOND</b>, né le 12 décembre 1964 à Marseille",
         },
         {
            "type": "text",
            "id": "parent2",
            "class": "parent",
            "label": "Second parent",
            "html": true,
            "content": "Régine <b>DUPOND</b>, né MARTIN le 12 décembre 1964 à Lyon" 
         }
         {
            "type": "block",
            "label": "Enfants",
            "content": [
               {
                  "type": "text",
                  "content": "Kévin DUPOND, 5 ans, né le 22 mars 2013",
               }
            ]
         }
      ]
   }
}

Le but de ce formalisme est de laisser à la fois un peu de liberté au portail métier sur les contenus et aussi la liberté pour Publik d'appliquer des feuilles de style aux contenus.

Coté Publik, ces contenus seront présentés via des cellules JSON (cellule associant un web-service JSON avec un template).

1 technologie équivalente https://github.com/portabletext/portabletext

Dépôt d'une demande

Voir https://doc-publik.entrouvert.com/dev/echanges-logiciel-de-demandes-metier/ en sachant que l'information « sub » peut être envoyée dans la demande si elle doit être reliée à un compte dans le logiciel cible.


Roadmap Publik

La roadmap présente les évolutions, en cours ou souhaitées, des différentes briques Publik. Elle est susceptible de varier fortement en fonction des développements financés ou non par les utilisateurs de Publik et les clients d'Entr'ouvert.

2022, 2021

2020

Numéro Sujet Date de fermeture
#37529 Action globale : Permettre une saisie de texte lors du déclenchement d'une action globale Ouvert
#27429 Permettre les champs lecture seule / caché / etc. 2020
#37539 Modification de l'action de notification pour intégrer mails et SMS ré-orienté
#37535 Étendre les actions de masse aux sauts manuels 04 juil. 2020 08:29
#27450 Gestion de template de message dans w.c.s. (gestion de modèle de mail...) : financé 17 avr. 2020 15:56
#19754 Possibilité pour les agents de sauvegarder des vues personnalisées 17 avr. 2020 15:55
#37534 Améliorer les champs listes utilisés comme critère de recherche 21 jan. 2020 20:35
#37538 Ajouter des options de personnalisation à l'intégration graphique native Ouvert
#27471 Gestion des intégrations graphiques via le paramétrage d'options de mise en page et de design Ouvert
#32249 Paiements sans voir le panier 21 jan. 2020 20:31
#37540 Amélioration de l'ergonomie de la connexion FranceConnect Ouvert
#26907 Cycle de vie des comptes Ouvert
#19856 Cellules JSON : système de rayonnement de passerelle vers combo Ouvert
#37542 Création d'un nouveau type d'agenda : agenda virtuel 28 mar. 2020 19:37
#37536 Étendre le modèle événement dans Chrono 21 jan. 2020 20:33
#27455 Mettre en place des indicateurs stats liés à Chrono 2021
#19745 Création de rapports automatiques pour l'année en cours et les 3 derniers mois. Ouvert
#19742 Statistiques sur les comptes et les connexions 2021
#27448 Donner la possibilité de filtrer les résultats dans Combo au moment du rendu graphique Ouvert
#27452 Intégrer des options de tri des résultats dans la construction de l'indicateur 18 sept. 2020 11:37
#37531 Cellules concernant les fiches 2020
#37527 Lier des utilisateurs à des fiches 2020
#37528 Développer des actions de workflow pour la gestion des fiches (ajouter / modifier / supprimer) 04 juil. 2020 08:29
#37530 Moteur de recherche sur un modèle de fiche 20 juin 2020 16:39
#37532 Vues personnalisées sur les demandes et sur les fiches 17 avr. 2020 17:39
#37533 Importer un CSV dans un modèle de fiche 18 fév. 2020 14:18

Saga

SAGA est un logiciel de gestion de régie édité par FuturSystem.

Documentation des interfaces

Voir fichiers attachés plus bas.


Connexion avec un SIG (système d'information géographique)

Publik permet de se connecter à un SIG pour divers usages :

Systèmes par défaut

Pour faire ces opérations, Publik peut se connecter à des système génériques qui couvrent le territoire français.

Tuiles pour affichage des cartes

Publik peut utiliser tout système un système compatible avec Leaflet https://fr.wikipedia.org/wiki/Leaflet

Toutes les cartes s'affichent avec le même serveur de tuiles.

Géocodage & géocodage inverse

Publik peut utiliser tout système compatible avec le format de l'API Nominatim https://wiki.openstreetmap.org/wiki/Nominatim, ou l'API de la BAN (https://adresse.data.gouv.fr/api)

Sectorisation

Pour les sectorisations, il faut étudier selon le cas et le "métier" cible : on ne gère pas de la même façon une sectorisation qui doit être très précise (telle que les secteurs scolaires) ou juste à des fins de statistiques (en vue de connaître le nombre de demandes par quartier).

Quelques cas possibles :

Dans les autres cas, il faut étudier comment Publik peut interroger le système cible (SIG ou base adresse locale) et, si nécessaire, créer un connecteur (https://doc-publik.entrouvert.com/tech/connecteurs/)

Normaliser ou valider adresse

L'utilisation du système de géocodage peut permettre de normaliser une adresse, par interrogation du géocodage puis du géocodage inverse.

Pour la validation d'adresse, il faut un webservice capable de répondre "ok" ou "ko". Un passage par le système de géocodage est éventuellement utilisable, qui doit alors répondre un score au dessus d'un certain seuil. Il est aussi possible, en amont, d'imposer une adresse valide lors de la saisie, en bloquant les choix possibles — cependant ce n'est pas recommandé sauf si les sources des listes (villes, rues, numéros dans les rues) sont connues pour être totalement à jour.

Si des webservices spécifiques de normalisation/validation existent dans le SIG ou la base adresse locale, il faut étudier comment Publik peut les interroger et créer un connecteur le cas échéant (https://doc-publik.entrouvert.com/tech/connecteurs/)


Signature-Bash

#!/bin/bash

# origine de la requête (~ identifiant)
orig="foobar" 
# clé à utiliser pour la requête (~ mot de passe)
key="XXX" 

# cmd arg, example "https://demarches.example.net/api/formdefs/" 
url=$1

qs=$(echo $url | cut -d? -f2)
url=$(echo $url | cut -d? -f1)

function rawurlencode() {
  local string="${1}" 
  local strlen=${#string}
  local encoded="" 
  local pos c o 

  for (( pos=0 ; pos<strlen ; pos++ )); do
     c=${string:$pos:1}
     case "$c" in
        [-_.~a-zA-Z0-9] ) o="${c}" ;;
        * )               printf -v o '%%%02x' "'$c" 
     esac
     encoded+="${o}" 
  done
  echo "${encoded}"    # You can either set a return variable (FASTER).
  REPLY="${encoded}"   #+or echo the result (EASIER)... or both... :p
}
d=$(date -u +%FT%TZ);

sig=$(rawurlencode $(echo -n "$qs&algo=sha256&timestamp=$d&orig=$orig" | openssl dgst -binary -sha256 -hmac $key | base64))

url="${url}?$qs&algo=sha256&timestamp=$d&orig=$orig&signature=$sig" 
echo "URL: $url" 


Simplifier Publik

On a ajouté pas mal de choses dans l'interface des différentes briques depuis 2 ou 3 ans, trop. Réfléchir à ce qu'on peut enlever est plus important que réfléchir à ce qu'on peut ajouter (pour avoir une application robuste, facile à comprendre, facile à maintenir, sur laquelle il ne devient pas impossible de faire du support).

Une partie de ces complexités, mais une partie seulement, vient de Publik Famille (une série de trucs dans chrono ou encore les cellules concernant les fiches). Il est logique que sur un projet émergent et pas généricisé on tâtonne, on produise des choses qui devront mûrir. Il est logique aussi qu'on accorde parfois trop d'importance aux demandes de l'unique client (parce qu'on ne peut pas les relativiser et les mettre en perspective avec les demandes contradictoires d'autres clients). Génériciser/simplifier le Publik Famille Vénissieux sera un gros travail sur lequel je compte m'investir si Stef veut bien de moi.

Mais je laisse Publik famille de côté ici pour me focaliser sur le reste :

L'idée c'est de débattre ici de l'ampleur des pertes de fonctionnalités induites avant d'entamer un éventuel dialogue avec les devs.

L'objectif de ce débat c'est aussi que chacun s'oblige à discuter collectivement et à pointer explicitement les choses dont elle/il demande qu'elles soient ajoutées dans l'interface AVANT qu'elles le soient.

J'ai pour l'instant identifié 3 "endroits" qui me semblent être les plus consommateurs de temps administrateur fonctionnel :

Les types de champs

On a trop de types de champs et une liste mal fichue.

Les actions de WF

Il y a trop d'actions. On va pouvoir en diminuer significativement le nombre quitte à avoir parfois des actions un peu plus complexes. Il faut toutefois veiller à ne pas complexifier la compréhension du schéma avec des actions trop fourre-tout.

Modif la plus importante : virer les actions commentaire, fichier et saut à la soumission

C'est assez complexe à faire mais c'est aussi un sacré gain. Ça passe par :

Autres modifications

Les cellules

On a un peu trop de cellules, classées un peu n'importe comment dans la liste.

Supprimer des cellules

Réorganiser la liste des cellules


Statistiques (Cubes / obsolète)

3 cellules combo sont utilisés:

Diagramme bâton

Tableau

La configuration est identique à celle des diagrammes bâtons, seulement le premier axe d'analyser est affiché en première colonne et le second axe d'analyse en première ligne, donnant un tableau croisé si les deux sont utilisés en même temps.

Paramètres

Ils permettent d'indiquer une liste de filtrages selon une syntaxe un peu différente du champ « Paramètres additionnels » mais avec en plus la possibilité de laisser l'utilisateur choisir ses filtres, d'en combiner plusieurs et de restreindre certains filtres à des groupes d'utilisateurs.


Support et infogérance

(contenu récupéré de https://doc-publik.entrouvert.com/guide-de-l-administrateur-systeme/exploitation/support/)

Support

Les moyens de contact pour le support sont :

Infogérance

Périmètre de la maintenance

Lors d'une installation auto-hébergée (ou on-premise) voici le périmètre habituel de la maintenance :

Sont exclus du cadre de la maintenance :

Pré-requis

Le maintien en conditions opérationnelles à distance par Entr'ouvert requiert :


Connexion de Publik à un système téléphonique

Publik est capable d'afficher à un agent (sur le portail agent) la fiche de l'usager qu'il a en ligne.

Configuration de Publik

Pour cela :

C'est ce remplissage automatique de la cellule recherche avec le numéro de téléphone de l'interlocuteur qui va déclencher la remontée des informations de Publik concernant ce numéro : les utilisateurs mais aussi les demandes en cours où ce numéro est présent (en fait, tout élément de Publik sur lequel la recherche s'effectue).

À noter que pour que la recherche d'utilisateur fonctionne efficacement, les numéros de téléphone dans les profils doivent suivre le même format que celui utilisé par le système téléphonique (souvent 10 chiffres, 0123456789)

Connexion technique

Le système téléphonique doit informer Publik lorsqu'un agent décroche et raccroche son téléphone. Pour chacun de ses deux événements, le système indique à Publik le numéro de l'appelant (la personne qui appelle la collectivité) ainsi que le numéro de l'appelé (en général, le numéro de poste interne de l'agent).

L'information est envoyée via des "appels webservice", en HTTPS, par des requêtes GET sur des URLs du système Publik, en fournissant en argument les numéros appelant et appelé.

Lorsque l'agent décroche son téléphone, une requête GET doit être envoyée par le système téléphonie sur :

https://passerelle.publik.ville.fr/phonecalls/ipbx/call-start?caller=0143250135&callee=42&apikey=abcdef
où :

Lorsque l'agent raccroche, la même requête sera envoyée en remplaçant "call-start" par "call-stop", c'est-à-dire :

https://passerelle.publik.ville.fr/phonecalls/ipbx/call-stop?caller=0143350135&callee=42&apikey=abcdef

Note : en réponse à ces requêtes, Publik renvoie un HTTP 200 (OK), contenant un dictionnaire JSON avec un champ "err" à 0 (pas d'erreur) et un rappel des données reçue dans "data". Mais il n'est pas demandé que le système téléphonique interprète le contenu de la réponse envoyée par Publik ; il peut juste être utile d'alerter si le code de retour n'est pas 200 (panne de Publik ou erreur de configuration de la connexion).


Tests fonctionnels

Les tests qu'il faudrait dérouler sur les briques publik sur le serveur de recette "démo" et éventuellement pouvoir dérouler sur n'importe quel site de prod via un paramétrage

Authentification

Tests avancés


TIPI et Publik

On se référera à TIPI (page du Wiki du projet eopayment, eopayment étant la librairie utilisé par Publik pour gérer les paiements).

En l'état actuel des choses Publik peut proposer :

Votre installation de Publik sera composé de plusieurs modules, et chacun doit avoir un nom de sous-domaine, sur un domaine commun et unique, pour que l'ensemble puisse fonctionner.

Il vous revient donc donc choisir un domaine commun, comme par exemple :

Si nous prenons l'exemple de guichet.grandlyon.com, nous aurons donc la structure suivante : yyyyy.xxxxx.com

Note interne : en premier il faut proposer de faire une délégation de zone, qu'au niveau du DNS yyyyy.xxxxx.com soit géré par Entr'ouvert. (éléments techniques sur le sujet à rédiger)

Sous-domaines pour la partie production

Pour fonctionner, Publik a besoin de sous-domaines complémentaire à cette structure de base.
Ces sous-domaines qui devront être couverts par un certificat couvrant *.yyyy.xxxxx.com.

Voici les sous-domaines à créer :

et également ces sous-domaines internes, invisibles pour le citoyen :

En fonction des modules déployés sur Publik, d'autres sous-domaines devront éventuellement être créés.

Sous-domaines pour la partie recette

Il est préférable que les sous-domaines utilisés en recette soit cohérents avec ceux utilisés pour la partie production.

Nous proposons de mettre en place, dès le début du projet, d'utiliser le même sous-domaine en rajoutant -test sur le préfixe.

Pour la recette, nous aurons donc besoin des sous-domaines suivants. Ces sous-domaines doivent également être couverts par le certificat.

Certificat

Tous les modules Publik dialoguent via des connexions chiffrées, il est donc nécessaire que vous disposiez de certificats pour la recette et pour la production, ceux-ci peuvent être des certificats
"wildcard" couvrant un domaine et ses sous-domaines (cf plus haut).
Si souhaité de votre part, il est possible, pour la recette, d'utiliser notre certificat qui couvre la zone "test.entrouvert.org" avec des URL alors à définir pour la recette.


Ces usagers institutionnels peuvent être qualifiés par deux moyens complémentaires : Problèmes identifiés :

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 :

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 : 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 :

~~

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:

Ç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:

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)


Utilisation des plates-formes de test et de production

L'utilisation d'une plate-forme de test est intéressante pour pouvoir évaluer le bon fonctionnement des formulaires et des workflows avant le passage en production. Toutefois, il ne faut pas chercher à faire de la plate-forme de test une réplique exacte de la plate-forme de production, cela générerait plus de contraintes que de bénéfices.

Pouvoir distinguer facilement les deux plates-formes

Dans l'interface d'administration, il est possible d'ajouter une variable environment_label qui va modifier l'apparence du front office et du backoffice, permettant ainsi de distinguer sans ambiguïté la plate-forme de test :

Modification en Front-office
Bandeau test front office

Modification en Backoffice

Mise en production d'une modification

La façon normale de procéder à la mise en production d'une modification sur un formulaire ou un workflow est de la tester sur la plate-forme de test dans un premier temps. Une fois que les tests sont concluants, la mise en production peut alors être envisagée.
La mise en production peut consister dans le fait de :

Formulaires

Si vous vous contentez d'importer un formulaire sur la plate-forme de production, même s'il a le même nom qu'un formulaire existant, il ne viendra pas prendre automatiquement la place de ce dernier, il va venir se créer à côté. Pour remplacer le formulaire existant en production par celui que vous avez exporté depuis la plate-forme de test, il faut se mettre sur la page d'accueil du formulaire à écraser et sélectionner dans la colonne de droite "Écraser avec un nouvel import". Vous sélectionnez alors votre fichier et le formulaire viendra prendre la place de l'ancien et sera bien lié à toutes les demandes déjà saisies.

ATTENTION : Si vous avez supprimé des champs dans le nouveau formulaire par rapport à l'ancien les informations contenues dans ce champs ne seront plus disponibles, pour les demandes faite avant ce changement, même si elle sont en cours de traitement. Si par exemple, vous souhaitiez supprimer un champ "adresse" pour le remplacer par "voie" et "numéro", choisissez plutôt de renommer l'ancien champ adresse en "voie" et de créer "numéro" (cela permettra de conserver les données d'adresse pour les demandes précédant le changement).

Workflows

Lorsque vous importez un nouveau workflow sur la plate-forme de production, même s'il a le même nom qu'un formulaire existant, il ne viendra pas prendre automatiquement la place de ce dernier, il va venir se créer à côté. Il faudra donc associer votre formulaire à ce workflow nouvellement créé pour que le changement soit effectif.

ATTENTION : lorsque vous associerez le formulaire au nouveau workflow un écran vous demandera d'associer les anciens et les nouveaux statuts. Si vous n'avez fait aucune suppression de statut entre l'ancien et le nouveau workflow, vous pouvez valider sans rien modifier. Si vous avez supprimé un ou plusieurs statuts, il vous faut indiquer dans quel statut le système doit positionner les demandes se trouvant éventuellement dans un des statuts supprimés.


Ajout du verif_orig dans settings.KNOWN_SERVICES

Mise en place du nouveau système de signature, basé sur #8580

On a un settings.KNOWN_SERVICES ainsi formaté :

# sur espace-usager.example.net, le settings_loaders.KnownServices génère cela :

settings.KNOWN_SERVICES = {

  "wcs": { 
    "wcs": {
      "url": "https://demarches.example.net/", 
      "orig": "espace-usager.example.net" 
      "verif_orig": "demarches.example.net", 
      "secret": "452b896499d919671d1369c159d844bc4344d1aee25c4ea5724944322e6eaebe",
           # à utiliser pour signer une URL vers https://demarches.example.net/
           # à utiliser pour vérifier une URL signée par orig=demarches.example.net
      "title": "Démarches en ligne", 
      "backoffice-menu-url": "https://demarches.example.net/backoffice/menu.json", 
      "variables": {}, 
    }
  },

  "combo": {
    "portail-agent": {
      "url": "https://portail-agent.example.net/", 
      "orig": "espace-usager.example.net" 
      "verif_orig": "portail-agent.example.net", 
      "secret": "dadd71c5f9a7c0669240844a0452ce8bbbeadc4be1f27ddc75dcf76eb6279348", 
           # à utiliser pour signer une URL vers https://portail-agent.example.net/
           # à utiliser pour vérifier une URL signée par orig=portail-agent.example.net
      "title": "Portail agent", 
      "backoffice-menu-url": "https://portail-agent.example.net/manage/menu.json", 
      "variables": {}, 
    }, 
    "espace-usager": {
      "url": "https://espace-usager.example.net/", 
      "orig": "espace-usager.example.net" 
      "verif_orig": "espace-usager.example.net", 
      # c'est le service local : pas de secret nécessaire
      "title": "Espace Usager", 
      "backoffice-menu-url": "https://espace-usager-alfortville.dev.entrouvert.org/manage/menu.json", 
      "variables": {}, 
    }
  }, 

  # les autres services

}

Sur wcs on a seulement les équivalents de verif_orig :

# extrait de demarches.example.net/site-options.cfg 

[api-secrets]
# utilisé par wcs pour vérifier une URL signée avec orig=espace-usager.example.net
espace-usager.example.net = 452b896499d919671d1369c159d844bc4344d1aee25c4ea5724944322e6eaebe

Tests après migration vers le nouveau code

Opérations à faire lors de l'installation du nouveau code (sur recette & prod)

Passerelle

Vérifier que les nouvelles clés sont bien visibles dans https://passerelle.example.net/manage/access/

w.c.s.

Vérifier que les nouvelles clés sont bien visibles dans /var/lib/wcs-au-quotidien/demarches.example.net/site-options.cfg

Il faut aussi regarder les wscall, si certains ont été configurés avec de la signature en utilisant les anciennes clés (typiquement vers passerelle). Inventaire à faire.

Inventaire des request_signature_key dans les workflows à modifier, éventuellement.

Recette : Prod :

Combo

Changement des clés FAMILY_SERVICE/signature_key dans les settings.json : prendre la clé de signature du combo visible dans passerelle (clé dupliquée)

Combo/Lingo

Changer les clés LINGO dans les settings.json :

Plus tard


Wiki

Club utilisateurs

Présentation sous forme d'une charte du Club utilisateurs
Le guide d'organisation du club est disponible sur https://dev.entrouvert.org/projects/commercial/wiki/Guide_pour_organisation_Club

Les éditions du club utilisateurs sont les suivantes :

Road-map(s)

Documentation

Laïus standards

Autre

Ressources

Analyses

Divers

Obsolète