Extension:Graph/Plans/fr

<translate> Tracked in [[<tvar name=1>phabricator:</tvar>|Phabricator]]</translate>
<translate> Task <tvar name=1>T334940</tvar></translate>

Mise à jour d'avril 2024

Bonjour à tous, je m'appelle Marshall Miller; Je suis directeur senior des produits à la WMF et travaille avec les chefs de produit et les équipes consacrées à l'expérience utilisateur de lecture et de rédaction des Wikis. Merci à tous d'avoir participé à cette conversation en cours et d'avoir fait preuve de patience pendant la panne frustrante de l'extension Graph. J'ai donné la dernière mise à jour sur les graphes ici et sur wikimedia-l. Depuis, j'ai parlé à de nombreux bénévoles de leurs expériences et de leurs besoins en matière de graphiques, et j'ai rassemblé un groupe d'employés pour proposer un plan. Je suis de retour avec une proposition de plan pour vos commentaires et contributions. Je publie ici sur la page du projet au lieu de la page de discussion afin que cette mise à jour puisse être marquée pour traduction dans d'autres langues. Il y a un nouvel en-tête sur la page de discussion pour la discussion.

Résumé

En bref, nous, à la Fondation Wikimédia, proposons de continuer avec une approche suggérée par de nombreux membres de la communauté: construire un nouveau service pour remplacer l'extension Graph. Cette approche permettra aux éditeurs de créer des visualisations de base, nécessitera une coordination avec les communautés autour de la migration des graphiques existants et sera extensible par les développeurs qui souhaitent créer et maintenir des fonctionnalités supplémentaires.

Nous avons eu besoin d'un certain temps pour réfléchir à toutes les questions architecturales et à la manière de financer ce travail, et nous souhaitons maintenant entendre les bénévoles nous dire si cela semble être la bonne approche. Ce travail sera dirigé par Chris Ciufo, le chef de produit de l'équipe de conception de systèmes. Vous pouvez vous attendre à avoir de ses nouvelles à l’avenir. Vous trouverez plus d’informations ci-dessous pour ceux qui souhaitent voir plus de détails et de considérations de cette approche.

Ces travaux n’ayant pas encore commencé, il reste encore plusieurs mois avant que les nouveaux graphes soient opérationnels. Nous allons impliquer les bons ingénieurs et commencer à concevoir l'architecture au cours des prochaines semaines, en nous assurant que nous avons un plan solide et que nous sommes prêts à le mettre en œuvre, puis nous commencerons probablement ce travail en juillet, à mesure que les membres du personnel auront complété leurs projets précédents. On ne sait pas encore combien de temps il faudra avant que les premiers types de graphiques soient opérationnels. Nous sommes heureux de discuter des idées des membres de la communauté sur ce qu'il faut faire, au le cas où les graphes restent indisponibles au cours des mois à venir.

Raisonnement

Chris et moi proposons cette approche basée sur l'examen de la manière dont les gens ont utilisé les graphes dans le passé, sur la manière dont nous pensons qu'ils les utiliseront à l'avenir et sur des considérations visant à garantir que notre technologie sera sécurisée, évolutive et maintenable dans le futur.

En regardant comment les gens ont utilisé les graphes dans le passé, nous constatons que ceux-ci sont un outil précieux, mais pas extrêmement courant dans les Wikis. Sur la Wikipédia en anglais, les graphes sont utilisés dans environ 10.000 articles, soit 0,15% de tous les articles. Dans toutes les versions linguistiques de Wikipédia, les graphes sont utilisés dans environ 178.000 articles, soit un pourcentage de 0,28%. En dehors de l’espace de noms principal, les graphes sont utilisés plus souvent, fréquemment parce qu’ils font partie de modèles très affichés. Par exemple, sur la Wikipédia en arabe, il y avait un graphe de pages vues sur chaque page de discussion d'article (jusqu'à ce qu'elles soient récemment supprimées). Surtout, nous avons remarqué que la grande majorité des graphes sont relativement simples: Barres, courbes, secteurs, etc., et utilisent des données en ligne dans le texte Wiki ou dans l'espace de noms Data sur Commons. Les ressources affectées aux graphes doivent correspondre à cette utilisation modérée – une prise en charge suffisante, mais pas pour des fonctionnalités complexes qui ne sont pas largement utilisées.

Discussion technique

La fonctionnalité de la nouvelle extension serait plus limitée par rapport à l'ancienne, notamment dans la mesure où elle ne prendra pas en charge tous les types de visualisation et sources de données de l'ancienne extension. Cette approche représente un nouveau départ vers un avenir plus durable avec les graphes.

En terme de sécurité, d'évolutivité et de maintenabilité, nous avons décidé en décembre qu'il n'existait pas de moyen viable de corriger et de continuer à utiliser l'ancienne extension Graph. Entre autres options, nous avons tenté de mettre à niveau vers Vega 5 (mais avons continué à trouver les mêmes problèmes de sécurité), et nous avons essayé d'envelopper le canevas Vega dans un brouillon iframe (ce qui a entraîné des problèmes significatives de performance). La conclusion était donc qu'il fallait trouver une nouvelle extension pour les graphes.

Voici un bref aperçu de l'approche à laquelle nous pensons:

• L’ancienne extension Graph serait abandonnée.
• La Fondation construirait une nouvelle extension de balise d'analyseur qui prendrait en charge un ensemble limité de types de visualisation prédéterminés, comme des graphes et des cartes de base, qui couvrent la majorité des cas d'utilisation existants, que les éditeurs spécifieraient dans le texte Wiki et seraient affichés sous forme d'images statiques sur les pages Wiki.
• Le rendu côté serveur éviterait les risques de sécurité connus ou importants, tels que ceux de l’ancienne extension Graphs.
• Nous ne savons pas encore quelle(s) bibliothèque(s) de visualisation serait utilisée, que ce soit Vega, d3 (qui alimente Vega), quelque chose comme Notre monde dans Data-Grapher, ou autre chose.
• La nouvelle extension prendrait en charge les données de définition de graphes spécifiées en ligne ou via des données tabulaires Commons (dans l'espace de noms Data:namespece), comme cela était pris en charge par l'extension Graph. Nous essaierons d'offrir une assistance pour migrer les graphes existants à l'aide de ces sources de données.
• Elle pourrait être étendue avec de nouveaux types de visualisation par le personnel ou les développeurs bénévoles à travers un processus contrôlé, centralisé et révisable par le code.
• Elle pourrait être étendue pour extraire des données d’autres sources, telles que Wikidata, ce pour quoi elle n’est pas été conçue au départ.
• Elle afficherait des graphies sur les applications Wikipedia iOS et Android (cela n'était pas possible avec l'extension Graph après la mise hors service de Graphoid).
• Elle serait officiellement entretenue par la WMF pour résoudre les bugs.

Dans les nombreuses conversations autour des graphes, les bénévoles ont également soulevé des questions à plus long terme sur le “contenu interactif”, tel que les chronologies et les objets 3D. Reconstruire la capacité de servir des graphes simples en toute sécurité représentera une énorme quantité de travail pour le personnel et les bénévoles. Dans ce cadre, la nouvelle extension sera facilement extensible par des bénévoles possédant les compétences techniques nécessaires pour ajouter des visualisations plus sophistiquées et davantage de sources de données. Cela peut être une porte ouverte à certains types de contenu interactif, mais le sujet plus général du contenu interactif mérite des conversations distinctes et continues à l’avenir.

Perspectives futures

À l’avenir, nous souhaitons connaître votre avis sur cette approche:

• Est-ce que cela semble être la bonne façon de procéder?
• Quels sont les types de visualisation de base qui sont les plus importants à soutenir? Quels sont ceux dont on peut se passer?
• Quels cas d’utilisation craignez-vous d’être manqués?
• Comment les communautés devront-elles participer ou réagir à ces changements?

Au fur et à mesure de nos discussions, de nombreuses questions importantes doivent être résolues. L’une de mes principales préoccupations est ce qui se passera avec l’écosystème de modèles et de sources de données qui a été construit autour de l’extension Graph au cours des dix dernières années. Même si nous souhaitons faciliter le fonctionnement de nombreuses spécifications de graphes existantes dans le nouveau système, nous devrons réfléchir à cela ensemble.

Merci d'avoir lu cette longue mise à jour et de continuer à faire partie de cet effort. Je sais que beaucoup d'entre vous ont passé beaucoup de temps au cours des derniers mois à discuter de graphiques et à élaborer des solutions de contournement. Nous sommes impatients de poursuivre le travail.

Discussion par rapport à cette mise à jour

Détails historiques - bientôt mis à jour

Cette page est un lieu de collecte et de partage d'information et d'idées entre Wikimédiens·nes destiné à éclairer l'action à mener par Wikimédia pour s'assurer que les besoins en réponse auxquels l'extension Graph a été créée continuent à être pourvus.

Avancement

Phases to fix Extension:Graph

Phase	Tâche de suivi	Statut	Date d'achèvement
Phase 0: Invite volunteers to review roadmap		File:OOjs UI icon check-constructive.svg <translate> Done</translate>	File:OOjs UI icon check-constructive.svg <translate> Done</translate>
Phase 1: Validate Security of Sandboxing Approach	Initial approach: T222807	Initial approach did not work.
Phase 2: Transition Graph Extension to Vega 5	T165118	File:OOjs UI icon reload-progressive.svg <translate> In progress</translate>
Phase 3: Define maintenance responsibilities and security/incident response
Phase 4: Deploy Graph Extension (Vega 5)
Phase 5: Optimize the Graph Extension's longevity

Feuille de route

📍 Phase 0 : inviter des volontaires à examiner la feuille de route

Objectif

Veiller à ce que les bénévoles comprennent et soutiennent suffisamment les phases 1 à 5 pour que nous (personnel et bénévoles) puissions élaborer des décisions/compromis efficacement à mesure qu'ils se présentent au cours de la mise en œuvre.

Étapes

1. Les bénévoles et la Fondation Wikimédia discutent de la feuille de route proposée et l'améliorent si nécessaire.

Phase 1 : valider la sécurité de l'approche "Isolement en bac-à-sable"

Objectif

S'assurer que le cadre d'intégration isolé en bac-à-sable est suffisamment sécurisé : 1) installer l'extension Graph avec Vega 5 sur le bloc de données en bêta et 2) publier la documentation et les outils nécessaires pour que les volontaires et le personnel puissent évaluer sa sécurité.

Étapes

1. Achever le patch correctif de mise en bac-à-sable actuellement en cours d'élaboration pour fournir l'infrastructure de base des prochaines étapes.
2. Créer une page jouant le rôle de bac d'essai, soit en tant qu'extension, soit en tant que page spéciale dans le cœur logiciel, lequel permet d'exécuter arbitrairement du code JavaScript à l'intérieur du bac-à-sable de l'infrastructure.
3. Déployer la page « bac d'essai » sur l'environnement de test bêta, avec les règles initiales d'isolement en bac-à-sable appropriées.
4. Soumettre la page « bac d'essai » à un test d'intrusion pour vérifier sa sécurité et affiner de manière itérative les règles de l'isolement en bac-à-sable.
5. Procéder à toute analyse de sécurité statique pertinente sur le code mis à jour, en amont de son déploiement.

Phase 2 : migrer l'extension Graph vers Vega 5

Objectif

Finaliser l'extension Graph pour Vega 5 : réimplanter les fonctionnalités de Vega 2 en utilisant la syntaxe compatible avec Vega 5 pour que tous les nouveaux graphes bénéficient désormais des améliorations de Vega 5 en matière de sécurité, d'accessibilité et de syntaxe.

Étapes

1. Connecter Vega 5 à l'infrastructure d'isolement en bac-à-sable en implémentant à son chargeur autant de contrôles d'isolement supplémentaires que nécessaire.
2. (Ré-)implémenter la prise-en-charge du protocole pour Vega 5 sur la base des implémentations de Vega 2, en évaluant à l'occasion leurs sécurité et maintenabilité.
3. Déployer Vega 5 isolé en bac-à-sable sur l'environnement de test bêta pour permettre aux bénévoles d'effectuer des essais préliminaires.
4. Tester et évaluer l'approche "Isolement de Vega 5 en bac-à-sable"
5. Mener des tests de sécurité supplémentaires avec des charges utiles spécifiques à Vega 5 pour suivre les travaux de la phase 1.
6. Améliorer l'actuel outil de conversion de Vega 2 vers Vega 5 en un assistant de mise à niveau aidant les bénévoles à convertir les spécifications de Vega 2 existantes en syntaxe de Vega 5.
7. Implémenter un message similaire à celui décrit par Pietrasagh demandant aux gens de migrer les graphiques basés sur Vega 2 vers Vega 5.

Phase 3 : Définir les responsabilités de maintenance et la réponse aux incidents sécuritaires

Objectif

Définir à quoi les bénévoles doivent pouvoir s'attendre quant au niveau de support de maintenance fourni, qui doit être responsable de fournir de support, et comment nous répondrons aux incidents sécuritaires au fur et à mesure de manière à ce que l'équipe permanente se sente sereine de déployer l'extension et les bénévoles sereins de dépendre d'elle.

Étapes

1. Déterminer qui au sein de la Fondation WikiMédia sera responsable de la réponse aux incidents sécuritaires à l'avenir.
2. Définir une stratégie de maintenance et de support établissant clairement ce à quoi les bénévoles pourront s'attendre de la part de la Fondation Wikimédia concernant l'extension Graph à l'avenir et quelle‧s équipe‧s seront responsables de ce support, et donc de ses mises-à-niveau vers les versions futures de Vega ainsi que des autres tâches listées en Phase 5.

Phase 4 : Déployer en production l'extension Graph (Vega 5) en l'isolant dans un cadre d'intégration en bac-à-sable avec une stratégie de sécurité de contenu restrictive

Objectifs

Offrir aux bénévoles l'accès aux informations et aux capacités dont la désactivation de l'extension Graph les a privés.

Développer les ressources (documentation + outils) nécessaires pour soutenir les efforts de migration des bénévoles.

Étapes

1. En collaboration avec les bénévoles, créer une page "Migration vers Vega 5" qui renvoie à la fois à la documentation d'origine sur la migration de la version 2 à la version 5 ainsi qu'à des informations spécifiques relatives à l'extension Graph. Par exemple, des modifications apportées aux protocoles, aux meilleures pratiques de wiki, aux modèles et modules connexes, etc.
   1. Si approprié, la documentation peut également mentionner le moyen d'accéder à la "dernière" version de Vega 2 du graphique à migrer depuis archive.org.
2. Avec la communauté, migrer les modules Lua existants générant une sortie en Vega 2 pour qu'ils émettent une sortie en Vega 5 à la place.
3. Portant les graphes en Vega 2 existants vers Vega 5 et offrir des outils qui aident à faciliter cette transition.
4. Construire un catalogue plus robuste des cas d'utilisation et de ce sur quoi les fonctionnalités de Vega peuvent être reliées.

Phase 5: Optimize the Graph Extension's longevity

Objectif

Optimize the Graph Extension's longevity and support the community building graphs on Wikimedia projects.

Étapes

1. Deprecate, and then remove support for Vega 2 from the codebase, creating categories or linter tags to mark any remaining Vega 2 graphs.
2. Formally transfer Graph Extension maintenance responsibilities to a Wikimedia Foundation engineering team.
3. Create tools and document processes to facilitate routine updates to Vega from upstream for minor/patch/security releases and commit to an appropriate SLA.

FAQ

1. When can we expect to see a timeline for the Roadmap above?
   1. The team expects there to be a timeline to share during the first or second week of November 2023. By this time, we think we will know whether volunteers see any fundamental issues with the roadmap that warrant it being revised.
2. Once re-enabled, will the Graph Extension support pseudo-protocols? Yes. Once the Graph Extension is re-enabled, it will support the protocols already implemented in T335325. Of course, if there are particular ones you think ought to be supported, we'd value you naming them and sharing why on the talk page, as Snævar, Bawolff, Nikki, and Pietrasagh have started doing. Please note: protocol support is a notably fragile part of the Graph Extension. If/when we come to learn this facet of the extension is causing problems, we might need to disable protocol support.
3. How much time – if any – will elapse between the Graph Extension being re-enabled with support for Vega 5 and support for Vega 2 being discontinued? In short, we do not yet know when support for Vega 2 will be discontinued. This is a timeline we (staff + volunteers) will need to define together. With the above said, here is what we are certain about at it relates to Vega 2 and Vega 5 support:
   1. Being able to provide guidance about when Vega 2 support will be discontinued depends on us first learning how the migration to Vega 5 is going.
   2. We do not plan to support Vega 2 graphs indefinitely
4. What can we do to preserve graphs that have not/can not be converted from Vega 2 to Vega 5? Converting graphs of this sort on a server that allows sandboxed rendering exposes security vulnerabilities the current approach is meant to mitigate. More details in T334940#9161842. With the above said, we estimate the graphs that have not/cannot be ported from Vega 2 to Vega 5 to be relatively small and comprised of:
   1. Graphs that use a custom protocol (e.g. Wikimedia API or WDQS) the sandboxed iFrame approach does not support.
   2. Graphs that can be ported, but no one has undertaken the work to do so.
5. Why do we think it's worthwhile to migrate from Vega 2 to Vega 5?
   1. Vega 2 has been superseded by Vega 3, 4, then 5 upstream.  Upstream and third-party documentation exclusively refers to syntax in “Vega version 3.0 and later”, and it is difficult for new contributors to find documentation relevant to Vega 2.  The last upstream release (bugfix or security) of Vega 2.x was in January 2017.  Vega 5 was released in March 2019 and is still under active maintenance and development, with the latest 5.25.0 release in April 2023.
   2. Volunteers have reported issues with Vega 2's accessibility, syntax, and overall functionality, per this 2023 wish.
   3. Vega 5 has made improvements to the library's expression layer that harden it from a security perspective compared to Vega 2.  It is not perfect, but by introducing a parsed expression grammar it offers a more robust foundation for additional security hardening in the future if it proves necessary.
   4. Maintaining multiple versions of Vega concurrently is unsustainable in the long run. The wiki community is taxed in the attempt to independently support software which is not being maintained upstream. Our efforts are best spent working in cooperation with upstream and third-party developers, and to do this we need to be working from the upstream Vega 5 code base.
6. What might be required to migrate graphs from Vega 2 to Vega 5?
   1. Create a converter that would migrate Vega 2-based graphs to be compatible with Vega 5. @Jdlrobson started work on an initial approach in T335048#8794138.  The initial work needs to be restructured slightly to refocus it on being an aid to manual porting, instead of the automatic translator which was its original goal. Note: We estimate this converter currently works for ~80% of graphs, with diminishing returns on additional engineering effort to cover more.  We do not plan on continuing to invest significant additional engineering resources here, but instead to simply repurpose the existing codebase as an aid to manual porting.
   2. Volunteers would need to update <graph> syntax on a case-by-case basis, aided by (1) the ability to run the existing Vega 2 and new Vega 5 specification side-by-side, (2) the partial Vega2-to-5 porting tool which handles 80% of the “obvious” keyword changes and other mechanical conversions, (3) the upstream Vega2 porting guide, and (4) additional documentation or tools which might be created by the wiki community.
   3. Update the limited number of Scribunto templates on-wiki which generate <graph> output in Vega 2 format to instead output Vega 5.  This requires both lua and Vega expertise, but fixes a larger number of Vega 2 uses on wiki at once.

Proposition

Afin de rétablir en toute sécurité l'accès aux informations et aux fonctionnalités dont la désactivation de l'extension Graph a privé les Wikimédiens·nes, et pour promouvoir la collaboration nécessaire à cela entre les bénévoles et le personnel de Wikimédia, nous, Fondation Wikimédia, nous engageons à :

Re-enable the Graph Extension in a sandboxed iFrame with a restrictive content security policy.

1. Once the Graph Extension is reenabled, it will continue to work with Vega 2 for a yet-to-be defined period of time. Note: we'll need to define this window together.
   1. After that "yet-to-be defined period of time," Vega 2 support will be discontinued and use of the Graph Extension will require volunteers to make graphs with Vega 5.
   2. As soon as possible, make the sandboxed Graph extension available on the beta cluster for testing. See: T346292.
2. Investigate the viability of adding logging to increase our awareness of instances where people are exploiting the security vulnerabilities inherent with restoring support for Vega on our platform. See T346414.
3. Publish the technical documentation needed for developers across the Movement to understand how we implemented the sandboxed CSP approach
4. Publish a clear timeline for when you all can expect all of the above to happen
5. Note: exploratory work to redeploy the Graph Extension in a sandboxed iframe has started. See T222807.
6. Share regular updates about the progress we're making on the commitments named above on Phabricator and MediaWiki.
7. Support volunteers with code and processes that will ease the transition from Vega 2 to Vega 5 when the time for this transition comes.

In support of the above, we'd need to depend on ya'll (volunteers) to:

1. Spread awareness of this proposal and the updates that will come as we start implementation, assuming this proposal moves forward.
2. Manually migrate some proportion of Vega 2-based graphs to be compatible with Vega 5. See the "questions 5 and 6 in the FAQ section".
3. Potentially, fix/port graphs that attempted to fetch live data using methods that the sandboxing approach inhibits.
   1. Note: the need for the above will become clear once we decide on whether we will restore the pseudo-protocols that were used to fetch data live from the action API, the REST API, WDQS etc, and the precise sandbox parameters we select (domains/ports/http methods allowed). This decision will be made in T346291.

Research

The research that informed the the proposal for safely and securely restoring access to the information and capabilities disabling the Graph Extension has left people without can be found here .