Réunion des dév' de Zeste de Savoir

On avait prévu de faire une réunion pendant la première semaine de mars, voici le sondage pour choisir la date.

J’ai aussi déjà créé un pad pour le compte-rendu, avec une ébauche de points à aborder, n’hésitez pas à compléter les points dont vous souhaiteriez discuter.

La réunion aura lieu samedi 9 mars à 18h, sur le canal Discord habituel.

Voici le compte-rendu de la réunion.

Présents : Aabu, Amaury, Situphen et moi-même.

Administration système

Réalisé : mise à jour du serveur de production vers Debian 12 (dernière version)

Vaultwarden

Prochaine étape : mise en place de Vaultwarden pour gérer les secrets (mots de passe pour accéder à divers services en ligne, aux API, …) ? Sur quel serveur ?

• réplication ?
• pas sur la bêta
• matomo et prod ? (si on finit par héberger Matomo chez le même hébergeur que la bêta, autant éviter de tout mettre chez un unique hébergeur)
• la base de données de vaultwarden est-elle chiffrée ? voir cette page

Conclusion : sur le serveur hébergeant Matomo et répliqué sur le serveur de production

Rien d’autre vraiment prioritaire concernant l’administration système.

Prochaine version : 30.6

• Avec les > 60 PRs fusionnées depuis 30.5 (mise à jour de dépendances (zmd !), correction de bugs mineurs, ajout de quelques fonctionnalités mineures, passage à Django 4)
• très bientôt (déploiement sans doute lors de la maintenance mensuelle des serveurs qui a lieu le week-end prochain)
• rien de particulier à inclure en plus, peut-être mettre à jour les dépendances ?

Développements prioritaires

• Passer à Django 4.2 fait.
• En profiter pour passer à Django 5 dans la foulée ? (le calendrier des versions)
  • rester sur la LTS (la 4.2), mais tester les nouvelles versions (enlever les choses dépréciées, préparer la mise à jour avant de vraiment la faire)
• Finir la PR sur Typesense : en cours

Roadmap pour la suite

• refondre progressivement de l’interface de rédaction
• continuer les actions du groupe de travail "Organisation des publications"

Idées de sujet pour les projets étudiants (pour la prochaine année scolaire)

• fusionner zds-antispam dans zds-site pour pouvoir facilement détecter du spam dans différents contenus (relativement simple, à minima pour l’anti-spam des biographies)
• revoir le fonctionnement des galeries : améliorer le lien entre les galeries et les contenus, par exemple savoir si une image d’une galerie est utilisée dans un contenu (sujet assez complexe, bien définir le besoin en amont ; demande que zmd puisse nous donner la liste des images dans un contenu)
• améliorer l’utilisation de Matomo : optimisation des requêtes, etc. (1er temps : voir si on utilise correctement l’API à partir de la doc, etc. / 2ème temps : essais avec des données réalistes)
• statistiques sur les contenus/forums/commentaires/MP de ZdS (comme https://linuxfr.org/statistiques) (relativement simple à condition que le besoin soit bien défini en amont / pourrait remplacer les statistiques mensuelles de firm1 / bien mettre du cache )
• convertir le code JavaScript en utilisant des modules pour pouvoir mettre à jour nos dépendances JS et mettre à jour le système de build JS (classé aussi comme développement prioritaire)
• les tâches pour améliorer l’organisation des contenus
• suggérer facilement des modifications aux auteurs (pouvoir indiquer précisément où est le passage concerné)
• les claps : reprendre la PR en cours

Divers

• Passage en revue des PRs
• Prochaine réunion : sondage fin avril pour réunion début mai

À inclure dans l’ordre du jour de la prochaine réunion :

• Meilleure gestion de l’organisation Github
  • Seulement 3 personnes avec les droits Owner, est-ce assez ?
  • Nettoyage de l’équipe avec les droits de merge sur le dépôt zds-site
  • Nettoyage des autres équipes
  • Suppression de l’équipe « Les bourgeons » ?
  • Nettoyage des membres de l’organisation (enlever ceux qui ne font parti d’aucune équipe ?)
  • (Conséquence) Nettoyage des casquettes Équipe technique

À inclure dans l’ordre du jour de la prochaine réunion (2^ème version) :

• Meilleure gestion de l’organisation Github
  • Seulement 3 personnes avec les droits Owner, est-ce assez ?
  • Nettoyage de l’équipe avec les droits de merge sur le dépôt zds-site
  • Nettoyage des autres équipes
  • Suppression de l’équipe « Les bourgeons » ?
  • Nettoyage des membres de l’organisation (enlever ceux qui ne font parti d’aucune équipe ?)
  • (Conséquence) Nettoyage des casquettes Équipe technique
• Hébergement d’un coffre-fort partagé pour les mots de passe de l’association
• Respect du RGPD (suite à ce sujet)
  • Quelles solutions techniques pour les vidéos et autres intégrations externes ?
  • Quelle précision pour les informations sur les profils (géolocalisation, date d’inscription, date de connexion) ? Différenciée ou non pour les membres et les modérateurs ?

On avait prévu de faire une réunion début mai, voici le sondage pour choisir la date.

J’ai aussi déjà créé un pad pour le compte-rendu, avec une ébauche de points à aborder (j’ai repris ceux de Situphen ci-dessus, ne pas hésiter à créer un pad dès qu’il y a quelques idées ! ), n’hésitez pas à compléter les points dont vous souhaiteriez discuter.

La réunion aura lieu le mercredi 1er mai à 19h, sur le canal Discord habituel.

Voici le compte-rendu de la réunion.

Présents : Situphen, Aabu, firm1, sgble et moi-même.

Respect du RGPD

À propos de ce sujet (et en particulier la todo-list)

• Avatars chargés depuis chez Gravatar :
  • PR qui permet d’avoir un avatar par défaut en JS, sans requête inutile (et fuiteuse de l’adresse mail md5-ée) si on n’a pas de compte chez Gravatar
  • On abandonne le support de Gravatar pour les nouveaux comptes
• Quelles solutions techniques pour les vidéos et autres intégrations externes ?
  • Solution directement chez zds-site et/ou aussi chez zmd ? => on a besoin des deux car il faut l’appliquer aux nouveaux messages / contenus et aux anciens (ceux dont le code HTML généré est stocké en base)
  • Dans tous les cas : besoin de code côté JS zds
  • Outils comme Tarte au citron ou /iframemanager a priori ne conviennent pas, notamment parce qu’on ne régénère pas toujours le HTML
  • On veut garder des intégrations vidéo ou JSFiddle
• Quelle précision pour les informations sur les profils (géolocalisation, date d’inscription, date de connexion) ? Différenciée ou non pour les membres et les modérateurs ? Date d’expiration ?
  • Pour le staff, afficher toutes les infos, précision au max
  • Pour quelqu’un pas connecté : affichage date relative de l’inscription ("il y a 3 semaines"), pas de date de connexion
  • Pour un membre lambda : affichage date relative inscription et connexion
  • Geolocalisation : afficher uniquement le pays
  • => Il faudrait revoir les droits en général de qui a accès à quoi (staff, valido, modo, admin, etc), mais c’est un autre gros morceau
  • Date d’expiration de la géolocalisation liée à l’expiration de l’IP
• Documenter notre conformité au RGPD
  • Même ce qui n’est pas conforme
  • À gros grain (comme le contenu de ce compte-rendu par exemple, pas dans les détails des articles du RGPD…)

Hébergement d’un coffre-fort partagé pour les mots de passe de l’association

• Mentionné lors de la dernière réunion du CA
• Dernière réunion des devs : Vaultwarden, hébergé sur Matomo et répliqué sur la production
• Exemples de cas d’usage ? (notamment si ça doit concerner plus que l’équipe technique)
  • Serait très utile pour l’équipe de communication, pour les identifiants d’accès aux différents services/réseaux, et pour le CA, pour les identifiants aux outils administratifs (p.ex. moncompteasso ou HelloAsso).
  • Système de groupes
  • Rappels pour changer régulièrement les mots de passe

Prochaine action concernant l’administration système : migration du serveur Matomo vers Pulseheberg ?

• Pas d’urgence d’un point de vue financier, Scaleway nous coûte 13,43€ / mois
• On avait déjà commencé à discuter de l’offre qui nous conviendrait lors de la migration du serveur de bêta vers Pulseheberg

UI/UX/DA

• Mentionné sur le forum : acter de demander des devis pour renouveler la DA du site ?
  • N’inclurait pas l’intégration (développement du HTML/CSS)
  • 700 / 1200€
  • L’équipe technique ne se prononce que sur le côté technique : ok, ça nous poussera peut-être à vraiment faire l’intégration (on aura vraiment une base à partir de laquelle travailler)
  • L’amélioration des outils de rédaction peut se faire en parallèle

Réflexions quant à la décision d’entamer tutorielv3

• Les pistes, idées et envies d’évolution du modèle de contenus actuel sont plutôt radicales, très simplificatrices et unificatrices, et peu de paire avec notre modèle actuel tutorielv2
• Le code de tutorielv2 est complexe et semble difficile à maintenir (à moins que non ? confirmation ou infirmation bienvenue)
  • Pas tant que ça, mais de la refactorisation est la bienvenue
• Ne serait-ce pas l’occasion de reprendre from scratch vers ce nouveau modèle plus simple ?
• On ne parle pas de changer le format des cours eux-même (manifest/etc.)

=> Pas forcément pertinent de repartir from scratch. Pour ajouter des nouvelles fonctionnalités on a surtout besoin de temps.

Meilleure gestion de l’organisation GitHub

• Seulement 3 personnes (artragis, Situphen et moi-même) avec les droits Owner, est-ce assez ?
  • Amaury, le président du CA est ajouté (juste pour ne pas se retrouver bloquer au cas où)
• Suppression de l’équipe « Les bourgeons » (les personnes qui peuvent pouvaient être assignées à des tickets)
• Pas de changement dans l’équipe avec les droits de fusion sur le dépôt zds-site
• Pas de changement dans les autres équipes
• Nettoyage des membres de l’organisation (suppression de ceux qui ne font partie d’aucune équipe)

Passage en revue des PRs

• Passage à Typesense : bien avancé, tests en bêta à faire, fonctionnalités identiques à ce qu’on a actuellement avec ElasticSearch
• Verrouiller les commentaires d’un contenu : quelqu’un d’autre peut reprendre : pas mal de refacto à faire

Prochaine réunion

Sondage pour que la réunion soit la semaine du 17–23 juin

On avait prévu de faire une réunion vers la fin juin, voici le sondage pour choisir la date (il n’y a pas le mardi parce que je ne suis pas dispo, et attention le vendredi c’est la fête de la musique).

J’ai aussi déjà créé un pad pour le compte-rendu, avec une ébauche de points à aborder. Pas beaucoup de sujets pour l’instant (ce qui n’est pas forcément une mauvaise chose), n’hésitez pas à compléter.

Cette semaine sera déjà très chargée pour ma part, donc je préférerai la semaine d’après si possible.

La réunion aura lieu le samedi 22 juin à 21h, sur le canal Discord habituel.

Voici le compte-rendu de la réunion.

Présents : Amaury, Aabu, Philippe

Administration système

• Mise en place de Vaultwarden : notamment basculement de l’équipe de com' en cours de manière progressive
• Migration des projets GitHub vers le nouveau système : pas de soucis majeurs, quelques pertes d’UX minimes et opportunités possibles avec les nouvelles fonctionnalités
• Les problèmes de RAM de MariaDB pour Matomo semblent être corrigés depuis la mise en place du swap

UI/UX/DA

• Philippe a peut-être un contact : ecrire@racinesdesign.fr
  • On aimerait trouver des contacts avec des valeurs similaires, mais ça ne court pas les rues, donc dur à trouver.
• Amaury a aussi un potentiel contact : contact@simonlucas.fr (designer de Wolfy et CodinGames : sait faire des interfaces playful, ce qui pourrait bien nous correspondre)

Préparer le prochain projet étudiant

Sujet déjà évoqué lors de la réunion de mars 2024

Pour rappel, en 2021–2022, on avait proposé les tâches suivantes :

• Migration de zMarkdown (finalement abandonné)
• Évolution du module de recherche (ça nous a permis de bien avancer ce sujet, on n’est pas loin de le fusionner)
• Quiz et sondages (la conclusion c’était qu’il faut qu’on définisse mieux nos besoins, mais un POC a été produit)
• Tâche "Organisation des publications" (quelques PRs fusionnées)

Proposition pour 2024–2025

• fusionner zds-antispam dans zds-site pour pouvoir facilement détecter du spam dans différents contenus (les commentaires sur les contenus, les posts sur les forums, etc)
  • besoin facile à décrire
  • est surtout technique mais touche à pas mal d’aspects du code (pédagogiquement, c’est une tâche intéressante)
• améliorer l’utilisation de Matomo : optimisation des requêtes, etc. (1er temps : voir si on utilise correctement l’API à partir de la doc, etc. / 2ème temps : essais avec des données réalistes)
  • pédagogiquement, c’est une tâche intéressante : ça peut les occuper assez longtemps, ça les force à aller lire la doc de Matomo, faire des essais
  • c’est un point gênant qu’on se traîne depuis longtemps et personne n’a le temps d’y regarder
• convertir le code JavaScript en utilisant des modules pour pouvoir mettre à jour nos dépendances JS et mettre à jour le système de build JS
  • point plutôt urgent
  • tâche pas vraiment passionnante…
  • Amaury a de l’expérience avec Vite, webpack (mais avis moins positif) et rollup (utilisé pour lime-editor, base de Vite). Faire une comparaison et en discuter sur le forum, pour leur donner directement la solution à utiliser.
• meilleure gestion de l’obsolescence des contenu
  • pouvoir préciser le message d’obsolescence (titre très gros + détails), exemple
  • mettre le message plus en avant
  • avoir une interface pour les validateurs/auteurs pour par exemple lister les contenus pas mis à jour depuis x mois/années
• suggérer facilement des modifications aux auteurs (pouvoir indiquer précisément où est le passage concerné)
  • serait plus expérimental / exploratoire (on n’attend pas quelque chose fusionnable, mais plutôt un/des POC)

Abandonné (pour cette année)

• Mise en place des parcours
  • Demande plus de discussions en amont, de bien définir les besoins
• les claps : reprendre la PR en cours
  • Est-ce qu’on a fini par ce mettre d’accord sur ce qu’on voulait ?
  • Amaury semble se souvenir d’un document qui décrit exactement ce qu’on veut
• meilleure gestion des bans : bien communiquer la raison du ban et laisser un canal de communication ouvert avec l’équipe de modération
  • pas trivial avec le fonctionnement actuel
• revoir le fonctionnement des galeries : améliorer le lien entre les galeries et les contenus, par exemple savoir si une image d’une galerie est utilisée dans un contenu
  • nécessite de bien définir le besoin en amont, on n’aura pas le temps de faire ça
  • sujet complexe
  • idéalement, il faudrait que zmd puisse nous donner la liste des images utilisées dans un contenu, ce qui rajoute encore à la complexité
• statistiques sur les contenus/forums/commentaires/MP de ZdS (comme https://linuxfr.org/statistiques) (relativement simple à condition que le besoin soit bien défini en amont / pourrait remplacer les statistiques mensuelles de firm1 / bien mettre du cache )
  • gadget et pas nécessaire / urgent

Rencontre des dev’s ZdS ?

• Pour fêter les 10 ans du site (https://zestedesavoir.com/forums/sujet/17458/10-ans-de-zds-appel-a-idees-et-contributions/)
• Sprint de dev ZdS
• Sprint en marge de la PyConFR (https://zestedesavoir.com/billets/4677/pyconfr-2024-strasbourg/, 31 oct - 3 nov) ?
  • Amaury et Aabu absents
• En marge du Capitole du Libre, Toulouse, 17–18 nov ?
  • pas sûr qu’il y ait la possibilité d’avoir des sprints et puis il y a déjà les conférences du Capitole du Libre et une MiniDebConf
• Un événement exprès ?
• Chez quelqu’un ?
• JDLL, FOSDEM, PasSageEnSeine, Hacktoberfest, …
  • se rattacher à un événement permet potentiellement de faire sauter la contrainte de la distance
  • pourrait motiver des personnes pour en plus tenir un stand ZdS
• Philippe lance un sujet

Passage en revue des PRs

• Il serait bien d’avancer sur Refonte de la page à propos qui est actuellement en bêta
  • Empêche de tester le passage à Typesense
  • Si c’est juste pour montrer à Gandi qu’on a mis leur logo, on peut faire une plus petite PR qui ne fait que ajouter le logo $\rightarrow$ pas vraiment le cas
• Passage à Typesense : pas d’avancés depuis la dernière réunion

Prochaine réunion

Programmer une réunion pour début septembre.

On avait prévu de faire une réunion vers la fin juin, voici le sondage pour choisir la date j’ai mis les deux premières semaines de septembre).

J’ai aussi déjà créé un pad pour le compte-rendu, avec une ébauche de points à aborder, n’hésitez pas à compléter.

La réunion aura lieu le mardi 10 septembre à 19h, sur le canal Discord habituel.

Voici le compte-rendu de la réunion.

Présents : Aabu, Amaury, Philippe, Situphen

Administration système

Intégration de GitHub à Sentry pour le projet zds-site. À voir à l’usage si c’est vraiment utile (permet entre de créer des ticket GitHub directement depuis un problème affiché dans Sentry). Option aussi activée pour que Sentry analyse les PRs ouvertes pour trouver de potentiels problèmes.

Prochain gros changement (mais pas super urgent) : migration du serveur Matomo de Scaleway vers PulseHeberg

Projet étudiant

On a encore le temps pour rédiger le sujet : début pas avant octobre.

Un point à discuter un peu plus en détail, la fusion de zds-antispam dans zds-site :

Dans quels champs veut-on chercher du spam ?

Actuellement uniquement dans les biographies de l’objet Profile. on souhaite chercher dans les signatures, les commentaires de contenus, sujets du forum (regarder directement l’attribut text de la classe Comment, sauf pour les MP )

Techniquement, quelle solution veut-on implémenter pour marquer les colonnes dans lesquelles chercher du spam ?

Plusieurs idées :

1. une sorte de décorateur sur les attributs où chercher du spam:
   @detectspam(is_spam=author.is_banned)
   text = model.TextField(...)
   

2. pour chaque modèle, ajouter un récepteur du signal de sauvegarde de l’objet en base de données :
   @signal(save...)
   def antispam_comment():
       # ...
   

3. dans un module à part, avoir une liste décrivant où chercher le spam :
   spam_fields = [{
     "training_queryset": Comment.objects.prefetch_selected(...),
     "field": Profile._meta.fields("biography"),
     "training_condition": lambda x: x.banned and ....,   # Q et F functions et cie
     }, {}]
     
   @receiver(save, sender=tous les objets dans spam_fields)
   def analyze_record(....):
     # test if spam or not, trigger alert if yes
   

La version 3 est préférée, dans un module dédié, évite les inter-dépendences entre les modules.

Quand la détection se fait-elle ? A posteriori de l’enregistrement en bdd (via une cron) ou bien a priori en renvoyant une erreur de formulaire invalide ?

Au moment de l’enregistrement dans la BDD, faire tourner la détection (c’est normalement suffisamment rapide pour ne pas pénaliser la durée de la requête HTTP), mais juste signaler, ne pas bloquer l’enregistrement si suspicion de spam

Comment c’est signalé ?

Le compte bot "antispam" crée un objet de signalement (comme c’est fait actuellement)

Ajouter des statistiques Munin

Par exemple le nombre de signalements par jour.

Rencontre IRL des dev’s ZdS

Sujet sur le forum

Capitole du Libre à Toulouse, 16 et 17 novembre

• stand au village associatif ? à voir si on arrive à mobiliser assez de monde pour tenir le stand, il faut répondre à l’appel avant le 15 septembre
• réunion des devs ? à faire derrière le stand pendant les temps de creux

Création d'un sujet sur le forum

Passage en revue des PRs

• Serait vraiment bien d’avancer sur la refonte de la page à Propos. Moins urgent, puisqu’on a patché la prod pour inclure le logo de Gandi
• Typesense : testé sur la bêta, seul point bloquant : on ne renvoie que 20 résultats de chaque type de contenu. => renvoyer uniquement le maximum de résultats possibles sur une page.

ZdS et les LLMs

Sujet à traiter par le CA.

Quelle est la position de ZdS vis-à-vis des LLMs (ChatGPT & co), par rapport à :

• l’utilisation pour la rédaction d’un contenu ? (impossible à détecter automatiquement)
  • concerne les validateurs
  • écrire dans nos règles éditoriales qu’un contenu manifestement généré par LLM peut être refusé
• l’utilisation des contenus de ZdS pour alimenter des LLMs ? (il est possible d’indiquer qu’on refuse que les robots lisent notre site, par exemple : https://github.com/ai-robots-txt/ai.robots.txt)
  • interdire par défaut car ça peut aller à l’encontre des contenus avec tous droits réservés

Prochaine réunion

Lancer un sondage pour une réunion début novembre.

On avait prévu de faire une réunion début novembre, voici le sondage pour choisir la date.

J’ai aussi déjà créé un pad pour le compte-rendu, avec une ébauche de points à aborder, n’hésitez pas à compléter.

La réunion aura lieu le samedi 9 novembre à 21h, sur le canal Discord Développement de ZdS.

Voici le compte-rendu de la réunion.

Présents : Aabu, philippemilink, Situphen (arrivé en cours de route)

Administration système

• À deux doigts de demander à Pulseheberg une VM avec un SSD pour la bêta…
• Prochain gros changement : migration du serveur Matomo de Scaleway vers PulseHeberg
  • à voir à quel point c’est urgent : il reste 3 Go de libre sur la partition qui stocke la base de données SQL (out of 19 Go), il faut regarder la vitesse à laquelle ça se remplit : https://munin.beta.zestedesavoir.com/zds-matomo/zds-matomo/df.html

Nouveau moteur de recherche

• Pas de problème particulier/grave remonté
• Quelques bugs, certains sont hotfixés en prod :
  • rechercher depuis la page d’une catégorie de la bibliothèque mène vers une 500
    • nécessite de pouvoir faire une recherche en filtrant selon les catégories (patché en prod pour éviter l’erreur 500, mais cherche dans toutes les catégories)
  • déplacer un sujet pas encore indexé crée une 500
    • écrire le test unitaire est un peu compliqué (patché en prod de façon sale pour éviter la 500)
  • suite au changement de formats possibles pour tous les contenus, les poids n’ont pas été mis à jour
    • PR correspondante à QA
  • il est possible que des résultats n’aient pas de highlights, ce qui créait une 500
    • PR fusionnée, déployée en prod

Le futur de la recherche

• https://github.com/zestedesavoir/zds-site/labels/C-Search
• Ne pas indexer certains forums (corbeille)
  • très facile à faire
  • le forum corbeille représente finalement peu de sujets
  • le staff pourrait quand même avoir besoin de chercher dans la corbeille ? est-ce un cas d’usage qui peut arriver ?
• Nécessité d’indexer les topics ? On indexe déjà les premiers posts de chaque topic dans les posts (peut donner des résultats bizarre où le même topic apparaît plusieurs fois dans les résultats : une fois en tant que topic, puis en tant que posts du topic)
• Indexer tous les commentaires (aussi ceux des contenus)
• Améliorer les filtres (avant de lancer la recherche)
• Mécanisme de facettes (filtres sur les résultats)
• Pouvoir chercher des membres
  • afficher les auteurs d’un contenu dans les résultats
  • le profil d’un membre apparaît dans les résultats de la recherche
  • les contenus (+ commentaires, topics, posts) d’un membre apparaissent lorsque ce membre est cherché ?
    • déjà accessible depuis la page de profil (mais le membre peut choisir de le cacher sur sa page de profil, donc il ne faudrait pas que ça apparaisse dans la recherche !)

Projet étudiant

• Changement cette année : ne démarre qu’au second semestre
• Le sujet doit être envoyé début décembre (déjà bien commencé, on en a discuté lors des réunions précédentes)

Rencontre IRL des dev’s ZdS

Capitole du Libre 16 et 17 novembre (philippemilink y sera)

ZdS et les LLMs

Qu’est-ce qui s’est dit lors de la dernière réunion du CA ? Extrait du CR de la réunion du CA du 21 octobre 2024 :

Sur l’utilisation de ChatGPT dans les contenus

• Il nous semble que nous ayons déjà les outils pour modérer l’utilisation des IA
  • Pour les contenus publiés, ils sont soumis à validation donc de fait les contenus générés en très grande partie avec des IA peuvent facilement être filtrés.
  • Pour les billets, on peut considérer que de tels contenus sont pour nous du spam.
• Cela dit, les règles éditoriales pourraient être modifiées pour adresser explicitement ce sujet et c’est à l’équipe de validation d’en discuter.

Sur l’ajout d’UA de robots d’indexation de LLM au robots.txt

• Avis unanime positif
• Argument supplémentaire (Situphen et germinolegrand) : les petits (pas encore reconnus) peuvent se permettre de ne pas les respecter, mais les plus gros (institutionnalisés ou un minimum “respectables”), moins
• Avis unanime de ne pas aller plus loin (bloquer les UA complètement, détecter le style de navigation…) car rapport bénéfice/risque trop peu intéressant.

Les interdictions via le fichier robots.txt ont l’air d’être respectées par les indexeurs des LLMs : https://x.com/Progerance/status/1854252890816483661

Quelle garantie de service assurer pour zestedesavoir.com ?

Il faut être (tout le temps) disponible pour pouvoir réagir aux alertes.

Ce que je (Philippe) aimerais : qu’on acte officiellement qu’on n’a aucune garantie de service, il est possible que le site soit inaccessible pendant plusieurs heures, voire au pire un jour. L’objectif est qu’on soit inattaquable (a priori personne ne va nous attaquer, mais vous voyez l’idée) à la fois en tant que l’équipe derrière ZdS (le CA, l’équipe technique, …) mais aussi les personnes qui ont accès aux serveurs.

En réalité déjà le cas : https://zestedesavoir.com/pages/cgu/ point 4 "accès au site"

L’équipe des développeurs est bénévole, reste attentive à la continuité du service, mais ne s’engage pas sur un délai de résolution des problèmes.

Passage en revue des PRs

• Quelques PRs à QA
• Les PRs zombies sont toujours bonnes à reprendre
• Aabu a repris la PR sur les liens de partage

Prochaine version de zds-site

• avec tous les correctifs pour la recherche
• afficher le nombre de commentaires sur la page de profil (s’il n’y a que des commentaires, utile pour détecter les comptes spam)

Prochaine réunion

Lancer un sondage fin décembre pour une réunion début janvier 2025.