Applications Wikimedia/Équipe/L'avenir de l'édition sur les applications mobiles
Définition du problème
Ces applications attirent chaque année de nouveaux utilisateurs, et il est prévu de les promouvoir auprès de nouveaux publics. Les fonctionnalités de lecture constituent la principale raison pour laquelle les utilisateurs téléchargent les applications, et la plupart des commentaires que l'équipe reçoit de la part des utilisateurs portent sur l'amélioration de ces fonctionnalités. À mesure que ces lecteurs s'impliquent davantage dans Wikipédia, certains d'entre eux se mettent à envisager de contribuer. Parmi ceux qui tentent de modifier leurs articles, nombreux sont ceux qui constatent que l'interface d'édition de l'application (bien que suffisante pour les modifications de base) ne propose pas encore l'éditeur visuel ni d'autres fonctionnalités disponibles sur la version mobile du site web. Les nouveaux utilisateurs ont également du mal à trouver des espaces communautaires tels que le « Teahouse » et le « Help Desk » depuis les applications.
Cela pose un risque pour le recrutement des contributeurs. De nombreux contributeurs font leurs premières contributions en corrigeant de petites erreurs au fil de leur lecture. Si ces moments d'inspiration surviennent au sein de l'application et qu'un nouveau venu se retrouve face au wikitexte sans pouvoir utiliser VisualEditor, cela risque de le décourager avant même qu'il ne prenne ses marques.
Ce que révèlent les études
Une étude réalisée en avril 2025 sur la lecture et la modification dans l'application iOS a mis en évidence des tendances récurrentes chez les contributeurs novices comme chez les contributeurs expérimentés : sans VisualEditor, le wikitexte devient un obstacle. Comme l'application ne dispose pas de l'éditeur visuel, toute personne qui ouvre un article pour le modifier se retrouve immédiatement face à du wikitexte brut, qui ressemble à du code et qui conduit de nombreux nouveaux utilisateurs à penser que la modification nécessite des connaissances techniques. Cette perception décourage activement toute contribution avant même qu'elle ne commence. Même les contributeurs expérimentés ne sont pas épargnés : même ceux qui maîtrisent le wikitexte trouvent que la modification du code source sur mobile est lente et source d'erreurs. Les participants à l'étude ont systématiquement décrit VisualEditor comme étant plus rapide et plus intuitif. Pour beaucoup, son absence dans l'application est la principale raison pour laquelle ils ne font pas leurs modifications là-bas.
Voici quelques citations tirées directement des témoignages des participants à l'étude :
Sur PC, vous pouvez choisir entre l'édition au niveau du code source et l'édition visuelle, ce qui rend l'expérience beaucoup plus intuitive. Sur l'application, l'édition visuelle ne semble pas disponible, ce qui est regrettable. Si cette fonctionnalité était ajoutée, elle rendrait l'édition plus accessible aux débutants.
Il faudrait une fonctionnalité permettant de modifier le contenu sans avoir à consulter le code wiki, comme sur la version pour ordinateur. Un éditeur visuel : il faudrait quelque chose de ce genre pour l'application. Je pense que cela rendrait les choses beaucoup plus pratiques.
Je n'ajouterais aucune référence, car tous ces symboles m'intimident. C'est vraiment fastidieux de procéder à des modifications approfondies fondées sur des recherches ici.
Commentaires reçus de la communauté
Ces conclusions rejoignent les remarques formulées indépendamment par des rédacteurs expérimentés. Ces préoccupations sont prises très au sérieux. L'objectif de cette page est de les examiner ouvertement.
Ces conclusions concordent avec ce que les éditeurs ont souligné de manière indépendante. Les citations ci-dessous ont été recueillies à partir des avis publiés sur l'App Store, des e-mails envoyés au service d'assistance et d'une discussion récente sur le forum de discussion de Wikipédia en anglais.
Je passe souvent sur le Web mobile pour faire des modifications, car les outils y sont plus faciles à utiliser.
Si l'application limite les possibilités d'édition ou ne propose pas toutes les fonctionnalités disponibles sur la version Web mobile, elle devrait indiquer clairement que la version Web mobile est plus adaptée à cette tâche.
Pas d'éditeur visuel, pas d'accès au service d'assistance ni au Teahouse... Ne convient pas aux nouveaux contributeurs. Ne convient pas non plus aux contributeurs expérimentés. Si la WMF a l'intention de rendre l'application équivalente à la version web mobile, je suis partant. Si elle reste aussi médiocre, alors il faut dissuader les contributeurs de l'utiliser dès que possible. L'expérience de lecture est meilleure sur l'application. Mais les gens lisent Wikipédia parce que ceux qui les ont précédés ont modifié les pages pour créer ce contenu.
Le bouton « Modifier » de l'application pourrait-il rediriger vers le site web ? Beaucoup de gens effectuent leurs premières modifications en corrigeant des fautes d'orthographe au fur et à mesure de leur lecture. Si l'application est trop compliquée à utiliser pour effectuer des modifications, cela risque de décourager les contributeurs potentiels.
Pour modifier le contenu de l'application, il faut utiliser le wikitexte, ce qui rend la tâche difficile pour les débutants.
L'application est très pratique pour lire, mais elle ne l'est pas vraiment pour modifier des documents.
Si l'édition fonctionne mieux sur le Web mobile, l'application devrait permettre de poursuivre facilement l'édition sur cette plateforme.
Arrière-plan et contexte
Les applications mobiles Wikipédia (iOS et Android) ont été initialement conçues comme des outils de lecture, mais au fil du temps, une fonctionnalité d'édition native et des suggestions de modification ont été ajoutées, que de nombreux utilisateurs utilisent activement. Les applications et le Web mobile n'ont jamais cherché à offrir les mêmes fonctionnalités ; elles ont délibérément mis l'accent sur la continuité tout en testant différentes fonctionnalités et en s'adressant à différents segments d'utilisateurs. Par exemple, les applications ont d'abord introduit les « modifications suggérées » comme méthode de contribution axée sur le mobile, qui a ensuite été développée et optimisée pour le Web mobile.
La Fondation Wikimédia a pris la décision organisationnelle délibérée d'investir dans le lectorat parallèlement à l'édition, en créant des équipes dédiées aux lecteurs afin de remédier à la baisse du nombre de lecteurs et de constituer une nouvelle génération d'utilisateurs de Wikipédia. Dans le cadre de la stratégie qui en découle, les applications seront positionnées comme l'expérience de lecture phare pour les lecteurs actifs, en mettant l'accent sur la découverte personnalisée, l'engagement quotidien et des liens plus profonds avec le contenu de Wikipédia. L'investissement dans l'édition, quant à lui, est concentré sur le Web par les équipes de contributeurs, qui ont intégré à l'expérience d'édition des outils tels que la vérification des modifications dans l'éditeur visuel, les suggestions de modifications et la page d'accueil pour les nouveaux arrivants. Le Web mobile bénéficiera également d'investissements issus de la recherche en cours sur l'édition mobile. As part of the resulting strategy, the apps will be positioned as the flagship reading experience for active readers, focusing on personalized discovery, daily engagement, and deeper connections to Wikipedia's content. Editing investment, meanwhile, is being concentrated on web by the Contributor teams, who have brought tools like Edit Check within Visual Editor, Suggested edits, and the Newcomer homepage to the editing experience. The mobile web will also be home to investments that come from ongoing mobile editing research.
Les équipes « Lecteurs » et « Contributeurs » travaillent ensemble sur ce sujet, et l'introduction de la fonctionnalité d'édition revêt une importance particulière sur les applications, où une grande partie des utilisateurs se connectent quotidiennement et où les utilisateurs quotidiens sont les plus susceptibles de s'essayer à l'édition. Lorsqu'un utilisateur de l'application manifeste son intérêt pour l'édition, quelle devrait être la suite ? C'est ce dont cette page a pour but de discuter.
Solutions possibles
Ce qui est à considérer
- Donner accès à l'éditeur visuel du Web mobile depuis l'application: L'application pourrait permettre aux utilisateurs de poursuivre leur édition sur le Web mobile, où l'éditeur visuel et d'autres outils plus complets sont disponibles. La question de savoir comment y parvenir efficacement reste toutefois en suspens. Voici quelques questions à l'étude :
- L'application devrait-elle proposer un transfert direct, en ouvrant l'article dans l'éditeur Web mobile lorsqu'un utilisateur appuie sur « Modifier », tout en conservant sa position dans l'application afin qu'il puisse y revenir par la suite ?
- L'éditeur Web mobile devrait-il s'afficher comme voie d'édition par défaut dès qu'un utilisateur manifeste son intention de modifier, ou seulement s'il en fait le choix délibéré ?
- Comment la transition doit-elle se faire ? Présentation dans une vue Web intégrée à l'application, redirection vers le navigateur, invite claire, bannière persistante.
- Should the app offer a direct handoff, opening the article in the mobile web editor when a user taps 'Edit', preserving their place in the app so they can return after?
- Should the mobile web editor be surfaced as the default editing pathway at the point where a user shows editing intent, or as a deliberate choice?
- How should the transition feel? Presented within an in-app webview, a redirect to the browser, a clear prompt, a persistent banner.
Qu'est-ce qui ne sera pas considéré ?
- Supprimer complètement les points d'accès à l'édition dans l'application : Les lecteurs très actifs sont des candidats idéaux pour une première contribution, et la base de lecteurs en pleine expansion de l'application offre une opportunité d'augmenter cette proportion. Pour les fonctionnalités destinées aux lecteurs qui nécessitent un compte, comme l'onglet « Activité », une partie des nouveaux comptes est régulièrement activée au sein des applications. La part des nouveaux contributeurs sur les applications (18 à 22 % des modifications provenant de personnes ayant un an d'expérience ou moins) est actuellement inférieure à celle du Web, et l'augmentation de cette cohorte fait partie des enjeux de cette discussion. Parallèlement, 33 à 37 % des modifications sur les applications proviennent de contributeurs ayant cinq ans d'expérience ou plus, qui s'appuient sur les points d'entrée existants. Tout changement doit tenir compte de ces deux cohortes.
- Développer un éditeur visuel entièrement natif pour les applications : Ce serait une entreprise de grande envergure pour l'équipe chargée des applications mobiles, qui entraverait sa capacité à investir dans des fonctionnalités visant à fidéliser les lecteurs. Un éditeur visuel natif sur les applications ne bénéficierait pas immédiatement des améliorations et des ajouts apportés à l'éditeur visuel Web ; le maintien de la parité des fonctionnalités nécessiterait donc un investissement continu alors que les applications accusent déjà plusieurs années de retard en matière de développement.
- Building a fully native visual editor for the apps: This would be a significant undertaking for the mobile apps team, and would hinder their ability to invest in reader retaining features. A native visual editor on the apps would not immediately benefit from improvements and additions to the web visual editor, so maintaining feature parity would require continued investment where apps are already years behind in development.
Discussion
La page de discussion est ouverte aux échanges. Des questions plus générales se posent quant à l'avenir de l'édition sur les applications, notamment le rôle des suggestions de modification, la manière de soutenir les contributeurs expérimentés, et les indices permettant d'identifier un contributeur potentiel afin de lui proposer de manière proactive un appel à l'action adapté et de lui confier une tâche. There are broader questions about the future of editing on the apps, including the role of Suggested Edits, how to support experienced editors, and what signals identify a potential editor where we can then surface the right call to action and handoff proactively. Vos commentaires sur ces questions plus générales sont les bienvenus. La question qui se pose actuellement est toutefois plus précise : quand un utilisateur de l'application appuie sur « Modifier » dans un article, comment l'application doit-elle s'assurer qu'il puisse accéder aux outils d'édition les plus performants disponibles — y compris VisualEditor sur le Web mobile ?
Questions pour les communautés
Voici quelques questions précises pour lesquelles il serait particulièrement utile d'obtenir des réponses :
- Quels sont les flux de travail d'édition ou les espaces communautaires les plus essentiels qui doivent être accessibles (même par redirection) depuis l'application ?
- Si l'éditeur Web mobile était accessible depuis l'application, les applications mobiles devraient-elles supprimer complètement l'éditeur natif ?
- Pour les contributeurs qui ont essayé d'éditer depuis l'application : à quel moment l'expérience s'est-elle avérée insuffisante, et l'accès à VisualEditor ou à l'éditeur Web mobile aurait-il changé la donne ?
- Y a-t-il des aspects du passage de l'application à l'éditeur web mobile qu'il serait particulièrement important de bien gérer ?
- Comment cette transition devrait-elle se présenter ? Une invite, une redirection, une explication claire de la destination de l'utilisateur et de la raison de ce transfert ?
- Pour les contributeurs qui accompagnent les nouveaux arrivants : à quelle fréquence l'application est-elle utilisée comme premier environnement d'édition, et quels problèmes cela entraîne-t-il ?
- If the mobile web editor was accessible from the app, should the Mobile Apps eliminate the native source editor altogether?
- For editors who have tried editing on the app: at what point did the experience fall short, and would access to VisualEditor / mobile web have changed that?
- Are there aspects of the handoff from app to mobile web editor that would be most important to get right?
- What should that transition feel like? A prompt, a redirect, a clear explanation of where the user is going and why?
- For editors who guide newcomers: how often does the app come up as a first editing environment, and what problems follow from that?