Plan Annuel de la Fondation Wikimédia/2025-2026/OKR des Produits & Technologies

This page is a translated version of the page Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs and the translation is 59% complete.

Outdated translations are marked like this.

L'année à venir

Même si le monde change, la Fondation Wikimédia reste convaincue que nous voulons que notre mission – rendre et maintenir disponibles sur internet gratuitement les informations utiles provenant des projets Wikimedia – soit un engagement plurigénérationnel : nous voulons que la connaissance libre continue d’être accessible à de nombreuses générations à venir.

Internet évolue rapidement. Les nouvelles générations obtiennent des informations via les vidéos sociales et les expériences d’IA, et, par rapport aux générations plus âgées, moins d’entre elles connaissent Wikipédia. Nous observons des baisses corrélées du nombre de personnes qui visitent nos sites et du nombre de personnes qui contribuent. Parallèlement, des plateformes à travers internet s’appuient sur le contenu Wikimédia pour étayer leurs offres d’IA et de recherche. Ces dynamiques constituent des défis majeurs, mais elles montrent clairement pourquoi la connaissance libre et fiable que nous créons ensemble est si importante. Le monde a plus que jamais besoin d’une source de connaissance fiable, revue par des humains, et les projets Wikimédia continuent de démontrer qu’ils peuvent la fournir.

Pour relever ces défis au cours de l’année à venir, nous créerons des voies permettant d’exploiter durablement le contenu Wikimédia, et nous porterons ce contenu dans les espaces sociaux en ligne où les nouvelles générations passent leur temps. Nous améliorerons nos propres sites afin que les lecteurs aient envie de revenir, de s’engager profondément et de contribuer de manière qui leur est significative. Et nous investirons dans notre capacité à expérimenter rapidement avec de nouvelles technologies, afin que notre rythme de développement suive celui auquel le monde change.

L’objectif d’infrastructure décrit la manière dont la plateforme et l’expérience utilisateur soutiendront la réponse à ces défis et permettront d’atteindre la majorité des participants au mouvement. Il ne s’agit pas d’une liste de projets, mais d’un ensemble de directions visant à stimuler la croissance des bénévoles, à permettre aux bénévoles de créer un contenu encyclopédique fiable, à financer notre mission et à faire évoluer notre offre pour façonner l’internet en mutation. Vous pouvez en savoir plus sur ces quatre piliers stratégiques.

Favoriser le développement du bénévolat

La communauté des bénévoles est le moteur unique du succès des projets Wikimédia, et nous avons besoin qu'elle soit en bonne santé et qu'elle se développe. Mais au cours de l'année écoulée, nous avons constaté une baisse continue du nombre de nouveaux éditeurs et de ceux qui reviennent sur les projets. Afin de mieux comprendre les besoins de nos bénévoles actuels et d'y répondre plus efficacement, la Fondation a réorganisé la Community Wishlist, qui n'est plus une enquête annuelle, mais un processus d'admission toujours ouvert où les besoins des utilisateurs et les idées de projets peuvent alimenter le travail de plusieurs équipes de la Fondation. Nous avons regroupé les souhaits en « Domaines d'intérêt » et avons intégré trois de ces domaines d'intérêt dans les résultats clés du plan annuel. Nous avons également lancé un projet pilote de Conseil consultatif sur les produits et les technologies pour compléter les nombreuses conversations que les équipes de la Fondation ont avec les membres de la communauté, sur et hors wiki, tout au long de l'année. En outre, nous avons identifié des opportunités d'intégrer de nouvelles générations dans nos projets, comme le fait que les plus jeunes participent avec enthousiasme à d'autres espaces sociaux en ligne où ils disposent de moyens simples et conviviaux pour se connecter sur des sujets d'intérêt commun.

Au cours de l'année à venir, nous alimenterons la croissance du nombre de bénévoles en rendant la contribution plus facile et plus attrayante pour les nouvelles générations grâce à l'expansion de mobile-first (le mobile en premier), à de nouvelles façons d'éditer (« tâches structurées ») et à l'ajout de flux de travail intelligents qui facilitent l'édition mobile constructive pour les nouveaux contributeurs (« vérifications d'édition »). Afin d'engager et de fidéliser les bénévoles existants, nous proposerons des actions et des tâches recommandées et les présenterons dans un hub central qui facilitera l'organisation de l'activité sur le wiki. Nous utiliserons l'IA de manière réfléchie pour renforcer les bénévoles dans leur travail, en gardant toujours les humains dans la boucle et en donnant la priorité à la transparence. Pour les nouveaux bénévoles et les bénévoles expérimentés, nous créerons des moyens de se connecter et de travailler ensemble sur nos sites - inspirés par des campagnes et des WikiProjects réussis - leur permettant de trouver des éditeurs qui les apprécient et d'améliorer le contenu lié à leurs intérêts (aligné avec ce domaine d'intérêt de la liste de souhaits).

Fournir un contenu encyclopédique de confiance

À mesure que le contenu généré par IA se multiplie sur internet, le monde a plus que jamais besoin de contenu encyclopédique fiable. Nous souhaitons accroître les capacités des bénévoles à la fois pour créer de nouveaux contenus, garantir que les contenus existants restent fiables, et fournir du contenu fiable à une nouvelle génération de lecteurs aux besoins et préférences nouveaux.

Pour aider les bénévoles à créer de nouveaux contenus, nous nous appuierons sur les outils et flux de travail guidés existants (tels que l'outil de traduction de contenu), afin que les communautés, grandes ou petites, puissent couvrir des contenus essentiels. Pour garantir que le contenu existant reste digne de confiance, nous aiderons les bénévoles expérimentés à mieux gérer leur charge de travail croissante en étendant les outils qu'ils utilisent pour trouver les tâches qui requièrent leur attention - ce qui leur permettra de mettre à jour plus facilement les articles et d'annuler les modifications inutiles (en accord avec ce domaine d'intérêt de la liste de souhaits).

Nous aiderons également les fonctionnaires à défendre notre contenu en faisant apparaître de nouveaux signaux (au-delà des adresses IP) qui identifient les mauvais acteurs, ce qui permettra de bloquer les utilisateurs de manière à minimiser le blocage erroné des éditeurs de bonne foi.

Pour fournir un contenu encyclopédique à une nouvelle génération, nous mettrons en place des fonctionnalités qui aideront de nouveaux types de lecteurs à comprendre facilement les articles, les aideront à trouver les informations qui les intéressent et leur permettront de participer activement à la lecture. Ces changements ont pour but d'encourager les nouveaux lecteurs de Wikipédia à devenir des lecteurs assidus, et certains d'entre eux à devenir des donateurs (en accord avec ce domaine d'intérêt de la liste de souhaits).

Fournir un contenu digne de confiance signifie également soutenir un modèle de “connaissance en tant que service”, où l'ensemble de l'internet s'appuie sur le contenu de Wikimédia. Dans ce modèle, notre infrastructure n'est pas seulement une ressource précieuse pour les humains qui visitent notre site web, mais aussi pour les entreprises de recherche et d'intelligence artificielle, qui accèdent automatiquement à notre contenu en tant qu'entrées et sorties fondamentales de leurs produits. Ce type d'entreprises ne représente qu'une des nombreuses utilisations qui imposent de plus en plus une charge insoutenable à notre infrastructure. L'année dernière, une augmentation significative du volume de requêtes provenant d'outils de grattage et de bots a rendu plus urgente la correction de cette tendance. Nous devons établir des voies durables pour que les développeurs et les réutilisateurs accèdent au contenu de la connaissance afin que les humains soient prioritaires par rapport aux robots.

Financer l'avenir du 'libre'

Le département "Produits et technologies" joue un rôle important dans la pérennisation de notre mouvement. Au cours de l'année à venir, nous travaillerons en étroite collaboration avec l'équipe de collecte de fonds afin que nos donateurs bénéficient d'une expérience de plus en plus claire et gratifiante. Sur nos sites et nos applications mobiles, nous créerons des opportunités pour les lecteurs d'exprimer leur appréciation de Wikipédia en faisant un don, et nous construirons de nouvelles façons pour les donateurs de se sentir reconnus afin qu'ils continuent à faire des dons d'une année à l'autre.

Façonner un internet en mutation

Pour apporter la connaissance gratuite à tout le monde sur la planète, nous devons les rencontrer là où ils sont, avec les expériences qui les aident à apprendre. Les personnes âgées de 18 à 24 ans connaissent et utilisent moins Wikipédia que les générations qui les ont précédées. Ils apprennent et interagissent principalement avec des plateformes vidéo de courte durée, des personnalités en ligne de confiance, des jeux sociaux et, de plus en plus, des applications d'intelligence artificielle. Cette année, nous mettrons Wikipédia à la disposition de ces publics dans les lieux où ils passent du temps en ligne, afin qu'ils sachent que Wikipédia est une source de connaissances dignes de confiance et créées par des êtres humains. Nous allons accroître notre présence sur les plateformes vidéo populaires, en diffusant le contenu de Wikipédia et en générant une communauté dans ces espaces. Et nous explorerons des idées pour apporter les connaissances de Wikipédia dans les jeux et les plateformes sociales.

Au sein de l'infrastructure, cette activité est divisée en trois portefeuilles de travail (appelés « buckets ») : Expériences Wiki, Services de signaux et de données, et Audiences futures. Ces portefeuilles sont identiques à ceux de l'année dernière et de l'année précédente.

Dans l'ensemble, nous pensons que ce plan marque un moment crucial dans l'histoire d'Internet, nous permettant de veiller à ce que le contenu de la connaissance libre continue d'être accessible et façonné par toutes les générations. Nos objectifs et nos résultats clés montrent plus en détail la structure et le contenu de ce plan, et nous attendons avec impatience d'entendre les questions et les idées de toutes les communautés.

Construire, améliorer et maintenir l'infrastructure pour les projets Wikimédia et les bénévoles, en s'appuyant sur nos valeurs

"La Fondation rendra et maintiendra les informations utiles de ses projets disponibles sur Internet gratuitement et à perpétuité".

Les équipes Produit et Technologie consacrent une priorité permanente, tout au long de l'année, à la construction, à l'amélioration et à la maintenance de l'infrastructure qui sert les projets Wikimédia. Nous investissons dans l'hébergement des projets Wikimédia, dans le développement de logiciels libres et de systèmes de conception, ainsi que dans la maintenance et l'amélioration de l'infrastructure pour les produits de données et les modèles d'intelligence artificielle.

Une partie de notre travail essentiel porte sur les principes fondamentaux du développement et de l'hébergement d'un grand site web populaire. Nous hébergeons nos projets Wikimédia dans des centres de données, sur des serveurs et du matériel que nous achetons, installons et entretenons, connectés les uns aux autres et au reste de l'internet via un réseau à haut débit. Nous surveillons et ajoutons de la capacité là où c'est nécessaire, et nous rafraîchissons l'équipement lorsqu'il devient trop vieux. Par exemple, cette année, nous prévoyons d'augmenter notre capacité et de rafraîchir notre matériel dans nos centres de données d'Ashburn, en Virginie, et de Carrollton, au Texas.

Nous concevons et développons des logiciels libres (notamment MediaWiki). Nous utilisons et déployons également de nombreuses applications, bibliothèques et frameworks open-source tiers existants. Les bugs importants de nos logiciels sont traités en priorité et corrigés. La maintenance des logiciels libres nécessite un travail hautement qualifié de la part de personnes disposant d'une expertise particulière en matière de développement de logiciels libres, d'ingénierie de la fiabilité des sites (SRE), de gestion des produits, de gestion des programmes, de conception, etc. Notre personnel veille à ce que nos logiciels et nos systèmes soient à jour et s'adaptent à un environnement en constante évolution. Il s'agit notamment de moderniser notre code afin de continuer à bénéficier des correctifs de sécurité et de fonctionner correctement avec les nouveaux logiciels tiers. Par exemple, MediaWiki est écrit en PHP et, l'année dernière, nous avons migré de PHP 7.4 à PHP 8.1, ce qui a nécessité des changements à la fois dans le code et dans l'infrastructure où nous hébergeons nos sites et nos services. Cette année, nous allons poursuivre cet effort et migrer vers la version 8.3, en utilisant les leçons apprises et les outils développés lors de la mise à jour 8.1. La mise à jour rendra nos systèmes plus rapides pour les lecteurs, plus faciles à utiliser pour le personnel et les bénévoles, et plus sûrs pour tout le monde. Elle permettra également de gagner du temps pour les développements futurs grâce aux améliorations en matière de sécurité, de performances et d'assistance qui accompagnent les mises à jour linguistiques.

Pour que nos projets et notre contenu restent disponibles sur l'internet, aujourd'hui et à perpétuité, nos équipes consacrent une part importante de leurs efforts à garantir la haute disponibilité de nos sites et de nos services. L'un des aspects de ce travail porte sur la reprise après sinistre en cas d'événements catastrophiques ou malveillants. Par exemple, nous nous assurons que nous disposons de sauvegardes des données importantes et que nous sommes en mesure de les récupérer. De même, deux fois par an, nous testons notre capacité à basculer nos sites entre nos centres de données de manière automatisée, et nous corrigeons les problèmes que nous constatons. Un autre aspect de ce travail consiste à identifier et à s'adapter aux tendances évolutives des types et des volumes de trafic que nous recevons. Par exemple, face à la croissance sans précédent des scratchers automatisés, nous donnons la priorité aux travaux visant à garantir que nos sites et services restent accessibles aux utilisateurs humains, en adoptant une approche systématique pour établir des normes relatives à l'utilisation responsable de notre infrastructure.

Tous les travaux ne sont pas planifiés longtemps à l'avance. Nous réagissons également aux événements et incidents inattendus, tels que les pannes de site, les rapports de sécurité ou les incidents de sécurité, ou encore les attaques de vandalisme à grande échelle contre nos projets. Nous surveillons nos performances et les obstacles à notre accessibilité dans le monde entier (y compris les problèmes de connectivité Internet ou les blocages dus à la censure), et nous enquêtons sur toutes les anomalies que nous constatons. Certains de ces événements inattendus ou de ces problèmes récurrents amènent le personnel à donner la priorité à des projets de suivi à court terme visant à atténuer ou à prévenir complètement tout nouvel impact négatif. Par exemple, ce type d'efforts a été crucial pour permettre à nos projets Wikimédia de résister à des pics de trafic mondiaux dus à des événements d'actualité majeurs (par exemple, le décès de célébrités), grâce à une combinaison d'optimisation des performances, de reconception architecturale des zones de goulot d'étranglement et d'augmentation de la capacité. De même, les récentes améliorations apportées à la convivialité de nos outils et systèmes de gestion du trafic que nous recevons nous ont permis de réagir plus rapidement et plus efficacement à l'évolution des conditions. Ce type de travail d'adaptation fait partie intégrante de notre capacité à répondre aux événements émergents, souvent dans des délais très courts, et à garantir que nos projets et notre contenu restent disponibles.

Objectifs du département Produits et Technologie

Les objectifs présentés ici sont à l'état de brouillon et peuvent faire l'objet de commentaires et discussions.

Les Objectifs représentent une orientation de haut niveau.
les "Résultats Clés" (RC) représentent un moyen mesurable de suivre la réussite de leur objectifs.
Les "Hypothèses" sous-jacentes à chaque RC représentent le travail réel que nous effectuons pour tenter d'atteindre les résultats clés associés. Elles seront mises à jour dans ce document et sur les pages wiki du projet ou de l'équipe concernés, au fur et à mesure des connaissances acquises tout au long de l'année.
est pour la tâche que la Fondation priorise dans la Liste de souhaits de la communauté.

Expériences Wiki (EW)

Expériences des Contributeurs (EW1)

Objectif : Les contributions augmentent parce que les bénévoles se voient offrir des opportunités motivantes et comprennent l’impact de leurs actions. Discussion
- Contexte : Cet objectif servira de base à la mise en œuvre de la nouvelle stratégie des contributeurs, articulée autour de trois piliers : 1) offrir aux bénévoles un moyen centralisé d’organiser leur activité sur les wikis, 2) proposer des tâches plus petites et mieux définies afin d’apporter davantage de clarté et d’aider les bénévoles à réaliser leur plein potentiel, et 3) rendre la contribution plus valorisante.

Au cours de l’exercice 2025/2026, nous prévoyons de mettre en place l’infrastructure de base permettant aux bénévoles d’organiser de manière centralisée leur activité sur les wikis, en commençant par des actions spécifiquement destinées aux rédacteurs et modérateurs expérimentés. Dans les années suivantes, nous ajouterons des actions couvrant l’ensemble des rôles de contributeurs et aborderons de nouveaux domaines problématiques. Par ailleurs, nous continuerons d’investir dans les projets *Edit Check* et *Structured Tasks*, afin d’établir une base solide pour l’utilisation de l’intelligence artificielle à grande échelle, à la fois comme outil d’assistance pendant le processus de modification et comme moyen d’orienter les bénévoles vers des opportunités intéressantes. Enfin, nous investirons dans la valorisation de l’impact des bénévoles afin de leur offrir une expérience plus gratifiante.

- - Résultat clé WE1.1 : Augmenter de 4 % [ii] le taux auquel les éditeurs ayant ≤ 100 modifications cumulées publient des modifications constructives sur le web mobile [i], tel que mesuré par des expériences contrôlées (d’ici la fin du T2).
    - i. « Modifications constructives » = modifications apportées à des pages dans tout espace de noms principal de Wikipédia qui ne sont pas annulées dans les 48 heures suivant leur publication.
    - ii. T389403#10960480
    - Les nouveaux (ou plus récents) bénévoles rencontrent des difficultés à commencer à contribuer efficacement, en particulier ceux qui utilisent des appareils mobiles, où l’espace d’affichage est limité et l’attention souvent fragmentée.
    - Certains se lassent à cause du contexte, de la patience et des épreuves et erreurs nécessaires pour contribuer de manière constructive. D'autres n'ont pas encore eu l'occasion de le faire.
    - EW 1.1 va aborder ces questions en:
      - Mise en avant de suggestions de modifications
      - Offrir des conseils exploitables au cours de l'édition
      - Construisant plus de flux de travail liés à des tâches spécifiques
    - Au cœur de ces efforts se trouve la nécessité de trouver des moyens évolutifs de détecter comment les modifications en cours et le contenu existant pourraient être améliorés. Pour développer cette capacité, nous continuerons à expérimenter l'apprentissage automatique afin de déterminer comment il peut servir au mieux les éditeurs, quels que soient leur rôle et leur niveau d'expérience.
    - Méthodologie proposée pour l’évaluation des résultats clés (KR) : plateforme par plateforme, nous calculerons la proportion d’interventions que nous avons déployées et évaluées au moyen d’expérimentations contrôlées, et qui ont atteint ou dépassé l’objectif de modifications constructives fixé au début de l’année. Voir phab:T379285#10782051 pour la logique sous-jacente.
      - Remarque : au 30 juin 2025, le WE 1.1 compte deux expérimentations contrôlées prévues.
  - Résultat clé WE1.2 : Augmentation du nombre de collaborations sur les wikis de 55 % en glissement annuel d’ici la fin du T4.
    - Les contributeurs ont souvent du mal à trouver des occasions de collaborer les uns avec les autres, en particulier autour des sujets et des tâches qui les intéressent. Cela peut conduire à un sentiment de solitude sur les wikis pour les nouveaux arrivants, et cela peut conduire au burn-out pour les éditeurs expérimentés. De plus, l'impact des activités de collaboration est souvent incertain, ce qui peut conduire à moins de personnes voulant se joindre, organiser ou soutenir la collaboration sur les wikis.
    - Nous voulons rendre la valeur de la collaboration plus claire en faisant cela:
    1. Créer de nouvelles façons de partager l'impact des activités de collaboration sur les wikis
    2. Commencer à recueillir des données à l’échelle du mouvement sur l’impact des activités collaboratives
    3. Créer l'infrastructure de base pour suivre les contributions collaboratives, afin de pouvoir fournir de nouvelles façons innovantes de reconnaître et de récompenser les contributions à l'avenir
    - Les collaborations seront mesurées par le nombre de nouvelles activités créées via l’enregistrement d’événements dans l’extension Événements de campagne (CampaignEvents). L’objectif est qu’à la fin de ce résultat clé, nous comptions davantage d’utilisateurs des outils de l’extension et que nous disposions de nouvelles manières de mettre en avant l’impact des collaborations. Cela nous placera dans une position favorable pour relier notre infrastructure existante à d’autres moyens de reconnaissance et de valorisation du travail sur les wikis (comme le module d’impact, les remerciements, etc.).
    - Domaine d'intérêt de la liste de souhaits: Liste de souhaits de la communauté/Domaines d'intérêt/Connexion des contributeurs
  - Résultat clé WE1.3 : À la fin du troisième trimestre (T3), 10 % des contributeurs à qui on a présenté une page d'accueil destinée aux nouveaux modérateurs l'ont visitée deux semaines de suite.
    - Nous pensons que nous pouvons mieux faire pour mettre en avant les opportunités de contribution aux bénévoles. À long terme, nous croyons qu'une page d'accueil peut être utile à tout éditeur pour organiser son travail, trouver de nouvelles opportunités et comprendre son impact. Notre objectif pour l'exercice 25/26 est de proposer de nouvelles opportunités aux éditeurs expérimentés pour qu'ils entreprennent des tâches de modération auxquelles ils n'auraient pas nécessairement été exposés autrement.
    - Nous testerons d'abord cette théorie en comprenant dans quelle mesure les éditeurs expérimentés s'engageraient avec une page d'accueil, similaire à celle à laquelle les nouveaux arrivants ont accès.
    - Nous proposerons ensuite des activités de modération spécifiques (détails à déterminer) aux contributeurs qui sont nouveaux dans ce type d'action de modération, dans le but d'aider à réduire la charge des éditeurs expérimentés en diminuant les arriérés (sous un nouveau KR).
    - Si le concept de page d'accueil est couronné de succès, nous prévoyons de rendre cette page modulaire afin de répondre aux besoins des communautés. Ces modules pourraient inclure des éléments tels que faciliter la compréhension de leur impact par les éditeurs.
    - Notes sur la méthodologie:
    - Nous aurons une hypothèse pour définir notre public, qui fera partie de WE1.3.1.
    - Les "modérateurs" suivront la définition donnée dans Research:Develop a working definition for moderation activity and moderators, bien qu'un travail de suivi soit nécessaire pour affiner la définition quantitative.
    - La deuxième semaine sera définie en fonction du moment de la première visite de chaque utilisateur. Dans ce cas, nous examinerons tous les nouveaux modérateurs qui ont visité la page d'accueil pendant une période donnée, puis qui ont effectué au moins une autre visite (7 à 14 jours) par la suite.
    - Domaine d'intérêt de la liste de souhaits: Liste de souhaits de la communauté/Domaines d'intérêt/Priorisation des tâches
  - Résultat clé WE1.4 : Augmenter le pourcentage de visiteurs uniques qui consultent la liste de suivi et/ou les modifications récentes et qui cliquent pour afficher une modification.
    - Notre objectif est d'aider les éditeurs ayant effectué plus de 100 modifications à trouver et à ouvrir plus efficacement les modifications qui correspondent à leurs centres d'intérêt. Nous allons explorer le domaine prioritaire de la hiérarchisation des tâches, répondre aux souhaits dans ce domaine et solliciter des commentaires supplémentaires auprès des bénévoles sur la manière d'améliorer ces interfaces. Nous pouvons mesurer le succès en améliorant l'efficacité de chaque page pour « trouver du travail », définie par l'indicateur métrique des taux de clics.
  - Résultat clé WE1.5 : Définir et mettre en œuvre sept indicateurs hautement prioritaires [1] nécessaires pour suivre les progrès accomplis dans la réalisation des objectifs définis dans la stratégie des contributeurs d'ici la fin du quatrième trimestre (T4), en créant un tableau de bord et en mettant en œuvre des indicateurs mensuels sur l'activité des modérateurs.
    [1] Éditeurs fidélisés, activation constructive, modifications constructives, inscriptions de comptes, nouveaux venus fidélisés, éditeurs actifs par ancienneté, éditeurs actifs par niveau d'expérience.
    - La stratégie relative à l'expérience des contributeurs prévoit un effort sur trois à cinq ans visant à « stimuler la croissance du bénévolat » et à « accroître la fidélisation et l'activation » des contributeurs nouveaux et existants à travers trois grands axes d'activité :
    1. Simplifier la manière dont les bénévoles peuvent recevoir des recommandations, gérer leurs tâches et leurs centres d'intérêt, voir ce qui se passe sur les wikis et comprendre leur impact.
    2. Proposer des tâches structurées de manière appropriée afin d'apporter plus de clarté et d'aider les bénévoles à réaliser leur potentiel en optimisant les flux de travail que nous leur confions, notamment en continuant à investir dans la fourniture de conseils structurés et l'automatisation des tâches répétitives, avec un accent particulier sur l'expérience web mobile.
    3. Rendre la contribution significative en montrant aux bénévoles leur impact et en investissant dans des moyens de créer des liens humains et un environnement basé sur les commentaires positifs.
    - Un projet de stratégie de mesure a ensuite esquissé un vaste réseau d'indicateurs permettant de suivre cette théorie du changement. Il a conclu que la principale mesure du succès (« indicateur clé ») devrait être le nombre d'éditeurs fidélisés, complété par des indicateurs plus précis tels que l'activation constructive et l'intention des contributeurs de revenir, ainsi que des indicateurs « en aval » plus larges tels que les éditeurs actifs et la qualité du contenu. Nous devons nous assurer que ces indicateurs sont opérationnels et visibles dans un tableau de bord, afin de pouvoir suivre nos progrès dans la mise en œuvre de la stratégie.
  - Key result WE1.6: By the end of Q3, watchlist users can more easily organize their work and act more effectively on taking patrolling or editing action, as measured by qualitative feedback.
    - Our goal is to help editors with 100+ edits to more efficiently find edits that relate to their interests. We will explore the Task Prioritization Focus Area, deliver wishes in this area, and solicit additional feedback from volunteers on how to improve these surfaces.
  - Key result WE1.7: Primary: Achieve a ≥ 10% relative increase in the edit completion rate of qualified newcomer and Junior Contributor mobile edit sessions, based on controlled A/B test(s).[i]
    [i] Qualified edit session = edit session in which a logged-in user with ≤100 cumulative edits spent at least ≥2 seconds in VE's "ready" state.
    Guardrail: No meaningful decreases in constructive edit rate among mobile edits published by newcomer and Junior Contributors, based on controlled A/B test(s).
    - 150,000–200,000 times/day, someone will tap "Edit" on mobile web, wait for the editing interface to load, look around for at least 2 seconds, and then leave without doing anything. No keystrokes, no taps on the toolbar…nothing.
    - WE 1.7 will meet these "curious clicks" with clear, compelling, and structured edit suggestions that cause the people making them to experience the satisfaction, joy, and meaning that can come with making Wikipedia, the resource they chose to visit, a bit better.
  - Key result WE1.8: By the end of Q4, target a 5 percent overall relative increase in the mobile web account creation completion rate, with success measured by at least three controlled experiments achieving a minimum 2 percent relative improvement each.
    - Account creation is the gateway to meaningful participation on Wikimedia projects, yet it remains an outdated experience in the newcomer journey. The current flows impose high cognitive load, present limited or confusing value propositions, and rely on legacy interface patterns that no longer reflect contemporary expectations. As a result, many potential contributors disengage before they have a chance to join the community.
    - This initiative aims to modernize account creation, reduce friction for good faith contributors, and introduce thoughtful experiments that encourage registration at the moments where motivation is naturally highest. The work lays essential groundwork for long term improvements in newcomer activation, retention, and editor diversity.
    - We estimate a 5 percent relative increase in account creation on Wikipedia on mobile would translate to several thousand additional new accounts per month, and several hundred more retained new editors per month, based on current registration volumes.
  - Key result WE1.9: By the end of Q4, deliver one tangible product recommendation each for goal setting, newcomer progression, and recognition to enable junior contributors to stay engaged and evolve.
    - Background: we know that retention of junior contributors is quite low despite recent gains (data). We believe that a fundamental challenge for overcoming this low junior contributor retention is developing our platforms to help editors stay highly motivated to contribute – i.e. not just reducing the barrier to contribute but also making the experience rewarding. This is not trivial though – e.g., editors enter the project with varying motivations; interventions such as gamification that may boost initial engagement might not help with long-term retention.
    - Why now: much of the focus of Contributors Product teams to date has been related to reducing technical barriers to activation/engagement but there are a suite of upcoming projects that are more retention-focused – e.g., Progression System and Recognition. The research under this KR aims to get ahead of this implementation work and provide clear recommendations to Product teams in this space about how they should design their platforms to better support the diverse motivations of editors and increase long-term retention. This links back to key questions related to newcomers and junior editors in the Contributor Strategy.
    - Proposed KR scoring methodology: for each identified project (goal setting; progression system; recognition), we will make at least one concrete recommendation with implications for design. Research is experimental work and the projects may evolve over the course of the KR but we will keep in close communication with the relevant product teams. In practice, these recommendations may include insights about what is most demotivating for newcomers (things to avoid) what is most satisfying (things to emphasize), common "tripping points" in journeys that need to be addressed, strategies for getting through these challenges, etc. The recommendation should help the PM identify clear next steps for design and/or engineering.
  - Key result WE1.10: By the end of Q4, implement a new guided article creation flow where the survival rate of articles created by junior editors on mobile is 5% greater on each deployed wiki than articles created by other means while the volume of surviving articles stays the same or higher, as measured by a controlled experiment.
    - The Article guidance initiative aims to develop new approaches that support editors in creating initial, well-structured contributions to Wikipedia that align with community policies and content quality. As an initial intervention, a new workflow for article creation was implemented last quarter, based on community-editable outlines that encapsulate the guidance for specific types of articles. In Q4, the goal is to run an A/B test experiment to measure the impact on a set of pilot wikis to evaluate the impact. Since the guidance is community-dependent, the experiment preparations will requires collaboration with the communities of the pilot wikis to adapt the system to their needs.

Connaissances vitales (EW2)

Objectif: Rendre plus de connaissances vitales disponibles et bien illustrées dans toutes les langues et sur tous les sujets. Discussion
- Contexte de l'objectif: Cet objectif permettra d'augmenter le contenu en fonction de l'intérêt des contributeurs pour des sujets et des langues spécifiques, et de la demande des lecteurs pour des connaissances vitales bien illustrées. Les connaissances vitales sont un ensemble d'articles qui fournissent l'étendue et la profondeur des sujets nécessaires à un projet linguistique utilisable sur Wikipédia. Elles sont définies par les communautés en fonction de la notabilité, de la pertinence, du lectorat prévu et des liens entre les articles.
- Nous adopterons une approche socio-technique visant à améliorer l’efficacité des fonctionnalités, des outils et des processus sociaux. Nous nous appuierons sur des fonctionnalités produits à fort impact, telles que les tâches suggérées, la recherche de médias et la traduction de contenu, tout en facilitant l’intégration et le développement des Wikipédias de langues plus petites.

Nous soutiendrons les organisateurs Wikimédia qui recrutent, forment et accompagnent les contributeurs travaillant sur des objectifs de contenu communs à travers des structures collaboratives comme les WikiProjets et les campagnes. (Nous estimons qu’au moins 300 organisateurs sont actifs chaque trimestre.) Nous développerons également des relations avec les éditeurs les plus pertinents afin de lever les obstacles liés à l’accès aux sources. (Nous avons actuellement des partenariats avec plus de 100 des principales bases de données mondiales accessibles uniquement par abonnement.)

- Pour nous assurer que nos interventions ont un impact positif sur les connaissances essentielles, nous mesurerons à la fois l'augmentation du contenu privilégié par la communauté et la qualité de ce contenu, en examinant des facteurs tels que les taux d'annulations de modifications, et le nombre de citations et d'images.
  - Résultat clé EW2.1: D'ici la fin du 2ème trimestre (T2), expérimenter et évaluer 3 interventions qui aident les contributeurs à améliorer l'état du contenu vital de leurs Wikipédias.
    - Ce RC mettra en évidence les lacunes des mécanismes de modification, telles que la découverte d'images sur Wikipédia, la traduction de contenu et la création guidée de nouveaux articles. Nous mettrons également en œuvre et testerons une intervention socio-technique visant à soutenir l'activité de création de contenu pour les petites communautés linguistiques. Pour chaque hypothèse, le succès sera mesuré.
  - Résultat clé WE2.2 : d'ici la fin du quatrième trimestre (T4), mettre en place les capacités de la plateforme nécessaires pour valider notre capacité à soutenir la vision d'Abstract Wikipedia à grande échelle. Nous saurons que nous avons réussi si nous parvenons à montrer que le système produit un contenu encyclopédique riche et multilingue à l'aide de Wikidata et de la génération de langage naturel, qu'il est contrôlé par la communauté Wikimédia et qu'il reste performant lors de déploiements à grande échelle.
    - Maintenant que nous pouvons utiliser Wikidata pour produire du contenu basique en texte brut sur Wikipédia, la prochaine étape consiste à continuer à développer les capacités de la plateforme afin qu'elle puisse prendre en charge Wikipédia abstraite à grande échelle. La plateforme devra prendre en charge un contenu riche et multilingue pouvant être contrôlé par la communauté tout en restant performante à grande échelle. Il s'agit d'un objectif clé, car nous passons de 0 à 1.
  - Résultat clé WE2.3 : d'ici la fin du quatrième trimestre (T4), déployer une première version du nouveau wiki afin de permettre à la communauté de commencer à créer des articles abstraits.
    - Ce KR nous prépare à tester les capacités de la plateforme d'un wiki Abstract l'année prochaine. Le nouveau wiki autonome hébergera la bibliothèque d'articles abstraits construite sur Wikifunctions et fournira les capacités de plateforme nécessaires pour intégrer ultérieurement les articles abstraits dans Wikipédia.
  - Résultat clé WE2.4 : Aligner WMF et WMDE sur la définition du succès pour les améliorations apportées à l'infrastructure technique soutenant un cas d'utilisation critique de Wikidata d'ici la fin du deuxième trimestre (T2), y compris les indicateurs et les objectifs pour les exercices 2025-2026.
    - L'équipe WMF Wikidata Platform (WDP) a été créée et dotée en personnel (un chef de produit et un responsable technique) en août 2025. En tant que nouvel ajout à un programme développé depuis des années par les responsables techniques et produits de WMF et WMDE, cet objectif reflète notre intention de transférer la propriété du programme en harmonisant les cas d'utilisation, les dépendances et les critères clés de réussite. Cet objectif clé permettra de jeter les bases d'une compréhension mutuelle du problème, sur laquelle nous nous appuierons pendant le reste de l'exercice fiscal (mai 2026).
  - Key result WE2.5: By the end of Q4, our backend replacement has been stood up in parallel to Blazegraph and is capable of supporting the cutover of select users. We define “migration ready” for this KR as capable of supporting the pilot phase of our migration in Q1 of FY26-27.
    - Following the progress made towards defining the success criteria as a part of WE2.4, we are now shifting into execution mode. In the next two quarters, we will outline all of the variables associated with the Blazegraph cutover in a migration plan, determine which are critical for pilot launch, implement them in a new RDF database, and define the migration timeline for all requirements beyond our pilot personas. Our work between now and our target launch of a new WDQS backend (est. July 2026) will be guided by the requirements laid out in this plan.

Expériences des consommateurs (EW3)

Objectif: Les lecteurs de plusieurs générations s'engagent et restent engagés sur Wikipédia, ce qui se traduit par une augmentation mesurable de la fidélisation et de l'activité de donation. Discussion
- Contexte de l'Objectif: Cet objectif se concentrera sur la fidélisation de nouveaux lecteurs grâce à des formats de contenu innovants, sur les publics de base en renforçant les expériences de lecture familières, et sur la viabilité à long terme en approfondissant les liens avec les lecteurs et en diversifiant les dons. Il comprendra la poursuite de nos travaux visant à faciliter la découverte du contenu grâce à des fonctionnalités nouvelles et plus expérimentales telles que les résumés faits par IA ou les labyrinthes personnalisés. Il s'agira également de conserver et d'améliorer la qualité de l'expérience de lecture à un stade plus avancé et d'explorer la conservation de la lecture au moyen de listes de lecture et d'autres formes de participation non éditoriales. Pour les donateurs, ce travail continuera à se concentrer sur la diversification des sources de revenus au sein de la plateforme.
  - Résultat clé EW3.1: D'ici la fin du deuxième trimestre (T2), démontrer une augmentation pratiquement significative de la rétention des lecteurs déconnectés, telle que mesurée par des tests A/B d'une fonctionnalité par plateforme
    - Ce RC portera sur la poursuite des investissements dans des expériences qui optimisent les nouvelles façons de naviguer et d'apprendre le contenu, souvent par l'utilisation de nouvelles technologies et de nouveaux formats - en présentant le contenu existant d'une manière nouvelle et attrayante. Dans le cadre de cet exercice, nous aimerions continuer à expérimenter de nouvelles fonctionnalités tout en nous concentrant sur l'extension des expériences réussies à l'ensemble des wikis et des plateformes. Le travail effectué dans le cadre du RC s'étendra au site web mobile et sur ordinateur, ainsi qu'aux applications iOS et Android, et se concentrera sur la découverte de contenu (points d'entrée de navigation et recommandations) et sur les formats d'apprentissage adaptables (résumés assistés par la machine, remixage de contenu).
    - Domaine d'intérêt de la liste de souhaits: Nouvelles expériences de consommation
  - Résultat clé EW3.2: Augmenter le nombre de dons par des méthodes autres que les bannières ou les e-mails de 5% Année après année par plateforme grâce à des interventions sur les produits qui favorisent des connexions plus profondes et réduisent les frictions pour les donateurs d'ici la fin du 2ème trimestre (T2)
    - Ce RC nous permettra de continuer à explorer de nouveaux points d'entrée pour les dons et d'autres possibilités de convertir les lecteurs en donateurs et de les fidéliser en approfondissant leurs liens avec les wikis, y compris par un contenu plus personnalisé. Le RC se concentrera sur l'introduction de nouveaux points d'entrée et sur l'itération des points d'entrée existants sur les applications et le web, en collaboration avec l'équipe de collecte de fonds.
  - Résultat clé EW3.3: D'ici la fin du deuxième trimestre (T2), démontrer une augmentation pratiquement significative de la rétention des lecteurs connectés, telle que mesurée par des tests A/B d'une fonctionnalité par plateforme
    - Ce RC portera sur l'amélioration de l'expérience de lecture et d'apprentissage des lecteurs existants et expérimentés, dans le but de maintenir notre public actuel et d'approfondir leur connexion au site afin qu'ils puissent apprendre davantage, et d'être prêts et ouverts à prendre des chemins vers le don et la rédaction. Les travaux ici se concentreront sur l'amélioration de l'expérience de lecture sur le Web et les applications (amélioration de la lisibilité, meilleure navigation et découverte), ainsi que sur la construction et l'itération de nos offres de conservation et de personnalisation (listes de lecture, suggestions personnalisées, historique des utilisateurs et des articles, etc.)
  - Résultat clé WE3.4 : D’ici la fin du T4, éliminer tous les blocages identifiés pour les déploiements de sites cache à petite échelle (PoP) qui respectent nos normes actuelles de qualité de service et de sécurité, conformément à nos déploiements actuels de sites cache.
    - Ce RC se concentrera sur la démonstration du concept selon lequel nous pouvons améliorer les performances du site Web et réduire la latence pour nos lecteurs en simplifiant notre infrastructure de mise en cache et en améliorant les processus de déploiement d'un site de mise en cache en réduisant le temps de déploiement de base d'environ un an en moyenne à un trimestre au plus. L'objectif sera de compléter la simplification, de déployer un PoC, de mener une revue de sécurité et de compléter un résumé de décision sur le déploiement de nos caches de bord dans les nuages (clouds) publics. La diminution de la latence peut entraîner une augmentation prouvée des vues des pages et une base de lecteurs plus diversifiée géographiquement.
  - Résultat clé WE3.5 : améliorer l'identification des donateurs - en veillant à ce que tous les lecteurs consentants connectés puissent être identifiés par leur statut de donateur pour une expérience personnalisée d'ici la fin du 4ème trimestre (T4).
    - Nous mettrons en œuvre des stratégies d'identification des donateurs afin de garantir que tous les lecteurs consentants connectés puissent être identifiés par leur statut de donateur, ce qui permettra une expérience plus personnalisée et plus engageante. Les efforts d'identification des donateurs seront priorisés par le biais du 4ème trimestre (T4) afin de soutenir des initiatives de personnalisation et d'activation plus efficaces à l'avenir.
  - Résultat clé EW3.6: Finaliser, publier et communiquer une stratégie pour l'expérience du lecteur et du consommateur de Wikipédia sur toutes les plateformes d'ici la fin du quatrième trimestre (T4), avec des objectifs définis et des indicateurs de base, développés en collaboration avec les différents acteurs et la communauté, pour guider notre travail jusqu'en 2030.
    - Le travail sur la stratégie destinée aux utilisateurs se poursuivra, en mettant l’accent sur l’élaboration et la communication de cette stratégie en interne ainsi qu’auprès de la communauté, et sur la définition et la mise en place d’indicateurs clés pour les utilisateurs, accompagnés de leurs valeurs de référence.
  - Key result WE3.7: Increase the number of donations through non-banner or email methods by 10% YoY per platform through product interventions that foster deeper connections and reduce friction for donors by the end of Q4.
    - This KR will see us continue to explore new entry points for donation and other opportunities to convert readers into donors and retain them by deepening their connections to the wikis, including more personalized content. The KR will focus on introducing new entry points and iterating on existing entry points on apps and web, in collaboration with the fundraising team.
  - Key result WE3.8: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for active readers in a test environment, monitoring a guardrail appropriate for the feature.
    - This KR will focus on scaling features that showed promise in improving engaged reader retention (or related indicator metric) across web and apps, based on experiment results from Q1/Q2. This includes scaling of the reading list on web (to drive account creation and internal referral rate), activity tab on iOS (for account creation and retention), and a potential longer production analysis of activity tab on Android (already released) to validate feature retention improvements.
  - Key result WE3.9: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for logged-out casual readers in a test environment, monitoring a guardrail appropriate for the feature.
    - In this KR, we will scale successful experiments that have proven to provide a high value to readers, new and lapsed, who do not currently engage with wiki projects. We will scale improvements focused on logged-out reader experiences that support knowledge seeking- content discovery experiences, visual presentations and modalities for sharing (knowledge, content, topics of interest). This KR spans across mobile web and apps platforms (iOS and Android).
  - Key result WE3.10: By the end of Q4, perform at least one experiment per platform (web and apps) that shows a practically significant improvement in logged-out casual reader retention or another indicator metric over control (with casual reader retention defined as 21-day cumulative retention for web, and 14-day cumulative retention for apps).
    - We are continuing our investment in experiments that convey Wikipedia's value to readers, new and lapsed, who do not currently engage with wiki projects. We will look to test improvements to the logged-out reader experience focusing on content discovery (e.g., Minerva TOC, semantic search, Q&A), visual presentations (e.g., visually engaging link cards), and modalities for sharing (e.g., share action). This KR spans web (mobile and desktop, though with an emphasis on mobile due to the audience) and apps (iOS and Android).

Sûreté et sécurité (EW4)

Objectif: Que nos systèmes protègent mieux les comptes et les informations privées de nos rédacteurs.trices par défaut, tout en offrant davantage de voies aux rédacteurs.trices et aux utilisateurs ayant des droits étendus pour prévenir et répondre aux activités abusives. Discussion
Résultat clé EW4.1: Déployer un système de signalement d’incidents viable et fonctionnel sur toutes nos wikis, qui soit utilisé et accepté par leurs communautés, d’ici la fin du deuxième trimestre (T2).
- Garantir la sécurité et le bien-être des utilisateurs est une responsabilité fondamentale de notre plateforme. De nombreuses juridictions ont des règlements qui exigent que des plateformes en ligne comme la nôtre surveillent et prennent des mesures contre le harcèlement, le harcèlement en ligne et d'autres contenus nuisibles sur ces plateforme. En cas de non-respect de ces critères, ces dernières pourraient être soumises à des sanctions légales et réglementaires.
- Nous voulons permettre à nos utilisateurs de signaler des menaces immédiates de dommages par un mécanisme de signalisation facilement détectable et intuitif pour nous assurer de pouvoir en apprendre davantage sur ces incidents et prendre des mesures rapides si nécessaire. Il s'agit d'une étape vers la sécurité des utilisateurs lors de leur contribution à notre plateforme. Nous le faisons en mettant en place un système de déclaration d'incidents sur nos wikis.
Résultat clé WE4.2 : Renforcer la précision et l’efficacité des outils anti-abus, en déployant 2 améliorations d’ici la fin du T2.
- Nous devons, ensemble avec notre communauté, mieux détecter et prévenir les activités frauduleuses et malveillantes sur les wikis. Pour ce faire, nous augmenterons le nombre et la qualité des signaux disponibles sur la plateforme, les combinerons dans des outils mis à disposition des utilisateurs disposant de droits étendus et identifierons les endroits où nous pouvons appliquer des restrictions automatisées et sécurisées sur les activités suspectes.
- Nous voyons également des opportunités d'améliorer l'accessibilité de Wikipédia et de nos autres projets simultanément. Par exemple, l'un de nos projets consiste à remplacer le CAPTCHA autogéré très classique des wikis, qui empêche les utilisateurs de se connecter avant d'avoir résolu une énigme, par un service de notation des risques qui ne sollicite que rarement les utilisateurs. Ce service marquerait discrètement les comptes avec un niveau de suspicion que nous pourrions utiliser pour désactiver la fonctionnalité, et rendrait ce statut visible aux modérateurs hautement privilégiés afin de les aider dans leur travail.
- Plus généralement, les projets de Wikimédia dépendent fortement du blocage d'adresses IP pour limiter les abus commis par des acteurs malveillants. Ce blocage est de moins en moins efficace et impacte négativement les utilisateurs de bonne foi concernés par le blocage d'adresses et de plages d'IP. Dans ce RC, nous souhaitons améliorer les fonctionnalités existantes et proposer de nouveaux outils permettant un blocage plus précis et plus efficace des acteurs malveillants, réduisant ainsi les dommages collatéraux causés par ces blocages.
- Pour évaluer notre efficacité, nous examinerons les commentaires qualitatifs des bénévoles engagés dans le travail de lutte contre les abus, ainsi que des indicateurs quantitatifs tels que le taux de blocages d’IP déployés, l’adoption de mesures d’atténuation basées sur la réputation d’IP et les signaux des navigateurs, le taux d’interactions humaines probables lors du blocage d'un utilisateur, et l’adoption de nouveaux signaux dans les outils de lutte contre les abus.
- Les travaux dans ce RC impliquent une meilleure détection et une meilleure atténuation des faux-nez et des interdictions, la remontée d'informations sur le potentiel de dommages collatéraux, le renforcement de la détection des bots, la remontée de signaux aux bénévoles anti-abus, l'amélioration de l'efficacité des interfaces d'outils anti-abus, l'amélioration des mesures liées aux abus et la fourniture de suggestions d'activités de compte suspectes pour enquête aux vérificateurs d'utilisateurs.
Résultat clé EW4.3: Réduire de 50% le nombre d'attaques à grande échelle nécessitant une intervention humaine des ingénieurs en fiabilité des sites (par rapport à l'année dernière) d'ici la fin du quatrième trimestre (T4).
- L'évolution du paysage de l'internet, notamment la montée en puissance des réseaux de zombies à grande échelle et l'augmentation de la fréquence des attaques, a rendu obsolètes nos méthodes traditionnelles de limitation des abus à grande échelle. Ces attaques peuvent rendre nos sites indisponibles en inondant notre infrastructure de demandes, ou submerger la capacité de notre communauté à lutter contre le vandalisme à grande échelle. Ces attaques exercent également une pression déraisonnable sur nos rédacteurs privilégiés et notre communauté technique.
- Nous avons besoin en urgence d'améliorer notre capacité à détecter, résister et atténuer ou à arrêter ces attaques.
- Cette année, nous nous concentrerons principalement sur l'automatisation de la détection des adresses IP et des réseaux qui se livrent régulièrement à des attaques contre nous. Nous allons aussi travailler à réduire la quantité de chargement que ces entités persistantes et nuisibles sont autorisées à placer sur nos systèmes.
Résultat clé EW4.4: Déployer des comptes temporaires dans 100% de nos projets, de sorte à ce que les informations personnelles identifiables de nos rédacteurs.trices non connecté.es ne soient accessibles qu'à moins de 0,1% des utilisateurs enregistrés, d'ici la fin du deuxième trimestre (T2).
- Les comptes temporaires visent à améliorer la vie privée et, par conséquent, la sécurité de nos éditeurs non enregistrés en protégeant leurs informations personnelles (adresse IP) de la vue du public et en limitant l'accès à ceux qui en ont besoin à des fins de patrouille. En plus d'être une amélioration importante de la sécurité des utilisateurs, ce projet est également important pour répondre à diverses exigences réglementaires.
Résultat clé EW4.5: Évaluer l’impact de l’IA générative sur la confiance et la sécurité, et déterminer les interventions sur les produits pour tirer parti des opportunités et prévenir les menaces pour les projets Wikimédia, d’ici la fin du troisième trimestre (T3).
- L'utilisation de l'IA, et en particulier de l'IA générative, connaît une croissance rapide sur Internet. L'omniprésence de l'IA offre des opportunités en matière de confiance et de sécurité, mais aussi des menaces. Par exemple, la création de contenu est plus simple et moins coûteuse, mais la modération est plus complexe. De même, la recherche peut être menée avec beaucoup moins d'efforts, mais les hallucinations de l'IA sont plus difficiles à identifier.
- Ce projet vise à s'appuyer sur l'évaluation de l'impact du ML/IA sur les droits humain, en évaluant l'impact de l'IA sur la confiance et la sécurité au sein du paysage Wikimédia. Cela comprend:
  - Consulter les utilisateurs ayant des droits étendus.
  - Identifier des exemples d'abus assisté par l'IA générative et d'atténuations potentielles.
  - Identifier les opportunités d'apprentissage par machine pour réduire le fardeau sur les utilisateurs avec des droits étendus.
  - Mener des expériences pour comprendre sur quoi nous devrions nous concentrer afin d’avoir le plus d’impact.
Résultat clé EW4.6: Appliquer techniquement le fait que 100 % des privilèges permettant aux utilisateurs.trices d'effectuer des actions sensibles à la sécurité ou à la confidentialité ne peuvent être exécutés que par des comptes ayant activé l'authentification à deux facteurs, d'ici la fin du quatrième trimestre (T4).
- Nous devons renforcer la sécurité des comptes utilisateurs sur nos wikis, notamment pour les utilisateurs disposant d'autorisations sensibles. L'un des principaux objectifs est d'exiger que toute action sensible ne puisse être effectuée que par les utilisateurs ayant activé l'authentification à deux facteurs (2FA). Nous allons mettre en place un système plus extensible pour l'application des privilèges, qui évitera les audits et l'application manuelle de l'authentification à deux facteurs, et élargira les privilèges nécessitant l'activation de l'authentification à deux facteurs sur la plateforme.
- Dans ce cadre, nous améliorerons nos systèmes d'authentification et de récupération afin que nous (WMF) et nos utilisateurs puissions plus facilement adopter une approche plus stricte de l'authentification à deux facteurs. Nous étendrons la disponibilité générale de l'authentification à deux facteurs à l'ensemble de la plateforme, afin que chaque utilisateur puisse l'activer à sa guise et garantir son activation avant l'octroi de privilèges sensibles. Nous nous concentrerons également sur la réduction de la charge opérationnelle de nos systèmes de récupération et de support de compte, contribuant ainsi à rationaliser nos processus de réinitialisation et de récupération liés à la connexion aux comptes. Nous souhaitons également améliorer la convivialité de notre implémentation de l'authentification à deux facteurs, en offrant aux utilisateurs davantage d'options pour sécuriser leurs comptes et éviter les blocages accidentels.
Key result WE4.7: Publicly conclude our bot detection trial, by the end of Q4.
- This KR is a focused, one-quarter effort to evaluate the results of this trial, to decide inside WMF about whether to maintain and expand this system across our wikis, and to publicly publish the results of the trial and our path forward.
Key result WE4.8: Simplify the patrolling of temporary accounts, by making it quicker to identify and address abuse, by the end of Q4.
- The purpose of temporary accounts is to continue to safely support participation from good-faith unregistered editors. However, some anti-vandalism workflows became more complicated by the release of temporary accounts. To ensure temporary account vandalism can be sustainably managed, we will make it easier and quicker for patrollers to understand and respond to temporary-account activity, both good- and bad-faith.
  We will surface clusters of related temporary accounts to patrollers, while also exploring other interventions that could improve early identification and rapid response.
Key result WE4.9: Empower volunteer investigators to deter and block more inauthentic activity on wikis where they actively review flagged accounts, as measured by a 20% increase in the rate of mitigating actions on those accounts, by the end of Q4.
- For Q3 and Q4, recognizing the strategic potential that Suggested Investigations has demonstrated, we will invest in deploying new signals independent of bot detection, and will set aside time to prioritize a variety of efficiency and quality-of-life features that have been requested by SI users since its original MVP release.
Key result WE4.10: By the end of Q4, we'll increase hCaptcha bot detection coverage from 18% to 100% of account creations and from 18% to 90% of higher risk edits.
- In Q3, we concluded our hCaptcha trial, during which we enabled hCaptcha during account creation, and later expanded it to include new users on the desktop wikitext editor, on eight large Wikipedias, including English Wikipedia. Based on the results of that trial, we’re now expanding hCaptcha to more editing interfaces and more wikis. Our main priority will be expanding what we currently have to all wikis, but we’ll also focus on new avenues to (discussion tools, uploads), as well as categories of users whose actions will be protected by hCaptcha.
Key result WE4.11: By the end of Q4, complete an IRS trial on enwiki with a graduated deployment, reaching at least 50% of logged in users and resulting in 5 new reporting metrics.
- We are trialing an incident reporting system (IRS) on English Wikipedia that is designed to help less experienced community members more easily report potentially bad behavior to the community-managed place that can best deal with it. For more rare and severe cases, it also provides a form to directly report imminent threats of harm to the WMF Trust and Safety team.
- This trial will be primarily focused on calibrating the first use case: helping editors report potentially bad behavior, without overloading the system.
- During the trial, we will focus on monitoring the volume of new reports, checking that reports are routed correctly, and identifying any immediate issues. We will be coordinating closely with all community members to fix bugs if they arise, and to otherwise streamline the process. For example, we are exploring some ways to tighten the user experience and help people more directly submit their reports, which we may deploy and measure during the trial as well.
Key result WE4.12: By end of Q4, we will have defined a detection pipeline for classifiers that automatically detect English Wikipedia policy-prohibited content, and evaluated the impact of at least one classifier detecting at least one type of prohibited content, validated against community datasets, on its potential for reducing volunteer workload.
- We want to support volunteers and UWERs by reducing work needed to remove harmful content from the projects, to enable volunteers to handle more difficult cases.
- In this quarter, we want to gain experience in defining repeatable processes for building detection pipelines for different types of content, and take first steps to evaluate these pipelines safely on large projects (A/B tests, log-only mode deployments, etc). We will start with a focus on content that should very likely be suppressed, such as threats, or disclosure of personal information.
- We plan to expand on these initiatives in FY26-27 work as part of an overhaul of anti-abuse tooling that supports UWERs and volunteers in reducing the time to mitigation for bad-faith activity.

Utilisation responsable des infrastructures (EW5)

Objectif: Les développeurs et les réutilisateurs accèdent au contenu des connaissances de manière structurée, garantissant ainsi la durabilité de notre infrastructure et la réutilisation responsable du contenu. Discussion
- Contexte de l'objectif: Cet objectif porte sur l'établissement de voies pour une réutilisation responsable du contenu.
- Wikimédia héberge la plus grande collection de connaissances organisées par des humains sur Internet. Cela fait de notre infrastructure de connaissances une destination précieuse, non seulement pour les humains, mais aussi pour les consommateurs automatiques de données. Notre contenu alimente les moteurs de recherche, les plateformes de médias sociaux, le commerce électronique et, depuis l'essor de l'IA, sert à entraîner de larges modèles d'apprentissage automatique. Les consommateurs obtiennent des données en moissonnant les pages, en utilisant les API et en téléchargeant du contenu, généralement sans attribution. Dans un monde où le trafic est non authentifié, nous ne pouvons pas différencier de manière fiable un utilisateur d'un autre, ce qui limite considérablement notre capacité à favoriser et à imposer une utilisation responsable de notre infrastructure: Comment pouvons-nous continuer à soutenir notre communauté tout en limitant la consommation automatique de contenu? Comment pouvons-nous orienter les utilisateurs vers les canaux privilégiés et pris en charge? De quelles orientations avons-nous besoin pour encourager la réutilisation responsable du contenu? Comment pouvons-nous favoriser une expérience développeur cohérente et créer des produits qui répondent aux besoins des développeurs bénévoles, des employés et des réutilisateurs? Si ces questions ne sont pas toutes nouvelles, l'urgence d'y répondre s'est accrue de manière exponentielle: Depuis 2024, nous observons une augmentation spectaculaire du volume de demandes, principalement due aux robots de moissonnage qui collectent des données d'entraînement pour les flux de travail et les produits basés sur l'IA. La charge sur notre infrastructure n'est pas soutenable et met en péril l'accès humain au savoir: Nous devons agir maintenant pour rétablir un équilibre sain, afin de soutenir efficacement les projets Wikimédia et de garantir le succès durable de notre mission.
  - Résultat clé WE5.1 : D'ici la fin du quatrième trimestre (T4), 50 % des demandes adressées aux canaux d'accès programmatique peuvent être attribuées à un développeur ou à une application connus.
    - Nous disposons actuellement de moyens limités pour identifier les responsables du trafic automatisé et, contrairement aux wikis, peu de moyens pour contacter les utilisateurs ou réguler leur accès. Nous avons constaté une augmentation significative du volume de trafic automatisé externe, ce qui n'est pas viable pour nous et compromet l'accès humain aux connaissances. Nous souhaitons augmenter le pourcentage de trafic automatisé attribué aux comptes connus, en exigeant une authentification et une autorisation basées sur des niveaux d'accès hiérarchisés pour le moissonnage à haut volume et l'utilisation des API. Cela nous permettra d'identifier les personnes qui réutilisent le contenu à grande échelle, de protéger notre infrastructure et d'améliorer la gouvernance en matière d'utilisation équitable, tout en répondant plus efficacement à leurs besoins. Nous étudierons également comment mieux soutenir la communauté technique grâce à une expérience développeur plus cohérente, qui protège l'accès préférentiel des membres de la communauté et offre de nouvelles fonctionnalités aux développeurs.
  - Résultat clé EW5.2: D'ici la fin du quatrième trimestre (T4) 2025, 70% des points de terminaison de l'API Web Wikimédia seront pris en charge par une infrastructure commune.
    - Nous souhaitons améliorer l'expérience et la pérennité de nos parcours de développement en proposant des API web plus cohérentes, stables et faciles à découvrir pour tous les développeurs Wikimédia. Nous simplifierons nos offres d'API en introduisant une infrastructure plus centralisée pour les fonctionnalités clés des API, ce qui nous permettra de disposer de parcours et d'une gouvernance cohérents pour: Les spécifications et la documentation OpenAPI, l'identification et le contrôle d'accès des développeurs, l'application des politiques API, le routage, le contrôle des versions et la gestion des erreurs. En simplifiant nos offres d'API, nous rendrons la création d'outils, de robots, de projets de recherche et de fonctionnalités au service de la mission Wikimédia plus rapide, plus simple et plus agréable. Cette approche contribue à l'avenir multigénérationnel de la mission en réduisant les coûts de maintenance de l'infrastructure API, en améliorant la visibilité et le contrôle d'accès pour lutter contre les acteurs malveillants, et en favorisant une communauté de développeurs plus forte.
  - Résultat clé WE5.3 : D’ici la fin du T4, un nouveau cadre d’attribution pour le web, les applications, les assistants vocaux et les LLM sera publié et lié à travers les sites Wikimedia, avec deux démonstrations de réutilisation déployées qui génèrent un engagement mesurable, et un partenaire externe de réutilisation adoptant l’attribution conforme aux meilleures pratiques.
    - Pour renforcer l’attribution appropriée du contenu Wikimédia, nous fournirons des directives claires de bonnes pratiques favorisant une réutilisation responsable. Cela comprend la création d’un cadre d’attribution pour les principales plateformes (web, applications, assistants vocaux, multimédia) et la présentation d’au moins deux exemples concrets mettant en avant des usages exemplaires du contenu Wikimédia. Parmi les résultats attendus figurent notamment l’encouragement des organisations médiatiques à créditer les images de Wikimédia Commons, des moteurs de recherche à faire remonter plus efficacement les données pertinentes de Wikimédia, ou encore des assistants d’intelligence artificielle à intégrer les connaissances de Wikipédia de manière transparente et responsable, renforçant ainsi la confiance dans leur fiabilité. Le renforcement des pratiques d’attribution accroît non seulement la sensibilisation du public et la participation aux projets Wikimédia, mais contribue également à établir des modes responsables et innovants de réutilisation des connaissances, tout en décourageant les usages abusifs.
  - Résultat clé WE5.4: Réduire le volume de trafic généré par les moissonneurs de 20% en termes de taux de requêtes et de 30% en termes de bande passante
    - Le moissonnage a toujours existé: Les moteurs de recherche s'appuient sur Wikipédia pour fournir des informations à leurs utilisateurs depuis des décennies. Cependant, une autre motivation majeure est apparue récemment: Il s'agit du plus grand ensemble de connaissances multilingues et organisées disponible sur Internet, et c'est un outil fondamental pour entraîner les larges modèles linguistiques. Cela est vrai aussi bien pour notre contenu encyclopédique que pour notre base de données multimédia, Wikimedia Commons, précieuse pour les modèles d'apprentissage automatique générant des images.
    - En conséquence, nous avons constaté l'année dernière une augmentation significative du trafic de moissonnage, ainsi que des incidents liés à la stabilité du site: Nos ingénieurs en fiabilité du site ont dû appliquer au cas par cas des limitations de débit ou des interdictions répétées de robot d'exploration de données pour protéger notre infrastructure. Le moissonnage est devenu si important que notre bande passante sortante a augmenté de 50% en 2024. De plus, une analyse récente a montré qu'au moins 65% de nos requêtes les plus coûteuses (celles que nous ne pouvons pas traiter depuis nos serveurs de mise en cache et qui sont traitées depuis les bases de données principales) sont effectuées par des robots.
    - Nos ressources informatiques sont extrêmement limitées par rapport à la quantité de trafic que nous générons. Nous devons donc prioriser ceux à qui ces ressources sont destinées. Nous voulons privilégier la consommation humaine et donner la priorité au soutien des projets et des contributeurs Wikimédia avec nos ressources rares.

Accélérer le chemin vers les résultats du produit (EW6)

Objectif: Les développeurs de Wikimédia mettent rapidement et en toute confiance leurs produits à la disposition des utilisateurs finaux. Discussion
- Contexte de l'objectif: Pour atteindre efficacement les quatre piliers stratégiques, les développeurs de Wikimédia doivent consacrer leur temps et leurs efforts à des activités à fort impact qui permettent de livrer des produits de qualité le plus rapidement possible. Des flux de travail trop complexes, l'absence d'outils standardisés et des composants système non durables entravent ces résultats.
- Ce travail s'appuie sur la dynamique initiée lors des deux derniers plans annuels visant à faire évoluer MediaWiki en tant que plateforme, ainsi que les logiciels qui soutiennent son développement et son déploiement. Cette année, les travaux porteront sur la fourniture d'environnements de développement plus fiables, la simplification des flux de travail de préproduction et la réduction des risques liés à la plateforme et à l'infrastructure.
  - Résultat clé EW6.1: D'ici la fin du quatrième trimestre (T4), le nombre de bugs bloquant l’entraînement au delà des wikis de test est réduit de 10%
    - En 2024, les développeurs ont dû revoir leur travail à 144 reprises en raison d'urgences empêchant le déploiement de MediaWiki. Dans de nombreux cas, les bugs ont été détectés après le déploiement sur les wikis de test, ce qui signifie que le problème a potentiellement touché des milliards d'utilisateurs. Nous ne pouvons pas contrôler l'existence de bugs, mais les détecter plus tôt permettrait de réduire le travail de l'équipe centrale. Cela renforcerait également la confiance des développeurs quant à l'absence de problème critique lors du passage en production.
    - Nous détecterons ces bugs plus tôt en fournissant les environnements nécessaires aux développeurs pour livrer et tester leur code en toute confiance tout au long du cycle de développement et de déploiement. Nous devons également veiller à ce que ces améliorations ne se fassent pas au détriment de la rapidité du développement.
  - Résultat clé EW6.2: D'ici la fin du quatrième trimestre (T4), 4 étapes de la liste de contrôle de l'état de préparation à la production peuvent être exécutées sans intervention des ingénieurs en fiabilité des sites
    - Le déploiement d'un nouveau service ou d'une nouvelle fonctionnalité en production repose actuellement sur une liste de 24 étapes, chacune nécessitant généralement l'assistance des ingénieurs en fiabilité des sites (SRE). Nous avons mis en place le programme d'ambassadeurs SRE afin d'intervenir plus tôt dans le cycle de développement et de renforcer les capacités des équipes de développement. Cependant, de nombreuses tâches devraient être entièrement autogérées. En ce moment, cela représente un travail manuel, répétitif, automatisable et dont l'évolution est linéaire avec le nombre d'équipes de développement. Cette situation n'est pas durable à long terme pour l'équipe SRE.
    - Auparavant, une grande partie de ce travail était confiée aux équipes de développement grâce à un ensemble de bibliothèques communes et de bonnes pratiques partagées pour interagir avec notre plateforme. Ces ressources ont été abandonnées lors de la migration vers notre nouvelle infrastructure Kubernetes et ne sont pas directement remplacées. En fournissant des bibliothèques, une documentation et des formations similaires, applicables à nos méthodes de développement et de déploiement actuelles, nous pensons pouvoir réduire l'implication de l'équipe SRE avant le déploiement d'un nouveau service ou d'une nouvelle fonctionnalité en production.
  - Résultat clé EW6.3: D'ici la fin du quatrième trimestre (T4), 100% des pages vues de Wikipédia seront diffusées à travers Parsoid
    - Parsoid offre des fonctionnalités améliorées pour l'évolution du wikitexte et la durabilité de la plateforme. Maintenir deux analyseurs simultanément n'est pas viable à long terme, car cela augmente la dette technique et la complexité. De plus, le succès de certains nouveaux projets comme Wikifonctions dépend de la large disponibilité de Parsoid.
    - Nous avons étendu le déploiement à de plus petits projets et, cette année, nous serons prêts pour les versions de Wikipédia. La gestion de toutes les pages Wikipédia consultées via Parsoid constitue la prochaine étape la plus importante. Outre le déploiement lui-même, ce travail comprend également la résolution des problèmes de performance et une communication efficace sur l'impact auprès des lecteurs et des rédacteurs.
  - Résultat clé EW6.4: D'ici la fin du deuxième trimestre (T2), au moins deux risques identifiés menaçant notre capacité à continuer de déployer ou de faire évoluer les wikis seront atténués ou réduits à un niveau acceptable
    - Grâce à quelques initiatives ciblées, nous réduirons ou atténuerons plusieurs risques d’évolutivité, de fiabilité ou de sécurité que nous avons identifiés comme une menace potentielle probable pour la croissance et la durabilité de notre plateforme et de nos projets publics.
    - Par exemple, nous allons remanier la structure des bases de données principales de Commons afin que leur croissance ne soit pas limitée par la capacité des serveurs disponibles au cours des prochaines années. Nous allons également moderniser PHP, le langage de programmation qui alimente MediaWiki et les services associés. D'autres risques identifiés nécessiteront probablement la mise en œuvre de mesures de sécurité supplémentaires pour protéger et renforcer notre infrastructure.
  - Key result WE6.5: By the end of Q4, determine the feasibility of and next steps for scalable cross-wiki code collaboration and logged-in reader support.
    - One of the central features of wikis is collaborative content creation. In the context of the Wikimedia movement, the collaboration needs are very specific to the evolution of the projects and the challenges that arise at the scales that some of the larger projects operate in.
    - Code collaboration (cross-wiki or on-wiki) is a legitimate need and should be accommodated. This is less a single problem and more a problem space that includes several overlapping problems around code (templates & modules primarily) and solving problems in this space requires shared understanding around priorities that are most impactful.
    - With an experimentation mindset, we're exploring a leaner approach to test shared code libraries that could improve cross-wiki collaboration in a small and controlled environment. This means we will go through a phase of technical feasibility and scope exploration to approach the experiment roll-out in small iterations to collect insights that can help us decide how we want to tackle the aforementioned problem. Our intention is to demonstrate our learnings and progress in the Wikimedia Hackathon 2026.
    - Similarly, if we want to improve the experience of logged-in users, we need to know where the performance gains are, what product work will make demands, and what a sustainable approach will look like for this work next FY. Research in this area will set us up for starting platform work quickly next FY.
  - Key result WE6.6: By end of Q4, developers are able to get the results of MediaWiki Core CI in under 10 minutes.
    - Our current median CI cycle time baseline is over 24 minutes while a DevEx industry standard for high performing teams is 10 minutes or less.
    - To bridge this gap, we're planning to optimize the CI workflows, address main bottlenecks such us browser tests by optimizing how we run them, the underlying testing framework and its configuration.
    - By slashing median CI wait times from 24 to 10 minutes we ensure the rapid feedback loop needed to test and fix issues quickly, significantly accelerating iteration speed. Additionally, improving this metric speeds up merge times, shortening the time between a change being ready and being available for deployment, which directly contributes to the top-level OW5 metric of making it "easier and faster to build products".
  - Key result WE6.7: By end of Q1 of 2026-27 fiscal year, developers are able to test MediaWiki code in production within 1 day of it being merged.
    - Currently, on average developers can test their code on production ~4 days after merging. By shrinking this time, developers can test sooner, and by improving test environments they will have more confidence that their tests will result in fewer bugs reaching production.

Signaux et services de données (SDS)

Métriques (SDS1)

Objectif: Les preneurs de décision utilisent davantage de données opportunes et dignes de confiance afin d'éclairer les décisions stratégiques et relatives aux produits. Discussion
- Contexte objectif : Nous utilisons des mesures pour éclairer les décisions de la Fondation quant à l'orientation de nos efforts afin de servir au mieux le Mouvement. Cependant, certains de nos pipelines de données sont susceptibles de se rompre, ce qui entraîne des retards de livraison. Lorsque des problèmes de données apparaissent, nos délais d'identification et de résolution sont trop élevés. En outre, nombre de nos ensembles de données ne sont pas optimisés pour faciliter l'exploration des tendances et il manque des dimensions qui se sont révélées importantes pour l'interprétation des données. Ces problèmes ralentissent et limitent notre capacité à évaluer les mesures.
- Au cours de l'exercice 25-26, nous nous concentrerons sur des cas d'utilisation spécifiques du plan annuel afin de combler les lacunes en matière de qualité des données dans nos pipelines actuels, de mettre en place une infrastructure et des processus pour contrôler et résoudre les problèmes de qualité des données, et de fournir des outils permettant aux décideurs de comprendre les tendances.
- L'un des cas d'utilisation concerne la manière dont nous mesurons le trafic humain et le trafic automatisé. L'augmentation du trafic automatisé au cours des deux dernières années a rendu plus difficile la compréhension de la mesure dans laquelle les humains interagissent avec les projets de Wikimédia et y contribuent. Notre objectif est d'améliorer notre capacité à évaluer les modèles de trafic humain et de robots, qui sont des données critiques pour la planification et les décisions relatives aux produits.
  - Résultat clé SDS1.1 : D’ici la fin du premier trimestre (T1), les analystes utilisant les mesures de consultation des pages auront accès à des mesures de référence de la qualité des données ainsi qu’à des indicateurs de performance des heuristiques de détection du trafic automatisé.
    - Grâce aux hypothèses explorées dans ce RC, nous visons à identifier les lacunes de nos heuristiques actuelles de détection automatisée du trafic et à comprendre où elles ne parviennent pas à catégoriser correctement le trafic des pages vues. Ces informations permettront d'améliorer les flux qui génèrent et classent les mesures de consultation des pages. De plus, nous définirons des métriques de la qualité des données afin de contrôler et de mesurer les améliorations apportées à la précision des données.
    - Cet examen critique jettera les bases d'un examen critique ultérieur axé sur la mise en œuvre des améliorations nécessaires du pipeline identifiées ici. Les paramètres de qualité des données établis au cours de cette phase serviront de référence pour évaluer l'efficacité de ces améliorations futures.
  - Résultat clé SDS1.2 : D’ici la fin du premier trimestre (T1), le contenu de l’ensemble de données sur l’historique du contenu de MediaWiki sera disponible via une exportation de fichiers avec des garanties de livraison hebdomadaires (SLO). Les données exportées seront équivalentes à celles issues de l’ancien pipeline d’exportation XML Dumps 1.
    - L'objectif de l'exercice 24/25 KR 1.4 a été de supprimer la dépendance à l'égard des ensembles de données mediawiki_wikitext_history et mediawiki_wikitext_history_current mis à jour mensuellement pour les 3 pipelines en aval les plus pertinents et de fournir un ensemble de données alternatif avec des SLOs hebdomadaires garantis.
    - Bien que la version 1.4 de l'exercice 24/25 ait permis d'atténuer les problèmes de fiabilité pour les pipelines dépendants les plus importants, il reste des pipelines qui utilisent la source d'entrée héritée peu fiable. Ceux-ci devraient être migrés ainsi que la source d'entrée basée sur les fichiers vers l'ensemble de données historiques wikitext lui-même.
  - Résultat clé SDS1.3: À la fin du deuxième trimestre (T2), la détection des bots intègre un signal supplémentaire et génère des alertes automatisées en cas d'anomalies.
    - Au sein de la Fondation, les équipes prennent des décisions en matière de produits et de financement en se basant sur leur capacité à faire la différence entre les lecteurs humains et le trafic automatisé. La plateforme de données est le référentiel central pour les signaux de détection des bots et l'analyse par lots. Grâce aux hypothèses que nous avons formulées au cours des premier et deuxième trimestres (T1/T2), nous prévoyons de commencer à introduire de nouveaux signaux de détection des bots afin d'affiner notre analyse du trafic automatisé, et de rendre le processus d'introduction de nouveaux signaux à la fois efficace et reproductible.
  - Résultat clé SDS1.4: À la fin du deuxième trimestre (T2), les décideurs auront une compréhension claire de l'état actuel des informations fournies par nos indicateurs organisationnels. Nous saurons que nous avons réussi si nous fournissons un dossier de présentation prêt pour la réunion du conseil d'administration qui situe l'analyse de nos indicateurs à la fois dans l'écosystème Wikimédia et dans les tendances et les défis plus larges de l'Internet sur le marché.
    - Les informations tirées de nos indicateurs organisationnels sont utilisées pour prendre une multitude de décisions au sein de la fondation, notamment celles concernant la manière dont nous développons notre produit, dont nous allouons les ressources infrastructurelles et dont nous collectons des fonds. Parallèlement, le paysage de l'internet évolue, le trafic automatisé affectant particulièrement nos indicateurs. L'objectif est que les dirigeants de la fondation se présentent à la réunion du conseil d'administration de décembre avec un discours clair sur les menaces et les opportunités au sein de l'écosystème Wikimédia, étayé par une analyse fiable des indicateurs internes et des tendances externes. Nous pouvons présenter ce récit en recueillant des informations, des indicateurs et des données qui nous renseignent avec certitude sur :
      - Tendances observées dans nos mesures internes du lectorat (pages vues)
      - Tendances dans notre écosystème de contributeurs
      - Tendances issues de données externes et de benchmarks concurrents
      - Conclusions tirées d'études internes et externes et de recherches fiables
  - Key result SDS1.5: By the end of FY25-26 Q4, analytics bot detection will incorporate 2 signals calibrated against 1 trusted classification.
    - In Q1/Q2, SDS1.3 addressed the big gap in incident detection time and analyzed additional signals for bot detection. We learned that:
      - Modern and feasible signals come with a number of caveats and uncertainties that need to be expressed in our metrics.
      - Evaluating the quality of our model, as well as doing robust analysis of signals to enable future iteration, will require labeled data, trusted by definition and preferably sourced from independent systems (formerly called “ground truths”).

We will need knowledge and calibration from third-parties that specialize in this domain to be able to quantify our current state and prioritize future improvements.

- - - In Q3/Q4, we will follow that with three main deliverables:

- - - - Extend our pageview metric to incorporate a numerical confidence score in addition to the existing labels, computed from at least 2 new signals, which will allow analysts to quantify and convey the nuances of those signals.
      - Curate trusted labels, preferably sourced from a third-party that specializes in this domain, and use it to evaluate our current performance and better understand the new signals.
      - Operationalize a client-side signal, which remains the most promising internally developed detection method.
  - Key result SDS1.6: Deliver a Movement Insights report on a regular basis, with consistent coverage across readership, contributors, and content thematic areas. We’ll know we’re successful when we’ve established the following by the end of Q4:
    - A consistent delivery cadence
    - Most valuable content for our stakeholders
    - Areas for future automation
    - Today, critical signals about the health of the Wikimedia Movement are fragmented across systems and teams. Readership trends, contributor health, brand perception, SEO/AEO, and competitor intelligence are monitored independently, without a consistent process or systems to aid in interpreting them together. We have existing monthly metric monitoring processes but they don’t address the scope and focus that is needed by executive decision-makers. The Movement Trends Brief is a concise, recurring intelligence brief that provides leadership and product teams with a shared understanding of how the Wikimedia movement is evolving week over week. Rather than describing everything that happened, this communication answers the following questions consistently:
      - What meaningfully changed in the past week/2 weeks?
      - Have we learned anything new about existing trends that we’re questioning?
      - Why does it matter now?
      - What requires attention or action?
    - The brief is designed to support situational awareness and provide a forum to present deeper analysis. It surfaces early signals, connects related trends across various data sources, and creates an entry point to inform decision-making.

Plateforme d'expérimentation (SDS2)

Objectif: Les gestionnaires de produits peuvent évaluer rapidement, facilement et en toute confiance l'impact des changements de caractéristiques des produits sur Wikipédia. Discussion
- Contexte de l'objectif: Pour permettre et accélérer la prise de décisions fondées sur des données concernant le développement de fonctionnalités de produits, les gestionnaires de produits ont besoin d'une plateforme d'expérimentation dans laquelle ils peuvent définir des fonctionnalités, sélectionner des groupes d'utilisateurs et consulter les mesures d'impact. Il est essentiel d'accélérer le délai entre le lancement et l'analyse, car le raccourcissement du délai d'apprentissage accélérera l'expérimentation et, par conséquent, l'innovation. Les tâches manuelles et les approches personnalisées de la mesure ont été identifiées comme des obstacles à la rapidité. Le scénario idéal est que les gestionnaires de produits puissent passer du lancement de l'expérience à la découverte avec peu ou pas d'intervention manuelle de la part des ingénieurs et des analystes.
- Nous nous concentrons sur Wikipédia pour l'année à venir parce que c'est là que les expériences de base sont intéressée à expérimenter (la stratégie organisationnelle nous fait doubler sur Wikipédia), et parce que cela nous permet de nous concentrer et de signaler plus clairement avec quelles équipes et projets nous sommes engagés. D'autres équipes ont utilisé les composants de la plateforme d'expérience et peuvent continuer à le faire, mais cette utilisation ne sera pas au centre de cet objectif.
  - Résultat clé SDS2.1 : D'ici la fin du deuxième trimestre (T2), permettre la réalisation d'au moins deux cycles d'expérimentation complets à l'aide de la plateforme d'expérimentation.
    - Alors que l'organisation met de plus en plus l'accent sur des décisions de produits fondées sur des données, nous devons rendre l'expérimentation accessible à toutes les équipes de produits, et pas seulement à celles qui ont des compétences spécialisées. Les équipes produit ont besoin de normes, d'outils et d'infrastructures partagés qui leur permettent de :
      - Tester rapidement des idées auprès de notre base d'utilisateurs mondiale
      - Mesurer l'impact des modifications apportées aux produits à l'aide de paramètres normalisés
      - Partager les résultats de manière transparente avec les parties prenantes de notre mouvement
    - Pourquoi nous passons du nombre d'« équipes activées » au nombre d'« expériences achevées » :
    1. Alignement stratégique : Il s'agit de la principale mesure de succès de la plateforme.
    2. Approche fondée sur les données : Notre recherche sur les utilisateurs (en cours) suggère que l'état de préparation de l'équipe est variable au sein de l'organisation, tandis que nous savons que l'équipe Web a confirmé son intérêt pour deux expériences spécifiques.
    3. Optimisation des ressources : Le déploiement de notre plateforme MVP nécessitera une prise en main importante, ce qui rendra plus efficace à court terme de se concentrer sur les opportunités d'expérimentation plutôt que d'étendre le champ d'action à plusieurs équipes. Nous prévoyons d'avancer vers une version générale et ne voulons pas réinvestir dans la formation des équipes, si nous pouvons l'éviter.
    4. Orienté vers l'avenir : Le retour d'information sur les cycles d'expérimentation complets permettra d'améliorer notre plateforme plus efficacement que les enseignements tirés d'une adoption partielle ou incomplète. Au fur et à mesure que nous avançons vers la diffusion générale, le fait de se concentrer sur l'achèvement des expériences évite d'investir dans des approches temporaires qui devraient être redéveloppées.
    - Nous avons entrepris des recherches sur les utilisateurs afin de déterminer les besoins et les exigences de l'ensemble de l'équipe : une enquête et des entretiens sont prévus pour clarifier les besoins de l'équipe produit au cours de la deuxième quinzaine de mai 2025. Une fois cette recherche terminée, nous établirons un calendrier d'expérimentation qui pourra être utilisé pour fixer nos prochains objectifs et priorités en matière d'AC.
  - Key result SDS2.2: Before the end of Q3, results for at least one web experiment can be analyzed and viewed in GrowthBook.
    - After a long and arduous process, we finally made a decision to integrate GrowthBook as a third-party experimentation solution that offers experiment flagging, automated analysis, and dashboarding, with support for guardrail metrics. Experiment Platform intends to replace the UI to define and deploy experiments (1) and the experiment analytics pipeline (5) with GrowthBook.
    - Because of the risks associated with this integration, the Experiment Platform Team believes that GrowthBook should be integrated as an experiment analytics pipeline first because it's non-disruptive and because it's the greatest source of risk.
    - The architectural decisions we made during FY24/25 SDS2 and GrowthBook’s modularity allow us to replace parts of the Experimentation Lab out of order, i.e. WMF staff can define and deploy experiments with xLab UI while analyzing them with GrowthBook. Further, we can run the current experiment analytics pipeline and GrowthBook’s in parallel, which allows for side-by-side comparisons as well as User Acceptance Testing in real-world scenarios.
  - Key result SDS2.3: By the end of Q4, all new Test Kitchen experiments are configured in GrowthBook.
    - After having enabled WMF staff to use GrowthBook for analyzing experiment results, the Experiment Platform team held a design sprint to assess options for experiment configuration. The decision was to use GrowthBook as the source of truth for experiment configuration but keep Test Kitchen UI (TKUI) as the source of truth for instrument configuration.
      In making GrowthBook the source of truth for experiment configuration, we aim to:
      - Reduce coordination when running an experiment
      - Enable more frequent and repeatable experimentation
      - Clearly delineate between instruments and experiments
      - Move toward a mental model centered on metrics rather than instruments
  - Key result SDS2.4: At least 14 out of 20 product teams have used Test Kitchen to inform a strategic decision for an OKR initiative, by the end of Q4.
    - The work done under SDS2.1 revealed a critical insight: building an experiment platform is not enough — Product & Tech teams face some barriers to adoption. Even though teams see value, they often lack time, infrastructure, instrumentation, or confidence to begin. In addition to this, they may encounter technical blockers that will need to be addressed by thoughtful partnership.
    - KR SDS2.4 shifts our focus from building to scaling adoption. By continuing to partner with teams as they onboard onto the platform, overcoming technical barriers and providing hands-on migration support, we aim to consolidate experimentation onto Test Kitchen as the unified platform for product teams, enabling fast, self-service testing cycles that reduce dependence on engineering and analytics support.
    - This KR was planned after we decided to split SDS2.2 in two pieces of work, which is why the numbering was affected. SDS2.3 is an upcoming KR that is sequential to GrowthBook for Experiment Analytics.

Publics futurs (PF)

Publics futurs (PF1)

Objectif: La Fondation Wikimédia est dotée de recommandations sur les investissements stratégiques à poursuivre pour aider notre mouvement à servir de nouveaux publics dans un Internet en mutation. Discussion
- Contexte de l'objectif: En raison des changements constants dans la technologie et du comportement des utilisateurs en ligne (par exemple, la préférence croissante pour l'obtention d'informations via des applications sociales, la popularité des courtes vidéos éducatives, l'essor de l'IA générative), le mouvement Wikimédia est confronté à des défis pour attirer et fidéliser les lecteurs et les contributeurs. Ces changements offrent également des opportunités d'engager de nouveaux publics en créant et en diffusant des informations de nouvelles manières. Cependant, en tant que mouvement, nous n'avons pas une image claire, basée sur des données, des avantages et des compromis des différentes stratégies potentielles que nous pourrions poursuivre pour surmonter les défis ou saisir de nouvelles opportunités. Par exemple, devrions-nous...
  - Investir dans de nouvelles fonctionnalités importantes telles que les chatbots?
  - Ramener les connaissances et les voies de contribution à Wikimédia à des plateformes populaires de tiers?
  - Faire autre chose?
- Pour s'assurer que Wikimédia devienne un projet multigénérationnel, nous testerons des hypothèses pour mieux comprendre et recommander des stratégies prometteuses - pour la Fondation et le mouvement Wikimédia - à mettre en œuvre pour attirer et retenir les publics futurs.
  - Résultat clé PF1.1: Grâce aux idées et recommandations expérimentales des publics futurs, à la fin du troisième trimestre (T3), au moins un objectif ou un résultat clé d'une équipe n'appartenant pas aux publics futurs est présent dans le projet de plan annuel de l'année suivante.
    - Depuis 2020, la Fondation Wikimédia suit les tendances externes qui peuvent avoir un impact sur notre capacité à servir les générations futures de consommateurs et de contributeurs de connaissances et à rester un mouvement de connaissance libre prospère pour les générations à venir. L'équipe de publics futurs, une petite équipe de R&D, va:
      - Exécuter des expériences rapides et limitées dans le temps (en visant au moins 3 expériences par année fiscale) pour explorer les moyens de répondre à ces tendances
      - En se basant sur les résultats de l’expérimentation, formuler des recommandations pour de nouveaux investissements non expérimentaux que la WMF devrait poursuivre – c’est-à-dire de nouveaux produits ou programmes qui doivent être pris en charge par une ou plusieurs équipes complètes – au cours de notre période de planification annuelle régulière.
    - Ce résultat clé sera atteint si au moins un objectif ou un résultat clé appartenant à une équipe en dehors des publics futurs, et motivé par une recommandation des publics futurs figure dans le projet de plan annuel pour l'exercice à venir.

Vidéos sur les réseaux sociaux (PF2)

Objectif: Les jeunes (< 25 ans) aiment, apprennent, s'engagent et partagent le contenu de Wikipédia sur les plateformes où ils aiment passer du temps en ligne. Discussion
- Contexte de l'objectif: L'expérimentation des publics futurs avec des vidéos courtes au cours de cet exercice a montré que nous pouvons atteindre des publics plus jeunes à grande échelle sur ces plateformes, mais nos données sur la santé de la marque montrent que notre investissement actuel n'est pas suffisant pour contrer le déclin de la notoriété et de l'affinité avec Wikipédia parmi les publics de la génération Z.
- Afin de garantir que nous atteignons et impliquons efficacement cette génération, nous pensons que nous devrons recourir à diverses tactiques et accroître considérablement notre engagement dans des domaines tels que le marketing payant et les influenceurs, les campagnes créatives, la réactivité aux tendances et l’augmentation de notre niveau d’expérimentation sur ces canaux.
- Nous nous attendons à ce que les défis auxquels nous sommes confrontés nécessitent un investissement plus substantiel pour nous aider à les surmonter, notamment dans les efforts de communication et de marketing pour créer de l'engagement, ainsi que dans la collaboration interdépartementale pour créer de nouveaux produits et expériences visant à accroître la présence de la marque et du contenu de Wikipédia sur ces plateformes.
  - Résultat clé PF2.1: Générer 9 500 000 de vues à partir de contenu vidéo court sur toutes nos chaînes d'ici la fin du premier semestre.
    - Cette année, nous avons atteint environ un million de vues en trois mois après le lancement de courtes vidéos sur les chaînes @Wikipedia sur TikTok, Instagram et YouTube. D'ici le début du prochain exercice, nous prévoyons d'augmenter de nombre d'abonnés sur nos chaînes et de disposer de davantage d'idées pour créer des contenus efficaces et engageants, que nous pourrons mettre en pratique afin de toucher encore plus de spectateurs.
    - En fixant un objectif ambitieux au cours du premier semestre de l’année, nous espérons obtenir un impact plus significatif, permettre la création de nouvelles stratégies/processus pour faciliter le travail et être en mesure de plaider en faveur de ressources supplémentaires pour atteindre cet objectif.
  - Résultat clé FA2.2 : Augmenter notre audience hors plateforme sur TikTok pour passer du niveau intermédiaire (100 000 à 250 000 abonnés) au niveau macro (250 000 à 1 million d'abonnés) d'ici la fin de l'exercice 2025/2026 (juin 2026).
    - Nous nous situons actuellement dans la catégorie « Mid » sur TikTok (entre 100 000 et 250 000 abonnés), et notre objectif est d’atteindre la catégorie « Macro » (entre 250 000 et 1 million d’abonnés) d’ici la fin de l’exercice 2025/2026 (juin 2026). Ces catégories — Micro, Mid et Macro — constituent des références standard dans le secteur pour mesurer la taille et la portée d’un public.

Pour y parvenir, nous affinerons notre stratégie de contenu afin d’attirer davantage de membres de la génération Z et d’accroître notre visibilité globale grâce à une gestion communautaire renforcée. Les performances du premier semestre serviront à ajuster nos tactiques au second semestre afin d’accélérer la croissance et d’atteindre cet objectif.

- - Résultat clé PF2.3: Lancer un produit hors plateforme destiné aux nouvelles méthodes d'apprentissage/de consommation de médias des futurs publics et le mettre sur le marché grâce à une campagne collaborative de marketing de produit.
    - L'équipe des publics futurs mène généralement des expériences à petite échelle avec un marketing minimaliste/organique. Cette année, nous souhaitons consacrer du temps à une campagne marketing et produit à plus grande échelle, ciblant un public plus jeune hors plateforme.

Support produit et ingénierie (PES)

Support produit et ingénierie (PES1)

Objectif: Les équipes de produits et d'ingénierie de la WMF seront plus efficaces grâce à des processus améliorés, favorisant un changement positif dans notre culture. Discussion
- Contexte de l'objectif: Cet objectif vise à rendre les méthodes de travail de la Fondation Wikimédia plus rapides, plus intelligentes et plus performantes. Tout repose sur notre façon de travailler. Cela signifie réduire les frictions et les obstacles (inefficacités et erreurs) dans les processus, et obtenir un impact plus rapidement. Cet objectif vise également à développer des méthodes de travail applicables à l'ensemble du service et de l'organisation.
  - Résultat clé PES1.1: D'ici la fin du deuxième trimestre (T2), définir des objectifs de niveau de service (SLO) pour 6 services de production sur la base d'une grille de priorisation qui vise à maximiser notre apprentissage sur la manière de définir et d'utiliser les SLOs pour prendre des décisions éclairées concernant la priorisation des travaux liés à la fiabilité par les équipes impliquées.
    - Un objectif de niveau de service (SLO) est un accord entre les équipes concernées sur un niveau de service cible (fiabilité/performance) que les équipes collaborent pour atteindre (et ne pas dépasser de manière excessive). Il permet par exemple de déterminer quand les tâches de fiabilité ou de performance doivent être priorisées (ou dépriorisées) par une équipe de développement, ou ce qui constitue un problème. Les équipes doivent veiller à identifier ce qui est immédiat (alertes/réponse aux incidents/bugs critiques) et ce qui ne l'est pas. L'objectif est de réduire les frictions entre les fonctions en négociant des objectifs et en établissant une priorisation claire et partagée.
  - Résultat clé PES1.2: D'ici la fin du deuxième trimestre (T2), les signaux de la communauté (y compris la liste de souhaits) auront incité la WMF à prioriser au moins 5 flux de travail de produits pour les troisième et quatrième trimestres (T3 - T4).
    - Notre but est d’identifier et de célébrer les moments où les équipes priorisent le travail sur la base de demandes communautaires fondées sur des données probantes.
    - Deux hypothèses prévues se concentrent exclusivement sur la liste de souhaits. Elles visent à renforcer la confiance, à rationaliser les processus et à accroître la participation du personnel et des bénévoles. Une autre hypothèse est une expérience visant à déterminer s'il y a suffisamment de signaux utiles provenant du bistrot, etc., et si l'IA peut soutenir notre capacité de collecte de signaux.
  - Résultat clé PES1.3: Deux expériences interdépartementales précoces, validées par nos publics externes de consommateurs, de donateurs et de contributeurs, sont intégrées par la Fondation dans le plan annuel.
    - Ce travail consiste à créer des expériences et des processus d’expérimentation destinés à être adoptés dans l’ensemble de notre organisation.
    - La Fondation renforce une culture d'expérimentation interdépartementale en intégrant deux expériences préliminaires validées à sa planification annuelle. Cette initiative favorise la collaboration au-delà des équipes dédiées aux produits et technologies, encourageant ainsi l'innovation avec d'autres services de l'organisation (tels que la communication et le développement). En suggérant de nouvelles idées non testées et en simplifiant les processus d'expérimentation, les équipes améliorent leur productivité et amplifient leur impact. La réussite se mesure par la réalisation de deux expériences interdépartementales par an, leur intégration aux futurs travaux ORC et l'adoption croissante de pratiques d'expérimentation. Parmi les résultats obtenus, on peut citer de nouveaux prototypes pour accroître la croissance et la productivité des nouveaux contributeurs, ainsi que des fonctionnalités expérimentales qui renforcent le lien entre les lecteurs et les donateurs de Wikipédia. Une opportunité spécifique identifiée est de relier de petites explorations de fonctionnalités pour célébrer le 25ème anniversaire de Wikipédia.
  - Key result PES1.4: By the end of Q4, we'll see a 10% adoption rate increase for Codex among P&T teams.
    - As a standardized UI library, Codex vastly reduces both the maintenance burden of creating custom UI components, as well as the time needed for implementing product UIs. Codex also provides a shared vocabulary for talking about design and implementation, which increases efficiency between Design & Engineering.
    - Codex will lose utility if adoption doesn’t increase and Codex isn’t widely used, and currently it is not being adopted or widely used in some places because the tooling isn't ready for some use cases. It may also need more prominent advertising/awareness. This work is a priority because teams must be able to adopt Codex organically, and currently not all can without blockers to adoption being addressed first.
    - We're anticipating that this will mean:
      - Discovery - What do different teams show us is blocking them? What are the use cases and blockers about which we are not yet aware?
      - Improvement - Example: We know that Codex PHP 1.0 will unblock server-side adoption.
      - Metrics deep dive - Example: What do the baseline metrics established in Q1 tell us about where organic adoption is not working (and are there lessons from OOUI adoption in years past)?
    - The KR will focus on tracking “official” usage (i.e. adoption that follows the documented guidance) separately from partial or piecemeal usage, e.g. when teams use only part of a component or just the CSS. The latter type of adoption incurs a higher maintenance cost than out-of-the-box component usage.
  - Key result PES1.5: 20% of service SLOs result in an impactful decision made by the end of Q4.
    - Service Level Objectives (SLOs) are a tool used to determine priorities based on data from service reliability. For instance, whether a down service needs immediate attention. SLOs work most effectively when ownership is clear, and everyone is using them. To make this happen we need to shift development culture toward adopting SLOs for every service. Building on the last few quarters of creating SLOs and testing them with service teams, we've identified an opportunity to clarify the value of SLOs, so that we can continue to spread this culture.
      - We have 19 SLOs currently.
      - We want to incentivize SLOs for services that would be most likely to leverage them. If we get ~3-4 (~20% 0f 19) "impactful decisions" from our current crop, great, but we anticipate we'll need to make more. The denominator will increase, but that further incentivizes targeting the right services.
      - Q4 is the end of the timebox because we want more than one cycle of data, and each quarter is a cycle. It also gives us space to shore up tooling, pilot SRE-alerting, etc.
    - Success looks like:
      - Impactful decision = “is this service currently reliable enough, or do we need to prioritize work to fix it” -- that is, it's as much a decision to find an error and say it's OK not to prioritize it, as it is to find an error and prioritize correcting it.
      - We want decisions to be diverse (e.g. Architectural vs Organizational vs Implementation; or affirmative vs deciding not to do something), because this is about spreading the value of SLOs and shifting culture. All the same type of decision or all from the same team doesn't accomplish that, even if it's good.
      - Even if we don't meet the KR target, we hypothesize that we'll have learned valuable information about why (e.g. we're targeting the wrong services).
      - Important: 80% of our SLOs not having an impactful decision is not a failure state for those, because most of the time services should not be failing.
  - Key result PES1.6: 20% of critical unowned services, according to a risk analysis framework, get owners committed by the end of Q4.
    - Clear code and service ownership is critical to ensuring the Wikimedia Foundation’s technical infrastructure remains reliable, scalable, and secure. Addressing current gaps in ownership will improve accountability, enhance cross-team collaboration, fast-track effective decision-making, and reduce risks to platform stability, security and sustainability. Additionally, it will provide greater clarity for Wikimedia affiliates and volunteers, helping them understand who is responsible for maintaining and supporting key services.
      - We estimate there are ~20 critical services without owners.
      - We think we can assign 4 owners over 4 months during Q3/4. The first 2 months or so will be setting ourselves up for success with prep work.
      - We plan to develop a risk analysis framework to determine criticality, as part of hypothesis work under this KR.
  - Key result PES1.7: By the end of Q4, 85% of wishes have a response within 10 working days, and a monthly update is posted on the work we committed to implement.
    - Having revamped Wishlist triage in the first half of the year, we want to consistently demonstrate that volunteers are getting responses to their Wishes plus a monthly update consisting of what’s coming, what’s pending or blocked, and what’s being scoped. We will judge the metric by measuring response time on a rolling average over a month, and aim to sustain that for at least a month.

Hypothèses

Trimestre 1 (T1)

Le premier trimestre (T1) du plan annuel de la WMF couvre la période de juillet à septembre.

Hypothèses des expériences Wiki (EW) [ Résultats clés des EW ] Discussion
Abréviation de l'hypothèse	Texte du premier trimestre (T1)	Informations et discussion
WE1.1.1	Si nous demandons aux nouveaux bénévoles qui collent des textes provenant de sites externes de confirmer s'ils ont écrit le contenu qu'ils tentent d'ajouter, nous constaterons une diminution ≥ 10% du pourcentage de nouvelles modifications de contenu publiées par les nouveaux bénévoles qui sont annulées pour des raisons de WP:COPYVIO (et des politiques associées).
WE1.1.2	Si nous livrons une version bêta initiale de la modification suggérée “Améliorer le ton”, nous pourrons alors déterminer si ce nouveau format de modifications suggérées est un moyen efficace d’augmenter les modifications constructives pour les nouveaux contributeurs sans augmenter la charge de modération pour les patrouilleurs/réviseurs.
WE1.1.3	Si nous déployons un nouveau mode de suggestion ciblant les contributeurs expérimentés sur l'éditeur visuel (mobile + ordinateur) en tant que fonctionnalité bêta avec ≥ 3 nouvelles suggestions de modification, nous découvrirons quels ajustements, s'il y en a, doivent être effectués avant d'évaluer l'expérience avec de nouveaux bénévoles à travers une expérience contrôlée.
WE1.1.4	Si nous déployons la vérification des références sur en.wiki via une expérience contrôlée, nous verrons une augmentation ≥ 10 % des modifications constructives publiées par les nouveaux bénévoles et découvrirons s'il existe un soutien suffisant parmi les patrouilleurs et les modérateurs pour activer la fonctionnalité plus largement.
WE1.1.5	Si nous testons un système de progression via des prototypes de conception avec les nouveaux arrivants, nous pouvons alors identifier quels types de jalons, de conseils et de reconnaissance sont perçus comme les plus motivants et utiliser ces informations pour finaliser une conception pour une future expérimentation pilote de wiki.
WE1.1.6	Si nous étudions les principaux obstacles et facteurs techniques, sociaux et comportementaux à la modification Web mobile par le biais de recherches sur les utilisateurs et d'analyses de données, nous générerons au moins trois informations exploitables qui combleront les principales lacunes en matière de connaissances et renforceront notre capacité à prioriser en toute confiance les investissements dans les produits pour le second semestre de l'exercice fiscal 25/26 et au-delà.
WE1.2.1	Si nous créons une preuve de concept pour l'affichage des données de contribution collaborative sur les wikis, nous pouvons recueillir les commentaires d'au moins 30 contributeurs, avec 70% des répondants partageant que la fonctionnalité est utile et pourrait contribuer à stimuler la croissance collaborative.
WE1.3.1	Si nous utilisons les besoins identifiés à partir de recherches et de conceptions antérieures et partageons les premières maquettes des X modules de modération les plus influents, nous pouvons modifier la page d'accueil des actions de modération avec eux.
WE1.3.2	Si nous modifions la page d'accueil des nouveaux arrivants pour afficher de manière conditionnelle les modules de modération, nous pouvons alors prouver la faisabilité d'utiliser la page d'accueil pour les modérateurs.
WE1.4.1	Si nous apportons un nombre d'améliorations mentionnées dans T396489, nous réduirons de X% les lenteurs des requêtes de changements récents sur les wikis volumineux. Les outils de modération pourront alors déployer des modules de page d'accueil sur ces wikis sans problème particulier de performances de base de données.	T400696
WE2.1.1	Si nous invitons les locuteurs natifs des petites wikis à travers une bannière CentralNotice sur une Wikipédia à fort trafic dans leur région à contribuer aux modifications suggérées et à d'autres fonctionnalités de croissance, nous pouvons évaluer si cette approche attire de nouveaux locuteurs natifs et s'ils utilisent ces outils de modification pour améliorer le contenu vital.
WE2.1.2	Si nous avions développé et publié des suggestions de traduction adaptées aux nouveaux rédacteurs.trices, nous aurions alors été en mesure de tester si cette approche produit de meilleurs résultats de traduction par rapport à notre approche actuelle. Cela répond aux défis rencontrés par les nouveaux rédacteurs.trices, qui sont plus susceptibles de voir leurs articles supprimés. En les orientant vers la traduction de contenus plus faciles à gérer, l'objectif est de leur offrir une introduction moins complexe et plus accessible au processus de traduction. Les articles et sections de qualité pourraient présenter une complexité limitée en termes de formatage et de longueur globale.
WE2.1.3	Si nous en apprenons davantage sur l'expérience des rédacteurs lors de la création de nouveaux articles et sections (y compris les motivations, les points faibles et leur réaction aux nouvelles idées sur comment mieux les soutenir), nous découvrirons alors les besoins et les comportements des utilisateurs qui fournissent des informations et des stratégies exploitables pour informer le produit, la conception et l'ingénierie sur l'amélioration de l'expérience de création d'articles.
WE2.1.4	Si nous explorons, à travers des ateliers participatifs ou des entretiens, comment trois Wikipédias de taille moyenne abordent les lacunes et l’importance des connaissances, nous découvrirons des définitions de travail ou des concepts de cadrage pour les “connaissances vitales” qui sont pertinentes pour chaque communauté.
WE2.2.1	Si nous suivons le déploiement de Parsoid et intégrons Wikifonctions sur la plupart des Wiktionnaires et certaines Wikipédias à faible trafic, nous obtiendrons les tests dont nous avons besoin pour déployer en toute confiance sur des plus grandes wikis.
WE2.2.2	Si nous permettons à Wikifonctions de générer des tableaux HTML, des styles et des liens, nous démontrerons, à travers une fonction qui affiche un tableau de conjugaison, sa capacité à générer de nouvelles connaissances sur les Wiktionnaires au-delà des simples conversions.
WE2.2.3	Si nous ajoutons le support pour les entités Wikidata dans les appels de fonctions intégrées, nous activerons plus de 200 nouvelles fonctions capables de générer des phrases complètes à l'aide d'entités Wikidata, rendant les fonctions plus faciles à utiliser sur les projets de Wikimédia.
WE2.2.4	Si nous élaborons un plan d’architecture indiquant où le contenu abstrait sera hébergé et comment il interagira avec Wikipédia, nous serons mieux préparés à mettre en œuvre la plateforme Wikipédia abstraite pour augmenter la fourniture de contenu encyclopédique de haute qualité.
WE2.2.5	Si nous définissons et communiquons entre les équipes Produit et Technologie sur les besoins en citations nécessaires au contenu abstrait, nous serons en mesure de mener un travail inter-Wikimédia pour fournir des informations de provenance attachées au contenu abstrait, ce qui est crucial pour une adoption réussie sur toutes les wikis.
WE2.2.6	Si nous rendons notre format de requête interne au back-end plus expressif et concis, nous pouvons augmenter la stabilité du système, favorisant ainsi un déploiement plus large.
WE2.2.7	Si nous fournissons des fragments de prototypes en utilisant des appels de Wikidata et Wikifonctions pour générer des extraits de langage naturel, nous montrerons que nous sommes prêts pour le projet et serons prêts à ce qu'il soit utilisé pour former l'IA afin que les humains ne pensent pas beaucoup aux fonctions.
WE2.2.8	Si nous fournissons l'importation de déclarations Wikidata avec des qualificatifs, il sera possible de générer des faits à multiples facettes (faits nécessitant plus que simplement un sujet/prédicat/valeur à exprimer), ce qui inclut environ 50 % du contenu encyclopédique de Wikidata.
WE2.2.9	Si nous fournissons la mise en cache des entités Wikidata récupérées, nous réduirons d'au moins 50% le temps d'exécution moyen des fonctions basées sur le contenu de Wikidata, réduisant ainsi les délais d'attente et la frustration des utilisateurs.
WE2.2.10	Si nous fournissons un composant de sens de lexème Wikidata dans l'interface utilisateur de Wikifonctions, les contributeurs pourront alors identifier et sélectionner les lexèmes pertinents sans quitter la plateforme/Wikifonctions, réduisant ainsi le changement de contexte et permettant une création plus rapide et plus réussie de fonctions liées au langage.
WE2.2.11	Si nous abordons les résultats d'utilisabilité de la communauté Dagbani sur l'intégration de Wikifonctions sur Wikipédia, nous observerons que les rédacteurs.trices rencontrent moins ou aucun problème d'utilisabilité critique lors de l'insertion d'une fonction dans un article lors des tests.
WE3.1.1	Si nous effectuons un test A/B d'une version améliorée de la fonctionnalité de navigation par onglets, sur l'application IOS, nous constaterons une augmentation de 5% de l'utilisation sur plusieurs jours parmi les utilisateurs des onglets.
WE3.1.3	Si nous proposons aux utilisateurs une nouvelle façon de parcourir le contenu d'images ou de vidéos pertinentes dans les pages d'articles, nous constaterons un taux de clics d'au moins 3% parmi les utilisateurs à qui cette fonctionnalité est présentée.
WE3.1.4	Si nous montrons aux lecteurs plusieurs concepts pour parcourir le réseau de connaissances sur les wikis, nous obtiendrons une liste prioritaire de concepts à développer ultérieurement.
WE3.1.5	Si nous offrons aux internautes la possibilité de consulter une version traduite automatiquement d'un contenu Wikipédia non disponible dans leur langue, nous saurons si l'activité de lecture augmente, mesurée par une augmentation de 3% des interactions sur les pages, attirant ainsi les lecteurs vers la wiki en langue locale et potentiellement une augmentation de l'activité de rédaction locale. Ce test A/B contrôlé sera proposé pendant une durée maximale de six mois, dans 13 versions de Wikipédia avec consentement préalable, grâce aux services de traduction automatique ouverts déjà accessibles aux rédacteurs.trices de Wikipédia.
WE3.2.1	Si nous collaborons avec les équipes de collecte de fonds, nous développerons des présentations plus engageantes, intégrées et personnalisées pour les donateurs, dans le bilan de l'année iOS, comme le montrent les tests utilisateurs. Une hypothèse sera ensuite formulée au deuxième trimestre (T2) pour évaluer si le Bilan de l'année amélioré a généré 5% de dons supplémentaires par rapport au Bilan de l'année 2024.
WE3.2.2	Si nous demandons aux lecteurs d'applications Android sur les marchés hors campagne de configurer un rappel facultatif et personnalisable (montant et fréquence) pour les dons en fonction de leur utilisation de Wikipédia, nous constaterons une augmentation de 5% des dons du menu de l'application sur ces marchés.
WE3.2.3	Si nous exécutons une expérience de test A/B sur des utilisateurs déconnectés pour afficher des variantes subtiles du point d'entrée du don pour les appareils mobiles et les ordinateurs, nous observerons un nombre de dons de 2% plus élevé via les chemins de traitement, par rapport au contrôle.
WE3.3.1	Si nous ajoutons des éléments personnalisés à effort faible à moyen demandés par les utilisateurs iOS en 2024 à l'année 2025, nous constaterons une augmentation de 3% de la satisfaction par rapport à l'année dernière, mesurée par des tests d'utilisabilité ou des tests bêta.
WE3.3.2	Si nous étendons l’onglet de modification existant sur Android en un centre d’activités personnalisé qui inclut des informations sur la lecture et la participation non liée à la modification, nous constaterons une augmentation de 5% de l’engagement sur plusieurs jours avec l’onglet par rapport à la version originale.
WE3.3.3	Si nous introduisons au moins un avatar déverrouillable dans l'application Android pour les personnes ayant un compte (obtenu grâce à des actions de lecture significatives comme l'enregistrement d'un certain nombre d'articles), nous augmenterons l'engagement répété avec l'action associée par les utilisateurs connectés de 10% sur plusieurs jours.
WE3.3.4	Si nous donnons aux lecteurs connectés la possibilité d'enregistrer des articles dans une liste de lecture privée, nous prévoyons une augmentation de l'engagement sur le site, mesurée par une augmentation de 5% du trafic de référence interne pour les lecteurs qui utilisent la fonctionnalité, et une augmentation statistiquement significative pour tous les utilisateurs.
WE3.3.5	Si nous menons une étude sur les utilisateurs qui permet aux lecteurs Web collecter/organiser le contenu de Wikipédia, alors au moins 10% des participants enregistreront deux ou plusieurs types de contenu distincts (par exemple, des articles, des extraits, des médias) dans une collection.
WE3.4.1	Si nous travaillons vers un déploiement hybride PoP/CDN, cela nous permettra de mettre en place à la fois des PoP complets et des mini PoP (physiques et cloud) selon les besoins, posant ainsi les bases d'un prototype de déploiement de mini PoP à l'avenir.
WE3.6.1	Si nous exécutons un test A/A sur le taux de rétention des utilisateurs déconnectés, nous établirons une base de référence pour le taux de rétention que nous pourrons utiliser pour les prochains trimestres.
WE3.6.2	Si nous créons et publions une définition de lecteur connecté, nous pourrons utiliser cette définition dans toutes les équipes et hypothèses liées au RC EW 3.3.
WE3.6.3	Si nous engageons les communautés dans des conversations sur l’évolution des besoins des lecteurs et sur la nature changeante des connaissances sur Internet, nous pouvons construire une vision commune sur la manière de servir les lecteurs et travailler ensemble sur l’opportunité et la manière de tester nos différentes idées (y compris celles autour du multimédia, de la recherche et de la découverte, et de l’apprentissage automatique).
WE3.6.4	Si nous étudions les différentes motivations, comportements et besoins qui sous-tendent quand, pourquoi et comment les lecteurs utilisent Wikipédia et d’autres plateformes de connaissances, nous aurons des résultats que nous pourrons utiliser pour informer et faire évoluer notre stratégie de consommation.
WE4.1.1	Si nous créons un prototype de flux non urgent minimalement viable et maintenons ouverte une boucle de rétroaction itérative pendant que nous le développons avec des utilisateurs ayant des droits étendus, alors ces groupes prendront en charge le déploiement étendu de ce flux.	Project page
WE4.2.1	En communiquant le niveau de risque hCaptcha associé à la création de comptes à des fonctionnaires de confiance, nous réduirons le temps nécessaire à l'identification des acteurs malveillants et augmenterons le nombre de détections de comptes créés sur la plateforme. La réussite de cette hypothèse peut être mesurée en examinant le taux de blocage des comptes, l'adéquation des niveaux de risque hCaptcha et des blocages de comptes en général, ainsi que les retours qualitatifs des fonctionnaires.
WE4.2.2	Si nous générons des suggestions d'enquêtes que les vérificateurs d'utilisateurs pourront suivre, nous constaterons une réduction du temps nécessaire à l'identification des comptes malveillants et une augmentation du nombre de comptes identifiés. Nous saurons que notre stratégie est efficace lorsque nous constaterons une utilisation régulière de la fonctionnalité “Enquêtes suggérées”, une augmentation des mesures d'atténuation appliquées aux comptes identifiés via les suggestions d'enquêtes et les retours d'enquêtes qualitatives.
WE4.2.3	Si nous analysons les données de l’essai de création de compte hCaptcha, nous comprendrons le processus de création de compte, l’efficacité du puzzle et des scores de hCaptcha, et nous disposerons des données nécessaires pour travailler sur le déploiement ultérieur de hCaptcha pour les créations de compte.
WE4.2.4	Si nous déployons la UserInfoCard sur toutes les wikis, nous donnerons aux fonctionnaires et aux modérateurs les moyens d'identifier et d'atténuer plus efficacement les comptes d'acteurs malveillants.	Project page
WE4.2.5	Si nous menons des recherches, consultons les communautés et étudions des solutions techniques, nous serons en mesure de définir un ensemble de raisons de blocage structurées qui pourront être utilisées sur toutes les wikis de la WMF.
WE4.2.6	Si nous développons la capacité de déployer des clusters basés sur OpenSearch sur la plateforme de données, les équipes d'ingénierie des fonctionnalités produit seront en mesure de développer des systèmes intégrant cette fonctionnalité, avec une grande autonomie et résilience, et une isolation par rapport aux autres systèmes de recherche. Le premier et principal locataire de ce système sera le service IPoid.
WE4.2.7	Si nous déployons l'intégration de hCaptcha Enterprise sur plusieurs Wikipédias de production en tant qu'essai pilote, nous pourrons collecter des données sur l'efficacité et la valeur de hCaptcha Enterprise en matière de lutte contre les abus, de détection de bots, d'utilisabilité et d'accessibilité.
WE4.3.1	Si nous intégrons le soutien du nouveau cookie Edge Uniques dans requestctl, notre moteur de règles Edge pour les SRE luttant contre les abus, nous serons mieux en mesure de nous défendre contre les attaques DDoS et la réutilisation de contenu.
WE4.4.1	Si nous pouvons apporter des améliorations en nous basant sur les projets pilotes et déployer des comptes temporaires sur tous les projets, nous serons en mesure de protéger l'exposition des informations personnellement identifiables (adresses IP) des utilisateurs non enregistrés sur tous nos projets afin qu'elles soient accessibles à moins de 0,1% de tous les utilisateurs (enregistrés).	Project page
WE4.4.2	Si nous communiquons clairement et à temps avec les parties prenantes concernées du mouvement (y compris les communautés wiki et les fonctionnaires globaux), nous pourrons déployer sur toutes les wikis restants, réduire la charge de travail découverte à la dernière minute et éviter de revenir en arrière dans le déploiement.
WE4.4.3	Si nous facilitons aux patrouilleurs le filtrage des actions et la visualisation de l'activité des comptes temporaires, en fonction de leurs adresses IP, nous permettrons alors le déploiement réussi des comptes temporaires sur toutes les wikis.
WE4.4.4	Si nous permettons à l'accès à la révélation de données IP temporaires d'être révoqué conformément à la politique d'accès aux données IP, et que la fonctionnalité apparaisse dans plus d'endroits, nous permettrons alors le déploiement réussi des comptes temporaires sur toutes les wikis.
WE4.5.1	Si nous menons des recherches qualitatives pour identifier des exemples d’abus de la part d’acteurs malveillants assistés par l’IA générative (tels que le spam, le harcèlement, les abuseurs à long terme, les modifications payantes non divulguées ou les campagnes de désinformation), nous serons en mesure d’évaluer le risque pour nos modèles communautaires et de générer des idées pour atténuer différents types d’abus assistés par l’IA générative.
WE4.6.1	Si nous automatisons le processus de synchronisation des comptes dans Zendesk pour les réinitialisations de mot de passe, cela allégera la charge de travail de l'équipe de confiance et sécurité et leur permettra de gérer davantage de demandes de réinitialisation 2FA entrantes.
WE4.6.2	Si nous soutenons et encourageons les utilisateurs à enregistrer plusieurs facteurs d'authentification, les utilisateurs avec 2FA activé seront moins susceptibles de se verrouiller et de se déconnecter de leur compte.
WE4.6.3	Si nous autorisons tous les utilisateurs disposant d'une adresse e-mail confirmée à pouvoir activer la 2FA pour leurs comptes, mais que nous n'annonçons pas proactivement ce changement aux utilisateurs, notre charge de travail au niveau du support de récupération restera à un niveau durable.
WE5.1.1	Si nous utilisons des backends de stockage différents pour les sessions authentifiées et anonymes, nous pourrons protéger Sessionstore des attaques DDoS et des gratteurs à haut volume, en ne le surchargeant pas avec les sessions anonymes créées pour fournir une prévention CSRF sur les pages d'authentification.	T398814
WE5.1.2	Si nous changeons les cookies de session MediaWiki en un format structuré avec une signature cryptographique, nous pourrons utiliser la présence d'une session comme facteur de protection contre les gratteurs, en permettant une vérification fiable des sessions à la périphérie de manière performante et hautement évolutive.	T398815
WE5.1.3	Si nous créons une solution de limitation de débit pour la passerelle API à l'aide d'un environnement de développement local basé sur Kubernetes, nous serons en mesure de déterminer la meilleure option à tester avec le trafic de production, en comparant les performances et les fonctionnalités d'au moins trois services de limitation de débit différents.	T398913
WE5.2.1	Si nous repensons l’interface utilisateur de l’API REST Sandbox pour mieux répondre aux besoins d’information des développeurs, nous améliorerons la clarté de la documentation, comme validé par des tests d’utilisabilité.
WE5.2.2	Si nous acheminons toutes les API sous rest.php via une passerelle centrale, nous débloquerons les moyens de gestion centralisée des API et pourrons commencer à mesurer de manière cohérente le trafic et les modèles d'utilisation de l'API REST pour obtenir des informations qui éclaireront les décisions et les actions futures.
WE5.2.3	Si nous mettons en œuvre des tableaux de bord de surveillance et des alarmes pour l’API REST de MediaWiki, nous pourrons alors démontrer une manière durable, utile et reproductible d’améliorer la visibilité du comportement de nos systèmes et de faire apparaître les problèmes plus tôt, en particulier lors de modifications critiques.
WE5.3.1	Si nous élargissons et rationalisons les directives d’attribution UX tout en mettant à jour les directives existantes, nous établirons un ensemble de directives améliorées prêtes à être testées en interne et affinées de manière itérative pour être préparées à une utilisation publique plus large.
WE5.3.2	Si nous créons un argumentaire qui démontre les avantages de l'attribution de Wikipédia aux réutilisateurs de contenu tiers et à leurs utilisateurs finaux, nous pouvons soutenir WME4.1 et WME4.2 en permettant à au moins un partenaire de réutilisation supplémentaire d'accepter d'apparaître dans une étude de cas ou une démonstration d'attribution d'ici la fin du premier trimestre.
WE5.4.1	Si nous garantissons qu'une majorité de requêtes Web reçoivent un cookie Edge unique, il sera plus facile d'identifier les bots et les requêtes falsifiées.
WE5.4.2	Si nous construisons un moyen évolutif d’identifier les clients connus, nous pouvons autoriser des exceptions aux limites générales de débit pour les bots d’origine vérifiée, et évoluer vers une application systématique de nos règles.
WE5.4.3	Si nous réorganisons le filtrage des requêtes de texte au niveau du CDN autour d'une approche de liste d'autorisation/de refus, nous pouvons appliquer une limitation générale du débit plus stricte pour les bots et rationaliser le filtrage du trafic.
WE5.4.4	Si nous développons une stratégie de mesure unifiée, nous permettrons d’évaluer la stratégie pluriannuelle pour 'l’utilisation responsable des infrastructures' et de définir une feuille de route pour guider le développement des mesures et les capacités de rapporter.
WE6.1.1	Si nous redirigeons les builds d'images quotidiennes sur le serveur de déploiement et ajoutons des mises à jour d'images déclenchées par des actions de déploiement sélectionnées, nous découvrirons les contraintes et établirons une base de référence pour le temps nécessaire pour effectuer des déploiements plus continus.
WE6.1.3	Si nous ajoutons des wiki fermes à un environnement de test de pré-fusion, cela permettra aux équipes de développement de construire par rapport à celles de production qui ont besoin de plusieurs wikis pour tester leurs correctifs de manière isolée, leur donnant une plus grande confiance en pré-production et entraînant moins d'échappements de défauts.
WE6.2.1	Si nous révisons et publions notre liste de vérification de préparation à la production qui définit clairement les conditions préalables pour qu'un service soit considéré comme prêt pour la production, ainsi que les tâches auto-entretenables, nous alignerons les attentes entre les ingénieurs en fiabilité des sites et les équipes de développement, améliorant ainsi notre efficacité opérationnelle globale et notre évolutivité.
WE6.2.2	Si nous annonçons la création d'une bibliothèque Golang et nodejs qui résume de nombreuses tâches fastidieuses pour les développeurs, ils répondront en offrant des commentaires et de l'intérêt.
WE6.2.3	En créant une liste de vérification/feuille de travail, les développeurs peuvent se préparer pleinement à l'avance à l'examen de conception de la persistance des données.
WE6.3.1	Si nous déployons au moins 70 Wikipédias à faible trafic au premier trimestre, sans compter les wikis avec support linguistique, nous augmenterons notre confiance dans le déploiement éventuel sur les 10 premières wikis, ce qui aura un impact plus important sur les pages vues servies via Parsoid.
WE6.4.1	Si nous déployons la table de liens de division de Commons dans son propre cluster, nous augmenterons les chances que la croissance de la base de données pour Commons reste durable.	T398709
WE6.4.2	Si nous (SRE) fournissons une assistance aux équipes d'ingénierie de MediaWiki - en créant la documentation, en préparant l'infrastructure nécessaire (par exemple, les packages PHP, les images de conteneurs) et en offrant des conseils et des révisions - ils seront en mesure de lancer en toute confiance la mise à niveau de production PHP 8.3 d'ici le début du deuxième trimestre.	T360995
WE6.4.3	Si nous exigeons un deuxième facteur physique (clé de sécurité matérielle) pour les connexions SSH par les utilisateurs disposant de privilèges système élevés, nous réduirons le risque qu'un ordinateur portable compromis provoque une grave faille de sécurité.
WE6.4.4	Si nous unifions nos domaines en diffusant toutes les consultations de pages des sites MediaWiki via un domaine canonique, nous réduirons la complexité de la plateforme et les risques liés à l’optimisation pour les moteurs de recherche (SEO) en supprimant la redirection du sous-domaine mobile. L’achèvement sera mesuré par la diminution des redirections pour les visites mobiles sur les domaines canoniques, passant de 100 % à 0 %.	T214998
WE6.4.5	Si l'équipe d'ingénierie MediaWiki surveille activement et corrige les problèmes liés à la mise à niveau vers PHP 8.3 dans MediaWiki, l'équipe SRE sera en mesure de procéder à la mise à niveau vers PHP 8.3 d'ici le début du deuxième trimestre (T2).	T360995

Hypothèses des services de signaux et de données (SDS) [ Résultats clés des SDS ] Discussion
Abréviation de l'hypothèse	Texte du premier trimestre	Informations et discussion
SDS1.1.1	Si nous analysons l’efficacité des heuristiques de détection automatisée du trafic dans nos ensembles de données de pages vues, nous serons en mesure de développer des mesures de qualité des données pour décrire leurs performances et déterminer la nécessité d’investissements supplémentaires dans ces heuristiques.
SDS1.2.2	Si nous migrons le processus de vidage XML de l'infrastructure actuelle 'Dumps 1' vers un pipeline de données qui exploite les pipelines de contenu MediaWiki, nous serons en mesure de garantir les SLO et de désactiver l'exportation XML basée sur 'Dumps 1'.
SDS1.2.3	Si nous effectuons une procédure pas à pas et examinons les objectifs de niveau de service pour l'historique du contenu MediaWiki et la plateforme/portail d'événements, nous pouvons valider les clients, les mesures et les parties prenantes dépendantes, et identifier les améliorations qui pourraient être nécessaires pour les objectifs de niveau de service, ce qui nous aidera à clarifier les lacunes dans nos garanties de livraison hebdomadaires.
SDS2.1.1	Si nous collaborons étroitement avec des équipes menant des expériences, nous apprendrons comment rendre le système plus autonome à l'avenir et quels défis conceptuels ou techniques ils pourraient rencontrer.
SDS2.1.2	Si nous pouvons mettre en œuvre un meilleur débogage pour le dépistage des événements, les équipes de produits sauront que leur expérience collecte les données d’événements comme prévu, ce qui augmentera la confiance des propriétaires d’expériences.
SDS2.1.3	Si nous améliorons la journalisation et l’observabilité du composant système de test A/B (xLab) de la plateforme d’expérimentation, et de ses parties MediaWiki associées, nous serons en mesure d’établir des lignes de base pour les performances du système et de répondre aux pannes liées à l’expérimentation.
SDS2.1.4	Si nous partageons les histoires et les résultats des expériences au sein de l'organisation une fois par mois (par le biais de réunions Product Ops, de réunions d'équipe de conception et de présentations inter-équipes), nous créerons une adoption organique de la plateforme d'expérimentation.
SDS2.1.5	Si nous indiquons aux utilisateurs que leur instrument, s'il est créé dans xLab, contient un ensemble d'attributs qui modifie la catégorie de risque, nous dissuaderons les utilisateurs d'instruments de collecter trop de données et augmenterons la clarté quant à la combinaison d'attributs nécessitant un examen de confidentialité.

Hypothèses sur le public futur (FA) [ Résultats clés des FA ] Discussion
Abréviation de l'hypothèse	Texte du premier trimestre	Informations et discussion
FA1.1.1	Si nous 1) proposons aux collectionneurs de médias sur d'autres plateformes (telles que Letterboxd, Goodreads et RateMyMusic) des moyens d'enrichir leurs collections avec des connaissances exclusives à Wikipédia, ou 2) proposons à ces collectionneurs de médias des éléments intéressants à partager sur les réseaux sociaux, alors nous serons en mesure d'augmenter la portée de Wikipédia hors plateforme.
FA2.1.1	Si nous renforçons notre capacité interne à créer du contenu vidéo court (en augmentant la taille de notre équipe et en vérifiant et en identifiant les opportunités d'accroître l'efficacité de notre processus de production actuel) au premier trimestre, nous serons en mesure de tirer les leçons du contenu créé au cours de l'exercice 2024-2025 et d'atteindre une plus grande portée annuelle du contenu produit au deuxième trimestre de l'exercice 2025-2026.

Hypothèses de support produit et ingénierie (PES) [ Résultats clés du PES ] Discussion
Abréviation de l'hypothèse	Texte du premier trimestre	Informations et discussion
PES1.1.1	Si nous soutenons xLab, Charts et ToneCheck dans la définition des métriques pour les SLIs (indicateurs de niveau de service) dans Prometheus, et que nous intégrons ces objectifs de niveau de service (SLOs) sur Pyrra, nous apprendrons les limites et les cas particuliers de nos outils dans plusieurs scénarios complexes, et clarifierons également les itérations nécessaires pour le modèle des objectifs de niveau de service, ce qui nous aidera à mieux prendre en charge les 6 objectifs de niveau de service prévus pour le RC.
PES1.1.2	En testant deux tableaux de bord d'alertes d'objectifs de niveau de service, nous constaterons la difficulté de mettre en place un outil adapté permettant aux responsables de services de comprendre clairement leurs engagements, et nous verrons également s'il est nécessaire de migrer vers un autre outil offrant une vue unique d'un objectif de niveau de service spécifique. Un tableau de bord sera dédié aux rapports trimestriels (où est défini l'accord de niveau de service actuel pour le budget d'erreurs) et un tableau de bord dynamique, plus petit (appelé "rolling"), sera dédié aux opérations quotidiennes et aux alertes.
PES1.1.3	Si nous continuons à soutenir le groupe Wikipédia abstrait dans l'élaboration d'un SLO (objectif de niveau de service) pour le projet Wikifonctions, nous apprendrons à définir une liste d'objectifs de SLO (ainsi que leurs mesures d'indicateur de niveau de service) pour une fonctionnalité complexe actuellement ajoutée à un flux de travail utilisateur critique: Le rendu des articles Wiki. Nous apprendrons également à visualiser correctement les marges d'erreur associées et à générer des alertes à l'aide des tableaux de bord et des moniteurs fournis par les SRE.
PES1.1.4	Si nous soutenons le groupe de plateformes de données avec la révision et l'itération des objectifs de niveau de service (SLO) pour le projet d'historique du contenu MediaWiki, nous apprendrons comment exploiter les SLOs pour soutenir la propriété du service lorsqu'une combinaison de services de traitement par lots et par flux est orchestrée ensemble pour mettre à jour l'ensemble de données, en le gardant cohérent et disponible pour les utilisateurs en aval.
PES1.2.1	Si nous créons 3 améliorations ciblées à la liste de souhaits, nous encouragerons 30% de participants uniques en plus dans la liste de souhaits
PES1.2.2	Si nous trions les souhaits entrants et attribuons un responsable de la maintenance (par exemple, les responsables de produits) dans les 72 heures (y compris le refus, la clarification, le signalement des services non maintenus, etc.), en recoupant les nouveaux souhaits avec le tableau des responsables de la maintenance et en attribuant une “catégorie de responsable de la maintenance” à l'équipe de produit ou à l'individu le plus pertinent, les responsables de la maintenance (par exemple, les responsables de produits) seront en mesure d'évaluer et de répondre aux souhaits en 10 jours ou moins.
PES1.2.3	Si nous menons un projet pilote visant à identifier les signaux communautaires dans leur ensemble, nous intégrerons davantage la voix des bénévoles dans nos efforts de priorisation informés par la communauté.
PES1.2.4	Si nous pilotons un processus trimestriel d’examen des souhaits et des signaux communautaires avec 3 équipes au premier trimestre, nous engagerons les responsables de produits à intégrer les signaux communautaires dans leurs processus de planification trimestriels et annuels.
PES1.3.1	Si, d'ici la fin du premier trimestre, nous coordonnons 3 sessions de planification fonctionnelle avec le département communication et les équipes produit pour nous aligner sur les messages, les besoins créatifs et les calendriers de campagne pour les initiatives WP25, nous finaliserons alors les briefs créatifs pour les 3 expériences de campagne (25YiR, Easter Eggs, WikiRun).
PES1.3.2	En créant un comité de pilotage composé de représentants des départements de conception et d’ingénierie des fonctionnalités, nous pourrons définir des indicateurs de référence pour les contributions au Codex: Notoriété, utilisation, qualité et quantité des contributions. Les résultats de l'évaluation par rapport à ces indicateurs de référence nous aideront à définir une feuille de route pour fédérer la croissance et la diversification de la base de contributeurs au Codex.

T2

Le deuxième trimestre (T2) du plan annuel de la WMF couvre la période d'octobre à décembre.

Hypothèses des expériences Wiki (EW) [ Résultats clés des EW ] Discussion
Abréviation de l'hypothèse	Texte du deuxième trimestre (T2)	Informations et discussion
WE1.1.1	Si nous analysons un ensemble prédéterminé d'indicateurs avancés ≥2 semaines après le début du test A/B de Paste Check, nous serons en mesure d'identifier ce qui – le cas échéant – des facettes de l'expérience de bout en bout doivent être ajustées ou examinées avant que nous puissions être confiants dans l'évaluation de l'impact de la fonctionnalité.
WE1.1.4	Si nous déployons Reference Check sur en.wiki dans le cadre d’une expérimentation contrôlée, nous observerons une augmentation d’au moins ≥ 4 % des modifications constructives publiées par les nouveaux (ou plus récents) bénévoles, et nous déterminerons s’il existe un soutien suffisant parmi les patrouilleurs et les modérateurs pour activer cette fonctionnalité plus largement.
WE1.1.7	Si nous analysons un ensemble prédéterminé d’indicateurs avancés au moins ≥ 2 semaines après le début du test A/B de Tone Check, nous serons en mesure d’identifier les aspects de l’expérience de bout en bout qui doivent, le cas échéant, être ajustés ou examinés avant de pouvoir procéder en toute confiance à l’évaluation de l’impact de la fonctionnalité.
WE1.1.8	Si nous appliquons le modèle Tone Check aux articles publiés, nous déterminerons s’il est possible d’identifier au moins ≥ 10 000 problèmes de ton (chacun présentant un score de probabilité de 0,8 ou plus) nécessaires pour constituer un ensemble de suggestions de haute qualité (avec une précision d’au moins 70 %) destiné à aider les rédacteurs à améliorer le ton des articles.
WE1.1.10	Si nous interrogeons environ ~10 bénévoles expérimentés sur en.wiki et fr.wiki qui conçoivent des AbuseFilters (ainsi que d’autres gadgets, scripts, modèles ou messages d’avertissement) afin d’automatiser les processus de patrouille ou de modération, nous identifierons au moins trois schémas ou besoins qui contribueront à définir la proposition de valeur des vérifications de modification créées par la communauté.
WE1.1.11	Si nous diffusons une enquête auprès d’au moins ≥500 nouveaux arrivants réussissant[i] et obtenons des données de haute qualité représentatives de l’ensemble de cette population, nous serons en mesure d’identifier au moins quatre enseignements exploitables qui nous aideront à hiérarchiser les aspects de l’expérience d’intégration à améliorer.
WE1.1.12	Si nous permettons à ≥3 bénévoles d'évaluer ≥30 échantillons de modifications chacun, pour chacune des 10 nouvelles langues vers lesquelles nous souhaitons étendre Tone Check, nous apprendrons à quelle fréquence les bénévoles sont d'accord avec les prédictions du modèle et serons en mesure de décider à quels nouveaux wikis proposer le déploiement de Tone Check.
WE1.1.13	Si nous étendons l'option « Ajouter un lien » à 100 % des nouveaux contributeurs de Wikipédia en anglais, l'activation constructive et la rétention des nouveaux arrivants s'amélioreront, ce qui augmentera les modifications constructives apportées par les nouveaux contributeurs de ≥4 %.
WE1.2.3	Si nous supprimons l'obligation d'avoir le droit « Organisateur d'événements » pour utiliser la fonctionnalité « Inscription à un événement » sur les wikis de petite et moyenne taille, nous verrons au moins X événements* supplémentaires créés sur ces wikis d'ici la fin de l'exercice fiscal. en attente du calcul de la base de référence/de l'objectif.
WE1.2.4	Si nous itérons sur le MVP des contributions collaboratives avec au moins deux améliorations, davantage de collaborations seront créées via l'inscription à l'événement.
WE1.2.5	Si nous définissons une stratégie d'adoption pour l'inscription aux événements sur Wikimedia Commons au début du deuxième trimestre (T2), nous pourrons la tester avec les organisateurs d'au moins une grande campagne et permettre à cinq organisateurs locaux d'utiliser cette fonctionnalité.
WE1.3.3	Si nous lançons une expérience visant à présenter le tableau de bord des modérateurs aux nouveaux éditeurs, 10 % des contributeurs qui le consultent le font pendant deux semaines consécutives.
WE1.4.1	Si nous apportons les améliorations définies dans T396489, nous réduirons d'au moins 30 % les requêtes lentes sur les modifications récentes dans les wikis de grande taille, ce qui permettra à Community Tech de déployer Watchlist Labels sans surcharger la base de données des modifications récentes.
WE1.4.3	Si nous mettons en place les changements récents et la liste de surveillance, nous pourrons alors définir une base de référence pour la fréquence à laquelle les gens cliquent sur les pages.
WE1.5.1	Si nous mettons en place un tableau de bord pour explorer 7 indicateurs de contribution et standardisons le calcul d'au moins un indicateur à l'aide de dbt, nous pouvons alors permettre aux équipes produit contributrices d'accéder en libre-service à des informations sur les indicateurs et développer une norme pour le stockage de la logique de calcul des indicateurs.
WE1.5.2	Si nous déterminons au deuxième trimestre (T2) quelles mesures de modération inclure dans la définition du rôle de modérateur, l'équipe Movement Insights pourra alors établir l'indicateur « modérateurs actifs mensuels » au troisième ou quatrième trimestre (T3/T4).
WE2.1.3	Si nous en apprenons davantage sur l'expérience des rédacteurs lors de la création de nouveaux articles et sections (y compris les motivations, les points faibles et leur réaction aux nouvelles idées sur comment mieux les soutenir), nous découvrirons alors les besoins et les comportements des utilisateurs qui fournissent des informations et des stratégies exploitables pour informer le produit, la conception et l'ingénierie sur l'amélioration de l'expérience de création d'articles.
WE2.2.12	Si nous déployons Wikifunctions sur les wikis qui ont activé Parsoid, nous pourrons continuer à tester si le système reste performant et utilisable dans le cadre de déploiements de plus en plus larges.
WE2.2.13	Si nous partageons la disponibilité de la fonction de tableau de conjugaison avec la communauté Wiktionary, nous obtiendrons des commentaires précieux sur l'utilisation de la fonction et des informations sur nos utilisateurs types que nous pourrons appliquer aux futurs déploiements.
WE2.2.14	Si nous examinons les travaux de Databox au sein de la communauté sur l'utilisation de Wikidata pour les infoboxes et que nous étudions si Wikifunctions pourrait être utile, nous serons en mesure d'identifier une première expérience pour Wikifunctions dans les infoboxes.
WE2.2.15	Si nous sensibilisons la communauté à la possibilité de créer et de traduire des messages d'erreur sur Wikifunctions, nous constaterons une augmentation du nombre de messages d'erreur utiles.
WE2.2.16	Si nous présentons les fonctions sémantiques disponibles à la communauté, nous constaterons une augmentation de 50 % des fonctions grammaticales.
WE2.2.17	Si nous fournissons un composant personnalisé pour afficher les déclarations Wikidata sur Wikifunctions, les utilisateurs seront plus à même de comprendre les données extraites de Wikidata et se sentiront moins dépassés.
WE2.2.18	Si nous parvenons à éviter les pics de consommation de mémoire multipliés par X10, l'orchestrateur sera mieux à même de gérer les objets Wikidata, ce qui renforcera l'utilité de Wikifunctions en tant que plateforme pour Wikipédia abstraite.
WE2.2.19	Si nous permettons aux utilisateurs de partager des liens directs vers des appels de fonctions spécifiques, y compris leurs entrées, les contributeurs pourront reproduire, vérifier et discuter plus facilement du comportement des fonctions, ce qui accélérera le débogage, améliorera les workflows de test et favorisera la résolution collaborative des problèmes au sein de la communauté Wikifunctions.
WE2.3.1	Si nous finalisons la décision de créer un nouveau wiki et choisissons un nom avec la communauté, nous pourrons mieux faire connaître la création de ce nouveau wiki auprès de nos parties prenantes et préparer la logistique d'un éventuel changement de nom du produit.
WE2.3.2	Si nous définissons un MVP pour un prototype wiki abstrait qui inclut l'expérience la plus basique possible pour tester nos capacités back-end et NLG, et qui nous permet de concevoir de manière itérative, nous serons en mesure de planifier et de lancer un prototype en direct au troisième trimestre.
WE2.3.3	Si nous commençons à discuter avec la communauté et à explorer les conceptions possibles pour l'expérience utilisateur d'un wiki Abstract, nous pourrons poursuivre nos travaux au troisième trimestre (T3).
WE2.4.1	Si nous recueillons des cas d'utilisation de Wikidata et WDQS auprès des équipes WMDE et WMF, nous serons en mesure de définir les exigences produit pour l'amélioration de l'infrastructure.
WE2.4.2	Si nous produisons une vue agrégée des indicateurs clés de performance (KPI) avec les objectifs de niveau de service (SLO) existants pour Wikidata et WDQS, nous serons en mesure d'articuler et de suivre les critères de réussite pour l'amélioration de l'infrastructure technique qui soutient le cas d'utilisation critique de Wikidata.
WE2.4.3	Si nous parvenons à évaluer et à comparer les alternatives à Blazegraph à l'aide de critères réalistes en matière de production au cours du trimestre, nous serons en mesure de prendre une décision de migration fondée sur les données et d'élaborer une feuille de route concrète avec un calendrier et les ressources nécessaires.
WE3.1.1	Si nous effectuons un test A/B sur une version améliorée de la fonctionnalité de navigation par onglets, nous constaterons une augmentation de 5 % de l'utilisation sur plusieurs jours parmi les utilisateurs d'onglets.
WE3.1.3	Si nous proposons aux utilisateurs une nouvelle façon de parcourir le contenu image pertinent dans les pages d'articles et que nous la testons auprès d'un sous-ensemble de lecteurs déconnectés via un test A/B sur un ensemble de wikis, nous observerons un taux de clics d'au moins 3 % parmi les utilisateurs auxquels cette fonctionnalité est présentée.
WE3.1.4	Si nous présentons aux lecteurs plusieurs concepts permettant de parcourir le réseau de connaissances sur les wikis, nous obtiendrons une liste hiérarchisée de concepts à développer davantage.
WE3.1.5	Si nous offrons aux lecteurs Web la possibilité de consulter une version traduite automatiquement du contenu Wikipédia indisponible dans leur langue, nous saurons si l'activité de lecture augmente, mesurée par une augmentation de 3 % des interactions avec les pages, attirant ainsi les lecteurs vers le wiki en langue locale avec une augmentation potentielle de l'activité d'édition locale. Cette fonctionnalité sera proposée dans le cadre d'un test A/B contrôlé pendant une durée maximale de 6 mois, sur 13 Wikipédias ayant donné leur accord préalable, à l'aide de services de traduction automatique ouverts déjà accessibles aux éditeurs de Wikipédia.
WE3.1.6	Si nous produisons un prototype pour la recherche sémantique et les questions-réponses dans les articles, présenté sous la forme d'une interface de démonstration qui compare l'approche actuelle à de nouvelles approches exploratoires, les équipes Reader seront alors en mesure d'évaluer qualitativement les performances de chaque approche dans différents parcours utilisateurs et de mettre en évidence les lacunes ou les opportunités d'itération supplémentaire.
WE3.1.7	Si nous examinons les recherches existantes sur la manière dont les lecteurs interagissent avec les outils de recherche et de navigation sur Wikipédia, et sur la manière dont ils utilisent la recherche externe pour trouver des informations sur Wikipédia, nous serons en mesure de fournir aux équipes Reader ≥3 recommandations et conclusions exploitables qui les aideront à définir un MVP de recherche et de découverte afin de combler les lacunes dans les attentes et les besoins des lecteurs.
WE3.1.8	Si nous évaluons deux prototypes de recherche sémantique (recherche en langage naturel, questions-réponses) avec des participants externes, nous pourrons déterminer si les utilisateurs voient l'intérêt d'outils de recherche améliorés et fournir aux équipes Readers une recommandation sur la manière de procéder pour mettre au point un MVP de recherche et de découverte.
WE3.1.9	Si nous présentons des concepts de conception haute fidélité pour la découverte de contenu via la recherche sémantique à 10-20 lecteurs occasionnels de Wikipédia dans le cadre d'une étude qualitative, nous constaterons un sentiment positif à l'égard de cette fonctionnalité et gagnerons la confiance nécessaire pour poursuivre le développement d'un MVP de recherche et de découverte qui s'appuie sur de courts extraits rédigés par des humains pour répondre aux requêtes de recherche.
WE3.1.10	Si nous montrons à 10 lecteurs occasionnels un prototype fonctionnel de la nouvelle expérience de navigation par images dans le cadre d'une étude utilisateur non modérée, nous découvrirons au moins une amélioration de l'expérience utilisateur pour les futures itérations de la fonctionnalité.
WE3.1.11	Si nous assouplissons la correspondance des mots-clés dans la recherche, nous pourrons mieux prendre en charge les requêtes en langage naturel et permettre au produit d'évaluer cette fonctionnalité, de l'intégrer dans la conception, la hiérarchisation et la réalisation des tâches dans l'espace de recherche sémantique.
WE3.1.14	If we launch an A/B test of a version of the mobile site which introduces navigation that opens all sections by default, we will see early indicators that signal towards an increase in session length (will report on full A/B test results in Q3)	T409163
WE3.2.5	Si nous introduisons une fonctionnalité « Bilan de l'année » sur Android qui met en avant l'impact des utilisateurs et inclut une messagerie intégrée pour les donateurs, nous encouragerons de nouveaux comportements en matière de dons et nous constaterons une augmentation de 5 % dans le menu de l'application par rapport à 2024.
WE3.2.6	Si nous rendons les diapositives des donateurs dans le bilan annuel iOS plus intégrées et personnalisées, nous constaterons une augmentation de 5 % des dons par rapport à 2024.
WE3.3.3	Si nous introduisons au moins un avatar déverrouillable dans l'application Android pour les personnes ayant un compte (obtenu grâce à des actions de lecture significatives comme l'enregistrement d'un certain nombre d'articles), nous augmenterons l'engagement répété avec l'action associée par les utilisateurs connectés de 10% sur plusieurs jours.
WE3.3.4	Si nous offrons aux lecteurs connectés la possibilité d'enregistrer des articles dans une liste de lecture privée, nous prévoyons une augmentation de l'engagement sur le site, mesurée par une augmentation de 5 % du trafic de référence interne pour les lecteurs qui utilisent cette fonctionnalité, et une augmentation statistiquement significative pour tous les utilisateurs.
WE3.3.6	Si nous mettons à disposition les données d'inférence sur les sujets des articles via un service qui répond aux exigences convenues en matière d'évolutivité et de disponibilité, ainsi que tout complément de données nécessaire, nous aurons alors établi les bases techniques nécessaires pour prendre en charge les expériences personnalisées des lecteurs qui dépendront de ces données.
WE3.3.7	Si nous exploitons les capacités de traitement de la plateforme de données pour agréger des mesures éditoriales personnalisées et des données d'impact, puis fournissons les données agrégées via des services adaptés avec des SLO définis, nous pourrons améliorer les futures itérations de Year in Review WE3.3.1 et Activity Tab WE3.3.2.
WE3.3.9	Si nous publions Year in Review sur Android et que nous effectuons un test A/B en offrant aux utilisateurs engagés une récompense pour enregistrer une liste de lecture personnalisée, nous constaterons une augmentation de 1 % du taux de rétention global de l'application parmi les lecteurs ayant bénéficié de la récompense par rapport à ceux qui n'en ont pas bénéficié.
WE3.3.10	Si nous effectuons un test A/B exigeant la création d'un compte pour consulter les informations personnalisées de Year in Review, nous constaterons une augmentation de 1 % du taux de rétention global pour les utilisateurs qui devaient créer un compte, par rapport à ceux qui n'étaient pas tenus de le faire.
WE3.3.11	Si nous réalisons un test A/B sur une version améliorée de l'onglet « Activité » sur iOS qui met en avant la lecture, l'édition et d'autres comportements participatifs, nous constaterons une augmentation de 5 % des visites sur plusieurs jours de la part des lecteurs connectés à cet onglet par rapport à la version prototype.
WE3.4.1	Si nous travaillons à la mise en place d'un point de présence hybride (PoP/CDN), cela nous permettra de mettre en place à la fois des PoP complets et des mini-PoP (physiques et dans le cloud) selon les besoins, jetant ainsi les bases d'un déploiement prototype de mini-PoP à l'avenir.
WE3.5.1	Si les équipes Produits et technologies et Collecte de fonds évaluent et documentent conjointement les approches techniques permettant d'identifier les donateurs au sein de nos plateformes, nous serons en mesure de recommander une solution à court et à long terme qui concilie confidentialité, faisabilité et impact. Cette compréhension commune permettra d'harmoniser la prise de décision, de reconnaître les donateurs de manière cohérente sur toutes les plateformes et de mener des expériences plus ciblées dans le cadre des futures fonctionnalités liées à la collecte de fonds.
WE3.6.3	Si nous engageons les communautés dans des conversations sur l'évolution des besoins des lecteurs et sur la nature changeante des connaissances sur Internet, nous pouvons établir une vision commune sur la manière de servir les lecteurs et travailler ensemble pour déterminer s'il convient de tester nos différentes idées (notamment celles concernant le multimédia, la recherche et la découverte, et l'apprentissage automatique) et comment le faire.
WE3.6.4	Si nous étudions les motivations, les comportements et les besoins distincts qui sous-tendent le moment, la raison et la manière dont les lecteurs utilisent Wikipédia et d'autres plateformes de connaissances, nous serons en mesure de proposer des domaines prioritaires et des initiatives spécifiques pour la stratégie consommateur.
WE3.6.5	Si les équipes Produit & Technologie et Collecte de fonds collaborent à l'élaboration d'une stratégie commune visant à diversifier les possibilités de dons sur la plateforme, à accompagner et à reconnaître les lecteurs qui font des dons, nous fixerons des objectifs et des indicateurs clairs et harmonisés, liés à nos stratégies en matière de consommation et de collecte de fonds.
WE3.6.6	Si nous développons une stratégie de mesure unifiée, nous pourrons évaluer la stratégie pluriannuelle des consommateurs et définir une feuille de route pour guider le développement des indicateurs et les capacités de reporting.
WE4.1.1	Si nous créons un prototype de flux non urgent minimalement viable et maintenons ouverte une boucle de rétroaction itérative pendant que nous le développons avec des utilisateurs ayant des droits étendus, alors ces groupes prendront en charge le déploiement étendu de ce flux.
WE4.1.3	Si nous mettons à jour 7 Wikipédias (française, allemande, espagnole, hongroise, italienne, polonaise, portugaise) d'ici la fin octobre, nous aurons achevé la phase 1 du déploiement du nouveau pied de page juridique conformément aux exigences de la DSA.
WE4.1.4	Si nous déployons le système MVP de signalement des incidents sur au moins 15 wikis, en mettant l'accent sur les communautés complexes de grande taille, nous observerons son utilisation conforme à l'intention de la communauté et aurons démontré un modèle fonctionnel pour le signalement des incidents non urgents.
WE4.1.5	Si nous concevons un organigramme pour signaler les incidents d'abus sur les wikis qui ne disposent pas de processus établis de traitement des abus, cela encouragera l'adoption du système de signalement des incidents sur ces wikis et permettra aux utilisateurs de ces wikis de disposer d'une voie d'assistance claire et viable.
WE4.2.3	Si nous analysons les données de l’essai de création de compte hCaptcha, nous comprendrons le processus de création de compte, l’efficacité du puzzle et des scores de hCaptcha, et nous disposerons des données nécessaires pour travailler sur le déploiement ultérieur de hCaptcha pour les créations de compte.
WE4.2.5	Si nous menons des recherches, consultons les communautés et étudions des solutions techniques, nous serons en mesure de définir un ensemble de motifs structurés pouvant être utilisés sur tous les wikis de la WMF.
WE4.2.6	Si nous développons la capacité de déployer des clusters basés sur OpenSearch sur la plateforme de données, les équipes d'ingénierie des fonctionnalités produit seront en mesure de développer des systèmes intégrant cette capacité, avec une grande autonomie, une grande résilience et une isolation par rapport aux autres systèmes basés sur la recherche. Le premier et principal locataire de ce système sera le service IPoid.
WE4.2.7	Si nous déployons l'intégration de hCaptcha Enterprise sur plusieurs Wikipédias de production en tant qu'essai pilote, nous pourrons collecter des données sur l'efficacité et la valeur de hCaptcha Enterprise en matière de lutte contre les abus, de détection de bots, d'utilisabilité et d'accessibilité.
WE4.2.8	Si nous rendons le proxy hCaptcha prêt pour la production en améliorant sa disponibilité et son observabilité, nous fournirons un service plus stable et plus fiable aux Wikipédias en production au cours du premier trimestre.
WE4.2.9	Si nous intégrons le SDK hCaptcha dans les applications mobiles natives, évaluons l'expérience utilisateur des applications natives et évaluons l'activation des défis hCaptcha dans le cadre de l'API de création de compte, nous disposerons d'informations suffisantes pour décider de la poursuite du déploiement de hCaptcha pour l'API de création de compte.
WE4.2.11	Si nous activons hCaptcha pour détecter les robots dans les scénarios d'édition à haut risque, nous constaterons que hCaptcha peut réduire les abus automatisés.
WE4.2.16	Si nous consultons les équipes concernées de la WMF, nous serons en mesure d'élaborer un plan concerté pour gérer de manière plus granulaire l'accès des utilisateurs aux données non publiques et soutenir le déploiement de règles défensives non publiques en matière de logiciels.
WE4.2.17	Si nous analysons des exemples concrets et interrogeons les CheckUsers afin d'identifier au moins deux signaux de comportement abusif potentiel à partir du prototype d'historique des modifications, l'équipe chargée de la sécurité et de l'intégrité des produits pourra ensuite intégrer ces signaux dans la fonctionnalité « Suggestions d'enquêtes » avec une plus grande certitude quant à leur utilité.
WE4.3.2	Si nous déployons les empreintes JA4H, qui résument le comportement des clients HTTP, nous serons mieux à même d'identifier et de catégoriser le trafic des bots.
WE4.4.1	Si nous pouvons apporter des améliorations basées sur les commentaires des pilotes et déployer des comptes temporaires dans tous les projets, nous serons en mesure de protéger l'exposition des informations personnelles identifiables (adresses IP) des utilisateurs non enregistrés dans tous nos projets afin qu'elles ne soient accessibles qu'à moins de 0,1 % de tous les utilisateurs (enregistrés).
WE4.4.2	Si nous communiquons clairement et à temps avec les parties prenantes concernées du mouvement (y compris les communautés wiki et les fonctionnaires globaux), nous pourrons déployer sur toutes les wikis restants, réduire la charge de travail découverte à la dernière minute et éviter de revenir en arrière dans le déploiement.
WE4.4.5	Si nous réduisons les difficultés rencontrées par les patrouilleurs pour identifier les mauvais acteurs qui utilisent des comptes temporaires pour commettre des actes de vandalisme, nous pourrons empêcher une augmentation du vandalisme en constatant qu'il n'y a pas d'augmentation du taux de restauration sur l'ensemble des wikis utilisant des comptes temporaires.
WE4.4.6	Si nous supprimons l'extension LiquidThreads, nous débloquerons les comptes temporaires déployés dans tous les projets qui utilisent actuellement cette extension.
WE4.6.1	Si nous automatisons le processus de synchronisation des comptes dans Zendesk pour les réinitialisations de mot de passe, cela allégera la charge de travail de confiance et sécurité (T&S) et leur permettra de traiter davantage de demandes de réinitialisation 2FA entrantes.
WE4.6.3	Si nous autorisons tous les utilisateurs disposant d'une adresse e-mail confirmée à pouvoir activer la 2FA pour leurs comptes, mais que nous n'annonçons pas proactivement ce changement aux utilisateurs, notre charge de travail au niveau du support de récupération restera à un niveau durable.
WE4.6.4	Si nous poursuivons la refonte de l'expérience utilisateur de notre système 2FA et ajoutons la prise en charge des clés d'accès, davantage d'utilisateurs enregistreront plusieurs facteurs d'authentification et seront mieux protégés contre la perte d'accès à leur compte.
WE4.6.5	Si nous concevons et élaborons un cadre général pour définir les exigences auxquelles doivent satisfaire les membres d'un groupe local ou mondial, nous utiliserons ce cadre pour veiller à ce que les membres du groupe temporary-account-ip-viewer respectent les exigences politiques existantes.
WE4.6.6	Si nous étudions la manière dont les utilisateurs disposant de droits étendus (UWER) s'appuient sur les scripts utilisateur, nous serons en mesure de proposer un plan, que la communauté UWER pourrait soutenir, visant à mettre en œuvre une ou plusieurs interventions techniques significatives qui sécuriseraient de manière significative le système des scripts utilisateur.
WE4.6.7	Si nous évaluons l'expérience utilisateur et les modifications techniques requises pour les applications mobiles natives afin d'harmoniser l'expérience de connexion mobile avec la plateforme Web, en explorant des mécanismes alternatifs tels que OAuth, nous pouvons déterminer la faisabilité de l'intégration, dans le but d'offrir une expérience plus sécurisée et plus cohérente aux utilisateurs.
WE4.6.8	Si nous surveillons l'impact des formulaires Zendesk et MediaWiki que nous avons créés au premier trimestre, nous pourrons proposer des interventions techniques pour les trimestres à venir afin de mieux automatiser le reste du processus de récupération de compte.
WE5.1.2b	Si nous intégrons plusieurs méthodes d'identification et d'authentification des développeurs dans la passerelle API, nous serons en mesure d'attribuer une limite de débit appropriée à chaque requête, en identifiant correctement les requêtes provenant de différentes cohortes d'utilisateurs.
WE5.1.3b	Si nous effectuons un test de limitation du débit sur au moins trois 3 routes de la passerelle REST, cela nous permettra de vérifier la faisabilité de la limitation du débit en termes de consommation des ressources et de définir un ensemble initial de limites pouvant être appliquées avec un impact minimal sur les utilisateurs.
WE5.1.4b	Si nous validons les mécanismes proposés de segmentation des utilisateurs de l'API à l'aide d'ensembles de données plus larges et d'examens manuels des groupes identifiés, nous serons en mesure de finaliser les cohortes d'utilisateurs, d'affiner les méthodologies utilisées pour le calcul et de mieux comprendre leur efficacité.
WE5.1.5	Si nous collaborons avec l'équipe MediaWiki Platform sur l'identification du trafic et la limitation du débit, nous serons en mesure de déployer la limitation du débit pour les tests à blanc en production, en aidant l'équipe Platform à créer et à déployer cette fonctionnalité.
WE5.2.1b	Si nous collaborons avec les utilisateurs potentiels du nouvel explorateur d'API REST, cela nous aidera à identifier les principaux éléments d'information sur la convivialité qui indiquent si la nouvelle conception est facile à utiliser et correspond au modèle mental des développeurs.
WE5.2.2b	Si nous acheminons l'API Action via la passerelle API centrale, nous pouvons commencer à mesurer de manière cohérente le trafic et les modèles d'utilisation afin d'obtenir des informations qui éclaireront nos décisions et actions futures.
WE5.2.4	Si nous mettons en œuvre des modèles de documentation standard pour deux API, nous serons en mesure d'affiner les directives relatives au contenu, de comprendre ce dont les propriétaires d'API ont besoin pour adopter ces directives et de quantifier les efforts nécessaires pour les mettre en œuvre dans l'ensemble des documents API Wikimedia restants.
WE5.2.5	Si nous testons la définition et l'application des règles de linting OpenAPI aux API REST MediaWiki, nous démontrerons un moyen d'appliquer de manière programmatique les guides de style API afin d'améliorer la qualité et la cohérence des API publiées sur Wikimedia et dans nos communautés.
WE5.3.1	Si nous élargissons et rationalisons les directives d'attribution UX tout en mettant à jour les directives existantes, nous établirons un ensemble de directives améliorées prêtes à être testées en interne et affinées de manière itérative afin d'être préparées pour une utilisation publique plus large.
WE5.3.1b	Si nous publions et itérons les directives UX provisoires et les démos, nous établirons un cadre de base prêt à être testé en interne et affiné de manière itérative afin d'être prêt pour une utilisation publique plus large.
WE5.3.2	Si nous créons un argumentaire démontrant les avantages de l'attribution de Wikipédia aux réutilisateurs de contenu tiers et à leurs utilisateurs finaux, nous pouvons soutenir WME4.1 et WME4.2 en permettant à au moins un partenaire de réutilisation supplémentaire d'accepter de figurer dans une étude de cas ou une démonstration sur l'attribution d'ici la fin du premier trimestre (T1).
WE5.4.2b	Si nous mettons en place un moyen évolutif d'identifier les clients connus, nous pourrons autoriser des exceptions aux limites générales imposées aux robots d'origine vérifiée et progresser vers une application systématique de nos règles.
WE5.4.5	Si nous commençons à appliquer des limites de débit adaptées aux différentes catégories de clients individuels, nous réduirons la charge liée à l'exploration de notre infrastructure.
WE5.4.6	Si, à la fin du deuxième trimestre, nous avons classé les N principaux robots d'indexation comme des robots connus, nous pouvons limiter la quantité de ressources qu'ils utilisent.
WE5.4.7	Si nous nous mettons d'accord sur un ensemble standardisé de tailles de vignettes autorisées sur notre infrastructure multimédia et que nous pré-générons les plus coûteuses tout en limitant le débit de génération des différentes tailles d'images, nous réduirons la charge pesant sur l'infrastructure de diffusion multimédia.
WE6.1.2	Si nous ajoutons des wiki fermes à un environnement de test de pré-fusion, cela permettra aux équipes de développement de construire par rapport à celles de production qui ont besoin de plusieurs wikis pour tester leurs correctifs de manière isolée, leur donnant une plus grande confiance en pré-production et entraînant moins d'échappements de défauts.
WE6.2.1	Si nous révisons et publions notre liste de contrôle de préparation à la production, qui définit clairement les conditions préalables pour qu'un service soit considéré comme prêt à être mis en production, ainsi que les tâches pouvant être effectuées en libre-service, nous alignerons les attentes entre les équipes SRE et les équipes de développement, améliorant ainsi notre efficacité opérationnelle et notre évolutivité globales.
WE6.2.2	Si nous annonçons la création d'une bibliothèque Golang et nodejs qui résume de nombreuses tâches fastidieuses pour les développeurs, ils répondront en offrant des commentaires et de l'intérêt.
WE6.2.4	Si nous appliquons et soutenons activement la révision de la conception de la persistance des données, nous pourrons identifier des voies ouvertes vers la production.
WE6.3.2	Si nous développons de nouveaux indicateurs, améliorons l'infrastructure de cache de Parsoid et déployons le système sur deux wikipédias classées parmi les « dix meilleures », nous établirons des critères de performance pour le cadre de confiance, ce qui nous aidera à valider notre état de préparation pour le déploiement sur d'autres wikis de grande envergure et à démontrer notre capacité à gérer des volumes de trafic élevés à grande échelle.
WE6.3.3	Si nous mettons en œuvre les améliorations essentielles apportées à la prise en charge des variantes linguistiques et déployons avec succès Parsoid sur au moins trois wikis en variantes linguistiques au cours du deuxième trimestre, nous identifierons et résoudrons les principaux défis techniques nécessaires pour déployer en toute confiance cette solution sur tous les wikis en variantes linguistiques restants.
WE6.4.6	Si SRE apporte son aide aux équipes d'ingénieurs MediaWiki (via la gestion des capacités et du trafic, la préparation et la révision des modifications de configuration, ainsi que la collaboration pour étudier et résoudre les problèmes), nous réaliserons ensemble la mise à niveau vers PHP 8.3 au deuxième trimestre et rédigerons une série de recommandations visant à minimiser les dépendances critiques vis-à-vis de SRE pour les futures mises à niveau.	T360995
WE6.4.7	Si nous migrons au moins 90 % de tous les utilisateurs disposant d'un accès root global vers l'utilisation d'une clé SSH matérielle pour accéder aux serveurs de production Wikimedia, nous réduirons le risque qu'un ordinateur portable compromis provoque une grave faille de sécurité.
WE6.4.8	Si l'équipe d'ingénierie MediaWiki surveille activement et corrige les problèmes liés à la mise à niveau PHP dans MediaWiki, cela permettra à l'équipe SRE de terminer la mise à niveau PHP 8.3 en production d'ici novembre 2025.	T360995

Hypothèses des services de signaux et de données (SDS) [ Résultats clés des SDS ] Discussion
Abréviation de l'hypothèse	Texte du deuxième trimestre (T2)	Informations et discussion
SDS1.2.1	Si nous migrons le processus XML Dumps de l'infrastructure actuelle « Dumps 1 » vers un pipeline de données qui exploite les pipelines de contenu MediaWiki, nous serons en mesure de garantir les SLO et de désactiver l'exportation XML basée sur « Dumps 1 ».
SDS1.2.2	Si nous effectuons une vérification et passons en revue les SLO pour MediaWiki Content History et Event Platform / Event Gate, nous pouvons valider les clients, les indicateurs et les parties prenantes concernées, et identifier les améliorations qui pourraient être nécessaires pour les SLO, ce qui nous aidera à clarifier les lacunes éventuelles dans nos garanties de livraison hebdomadaires.
SDS1.3.1	Si nous introduisons des signaux côté client et que nous les auditons en les comparant aux journaux de requêtes Web côté serveur, nous trouverons d'autres modèles de bots pouvant être caractérisés.
SDS1.3.2	Si nous prenons comme référence la répartition actuelle entre les bots et les humains et que nous créons des alertes automatiques en cas de changement dans cette répartition, nous réduirons le temps de détection du prochain modèle imprévisible de trafic automatisé de plusieurs semaines à quelques minutes.
SDS1.3.3	Si nous automatisons le mécanisme de backfill pour webrequest et l'utilisons sur les logs de mai, nous réduirons le temps de remédiation des incidents futurs de mois à jours et résoudrons l'incident « augmentation des pages vues en mai ».
SDS1.3.4	Si nous mettons en place un processus d'audit interne régulier et opérationnalisé des sorties de classification des bots, nous renforcerons la confiance dans nos solutions et anticiperons les changements dans les schémas de trafic qui ne sont pas détectés automatiquement.
SDS1.3.5	Si nous analysons le signal de base côté client et l'incorporons dans nos heuristiques, nous détecterons des schémas de bots supplémentaires dans la plateforme de données.
SDS1.3.6	Si nous importons, analysons et intégrons la réputation IP de Spur.us dans nos heuristiques, nous détecterons des schémas de bots supplémentaires dans la plateforme de données.
SDS1.3.7	Si nous importons, analysons et intégrons dans notre heuristique un signal provenant de la périphérie, nous détecterons des modèles de bots supplémentaires dans la plateforme de données.
SDS1.4.1	Si nous confirmons les analyses existantes des tendances au sein de l'écosystème Wikimedia (nombre de pages vues, indicateurs relatifs aux contributeurs et aux lecteurs, trafic, etc.), nous serons en mesure d'étayer avec assurance les points saillants de nos conclusions les plus importantes concernant le mouvement.
SDS1.4.2	Si nous confirmons les analyses existantes des tendances au sein de l'écosystème Wikimedia (nombre de pages vues, indicateurs relatifs aux contributeurs et aux lecteurs, trafic, etc.), nous serons en mesure d'étayer avec assurance les points saillants de nos conclusions les plus importantes concernant le mouvement.
SDS2.1.1	Si nous collaborons étroitement avec des équipes menant des expériences, nous apprendrons comment rendre le système plus autonome à l'avenir et quels défis conceptuels ou techniques ils pourraient rencontrer.
SDS2.1.2	Si nous parvenons à améliorer le débogage pour la journalisation des événements, les équipes produit sauront que leur expérience collecte les données d'événements comme prévu, ce qui renforcera la confiance des responsables d'expériences.
SDS2.1.3	Si nous améliorons la journalisation et l'observabilité du composant du système de test A/B (xLab) de la plateforme d'expérimentation, ainsi que des parties MediaWiki associées, nous serons en mesure d'établir des références pour les performances du système et de réagir aux défaillances liées aux expériences.
SDS2.1.4	Si nous partageons les histoires et les résultats des expériences au sein de l'organisation une fois par mois (par le biais de réunions Product Ops, de réunions d'équipe de conception et de présentations inter-équipes), nous créerons une adoption organique de la plateforme d'expérimentation.
SDS2.1.5	Si nous indiquons aux utilisateurs que leur instrument, s'il est créé dans xLab, contient un ensemble d'attributs qui modifie la catégorie de risque, nous dissuaderons les utilisateurs d'instruments de collecter trop de données et augmenterons la clarté quant à la combinaison d'attributs nécessitant un examen de confidentialité.
SDS2.1.6	Si l'équipe Growth travaille sur la mise en place de deux cas d'utilisation (l'un avec un test A/B pour obtenir des informations sur les capacités de regroupement, et l'autre avec une instrumentation à long terme pour en savoir plus sur la prise en charge des indicateurs de type KPI) avec l'Experiment Lab, nous pourrons alors évaluer si cela répond suffisamment aux exigences pour remplacer notre configuration d'expériences sur mesure dans GrowthExperiments.

Hypothèses sur le public futur (FA) [ Résultats clés des FA ] Discussion
Abréviation de l'hypothèse	Texte du deuxième trimestre (T2)	Informations et discussion
FA1.1.4	[Suite de l'exercice précédent] Si nous créons une nouvelle expérience Wikipédia sur Roblox, nous saurons si cela peut être un moyen efficace de faire connaître notre marque à un public plus jeune (génération Alpha).
FA1.1.2	Si nous créons une plateforme centrale dédiée aux nouvelles expériences Wikipédia sur itch.io, nous pourrons alors élargir notre audience à plus de 50 personnes non wikipédiennes intéressées qui nous feront part de leurs commentaires, ce qui nous aidera à comprendre ce qui fonctionne et ce qui ne fonctionne pas dans les jeux.
FA2.2.1	Si nous investissons dans la gestion communautaire sur les plateformes de vidéos courtes, d'ici la fin du deuxième trimestre (T3) (décembre 2025), nous constaterons une augmentation de 30 % en glissement trimestriel du pourcentage de vues provenant de nouveaux spectateurs sur TikTok. Sur l'ensemble des plateformes SFV, nous obtiendrons 50 000 interactions (likes et commentaires en réponse) sur les commentaires de marque laissés sur du contenu externe, ce qui nous aidera à accroître notre visibilité et à susciter l'intérêt d'un public que nous ne touchons pas actuellement.
FA2.2.2	Si nous développons et faisons approuver une stratégie interne et des éléments externes partageables pour le programme de partenariat avec les créateurs de Wikipédia (y compris un aperçu de notre valeur pour les créateurs, les critères de partenariat, le processus de contractualisation et la manière dont le contenu des créateurs sera présenté sur nos propres canaux et ceux des créateurs), nous serons en mesure d'établir une stratégie solide en matière de création qui nous aidera à toucher de nouveaux publics sur les réseaux sociaux grâce à notre contenu informatif.

Hypothèses de support produit et ingénierie (PES) [ Résultats clés du PES ] Discussion
Abréviation de l'hypothèse	Texte du deuxième trimestre (T2)	Informations et discussion
PES1.1.5	Si nous intégrons les objectifs de niveau de service (SLO) pour MediaWiki Content History et Wikifunctions à Sloth/Pyrra, nous aurons deux SLO supplémentaires en production.
PES1.1.6	Si nous testons Sloth avec les données rétroactives des SLO existants, nous comprendrons si Pyrra ou Sloth (ou autre chose) est l'outil adapté à notre approche à fenêtre fixe pour les fenêtres de budget d'erreurs. Nous apprendrons comment aider les propriétaires de services à adopter une approche en libre-service pour les métriques SLO et à les utiliser dans la prise de décision.
PES1.2.4	Si nous mettons en place un processus trimestriel d'examen des souhaits et des signaux de la communauté avec trois équipes au premier trimestre, nous demanderons aux chefs de produit d'intégrer les signaux de la communauté dans leurs processus de planification trimestrielle et annuelle.
PES1.2.5	Si nous ajoutons la possibilité de filtrer et de trier les souhaits dans l'extension Wishlist aux améliorations qui permettent la catégorisation à l'aide de balises et le vote, ces trois améliorations augmenteront d'au moins 30 % le nombre de participants uniques à la Wishlist.
PES1.3.3	Si nous créons au moins 5 interventions agréables sur la plateforme qui se produisent en fonction des interactions des utilisateurs, nous définirons quels seront les déclencheurs pour la page du portail et le gadget Birthday Mode. Les tests d'utilisabilité nous permettront de déterminer quelles interventions créent des associations positives avec notre marque. Cette hypothèse doit être validée avant la fin du WikiCon North America, fin octobre.
PES1.3.4	Si nous créons un site web immersif explorant l'histoire, le présent et l'avenir de Wikipédia, en collaboration avec les membres du département Communication, dans le but d'attirer un public en ligne âgé de 18 à 34 ans dans les zones cibles de la campagne, cela simulera une plus grande connexion avec Wikipédia via les partages sociaux et d'autres activités en ligne. Cela contribuera à l'objectif clé de performance (KPI) du département Communication, qui consiste à augmenter la présence de la marque de 10 points de pourcentage, tout en nous indiquant si les approches dynamiques du contenu améliorent la sympathie envers la marque.

Q3

The third quarter (Q3) of the WMF annual plan covers January-March 2026.

Wiki Experiences (WE) Hypotheses [ WE Key Results ] Discussion
Hypothesis shortname	Q3 text	Details & Discussion
WE1.1.3	If the Editing Team makes an initial set of edit suggestions available within VE via a URL parameter and invites ≥10 newcomers and patrollers to offer feedback about it, we will learn what improvements would need to be made before running a controlled experiment to evaluate the intervention's impact.
WE1.1.4	If we deploy Reference Check at en.wiki through a controlled experiment, we will see a ≥4% increase in the constructive edits new(er) volunteers publish and learn whether there is sufficient support among patrollers and moderators to enable the feature more widely.
WE1.1.12	If we enable ≥3 volunteers to evaluate ≥30 sample edits each, for each of the 10 new languages we are seeking to scale Tone Check to, we will learn how often volunteers agree with model predictions and be able to decide which new wikis to approach about deploying Tone Check to.
WE1.1.14	If we prompt new(er) volunteers to consider the tone they are writing in when an AI model detects them using non-neutral language, then we will see a ≥4% decrease in the percentage of new content edits new(er) volunteers publish that are reverted on the grounds of WP:NPOV (and related policies).
WE1.1.17	If we develop a task generation engine for the Revise Tone structured task, integrate our recent learnings about which content to include or filter out, and provide pipelines that automatically refresh the task list, we'll enable a qualitative evaluation of the tasks generated and an A/B experiment that tests whether this type of task helps newcomer editors to make more constructive edits.
WE1.1.18	If we analyze a pre-predetermined set of leading indicators ~2 weeks after the start of the Revise Tone Structured Task A/B test, we will be able to identify what – if any – facets of the end-to-end experience need to be adjusted or investigated before we can be confident evaluating the impact of the feature.
WE1.1.19	If we enable people on mobile web to edit any article section, regardless of which edit icon they first tap, then the newcomer mobile edit abandonment rate will decrease by #% because they will be able to more more easily locate the content they tapped edit seeking to change.
WE1.1.20	If the Growth team scales the “Add a Link” task to at least 10 additional Wikipedias, then we can complete leading indicator analysis to confirm that the task is performing as expected and identify any wikis that may require further review.
WE1.1.21	If we deploy the new Add-a-Link model version to both newly onboarded wikis and wikis currently using Add-a-Link, then the Growth team will be able to roll out Add-a-Link as a structured task to wikis where it did not previously exist, and wikis that already had the task will receive an updated model with fresher training data and improved offline performance.
WE1.1.22	If we improve the initial “Welcome to Wikipedia” verification email, the percentage of new accounts that verify their email address will increase. This would allow Growth to re-engage these accounts through follow up emails and ensure they receive talk page notifications.
WE1.1.23	If we prompt readily available GenAI models to generate and rank a set of edit suggestions for a diversified sample of 150 English Wikipedia articles, then we will learn what types of editing tasks these generic models can produce at scale and gain a rough, anecdotal understanding of the usefulness of these suggestions. This early signal will help us assess whether some task types could plausibly be generated at scale with generic models (with or without fine-tuning), or whether they would require more specialized approaches - ultimately helping us validate whether pursuing this "single model many suggestions" direction is worthwhile.
WE1.1.24	If we prompt new(er) volunteers pasting text from an external site to confirm whether they wrote the content they are attempting to add, then we will see a ≥4% increase in the percentage of new content edits new(er) volunteers publish that are reverted on the grounds of WP:COPYVIO (and related policies).
WE1.2.6	If we develop a goal-setting feature via Event Registration, then more collaborations will be created via Event Registration.
WE1.3.3	If we launch an experiment to surface a moderator dashboard to newer editors, 10% of contributors who visit it do so two weeks in a row.
WE1.3.4	If we deploy the Revert Risk filter to 150+ additional Wikipedias that currently lack damaging/goodfaith models, then we will see an increase in moderator patrol counts for contributors who use the personal moderator dashboard compared to those who don't get access to the dashboard.
WE1.5.1	If we implement a dashboard to explore 7 contributor metrics and standardize the calculation of at least one metric using dbt then we can enable contributor product teams to self-serve metric insights and develop a standard for storing metric calculation logic.
WE1.5.3	If Data Engineering productionizes a data product of edit types by the end of Q3, then the 6 moderator actions that are "Complicated" to measure will become "Simple", allowing Movement Insights to define a monthly active moderator metric as a next step.
WE1.5.4	If we produce a prototype dashboard with active moderator metrics that are currently available, then we will be able to produce a full dashboard by end of Q4.
WE1.6.1	If we introduce custom watchlist labels, we expect the labels to be used by 5% of users with more than 100 pages on their watchlist in the first month.
WE2.2.13	If we socialize the availability of the conjugation table function with the Wiktionary community, we will gather early signals about editor understanding and usability that can guide future improvements.
WE2.2.20	If we roll Wikifunctions out to wikis that have Parsoid enabled, we will be able to continue testing whether the system remains performant and usable in increasingly broad rollouts.
WE2.2.21	If we allow a limited set of reentrant functions in the evaluator, it will be possible to increase reliance on evaluated implementations, thereby leveraging the most performant part of the backend.
WE2.2.22	If we write an explicit interpreter for the composition language, the orchestrator will be more performant, and further performance-enhancing features will be easier to implement.
WE2.2.23	If we enable contributors to reuse whole composition blocks across functions, we will reduce repetitive work and significantly speed up the creation of new implementations, especially for similar linguistic functions.
WE2.2.24	If we define a clear documentation structure and entry points, function creators will more easily find relevant guidance and experience less friction when creating functions.
WE2.2.25	If we systematically identify the biggest friction points in the function creation experience, we can surface a small set of high-impact improvements that make creating and iterating on functions more efficient.
WE2.2.26	If we introduce a lightweight, local reference solution (via pop-ups) for Abstract Wikipedia, we can establish an initial citation mechanism to inform whether more complex solutions are necessary.
WE2.3.4	If we build and release an initial version of the Abstract Wikipedia platform, we can demonstrate the technical feasibility of the ecosystem working across multiple languages.
WE2.3.5	If we engage with a small number of under-resourced Wikipedia language communities with a concrete example of abstract content, we can validate whether content created outside their local wiki is acceptable and identify conditions needed for adoption.
WE2.3.6	If we design how Abstract Wikipedia content is surfaced and presented within local Wikipedias, and how local communities make integration decisions, we can socialize the proposal, reach agreement, and confidently plan Q4 development work.
WE2.5.1	If we deploy the Blazegraph candidate replacement in eqiad and augment existing evaluation work with production WDQS traffic-replay analysis, then we will confirm that the new backend performs comparably, supports real-world SPARQL queries, and is ready for limited live-traffic exposure once the surrounding ecosystem (UI, monitoring, onboarding, and real-time index update pipeline) is prepared.
WE2.5.2	If we define access guidelines for the Wikidata platform, we will better be able to control the load put on WDQS servers at the time of our backend migration.
WE2.5.3	If we define a cohort of user personas to test our new backend system, we will be prepared for the pilot and subsequent phases of the Blazegraph cutover.
WE2.5.4	If we produce a migration plan in a single document, we will be able to align upon and drive the execution of all aspects of the migration.
WE2.5.5	If we optimize the Wikidata Revert Risk model for low-latency inference and deploy it in a stable, scalable manner on LiftWing, then the Wikimedia Enterprise team will be able to integrate revert risk signals into their product pipeline, enabling customers to receive timely, high-quality model outputs.
WE3.1.8	If we evaluate 2 semantic search prototypes (natural language search, Q&A) with external participants, we can learn whether users see value in improved search tools, and provide the Readers teams with a recommendation on how to move forward with a search and discovery MVP.
WE3.1.12	If we collect a benchmark dataset consisting of a set of representative queries and annotations of relevant search results, we will be able to perform offline (i.e. without user studies) search evaluation of the quality of search results of different search models.
WE3.1.15	If we test hybrid search MVPs that blend keyword, natural-language, and meaning-based queries, in the Android app, we will rapidly identify the approach and design patterns that increases total search engagement by 10% without a negative impact on satisfaction, latency, or retention
WE3.1.16	If we define requirements for a Q&A model, we will produce model outputs to share with the community for feedback that we can incorporate into a production experiment.
WE3.1.17	If Search provides a production-ready (stable, performant) vector search infrastructure which supports semantic query processing — including a MediaWiki endpoint, then ML and Research will be able to generate embeddings and integrate their models with the system, enabling the MVP’s embedding-powered retrieval.
WE3.1.18	If we deploy a Qwen3 embeddings inference service that is compatible with our existing OpenSearch stack, then Mobile Apps can experiment with generating article-chunk and query embeddings through Qwen3, which should outperform the embeddings produced by OpenSearch’s built-in models.
WE3.3.6	If we make article topic inference data available via a service that meets agreed-upon scalability and availability requirements, plus any necessary data backfills, then we will have established the technical foundation necessary to support upcoming personalized reader experiences that depend on this data.
WE3.4.1	If we work towards a hybrid point of presence (PoP/CDN) deployment, it will allow us to bring up both full PoPs and mini PoPs (physical and cloud) as required, laying the foundation for a prototype mini PoP deployment in the future.
WE3.5.2	If we offer donors a badge acknowledging their status, at least 70% of donors who opt-in will report positive sentiment on a linked survey.
WE3.6.5	If Product & Technology and Fundraising collaborate on a shared strategy to diversify on-platform donation opportunities and steward and recognize readers who donate, we will set clear, aligned goals and metrics tied to our consumer and fundraising strategies.
WE3.6.6	If we develop a unified measurement strategy, we will enable evaluation of the consumers’ multi-year strategy and define a roadmap to guide metric development and reporting capabilities.
WE3.6.7	If we run a secondary A/A test on retention rate for logged-out users, we will begin to establish seasonal trends for retention rate that we can use for future quarters
WE3.6.8	If we systematically compare the information seeking needs and behaviors of 1) new and infrequent English Wikipedia readers and non-readers with those of 2) current English Wikipedia readers by simultaneously surveying both populations, we will be able to identify key insights about the demographic characteristics, online information needs, and online platforms used by these audiences, identifying potential opportunities for growing our readership as well as potential threats to our existing readership.
WE3.8.1	If we add additional modules to the activity tab and scale it to all users, we’ll see a 5% increase in overall iOS app account creation compared to before release
WE3.9.1	If we update the Wikipedia iOS app’s visual foundations, component defaults, and navigation behaviours to align with Apple’s Liquid Glass design language—while clearly defining design and behaviour for high-priority fallbacks across OS versions—then downstream engineering implementation will be clearer, lower-risk, and the app will feel more platform-native when Apple forces user switchover
WE3.10.1	If we user test a design prototype of the Explore Feed built with lightweight personalization, clear freshness cues, and repeatable Wikipedia-native patterns (e.g., topical rabbit holes, time-bound highlights, and interactive elements), casual reader participants will report understanding of the proposed feed’s purpose, reach an “aha” moment faster, and show a stronger intent for daily use. The visual design we recommend moving forward with will be described as digestible and aligned with the Wikimedia movement.
WE4.1.3	If we update 6 Wikipedias (English, French, German, Spanish, Italian, Polish) by the end of Q2, we will complete phase 1 of the new Legal Footer roll-out in response to DSA requirements.
WE4.2.5	If we conduct research, consult with communities, and investigate technical solutions, we will be able to define a set of structured block reasons that can be used across all WMF wikis.
WE4.6.8	If we monitor the impact of the Zendesk and MediaWiki forms we built in Q1, then we can propose technical interventions for future quarters that would better automate the rest of the account recovery process.
WE5.1.3c	If we roll out rate limiting to all APIs routed through the gateway, we will be able to reduce the number of anonymous API requests that reach our backend infrastructure, by limiting requests based on user classes that give higher limits to authenticated and community users.
WE5.1.5	If we improve the sustainability and reliability of our OAuth 2.0 implementation, we will be able to convince more developers to use OAuth and support the migration of the Wikipedia mobile apps, by increasing confidence that it can be relied upon for high profile applications.
WE5.1.5b	If we improve the developer experience for creating and managing OAuth 2.0 clients, we will be able to increase the number of applications that use OAuth 2.0, by deprecating OAuth 1.0 for new applications and promoting OAuth 2.0 as the preferred option for API authentication.
WE5.2.2c	If we reroute all APIs currently going through the API Gateway through the common gateway, we will be able to fully deprecate the historic API Gateway and ensure consistency for all community facing Wikimedia HTTP/web APIs
WE5.2.6	If we introduce access controls to the sitemap API to only allow trusted bots, we can improve strategic alignment and reduce the risk of abusive scraping.
WE5.2.8	If we create dedicated API modules for all API extensions and self-contained functionality within MediaWiki Core, we will enable enforcement for higher quality documentation with independent management and versioning.
WE5.2.9	If we have better separation of concerns for API registration and spec definition processes, we will simplify the complexity of API management and create a better developer experience for API authors.
WE5.2.10	If we conduct a listening tour specifically focused on v2 API consolidation and feature gaps, we will be able to move more quickly with a v2 implementation.
WE5.2.11	If we experiment and establish processes for standardizing documentation currently in the API Portal, we can consolidate sources of information and improve documentation consistency.
WE5.3.1b	If we publish and iterate on the draft UX guidelines and demos, we will establish a core framework ready to be internally tested and iteratively refined to be prepared for broader public use.
WE5.3.2b	If we establish a partner pilot program to experiment with Wikimedia attribution, we can show mutually beneficial impacts of attribution by reusers to drive engagement and contributions to Wikimedia.
WE5.4.6	If by the end of Q2 we've classified the top N spiders as known bots, we can constrain the amount of resources they're using.
WE5.4.8	If we start enforcing rate limits tailored to different classes of individual clients for media files, we will reduce the burden of crawling on our infrastructure.
WE5.4.9	If we add ip-reputation data on residential proxies to our bot detection, it will improve our ability to block scrapers
WE5.4.10	If we stop allowing generation of non-standard thumbnail sizes, it will reduce the strain on our backend media serving infrastructure
WE5.4.11	If we identify two high-confidence signals from the December 2025 scraping/DDoS incidents and deliver them to SRE, then SRE will be able to develop more effective automated mitigation rules for future similar incidents.
WE5.4.12	If we are able to attest where and from whom a request for an image is originated, we can make more informed decisions about rate-limiting them
WE6.1.2	If we add wikifarms to a pre-merge testing environment this will enable development teams building against production who require multiple wikis to test their patches in isolation giving them greater pre-production confidence and result in fewer defect escapes.
WE6.1.3	If we resolve the top 5 flaky Selenium tests over the next 90 days, we will increase developer confidence in automated browser testing as a valuable part of the pre-deployment workflow.
WE6.2.4	If we apply, and actively support the Data Persistence design review, we may identify paved pathways to production
WE6.2.5	By collaborating with the SLO group and gathering feedback from teams currently working with them, will help us not only identify gaps and improvements for the Production Readiness checklist, but also adapt it in such a way to directly facilitate SLO adoption and onboarding
WE6.2.6	By piloting the production readiness checklist on the hCaptcha proxy service against launch and high-importance items, we will identify untracked technical debt and create a visible work backlog, which will demonstrate the framework's value, while shaping a repeatable process for consistent adoption across services.
WE6.2.7	By collaboratively refining the production readiness checklist with SRE input and contributions, we will ensure it addresses real operational needs, build shared ownership, and create a practical tool that teams see value in adopting.
WE6.2.8	By analysing feedback from our collaboration with the SLO group, hCaptcha proxy pilot, and SRE collaboration, we will identify which checklist items and process steps require clearer guidance or supporting resources, and determine the next steps for streamlining the framework to make adoption achievable before the December break.
WE6.2.9	If we adopt node.js service-utils, we will be able to release, in a tested way, either of: service-mesh routing or OpenTelemetry publishing.
WE6.3.2	If we develop new metrics, improve Parsoid's cache infrastructure, and deploy on two "top-ten" wikipedias, we will develop performance criteria for the confidence framework, which will help validate our readiness for deployment to other large wikis and demonstrate our ability to handle high-traffic volumes at scale.
WE6.3.3	If we implement critical Language Variant support improvements and successfully deploy Parsoid to at least 3 Language Variant wikis in Q2, we will identify and resolve the key technical challenges necessary to confidently roll out to all remaining Language Variant wikis.
WE6.3.4	If we QA, identify, triage, and fix bugs within the reading experience across platforms for Parsoid Read Views, we will maintain the quality of the reading experience and unblock further scaling across wikis
WE6.3.5	If we target a Time To First Byte (TTFB) metric of <= 110% of legacy for parser cache hits and <= 150% of legacy for parser cache misses, we can deploy to all Wikipedias except for Chinese and English by the end of Q3 with no performance complaints. This will help validate our readiness for deployment on English Wikipedia, preparing us to handle high-traffic volumes at scale by understanding our cache capacity.
WE6.4.4	If we unify our domains by serving all page views on MediaWiki sites through a canonical domain, then we will reduce platform complexity and SEO risks by eliminating the mobile-subdomain redirect. Completion is measured by decreasing redirects for mobile visits on canonical domains from 100% to 0%.
WE6.4.7	If we migrate at least 90% of all users with global root access to use a hardware-backed SSH key for accessing Wikimedia production servers, we will reduce the risk that a compromised laptop will cause a severe security breach.
WE6.4.8	If the MediaWiki Engineering Team actively monitors and fixes issues in MediaWiki related to the PHP upgrade, this will enable the SRE team to complete the production PHP 8.3 upgrade by November 2025.

Signals & Data Services (SDS) Hypotheses [ SDS Key Results ] Discussion
Hypothesis shortname	Q3 text	Details & Discussion
SDS1.5.1	If we create a regular, operationalized internal audit process for bot classification outputs, we will build trust in our solutions and anticipate changes in traffic patterns that are not automatically detected.
SDS1.5.2	If we deploy a Test Kitchen instrument with 100% sampling and a request identifier, we'll be able to capture all requests regardless of whether or not they sent client-side events and analyze them for bot behavior.
SDS1.5.3	If we analyze the basic client-side signal and incorporate it into our heuristics, we will detect additional bot patterns in the Data Platform.
SDS2.2.4	If Product Safety and Integrity reviews GrowthBook and FerretDB, we will be able to identify, then mitigate and/or address any material risks before production rollout.
SDS2.2.5	If we update Test Kitchen JS and PHP SDKs with methods to log experiment exposure, we will not need to treat all events as exposure events, which will improve performance of experiment assignment queries in GrowthBook and yield more accurate experiment results.
SDS2.4.2	If we safely expand traffic enrolment through monitored stress testing, we will increase statistical power for Reader team experiments, shortening experiment timelines and improving decision confidence.

Future Audience (FA) Hypotheses [ FA Key Results ] Discussion
Hypothesis shortname	Q3 text	Details & Discussion
FA1.1.1	If we build a central hub for new Wikipedia experiences on itch.io, then we’ll be able to grow an audience of >50 interested non-Wikipedians giving us feedback, which will help us learn what works and what doesn’t in games.
FA1.1.2	If we create and test 3 different app-based content discovery features as short experiments, we can share recommendations with the Apps team about how to effectively engage with and retain a new generation of apps users
FA1.1.3	If we create 4 TikTok filters and publish them on our TikTok account, we will be able to learn how well we can incentivize creation of Wikipedia content off-platform.
FA1.1.6	If we create 3 different potential previews for Wikipedia links shared on Discord, we can align internally on our measurement and execution strategy and collaborate with Discord's ProdEng team.
FA2.2.1	If we invest in community management across short-video platforms, then by the end of Q2 (December 2025) we will see a 30% QoQ increase in the percentage of views from New Viewers on TikTok — and across all SFV platforms, we’ll earn 50,000 total engagements (likes and reply comments) on brand comments left on external content, which will help us increase visibility and drive engagement with audiences we’re not currently reaching.
FA2.2.2	If we develop and get sign-off on a Wikipedia Creator Partnerships Program internal strategy and external shareables (inclusive of an outline of our value to creators, partnership criteria, contracting process, and how creator content will show up across owned and creator channels), we will be able to establish a robust creator strategy that will help us reach new audiences across social media with our knowledge content.

Product and Engineering Support (PES) Hypotheses [ PES Key Results ] Discussion
Hypothesis shortname	Q3 text	Details & Discussion
PES1.3.5	If we build community configuration for Easter Eggs, and leverage Reader Experience full time for code review, we’ll be able to launch on Feb 15 and track impact of the project.
PES1.3.6	If we create bespoke social media posts for 25 Years of Wikipedia (25YoW), we can achieve similar success with social impressions as Comms’ existing templates, and prove we can support Comms’ by increasing their capacity. Benchmarking will be off of Truth Collective posts about the same project.
PES1.4.1	If we meet with 4-5 teams that are not primarily using Codex (including, but not limited to, teams primarily using OOUI), we will be able to document blockers to those teams adopting Codex for current and future projects.
PES1.4.2	If we make Codex PHP easier to use and stable enough to do a 1.0 release, then teams will adopt Codex PHP for server-generated UIs. This will increase Codex PHP usage from 3 projects to 5.
PES1.5.1	If we upgrade Sloth from a prototype to a replacement for Pyrra, by onboarding existing services, we can converge on a unified set of SLO dashboards, refine our alerts, and streamline the SLO onboarding experience.
PES1.5.2	If we continue to onboard SLI metrics for Wikifunctions and MediaWiki Content History, and check metrics for WikiData Query Service and EditCheck, we will debug issues with both dashboard reporting and service-owner engagement on loud-but-unaddressed SLO reports.

Q4

The fourth quarter (Q4) of the WMF annual plan covers April-June 2026.

Wiki Experiences (WE) Hypotheses [ WE Key Results ] Discussion
Hypothesis shortname	Q4 text	Details & Discussion
WE1.3.3	If we launch an experiment to surface a moderator dashboard to newer editors, 10% of contributors who visit it do so two weeks in a row.
WE1.5.1a	If we add new metrics to the Contributors dashboard using DBT we will enable contributor product teams to get more actionable insights into editing trends
WE1.5.5	If we automate updates of DBT models with Airflow on a fixed schedule, we will allow Movement Insights to build analyses and reports on those models using up-to-date information.
WE1.5.6	If we document workflows and establish per-team default output locations and access controls for dbt models, we will allow dbt usage to scale across team members in Movement Insights and other teams.
WE1.5.7	If we extend the MAM dashboard as specified, then we will have a more complete picture of moderator pipeline health that can inform decisions in the Contributor strategy.
WE1.6.1	If we introduce custom watchlist labels, we expect the labels to be used by 5% of users with more than 100 pages on their watchlist in the first month.
WE1.7.2	By testing a design prototype of the in-app webview editing flow with newcomers on the mobile apps, we will identify the highest-risk friction points that could cause abandonment before publishing - specifically around context shift, editor comprehension, and edit attribution - so that we can prioritize what must be resolved before this approach can successfully onboard new editors at scale.
WE1.7.4	If we prompt readily available GenAI models to generate and rank a set of edit suggestions for a diversified sample of 150 English Wikipedia articles, then we will learn what types of editing tasks these generic models can produce at scale and gain a rough, anecdotal understanding of the usefulness of these suggestions. This early signal will help us assess whether some task types could plausibly be generated at scale with generic models (with or without fine-tuning), or whether they would require more specialized approaches - ultimately helping us validate whether pursuing this "single model many suggestions" direction is worthwhile.
WE1.7.5	If we replace the unstructured Copyedit task with the Revise Tone structured task in a controlled experiment, then the task completion rate for Revise Tone edits made by junior editors will be higher than the completion rate for edits made through the Copyedit task.
WE1.7.6	If we test 2 structured workflows via design prototypes that align contribution opportunities with what readers arrive motivated to learn, and frame contributions as ways to act on curiosity or share knowledge they already possess, then concept testing will help us identify approaches that inspire readers to imagine themselves as contributors.
WE1.7.7	If we present an exit survey to users with ≤100 cumulative edits who abandon mobile editing sessions after spending ≥2 seconds in either the mobile visual or source editor, we will discover patterns in the reasons behind this behavior and be able to decide what interventions we will prioritize to increase the mobile web edit completion rate.
WE1.7.8	If we present junior contributors who enter the mobile VisualEditor with immediately actionable edit suggestions, then the proportion of edit sessions that result in someone publishing a constructive edit will increase by ≥10%.
WE1.7.9	If we publish a proposal on-wiki to enable VisualEditor by default for newcomers on mobile web at en.wiki, we will define the steps needed to make this happen.
WE1.8.2	If we improve the logged out edit warning, the account creation rate among newcomers on mobile exposed to the warning will increase by at least 2% relative to the control group.
WE1.8.3	If we improve the account creation form, the registration completion rate among mobile users who land on the form will increase by at least 2% relative to the control group.
WE1.8.4	If we add a user account button to the header on mobile web, then the number of new accounts created on mobile will increase by at least 2% relative to the control group.
WE1.8.5	If we surface Reading Lists to logged-out readers on mobile web, the registration rate will increase by at least 2% relative to the control group.
WE1.9.2	If we introduce key questions about factors that impact editor motivations [i] into the 2026 Community Insights survey, by the end of Q4 we will be able to provide ≥5 research insights which can inform our Contributors strategy implementation, with a focus on editor progression and recognition. [i] Defined through the lens of competence (ability to use tools and resources), autonomy (ability to navigate the platform and make informed decisions), and relatedness (ability to join the community, feel supported and valued).
WE1.9.3	If we co-design guidance for mobile-first onboarding with at least two affiliates, by the end of June we will be able to identify which gaps are perceived by organizers as most detrimental to the retention of mobile-first newcomers.
WE1.10.3	If we work with a few selected communities to customize the Article Guidance workflow for their wikis, editors will get guidance that’s tailored to each community’s content and policies.
WE1.10.5	If we complete all path-to-production requirements for the Article Guidance A/B test (including security review, legal consultation, instrumentation, community outline review and translation, and experiment configuration) we will launch the experiment for it to run to completion before the end of Q4 and start generating statistically meaningful data on the impact of Article Guidance on the 30-day survival rate of articles created by junior editors.
WE2.2.13	If we socialize the availability of the conjugation table function with the Wiktionary community, we will gather early signals about editor understanding and usability that can guide future improvements.
WE2.3.7	If we identify and address small but frequent friction points in contribution workflows together with early contributors, we can support and sustain the engaged core community that is building the foundational building blocks for Abstract Wikipedia.
WE2.3.8	If we implement the capabilities for article-level opt-in integration of Abstract Wikipedia content into local Wikipedias, we can demonstrate how the model works in practice and be ready to engage pilot communities in Q1.
WE2.3.9	If we implement basic instrumentation for Abstract Wikipedia (in addition to existing MediaWiki instrumentation), we will better understand how users interact with Abstract Wikipedia and identify areas for improvement.
WE2.3.10	If we support displaying images from Commons in Abstract articles via Wikifunctions, we enable communities to incorporate visual elements commonly used in Wikipedia articles.
WE2.3.13	If we build an analytical capability to map content availability, production, and consumption against a flexible topic taxonomy, then we'll have greater visibility to content trends that we can derive insights from.
WE2.3.16	If the Rust evaluator is brought to feature parity with the Node evaluator and the Node evaluator phased out, we will eliminate a huge maintenance burden and free up engineering resources.
WE2.5.4	If we produce a migration plan in a single document, we will be able to align upon and drive the execution of all aspects of the migration.
WE2.5.6	If we develop the capability to automate output comparison between WDQS v1 and v2 for selected sets of queries, we will be able to improve confidence in the correctness of the new service.
WE2.5.7	If we assemble a plan for messaging about our migration, we will experience a smoother transition to the new endpoints by aligning with the Wikidata community on when to expect changes and how to prepare for them.
WE2.5.8	If we start to build the decoupled architecture described in our design doc, we should be able incrementally deliver value throughout the quarter and stand by a service that is able to support the pilot cohort by FY27 Q1.
WE3.1.15	If we test hybrid search MVPs that blend keyword, natural-language, and meaning-based queries, in the Android app, we will rapidly identify the approach and design patterns that increases total search engagement by 10% without a negative impact on satisfaction, latency, or retention.
WE3.1.16	If we define requirements for a Q&A model, we will produce model outputs to share with the community for feedback that we can incorporate into a production experiment.
WE3.1.17	If Search provides a production-ready (stable, performant) vector search infrastructure which supports semantic query processing — including a MediaWiki endpoint, then ML and Research will be able to generate embeddings and integrate their models with the system, enabling the MVP’s embedding-powered retrieval.
WE3.3.6	If we make article topic inference data available via a service that meets agreed-upon scalability and availability requirements, plus any necessary data backfills, then we will have established the technical foundation necessary to support upcoming personalized reader experiences that depend on this data.
WE3.4.1	If we work towards a hybrid point of presence (PoP/CDN) deployment, it will allow us to bring up both full PoPs and mini PoPs (physical and cloud) as required, laying the foundation for a prototype mini PoP deployment in the future.
WE3.5.3	If we implement consent-based donor segment storage in MediaWiki and establish a reliable CiviCRM → MW sync, Product and Fundraising will be able to successfully identify and differentiate donor segments on-platform across web and apps by the end of the quarter.
WE3.5.5	If we offer logged-out donors on mobile web a persistent Thank You badge by default that triggers a brief delightful interaction upon tap (C), then we will see a 1% improvement in 21-day cumulative retention rate compared to having a badge with a simple popover message (B), and users who do not get a badge at all post-donation (A). We will also track whether a larger percentage of donors in group (C) tap on the badge again in at least one future return session compared to those in (B), to inform whether playful interactions create a re-engagement loop.
WE3.6.9	If we coordinate across identified stakeholders, we will gather the necessary information on development needs, dependencies, and timeline to create a decision brief on the consumer strategy measurement plan that gets signed off by all relevant stakeholders.
WE3.6.10	If we run an A/A test on retention rate for logged-in readers, we will establish a baseline for retention rate we can use for future quarters.
WE3.6.11	If we analyze existing data to see what user factors or actions correlate with retention, we can document our understanding of what product interventions/levers might increase retention.
WE3.6.12	If we experiment with measuring whether increasing the amount of translated Wikipedia content leads to a direct increase in pageviews, we will be able to make a recommendation on future strategic investment into translations.
WE3.7.2	If we roll out the new “heart” donate button design to all projects with a header donate link on desktop, based on the positive results of the previous clickthrough rate experiment, the total number of donations coming from that entry point will not decrease.
WE3.8.2	If we provide reading lists on web as an opt-in beta feature, as well as opt-in all new user accounts, at least 50% of users will rate the feature as useful when surveyed.
WE3.8.3	If we add a temporary 25th Birthday reading challenge widget on the apps that motivates users to meet a reading goal, we'll see a 5% higher conversion rate from casual (2-week return) to active (2-day returned) for users who joined the challenge in the first 14 days, compared to our baseline of 16.8%.
WE3.9.3	If we widely roll out the image browsing carousel and detail view on mobile web, then we will maintain CTR > 5% on the carousel.
WE3.9.4	If we test the addition of the “Which came first” daily-play trivia game to the iOS App, we’ll see 15% of engaged logged-out readers return to play the game on multiple days.
WE3.10.3	If we show readers several concepts for traversing the knowledge network on the wikis, we will come away with a prioritized list of concepts for further development.
WE3.10.5	If we give readers an enhanced sharing option then [33%] of readers who see the dialog will complete the enhanced share action without harming logged-out reader retention.
WE3.10.6	If we redesign the mobile apps Explore Feed, we'll see a 10% practically significant increase in Explore Feed engagement over multiple days per unique logged-out reader within 14 days of release.
WE3.10.7	If we identify the most frequent and important unmet needs for casual users (as rated by them) as well as which early-stage concept ideas are most desirable and useful, we will be able to prioritize which concepts to put into A/B testing in FY26-27 to give us the best shot at increasing retention.
WE3.10.8	If we test adding Page Previews on Minerva, we will see practically significant improvement to logged-out reader retention.
WE4.6.13	If we encourage users with an unconfirmed email address to confirm their email address, then 10% of active users who receive this notification will attempt to confirm their email address.
WE4.6.16	If we build support for enforcing group membership restrictions on global groups, we will be able to use this to enforce a 2FA requirement for global groups.
WE4.6.17	If we announce and enforce 2FA requirements for an additional set of groups, the number of users who have sensitive rights but don't have 2FA will drop to 0.
WE4.6.18	If we build support for enforcing 2FA on private wikis, we will be able to use this to secure user accounts who have access to private information.
WE4.6.19	If we require reauthentication for sensitive actions and implement other hardening measures, we will be less vulnerable to an attacker exploiting user scripts.
WE4.6.20	If we proactively scan user scripts for malicious code, we will be less vulnerable to an attacker exploiting user scripts.
WE4.6.21	If we reduce the number of staff accounts with advanced rights and how long they have those rights for, attacks targeting staff accounts are less likely to cause damage.
WE4.8.1	If we introduce a mechanism that detects and surfaces related temporary accounts, including a connected-accounts panel on Special:Contributions, then patrollers will identify abusive temporary-account activity faster and more accurately.
WE4.8.3	If we investigate recent complaints about patrolling taking longer than before, we would be able to determine whether or not they are correlated with the introduction of Temporary Accounts.
WE4.10.1	If we roll out hCaptcha to more wikis (Special:CreateAccount, wikitext editor on desktop) in stages, we will increase bot detection coverage across all projects.
WE4.10.2	If we deploy the hCaptcha bot detection in the visual editing, discussion tools, file upload wizard, and mobile editing pathways on pilot wikis, we will see an increase of 35% in the percentage of actions on Wikimedia Foundation wikis that were verified by hCaptcha.
WE4.10.3	If we deploy an hCaptcha risk score collection for blocked edit notices, we will better understand collateral damage impacts of IP range blocks.
WE4.11.1	If we roll out the Incident Reporting System (IRS) on enwiki through a staged deployment, starting small and scaling to at least 50% of logged-in users, then we will have enough data from our newly instrumented metrics to determine if IRS should be adopted on enwiki.
WE4.12.1	If we optimize and compare the performance of at least 2 content policy models with a community-vetted dataset of oversighted (WP:Oversight) content from English Wikipedia, we will be able to recommend a model or combination of models for automatic oversighting or flagging of content that very likely should be oversighted.
WE4.12.2	If we host the gpt-oss-safeguard-20b, CoPE-A-9B, and CoPE-b-12b models on LiftWing and optimize each model's performance to meet the PSI team's initial evaluation requirements, then the PSI team will be able to test the three models and compare their behavior.
WE5.1.3e	If we create a data product for analysis of API requests, we'll simplify analysis and segmentation of API requests, and allow Product Analytics to prototype the API Analytics Dashboard by further segmenting and aggregating this new data.
WE5.1.3f	If we reduce API rate limits for requests that only provide a User-Agent, we will increase the number of authenticated and known clients, by encouraging UA-only users to move to a more responsible pathway.
WE5.2.2c	If we reroute all APIs currently going through the API Gateway through the common gateway, we will be able to fully deprecate the historic API Gateway and ensure consistency for all community facing Wikimedia HTTP/web APIs
WE5.2.5b	If we finalize the linter architecture and a core set of linting rules, we can improve the quality of OpenAPI descriptions and start introducing programmatic guarantees of their compliance into CI workflows in API development processes.
WE5.2.8b	If we onboard at least 3 more API modules demonstrating a variety of use cases (at least 1 stand-alone service API, 1 feature team owned extension API, 1 internal module), we will be able to refine usability and set the foundation for the future of the API Platform.
WE5.2.11b	If we complete API Portal documentation migration, we will be able to fully deprecate the API Portal system, which will simplify API documentation discovery, increase documentation consistency, and reduce the number of API support systems.
WE5.2.12	If we iterate on the design and discovery work required for building the unified front-door for developers early, we will be able to effectively expedite engineering work in FY26-27.
WE5.2.13	If we begin enforcing existing user-agent policies on the dumps website, we can better understand dumps users and use cases while ensuring more consistent access expectations across developer pathways.
WE5.3.2b	If we establish a partner pilot program to experiment with Wikimedia attribution, we can show mutually beneficial impacts of attribution by reusers to drive engagement and contributions to Wikimedia.
WE5.3.3	If we provide content reusers with canonical, low-friction retrieval paths, we will lower the effort required to adopt trust signals from Wikimedia’s Attribution Framework, avoid the standardization of suboptimal retrieval paths, and unlock our ability to reliably measure attribution adoption.
WE5.3.3b	If we build a data pipeline to compute unique contributor counts and develop a method to serve it to MediaWiki, we will be able to surface contributor counts as a signal to Attribution API users.
WE5.3.3c	If we design and implement an API and event stream offering a naive, pageviews-based "relative trending" metric for pages, we will allow the Attribution API to use it as a Trust & Engagement metric and enable prototyping for the mobile apps.
WE5.3.4	If we define “qualified traffic” (specific outcomes of interest) and distinguish referrers by platform and surface, then we will observe systematic differences in downstream engagement and contribution outcomes that are relevant for product and partnership decisions.
WE5.3.4b	If we establish a consistent set of traffic health indicators, then we can reliably detect and explain meaningful shifts in Wikimedia’s incoming traffic over time and by referrer beyond raw pageview counts.
WE5.3.4c	If we analyze real-world visibility shocks as natural experiments, then we will see measurable changes in content quality and maintenance outcomes, supporting the relationship between visibility and content health.
WE5.4.2c	If we can identify the official Wikimedia mobile apps on iOS and Android in the CDN using their application-layer fingerprints, we can add them as a known-client in requestctl, allowing us to set exceptions and custom rate-limits on them to ensure a smooth user experience.
WE5.4.8b	If we rate limit requests for multimedia files based on a tally of response sizes, we will increase fairness in allocating the available bandwidth to users.
WE5.4.10	If we stop allowing generation of non-standard thumbnail sizes, it will reduce the strain on our backend media serving infrastructure.
WE5.4.12	If we create signals to distinguish on-site media traffic from external reuse, SRE can prioritize on-site traffic when under load by rate-limiting expensive media requests from external sources.
WE5.4.12b	If we can get the image provenance information from MediaWiki, we can use that in conjunction with other identifiers such as referrers and the assigned X-Is-Browser score to relax or vary the rate-limits for on-wiki users.
WE5.4.13	If we establish regular processing and reporting of WE5 objective indicator metrics (request rate, bandwidth, and User-Agent compliance), it will help us track progress across the KRs and assess the effectiveness of blocking high-volume scraping and enforcing the User-Agent policy.
WE5.4.14	If we make our WAF software less tied to our CDN infrastructure, it will be able to serve more use-cases, internal or not.
WE5.4.15	If we can identify and categorize known large-scale NATs containing wiki users, we can use this information to fine-tune ratelimits and other defenses more-strictly on a per-IP level to blunt some of the impact of scraping.
WE5.4.16	If we create a threat model for selected operators of automated traffic, including their intentions, level of investment and techniques employed, we will be able to advance the SRE teams’ ability to identify scrapers and other actors.
WE5.4.17	If we can do near-real time analysis on webrequest traffic to detect one kind of persistent scraping campaign, it will allow us to export rules from the data lake that we can push out to the edge automatically to block/throttle that scraping.
WE6.3.3	If we implement critical Language Variant support improvements and successfully deploy Parsoid to at least 3 Language Variant wikis in Q2, we will identify and resolve the key technical challenges necessary to confidently roll out to all remaining Language Variant wikis.
WE6.5.1	If we investigate and audit the performance concerns and catalog the content-caching fragility for logged-in users, informed by the Readers' strategy for readership retention, we can plan ST6.4 confidently with the right prioritisation framework by observing which cataloged concerns deliver the most value.
WE6.5.2	If we experiment with a platform for cross-wiki code collaboration, testing on at least 4 Indian communities, we will learn how to empower community developers to reuse modules across wikis, and receive positive feedback of these findings at the Hackathon the first week of May. This will be scoped to Lua Modules only, and integrated with WMF's GitLab infrastructure.
WE6.6.1	If we reduce the runtime of the Browser Test jobs to under 10 minutes, we will remove them as the bottleneck and reduce the feedback time of the MW Core Main test build.
WE6.6.2	If we reduce the runtime of the Unit Test jobs to under 10 minutes, we will remove them as the bottleneck and reduce the feedback time of the MW Core Main test build.

Signals & Data Services (SDS) Hypotheses [ SDS Key Results ] Discussion
Hypothesis shortname	Q4 text	Details & Discussion
SDS1.5.1	If we create a regular, operationalized internal audit process for bot classification outputs, we will build trust in our solutions and anticipate changes in traffic patterns that are not automatically detected.
SDS1.5.2	If we deploy a Test Kitchen instrument with 100% sampling and a request identifier, we'll be able to capture all requests regardless of whether or not they sent client-side events and analyze them for bot behavior.
SDS1.5.3	If we analyze the basic client-side signal and incorporate it into our heuristics, we will detect additional bot patterns in the Data Platform.
SDS1.5.4	If we move our heuristics to a private repository, we will protect the exact logic and data sources we use from motivated attackers.
SDS1.5.5	If we add a numerical score to our pageview metric based on 2 of the signals we’ve evaluated, we will provide a more complete and nuanced view of our traffic.
SDS1.5.6	If we use hCaptcha scores collected as events on account creation and edits as trusted labels, we’ll be able to correlate them to signals and our current bot detection heuristics to evaluate both.
SDS2.2.4	If Product Safety and Integrity reviews GrowthBook and FerretDB, we will be able to identify, then mitigate and/or address any material risks before production rollout.
SDS2.2.5	If we update Test Kitchen JS and PHP SDKs with methods to log experiment exposure, we will not need to treat all events as exposure events, which will improve performance of experiment assignment queries in GrowthBook and yield more accurate experiment results.
SDS2.2.8	If we conduct end-to-end user acceptance testing (UAT) with analyzing Reader Growth’s upcoming A/B/C test exclusively in GrowthBook, then we will learn which aspects of the experience meet production-readiness standards and which need improvement and supporting content before wider rollout.
SDS2.3.1	If we validate and adapt GrowthBook's API to our own, we can use GrowthBook as the canonical experiment control plane, and if we regularly poll GrowthBook's API, we can deliver experiments configured in GrowthBook quickly and easily.
SDS2.3.2	If we implement custom validation in GrowthBook, we’ll know people can’t accidentally misconfigure experiments in ways that violate the constraints of the platform.
SDS2.3.3	If we confirm role-based needs for GrowthBook users (humans, automation scripts from WMF, affiliates with established trust, and prospectively, vetted NDA end users), ensure automatic de-provisioning of stale users with regular report back to DPE, and update documentation to describe the role-based approach and user expectations regarding permissions and system interaction, user onboarding will be more predictable, and we'll have some additional guards to avoid exceeding our paid licensed seating.
SDS2.4.2	If we safely expand traffic enrolment through monitored stress testing, we will increase statistical power for Reader team experiments, shortening experiment timelines and improving decision confidence.
SDS2.4.3	If we introduce support for non-cache splitting experiments, then teams will be able to test JS-only features beyond the current traffic caps (10% all wikis, 0.1% enwiki), removing one of the primary barriers preventing teams from adopting Test Kitchen.

Product and Engineering Support (PES) Hypotheses [ PES Key Results ] Discussion
Hypothesis shortname	Q4 text	Details & Discussion
PES1.4.2	If we make Codex PHP easier to use and stable enough to do a 1.0 release, then teams will adopt Codex PHP for server-generated UIs. This will increase Codex PHP usage from 3 projects to 5.
PES1.5.3	If we enable SLO-based alerting, and make it possible to generate reports quarterly and automatically, service owners will be able to respond to service reliability data without (always) needing SRE to initiate.
PES1.5.4	If we set expectations with SRE Ambassadors about roles and responsibilities for SLOs and production readiness in FY26-27, onboard TPgMs and Objective owners to those expectations, and define how the SLO working group will operate, we will achieve buy-in and scalability for “business as usual” SLO and production readiness work starting in Q1.
PES1.6.2	If we onboard directors to the Service Catalog, they will populate it with "obvious" candidates, and we will identify and find owners for at least 2 more critical unowned services.

Future Audience (FA) Hypotheses [ FA Key Results ] Discussion
Hypothesis shortname	Q4 text	Details & Discussion
FA1.1.2	If we create and test 3 different app-based content discovery features as short experiments, we can share recommendations with the Apps team about how to effectively engage with and retain a new generation of apps users
FA1.1.6	If we create 3 different potential previews for Wikipedia links shared on Discord, we can align internally on our measurement and execution strategy and collaborate with Discord's ProdEng team.
FA2.2.1	If we invest in community management across short-video platforms, then by the end of Q2 (December 2025) we will see a 30% QoQ increase in the percentage of views from New Viewers on TikTok — and across all SFV platforms, we’ll earn 50,000 total engagements (likes and reply comments) on brand comments left on external content, which will help us increase visibility and drive engagement with audiences we’re not currently reaching.
FA2.2.2	If we develop and get sign-off on a Wikipedia Creator Partnerships Program internal strategy and external shareables (inclusive of an outline of our value to creators, partnership criteria, contracting process, and how creator content will show up across owned and creator channels), we will be able to establish a robust creator strategy that will help us reach new audiences across social media with our knowledge content.

Planifier ensemble

Mise à jour de janvier 2025.

Le Plan Annuel est la description de ce que la Fondation Wikimédia espère accomplir au cours de l'année à venir. Nous nous efforçons de rendre ce plan participatif, ambitieux et réalisable. Chaque année, nous invitons les contributeurs à partager leurs points de vue, leurs aspirations et leurs demandes spécifiques pour orienter l'élaboration du plan. Parmi les moyens utilisés pour recueillir ces contributions, on trouve les discussions des équipes produits avec les communautés, la liste de souhaits de la communauté, les conversations communautaires comme la série de discussions sur Commons, les conférences et les pages wiki comme celle-ci.

Pour notre prochain plan annuel, de juillet 2025 à juin 2026, nous réfléchissons à la meilleure manière de soutenir une vision intergénérationnelle face aux changements rapides dans le monde et sur Internet, et à l'impact de ces évolutions sur notre mission de libre diffusion des connaissances.

Comme je l'ai dit l'année dernière, nous devons nous concentrer sur ce qui nous distingue : notre capacité à fournir un contenu digne de confiance alors même que la désinformation et les fausses informations prolifèrent sur l'internet et sur les plateformes qui se disputent l'attention des nouvelles générations. Il s'agit notamment de s'assurer que nous remplissons notre mission, qui est de rassembler et de transmettre au monde la somme de toutes les connaissances humaines, en élargissant notre couverture des informations manquantes, qui peuvent être dues à l'iniquité, à la discrimination et aux préjugés. Notre contenu doit également servir et rester vital dans un internet en pleine mutation, mû par l'intelligence artificielle et les expériences enrichissantes. Enfin, nous devons trouver des moyens de financer durablement notre mouvement en élaborant une stratégie commune pour nos produits et notre collecte de fonds afin de pouvoir soutenir ce travail à long terme.

Pour faire des choix et des compromis concernant les domaines sur lesquels concentrer nos efforts l'année prochaine, nous avons rassemblé des questions et réfléchi à la manière d'allouer nos ressources limitées pour obtenir le maximum d'impact.

Si vous êtes particulièrement intéressé par les fonctionnalités ou services que le département Produit et Technologie développera en fonction des priorités établies ici, vous aurez l'occasion en mars de commenter les objectifs spécifiques et les résultats clés. (Voici les objectifs et les résultats clés du plan annuel actuel, pour référence.)

Si vous souhaitez réfléchir aux défis et aux opportunités de notre environnement technique ainsi qu'à l'orientation à adopter dans le prochain plan annuel, veuillez examiner avec nous les questions ci-dessous.

Nous recueillons en permanence des informations sur ces questions de diverses manières : à travers les conversations avec la communauté, les données que nous collectons, les entretiens de recherche que nous menons, et bien d'autres encore. Ce n'est pas la première fois que nous posons ces questions et apprenons à leur sujet – et nous avons déjà accompli un travail considérable autour de beaucoup d'entre elles ! Nous souhaitons les poser à nouveau maintenant et continuer à apprendre, car elles sont au cœur de nos préoccupations à ce stade de notre planification.

Questions :

Métriques et données
- Quelles sont les façons dont les données et les métriques pourraient mieux soutenir votre travail en tant qu'éditeurs ? Pouvez-vous penser à des données sur l'édition, la lecture ou l'organisation qui vous aideraient à choisir comment passer votre temps, ou à identifier quand quelque chose nécessite de l'attention ? Cela pourrait être des données sur votre propre activité ou sur l'activité des autres.
Édition
- Quand l'édition vous semble-t-elle la plus gratifiante et la plus agréable ? Quand vous sentez-vous le plus frustré et le plus difficile ?
- Nous voulons que les contributeurs reçoivent davantage de commentaires et de reconnaissance pour leur travail, afin qu'ils n'aient pas l'impression que personne ne remarque les efforts qu'ils consacrent aux wikis. Quel type de retour d'information et de reconnaissance vous motive ? Qu'est-ce qui vous incite à poursuivre votre travail d'édition ?
- En raison de la taille des wikis, il peut être difficile pour les éditeurs de décider à quel travail sur le wiki il est le plus important de consacrer leur temps chaque jour. Quels sont les informations ou les outils qui pourraient vous aider à choisir comment passer votre temps ? Serait-il utile d'avoir un endroit central et personnalisé qui vous permette de trouver de nouvelles opportunités, de gérer vos tâches et de comprendre votre impact ?
- Nous voulons améliorer l'expérience de collaboration sur les wikis, afin qu'il soit plus facile pour les contributeurs de se trouver et de travailler ensemble sur des projets, que ce soit par le biais de collectes d'articles en attente, de « edit-a-thons », de WikiProjects ou même de deux rédacteurs travaillant ensemble. Selon vous, comment pourrions-nous aider davantage de contributeurs à se trouver, à se connecter et à travailler ensemble ?
Lecture/Apprentissage
- Les wikis se chargent plus ou moins rapidement en fonction de l'endroit où vivent les utilisateurs. Existe-t-il des régions du monde où vous pensez qu'une amélioration des performances est particulièrement nécessaire ?
- Comment pouvons-nous aider les nouvelles générations de lecteurs à trouver le contenu de Wikipédia intéressant et engageant ? Nous avons déjà discuté d'idées autour de contenu interactif et de vidéos dans le passé, et cette année nous nous sommes concentrés sur les graphiques et sur l'expérimentation de nouvelles façons de mettre en avant le contenu existant de Wikipédia. Comment pourrions-nous poursuivre sur cette voie pour utiliser notre contenu existant de manière nouvelle, et propre à Wikimédia ?
Modérateurs
- Que faudrait-il changer dans Wikipédia pour que davantage de personnes souhaitent s'impliquer dans des rôles de bénévoles avancés, comme les patrouilleurs ou les administrateurs ?
- Quelles informations ou quel contexte concernant les modifications ou les utilisateurs pourraient vous aider à prendre plus rapidement ou plus facilement des décisions en matière de patrouille ou d'administration ?
Tendances externes
- Quels sont les changements les plus importants que vous remarquez dans le monde en dehors de Wikimedia ? Il peut s'agir de tendances dans le domaine de la technologie, de l'éducation ou de la manière dont les gens apprennent.
- En dehors du mouvement Wikimédia, à quelles autres communautés en ligne participez-vous ? Quelles leçons pouvons-nous tirer des outils et des processus utilisés sur d'autres plateformes communautaires ?
- Comment utilisez-vous les outils d'IA à l'intérieur et à l'extérieur de votre travail sur Wikimédia ? À quoi l'IA vous sert-elle ?
Commons
- Quelles décisions pouvons-nous prendre avec la communauté Commons pour créer un projet durable qui soutienne la création de connaissances encyclopédiques ?
Wikidata
- Comment aimeriez-vous que Wikidata évolue à l'avenir ? Comment peut-il être le plus utile pour construire un contenu encyclopédique digne de confiance ?

Discussion

–– Selena Deckelmann