Les différentes façons dont j'ai utilisé l'IA pour améliorer ProleWiki

← Retour Les différentes façons dont j'ai utilisé l'IA pour améliorer ProleWiki

de CriticalResist
Publié le : 2025-10-24 (mis à jour : 2025-11-15)
Error: Invalid content

a

Lire plus

L'IA est devenue quasi omniprésente dans certains domaines, tout en suscitant encore de vives critiques dans d'autres. Cet essai n'a pas pour but de plaider pour l'une ou l'autre de ces positions (cela devra faire l'objet d'un guide bien plus complet et exhaustif), mais en guise de point de départ, voici quelques-unes des façons dont j'ai personnellement utilisé l'IA pour améliorer ProleWiki.

ProleWiki offre tout son contenu gratuitement à ses lecteurs, sans aucune attente de retour. Nous travaillons pour le lecteur, et l'IA nous a aidés à apporter ce travail au public de manière plus efficace, libérant du temps que nous pouvons consacrer à d'autres problèmes. Le but de cet essai est de proposer des idées et de stimuler la créativité dans les cas d'utilisation des LLM.

De nos jours, mon choix de LLM est Deepseek Cloud.

Comprendre la structure de MediaWiki

La première fois que j'ai utilisé l'IA (plus précisément les LLM) pour travailler sur ProleWiki, c'était pour m'aider à comprendre le fonctionnement du logiciel MediaWiki, sur lequel ProleWiki repose. C'est grâce à l'aide de l'IA que j'ai compris ce que sont les espaces de noms, ce que

Un argument courant contre l'IA est qu'elle incite les gens à éteindre leur cerveau. Au contraire, je trouve que c'est un choix. Lisez les résultats de manière critique et vérifiez les informations importantes, et vous apprendrez. MediaWiki est notoirement mal documenté, avec des informations importantes difficiles à trouver, voire inexistantes. Certaines explications fournies par les développeurs nécessitent plusieurs lectures pour être comprises, et manquent parfois de la pièce d'information que vous recherchez réellement. Cependant, il existe de nombreuses discussions en ligne sur MediaWiki, et les LLM disposent donc de beaucoup de matériel d'entraînement sur ce logiciel.

Le premier projet que je voulais réaliser était de refaire la page d'accueil de la bibliothèque, qui n'était auparavant qu'une simple liste. Mais je n'étais pas sûr de ce que nous pouvions exactement coder sur MediaWiki et comment. J'ai expliqué mon idée en détail à un LLM, et il m'a fourni un guide étape par étape pour y parvenir. J'ai réalisé que ce n'était pas aussi difficile que je le pensais (nous envisagions potentiellement d'embaucher un développeur pour cela, malgré l'absence de fonds) et j'ai pu le coder moi-même. Il me fallait simplement un tutoriel qui, malheureusement, n'existait pas encore sur Internet.

Aujourd'hui, je suis le développeur MediaWiki que nous aurions dû embaucher autrement. Cela réduit les temps d'inactivité et nous permet de répondre rapidement et efficacement aux nouveaux bugs et fonctionnalités que nous voulons apporter pour servir les lecteurs.

Avec cette aide, je suis passé d'un utilisateur de niveau 1 de MediaWiki à un niveau 8 ou 9, et j'apprends davantage chaque semaine, confronté à des problèmes émergents que nous devons résoudre, comme nous le verrons dans les sections suivantes.

Créer la nouvelle page d'accueil

Fin 2024, nous avons introduit une nouvelle page d'accueil pour ProleWiki, ici (et l'ancienne est archivée ici).

Je suis designer de métier, donc mon recours aux LLM pour ce projet a été globalement faible. Cependant, tout le monde a ses angles morts et je n'y fais pas exception. Dans mon cas, il m'est difficile de démarrer un projet, mais une fois que la balle est lancée, tout devient plus facile. Pour la nouvelle page d'accueil, j'ai suivi la méthode de design thinking. J'ai d'abord demandé au LLM d'expliquer cette méthode avec ses propres mots, puis je l'ai guidé étape par étape. J'ai eu besoin du plus d'aide pour l'étape 1, Comprendre [votre public].

Nous avions une idée de notre public, mais l'aide du LLM nous a permis d'être plus confiants dans nos hypothèses, a révélé des considérations auxquelles nous n'avions pas nécessairement pensé, et nous a finalement aidés à lancer ce projet.

Voyez-vous, la première question qu'un designer se pose est : pourquoi voulons-nous même une nouvelle page d'accueil ? Ce que nous savions, c'est que notre ancienne page d'accueil nous avait bien servis, mais qu'elle était sévèrement dépassée en raison de la croissance considérable de ProleWiki en quatre ans d'existence. Nous avions aussi une idée des publics qui nous lisent (quatre au total), mais le LLM a pu nous aider à confirmer cela, à donner des noms à ces cohortes et à créer des personas plus détaillés que « je suppose que certaines personnes aiment les sources, je ne sais pas ».

Et il ne s'agit pas seulement de ce qu'il faut ajouter à cette nouvelle page d'accueil, mais aussi de ce qu'il faut retirer. Qu'est-ce qui est important, et qu'est-ce qui ne l'est pas ? Où placer les éléments importants ou non ? Grâce à Vision (la reconnaissance de ce que représente une image), nous avons pu soumettre cette nouvelle page d'accueil au LLM une fois codée et lui poser des questions. Nous avons également pu interroger les pratiques d'accessibilité que nous ne maîtrisions pas nécessairement.

Ainsi, un LLM a été un outil dans le processus de design pour combler les lacunes et les points faibles. En cours de route, j'ai personnellement renforcé ma compréhension de la méthode de design thinking et appris de nouvelles choses.

Cette nouvelle page d'accueil sert équitablement nos trois différents publics, ce qui est un équilibre délicat à atteindre.

Ajout de préférences pour le confort du lecteur

Police de caractères et thème Sépia (ainsi que potentiellement d'autres thèmes personnalisés) ajoutés par ProleWiki

Une autre grande addition, entièrement réalisée par un LLM cette fois, est l'ajout de nombreuses préférences dans l'icône d'engrenage (dans la barre latérale).

Par défaut, notre thème (ou skin, comme l'appelle MediaWiki) ajoute cette icône d'engrenage et des préférences de base : taille du texte, largeur de la page et schémas de couleurs clair/sombre.

Je voulais développer cela davantage, car ma philosophie en matière de développement pour ProleWiki est que chaque lecteur devrait pouvoir personnaliser son expérience. Les sites web doivent s'adapter à l'utilisateur, et non l'inverse.

Avec l'aide d'un LLM, nous avons ajouté de nouvelles préférences faciles à modifier : un sélecteur de police (actuellement sans empattement, avec empattement et polices d'accessibilité) ainsi que davantage d'options de couleurs : nous avons un mode sépia pour un compromis entre le mode clair et sombre, et en juin, nous proposons un thème LGBT/trans pour le Mois de la Fierté.

En arrière-plan, tout cela est ajouté via JavaScript. Nous avons un tableau qui nous permet d'ajouter des thèmes et polices personnalisés, puis dans le fichier CSS, nous déclarons l'apparence de notre thème ou police. Avec ce système, nous pouvons facilement créer d'autres thèmes et les rendre disponibles pour la sélection. Cela n'était pas réalisable nativement avec notre thème MediaWiki, nous l'avons donc codé pour répondre à nos besoins.

Pour y parvenir avec un LLM, j'ai simplement fourni à Deepseek la structure HTML du panneau de préférences et expliqué ce que je voulais. J'ai veillé à inclure que je souhaitais pouvoir créer facilement de nouveaux thèmes moi-même, et il a proposé la structure de tableau.

Mode lecture

Dans le cadre d'un objectif de longue date visant à améliorer l'expérience de lecture sur ProleWiki, j'ai également déployé une bascule pour le mode lecture. Il est actuellement en mode Alpha jusqu'à ce que nous sachions où le placer, et vous pouvez l'activer sur ordinateur en appuyant sur la touche 0 (il n'y a pas de bascule sur mobile car le thème du site le gère déjà automatiquement).

Ce mode a été entièrement développé par Deepseek. Je lui ai dit que je voulais basculer une certaine classe sur la balise <html> lorsque la touche 0 était enfoncée. Ensuite, je suis allé moi-même dans le fichier CSS du thème et j'ai manuellement supprimé les éléments que je ne voulais pas afficher. Le code original contenait quelques erreurs (par exemple, il pouvait se déclencher alors que vous étiez dans l'éditeur, c'est-à-dire en train de modifier le contenu d'une page), mais cela a été facilement corrigé en signalant simplement le bug au LLM. Les tests auront lieu quoi qu'il en soit de ce que vous codez.

Bien sûr, le code est un peu plus complexe que simplement ajouter une classe à une balise HTML. Il doit sauvegarder ce choix afin que, lorsque vous chargez une nouvelle page, vos préférences soient également chargées (c'est ainsi que j'ai découvert la propriété localStorage de JS). Il doit également actualiser correctement la préférence sauvegardée si vous passez, par exemple, de sans empattement à avec empattement : il doit supprimer la préférence sans empattement de localStorage et sauvegarder la nouvelle préférence avec empattement. Le LLM a géré cela de manière transparente tout seul.

J'ai appris le CSS avant que les LLM ne soient commercialement disponibles, mais à l'époque, les modes sombre et clair n'étaient pas répandus sur les sites web et reposaient souvent sur des techniques plus rudimentaires (comme la création d'un site web entier en mode sombre). Avec l'aide des LLM, je sais maintenant comment créer un thème sombre sur n'importe quel site web. J'ai appris grâce à un tutoriel.

(Le mode lecture sera bientôt déployé de manière plus accessible qu'une pression sur le clavier – nous estimons qu'il n'y a pas d'urgence, car il n'a pas existé pendant les 5 dernières années sans poser de problèmes.)

Simplification du code JavaScript pour améliorer les performances

En fin de compte, tout cela ajoute beaucoup de code JavaScript au site web. Ce n'est pas de loin le composant le plus gourmand en ressources (nous avons toujours des images, du PHP et d'autres éléments en cours d'exécution, comme tous les sites web), mais il vaut la peine d'économiser des ressources là où c'est possible.

Lorsque notre fichier JavaScript personnalisé a atteint une taille suffisante, j'ai entrepris de le refactoriser avec Deepseek pour améliorer les performances. J'ai simplement fourni les 1000 lignes (et oui, Deepseek gère facilement plus de 1000 lignes de code en une seule invite) et expliqué ce que je voulais. J'ai également dû intervenir manuellement dans certains domaines.

À la fin du processus, qui a pris si peu de temps que je n'ai même pas pris note de sa durée, nous sommes passés de plus de 1000 lignes de code à 600 – et une grande partie de cette réduction provenait de la réécriture de la logique de nos scripts, et non simplement de la suppression de commentaires et de sauts de ligne. Le fichier JS a perdu la moitié de sa taille initiale. Nous avons également ajouté des vérifications pour éviter d'exécuter certains scripts si certaines conditions n'étaient pas remplies. Ainsi, les utilisateurs sur des appareils plus anciens ou plus lents économisent du temps de chargement et de la puissance de traitement.

Script de division de livres

Toujours dans le cadre de l'amélioration de l'expérience de lecture, nous avons commencé à diviser nos livres de la bibliothèque en sous-chapitres. Vous pouvez voir le résultat sur ce livre : Bibliothèque:Vladimir Lenin/Matérialisme et empiriocriticisme.

Ce script Python a été entièrement codé par un LLM (Deepseek) de manière autonome. Je ne vais pas mentir, ce fut difficile. De nombreux cas particuliers devaient être pris en compte, et beaucoup d'éléments qu'il avait supposés (parce que nous n'avions pas pensé à les mentionner) ont dû être réécrits. Mais au final, nous avons réussi à le faire fonctionner. Ce script peut désormais être utilisé sur n'importe quelle page de bibliothèque : il génère une table des matières qui mène vers des sous-pages contenant chaque chapitre. Ensuite, tout ce contenu secondaire est réintégré sur la page principale, permettant aux lecteurs de choisir leur mode de lecture : soit par sous-chapitres, soit directement sur la page principale. Notre philosophie est d'offrir des choix aux lecteurs pour qu'ils puissent adapter leur expérience à leurs préférences, et les LLM nous aident à y parvenir.

Un travail manuel reste bien sûr nécessaire dans un tel projet. On ne peut pas donner une seule instruction à un LLM et s'attendre à ce que tout fonctionne immédiatement. Comme avec un développeur humain, il faut lui expliquer clairement ce que l'on veut et comment on le veut. Dans ce cas, je savais déjà ce que je voulais obtenir : par exemple, une table des matières, l'inclusion du contenu des chapitres sur la page principale du livre, et les flèches de navigation souvent négligées en bas de chaque chapitre. La partie difficile pour moi était d'écrire le script qui fait tout cela, alors un LLM l'a fait en quelques heures.

Un développeur humain aurait-il pu écrire ce script ? Oui, bien sûr. Mais il n'aurait peut-être pas pu le faire aussi rapidement, ou exactement comme nous le voulions. Nous cherchons des développeurs de tous horizons depuis des années, sans grand succès – hélas, les gens ont aussi leurs préférences et leurs emplois, et nous ne pouvons pas leur demander de consacrer 40 heures par semaine à ProleWiki gratuitement. Ils pourraient aussi vouloir faire les choses à leur manière, et ne pas livrer exactement ce dont nous avons besoin, mais ce qu'ils ont envie de livrer. Ce n'est pas une critique, mais plutôt un point important à considérer concernant les LLM. Les LLM vous donneront le résultat que vous leur demandez ; parfois c'est bien, parfois c'est insuffisant. Mais ils ne vous jugeront pas et ne refuseront pas de travailler pour vous.

Ce type de projet bénévole est un domaine où l'utilisation des LLM prend tout son sens, car cela nous permet de livrer du contenu à nos lecteurs beaucoup plus rapidement et avec des ressources minimales, que nous n'avons pas en premier lieu.

Traduction des pages et des œuvres

Nous avons utilisé des LLM pour traduire des pages et des œuvres entières de la bibliothèque, bien que les résultats soient mitigés. Beaucoup d'efforts sont nécessaires pour obtenir quelque chose de proche de l'original. La qualité est lisible ; il n'y a pas d'hallucinations, mais le LLM peut décider de raccourcir une phrase et ne saura pas toujours traduire certains termes techniques de manière cohérente (car on lui fournit le livre par morceaux).

Nous avions précédemment envisagé de faire traduire professionnellement Le Sentier lumineux de la CIA : Guerre politique. Un tel livre pourrait coûter plus de 12 000 $ pour une traduction professionnelle – une somme que nous ne pourrions jamais réunir, même avec une campagne de financement. Nous pouvons aussi refaire la traduction à mesure que les modèles s'améliorent, et la mettre à jour. En fait, ce livre avait initialement été traduit avec un modèle désormais considéré comme obsolète.

Avec ce type d'outil, nous pouvons rendre accessible au grand public de nombreuses théories qui n'étaient auparavant disponibles que dans une seule langue. Ce ne sera peut-être pas la meilleure traduction de tous les temps, mais cela n'a pas besoin de l'être si c'est la première du genre. Plus tard, des traducteurs professionnels pourront toujours réaliser leur propre version. À ce stade, cependant, nous continuons d'affiner nos instructions et notre processus de traduction pour obtenir des résultats plus précis.

Si nous parvenons à atteindre au moins 90 % de précision dans la traduction des pages, nous envisageons d'utiliser des modèles locaux et un script pour traduire automatiquement tout ProleWiki dans d'autres langues. Cela a du sens, car : a) nous ne sommes pas des traducteurs professionnels et ne ferions peut-être pas mieux que le LLM, b) cela prendrait des années à une équipe de bénévoles, alors qu'un script peut fonctionner en continu jusqu'à ce que la tâche soit terminée, et c) nous travaillons principalement sur l'instance anglaise (c'est en quelque sorte la branche principale), qui contient donc la majorité du contenu. Même les contributeurs qui participent à d'autres instances contribuent surtout à l'instance anglaise.

Résolution des problèmes de VPS

MediaWiki est un logiciel assez complexe. Bien qu'il présente quelques lacunes dans sa documentation, il reste un outil très puissant capable de répondre à tous nos besoins – certaines fonctionnalités sont prêtes à l'emploi, et d'autres doivent être configurées par nos soins.

Pour cette raison, nous exécutons MediaWiki sur un serveur privé virtuel (VPS). Cela signifie que nous sommes responsables de la gestion de la charge du serveur, des vulnérabilités et des bugs qui pourraient apparaître. Il y a certaines choses dont je ne peux pas parler car elles sont sensibles à notre opération, mais j'ai utilisé des LLMs comme assistant pour résoudre des problèmes de VPS avec un grand succès. Bien sûr, il ne faut pas simplement faire confiance au LLM lorsqu'il s'agit de la gestion de matériel sensible. Vérifiez deux fois, à la fois en ligne et avec quelqu'un d'autre, et si vous n'êtes pas sûr de quelque chose, ne le faites pas. Mais le dépannage est sans danger (par exemple, exécuter netstat), et un LLM peut vous aider avec cela. Vous pouvez ensuite simplement lui envoyer le journal et il trouvera le problème.

De même, il peut aider à installer de nouveaux logiciels. Les VPS ne viennent pas avec autre chose que le strict minimum, donc nous avons installé fail2ban nous-mêmes pour gérer le trafic des bots. Le LLM a aidé à l'installer et à le configurer avec les règles que je voulais qu'il ait, et maintenant je sais comment le faire sans aide. Pour être clair, le LLM n'a fourni que des instructions sur son interface en ligne - j'ai ensuite lu ces instructions et suivi manuellement le guide. À aucun moment l'IA ne s'est connectée à notre VPS et n'a effectué de modifications elle-même, ce qui pourrait être très dangereux.

Avec le temps, je me suis également familiarisé avec notre distribution Linux (qui est entièrement basée sur la ligne de commande) et je peux maintenant plus ou moins gérer un VPS moi-même. Auparavant, nous n'avions qu'un seul utilisateur capable de gérer le VPS : s'il tombait malade ou était occupé, nous ne pouvions rien faire si le site tombait soudainement en panne ou si nous devions installer quelque chose de nouveau.

Pourriez-vous apprendre cela avec une recherche Google ? Oui, mais : 1. cela ne correspondrait pas nécessairement à votre cas spécifique et vous devriez effectuer plus de recherches pour comprendre pleinement le problème, 2. ce qui compte, c'est que vous appreniez d'une manière ou d'une autre. Même aujourd'hui, en tant que pro du CSS, je dois encore régulièrement rechercher sur Google certaines propriétés de base parce que j'oublie si je veux align-content ou align-items pour mon flexbox. Ne prétendons pas qu'avant les LLMs, nous avions tous une mémoire parfaite et réussissions du premier coup.

Il y a certaines choses que les LLMs n'ont pas pu résoudre pour nous, mais ce sont aussi des choses que nous n'aurions pas pu résoudre nous-mêmes. Certaines erreurs n'ont vraiment aucun sens et ne devraient pas se produire, donc je ne peux pas en tenir rigueur au LLM. Dans la plupart des cas, un peu d'échange suffisent pour trouver le problème et le résoudre.

À venir

J'ai probablement d'autres exemples que j'ai simplement oubliés, car l'utilisation des LLMs est devenue une partie si intégrée de notre processus sur ProleWiki. Nous ne les utilisons pas pour écrire directement du contenu (bien qu'ils puissent aider avec la syntaxe et la simplification de phrases compliquées), car ce n'est pas vraiment là qu'ils excellent. Mais nous les utilisons beaucoup pour les aspects techniques et, plus important encore, pour combler nos lacunes.