Jeux de données périmés - réflexions sur les notifications

[ChristinaLaumond]

Hello,

Suite à une discussion avec @thbar sur les emails envoyés par le PAN en automatique nous avons réfléchi en particulier aux alertes envoyés sur les jeux de données arrivant à expiration.

Aujourd'hui :

- Mail envoyé à l'équipe : le PAN envoie un mail récapitulant les GTFS arrivant à expiration à différentes échéances : demain, +7j, +14j (et peut-être +30j ?)

Il serait peut-être intéressant d'ajouter à ce mail la liste des jeux de données déjà périmés (tous ou uniquement ceux qui sont périmés depuis moins de 2 mois par exemple).

Autre solution -> au lieu d'un envoi par email, avoir une notification quotidienne sur mattermost indiquant les jdd périmés.

- Mail envoyé aux producteurs Il semblerait qu'ils ne reçoivent qu'un mail leur indiquant la péremption à l'échéance qu'ils ont configurée. S'ils n'ont rien configuré, ils ne reçoivent rien. On pourrait envoyer un ou deux mails supplémentaires au moment de l'expiration du jeu de données -> le jour de l'expiration, 1 mois après l'expiration si c'est toujours le cas.

Un point de vigilance : les jdd périmés mais dont la péremption est normale -> transport saisonnier par exemple ou funiculaire en panne (donc pas de données à jours). L'idée serait de pouvoir temporairement "désactiver" ce jdd pour ne pas qu'il apparaisse dans les notifications.

Pour en reparler avec @Miryad3108

[AntoineAugusti]

Il semblerait qu'ils ne reçoivent qu'un mail leur indiquant la péremption à l'échéance qu'ils ont configurée. S'ils n'ont rien configuré, ils ne reçoivent rien.

La configuration des notifications est pour le moment réalisée à la main, c'est quelqu'un qui doit faire une association slug de jeu de données/liste de contact https://github.com/etalab/transport-notifications.

Ça a donc plusieurs limitations :

• peut ne pas être à jour en cas de renommages/ajouts/suppressions
• demande une veille
• demande une action manuelle de notre équipe

à noter que plusieurs producteurs sont déjà autonomes et disposent d'outils proposant des fonctionnalités similaires. Des réutilisateurs, en particulier calculateurs d'itinéraires font aussi des relances par des canaux privés ou par le biais de commentaires sur le PAN.

Pour les GTFS saisonniers il y a moyen de gérer ça dans le GTFS, mais il faut que les producteurs jouent le jeu https://github.com/etalab/transport-site/issues/2336

[AntoineAugusti]

Pour les mails à l'équipe, je me demande s'il serait utile de savoir qu'un rappel a été envoyé aux gestionnaires (AOM/transporteur).

[Miryad3108]

1/ Pour les mails à l'équipe je pense que ça serait effectivement intéressant de savoir quand un rappel a été fait, pour qu'on puisse relancer également de notre côté au moins à J-1, voire appeler quand c'est une AOM avec laquelle on échange souvent.

2/ Pour les JDD déjà périmés, je trouve que les informations fournies dans le backoffice suffisent mais si tu ne trouves pas ça suffisant @ChristinaLaumond, ça pourrait être ajouté oui.

3/ Pour la configuration des notifications , ces limitations présentent également des avantages :

• il y a un message d'erreur qui apparaît quand un slug n'est plus valide (quand on ajoute de nouvelles configurations) du coup ça nous permet de contacter l'AOM pour comprendre ce qu'il s'est passé : la dernière fois où c'est arrivé c'était parce qu'un nouveau jdd avait été référencé et l'ancien supprimé
• ça permet de ne pas relancer des AOM qui mettent à jour le GTFS sur leur portail opendata 7j ou 3j avant expiration : ça peut être embêtant de recevoir des mails quand c'est bien mis à jour avant expiration. C'était le cas de la région Grand Est qui en avait marre de recevoir des mails de rappel alors qu'ils avaient leur propre outil de gestion des délais de MAJ et que les GTFS étaient mis à jour 3 à 4j avant expiration (c'est de là qu'on a arrêté d'envoyer les mails automatiquement à tous les réseaux)

4/ Pour les GTFS saisonniers il me semble que c'est principalement Zenbus qui en publie. @AntoineAugusti a laissé un message dans le Channel Slack Zenbus<>PAN

[ChristinaLaumond]

Merci à tous pour vos retours.

Concernant les mails aux producteurs : Si on peut réfléchir à automatiser cela via l'espace producteur j'ai l'impression que cela faciliterait la gestion pour tout le monde en rendant les producteurs autonomes sur la configuration des emails qu'ils veulent recevoir + les mails sur lesquels ils souhaitent le faire (inscription /désinscription simple) . Concernant les avantages que tu mets en avant sur la configuration manuelle @Miryad3108 il faut s'assurer qu'ils peuvent être reproduits à travers la configuration autonome des producteurs (ex : que le système nous alerte si un mail n'est plus valide, pour supprimer la configuration et voir avec l'agglo qui mettre à la place ?)

Pour les GTFS saisonniers c'est noté.

Pour les jdd périmés le back-office est suffisant en effet pour notre usage interne. Mais quid des producteurs ? le système de notification actuel envoie des mails de relance avant et après la péremption ? cela rejoint le point 1 sur la gestion des notifications des producteurs où l'idée serait d'avoir une configuration adaptée par chaque producteur : je souhaite recevoir un mail 15 jours avant, 1 jour avant et si mon jeu est périmé un mail d'alerte hebdomadaire me rappelant que mon jeu est périmé (par exemple).

Je ne me rends pas compte de la complexité et de la durée de l'ajout de cette fonctionnalité côté dev mais on pourra en parler en réunion d'équipe pour voir si ca vaut le coup de se lancer là dedans ou non ;)

[AntoineAugusti]

@ChristinaLaumond Voir l'issue précédente pour l'historique concernant les notifications de péremption https://github.com/etalab/transport-site/issues/1461

Le fonctionnement que tu décris avait été envisagé mais écarté pour le moment au vu du temps de travail requis. On ne stocke aussi pas d'informations personnelles dans notre base de données et changer ceci est notable. Ceci est susceptible de prendre plusieurs jours de travail de dev, il faudra donc en parler.

À noter qu'actuellement il n'y a pas de rappel après péremption. Envoyer des rappels réguliers avec le système actuel est relativement aisé par rapport à l'alternative que tu proposes.

[ChristinaLaumond]

Merci, j'ajoute ces éléments dans l'investigation authentification (qui était orienté plutôt authentification réutilisateur mais qui peut être élargi à l'authentification producteur également) pour arbitrer ce sujet à la fin de l'investigation.

En attendant, c'est noté pour l'ajout d'un rappel après péremption via le système actuel. @Miryad3108 qu'en penses-tu ? ça nous permettrait d'automatiser cette tâche de relance si le jdd est périmé. On pourrait imaginer envoyer un mail automatique tous les lundis par exemple, dès lors que le jeu est toujours périmé ?

[Miryad3108]

Après péremption je pense que c'est mieux que soit un.e membre de l'équipe qui reprenne la main parce que si ils ne font rien après avoir reçu un mail 14j, 7j et 1j avant la péremption je me dis qu'ils ne le feront pas après et qu'un mail plus "direct" aura plus d'effet. Sinon envoyez quelques jours après la péremption puis qu'on prenne le relai. A en rediscuter avec le reste de l'équipe

[AntoineAugusti]

https://github.com/etalab/transport-validator/pull/144 devrait amener des dates d'expiration par agence à terme

[Miryad3108]

ça peut être fermé @AntoineAugusti ? (avec la "Gestion des contacts" dans le backoffice et l'inscription aux notifications). Sauf si on comptait aller plus loin ?