Lors du camp CHATONS, on a abordé la question de la communication avec nos utilisateurs/rises. Pour des services fermés ou réservés à un groupe de personnes, la question du canal de communication à utiliser est relativement simple puisqu’un premier échange a été nécessaire à l’utilisation du service. Pour les services ouverts (avec ou sans inscription), la question est plus difficile.
Il semble assez nécessaire pour chaque chaton d’avoir un canal d’information, qui soit le plus simple et efficace possible pour organiser des réunions avec les utilisateurs/rises, pour annoncer l’ouverture/fermeture/mise à jour d’un service etc.
Plusieurs solutions techniques sont envisageables et peuvent dépendre de la nature du service.
Avec @khrys, nous avions discuté d’une solution basée sur une barre d’information commune à toutes les services. Des implémentations avaient été discuté dans le post Barre d’outils multi-sites, où la barre était utilisé pour passer d’un service à un autre.
Je vous invite à discuter autour de ce problème ici et je pourrais essayer de faire un résumé dans le wiki, une fois que ça aura un peu maturé.
Pour nous, isidorus.fr c’est assez simple et basique : vu que les utilisateurs sont des connaissances (amis, famille) j’ai déjà leurs coordonnées, dont le numéro de téléphone. On a donc un groupe sur Signal pour ce genre d’infos.
Concernant la barre d’outils j’ai déployé une version pour le cnam qui gère un peu mieux les intégrations dans différentes apps. Il me reste à publier ça sous forme de thème yunohost…
Par contre, clairement chez ARN on a besoin de pouvoir informer les usagers qu’on connaît pas, et là avec le problème de pad qu’on a rencontré, on a rien pour le faire facilement. Au sens où les usager⋅es qui nous connaissent pas ne savent pas qu’il y a un post dédié sur notre forum.
Et le problème c’est que c’est pas quand tout casse que t’as le temps de créer un système pour faire ça (ou alors un pauvre truc comme j’ai fait pour le libreto pendant quelques heures).
Merci. La barre d’outils que tu as fait pour la cnam contenait une partie pour informer les gens, ou elle contenait uniquement des outils ?
Tu as raison de préciser que la méthode d’information doit être suffisamment robuste pour informer les gens en cas de pannes. Je pense que l’on peut faire face à deux situations:
la panne d’un service, qui pourrait être détectée pour afficher des informations à la place de l’accès au service,
la panne globale, où le serveur n’est pas accessible ou non fonctionnel. C’est un cas pas si exceptionnel quand on fait de l’auto-hébergement. Et je ne vois pas de solution ici, ça sort du cadre de la discussion.
Uniquement des outils, mais elle est paramétrable avec un json, donc déjà c’est possible d’afficher un onglet « incident en cours » en rouge avec une icône attention si besoin…
Mais l’idéal c’est je pense de rajouter un mécanisme de popup avec un cookies.
Je ne suis pas sûr de comprendre le fonctionnement que tu souhaites proposer ici. Ça serait plutôt une sorte de notification ? Donc, ça serait une solution pour annoncer les incidents sur des services au sein d’une collection de services. La question, qui restent en suspens, est de détecter les incidents et traduire ces incidents en message.
Finalement, tu proposes quelque chose qui est plus spécifique que ce que j’avais en tête, c’est à dire afficher un simple message avec des liens.
Oui alors en fait perso je suis effectivement plus basique (mais nous en sommes là) et je m’inquiète pas trop de la partie détection car si y a un trucs qui va pas, avec un peu de user tu as très vite une remontée en réalité… Par ailleurs détecter qu’un service est injoignable est une chose mais ça ne veux pas dire que tout fonctionne . Enfin pour moi, le monitoring (zabbix ou autre) pourrait très bien déclencher une activation du texte de la pop up.
. Enfin pour moi, le monitoring (zabbix ou autre) pourrait très bien déclencher une activation du texte de la pop up.