Ben DAVAKAN

Vous êtes au bon endroit pour concrétiser vos ambitions sur le web. Parlons-en dès maintenant.

WordPress publie de nouvelles consignes pour lutter contre les contenus médiocres produits par l’IA

WordPress publie de nouvelles consignes pour lutter contre les contenus médiocres produits par l’IA

WordPress publie de nouvelles consignes pour lutter contre les contenus médiocres produits par l’IA

WordPress publie de nouvelles consignes pour lutter contre les contenus médiocres produits par l’IA

Sommaire

WordPress a publié des **directives** encadrant l’utilisation de l’**IA** pour la création de plugins, de thèmes, de documentation et d’actifs multimédias. L’objectif de ces règles, organisées autour de cinq principes fondamentaux, est d’assurer que les contributions restent **transparentes**, compatibles avec la **GPL**, et portées par une responsabilité humaine, tout en maintenant des standards élevés de qualité pour le travail assisté par l’IA.

Les nouvelles directives énoncent les cinq principes suivants :

  1. « Vous êtes responsable de vos contributions (l’IA peut aider, mais elle n’est pas un contributeur). »
  2. « Déclarez toute aide significative de l’IA dans la description de votre PR et/ou dans le commentaire du ticket Trac. »
  3. « La compatibilité des licences est cruciale : les contributions doivent rester compatibles avec la GPLv2-or-later, y compris les contenus produits avec l’aide de l’IA. »
  4. « Les ressources non code comptent aussi (documentation, captures d’écran, images, supports pédagogiques). »
  5. « Priorisez la qualité sur la quantité : évitez le contenu IA à faible valeur ou non vérifié ; les réviseurs peuvent fermer ou rejeter un travail qui ne respecte pas le niveau attendu. »

Transparence

Le premier axe insiste sur la nécessité d’une transparence claire concernant l’utilisation de l’**IA**. Lorsque vous avez recours à des outils automatisés pour générer du code, rédiger de la documentation ou créer des éléments visuels, il est demandé d’expliquer comment l’IA a contribué afin de permettre aux examinateurs d’évaluer correctement la contribution.

Concrètement, cela signifie que vous devez documenter, dans la description de votre pull request (PR) ou dans le commentaire du ticket Trac, le rôle exact de l’IA : génération initiale, reformulation, suggestions de code, complétion de snippets, création d’images, etc. Cette approche vise à donner aux relecteurs un contexte suffisant pour juger de la qualité et de la provenance du contenu.

En pratique, une présentation transparente facilite :

  • la vérification de la conformité légale (licences) ;
  • l’identification des parties nécessitant une attention humaine supplémentaire ;
  • la traçabilité des décisions techniques et éditoriales.

Voici un exemple de squelette de description de PR, à adapter selon le cas :
– Source : outils d’IA utilisés (nom du service) ;
– Étendue de l’assistance IA : génération complète / ébauche / reformulation / suggestions ;
– Vérifications effectuées : tests unitaires, essais manuels, liens vers tickets ou documentation vérifiés ;
– Remarques : parties potentiellement problématiques ou nécessitant une revue approfondie.

Compatibilité des licences et choix des outils

La question des licences est au cœur de l’écosystème WordPress. WordPress est distribué sous la licence GPLv2 (ou ultérieure), et il est attendu que l’ensemble des éléments développés pour la plateforme — plugins, thèmes, bibliothèques associées — respectent cette obligation de logiciel libre. C’est un principe fondateur qui garantit la liberté d’utilisation, de modification et de redistribution.

Les directives rappellent qu’il est impératif de ne pas inclure dans les contributions des éléments dont la réutilisation ou la redistribution serait restreinte par la licence d’un outil tiers. Ainsi, si un service d’IA impose des conditions qui empêchent l’intégration ou la redistribution sous **GPLv2-or-later**, son utilisation est incompatible avec les contributions destinées à WordPress.

« N’utilisez pas d’outils dont les conditions interdisent l’emploi de leurs résultats dans des projets couverts par la GPL, ni d’outils qui ajoutent des restrictions supplémentaires à la redistribution. »

« Ne comptez pas sur des outils pour « nettoyer » ou modifier des licences incompatibles. Si la sortie d’une IA reproduit du code non libre ou incompatible, ce contenu ne peut pas être inclus. »

Autrement dit, le choix de l’outil d’IA n’est pas neutre : il faut vérifier les conditions d’utilisation et les clauses relatives aux droits d’auteur et à la propriété des sorties générées. Certains fournisseurs peuvent revendiquer des droits ou imposer des restrictions de réutilisation qui rendent leur sortie juridiquement inutilisable pour un projet GPL.

Recommandations pratiques concernant le choix des outils :

  • Consultez les termes de service et la politique de propriété des contenus pour chaque outil d’IA utilisé ;
  • Privilégiez des solutions dont la politique sur les sorties autorise la réutilisation sans restriction incompatible avec la GPL ;
  • Conservez des traces (captures d’écran, exportations, horodatage) des sessions d’IA si nécessaire pour établir l’origine et la nature des contenus générés ;
  • Lorsque le statut juridique d’un résultat généré est incertain, demandez l’avis d’un responsable juridique avant inclusion.

AI Slop

Le terme informel de « AI slop » désigne le contenu produit par l’IA qui manque de rigueur : hallucinations (liens, API ou références inexistantes), code inutilement complexe à la place d’une solution simple, ou PR génériques qui ne reflètent ni tests ni expérience réelle.

Les directives de WordPress mettent en garde contre ce type de production. Elles encouragent une utilisation réfléchie de l’IA : employer l’outil pour esquisser ou accélérer, puis apporter une revue et une validation humaines approfondies. Voici comment les contributeurs sont invités à se comporter :

« Utilisez l’IA pour rédiger des ébauches, puis revoyez le contenu par vous-même. »

« Soumettez des PR (ou des patches) petits, concis, avec des messages de commit atomiques et bien définis pour faciliter la revue. »

« Exécutez et documentez de véritables tests. »

« Liez les modifications à de vrais tickets Trac, issues GitHub ou à de la documentation que vous avez vérifiée. »

Pour éviter l’« AI slop », appliquez ces bonnes pratiques :

  • Ne soumettez pas de gros changements automatisés d’un seul coup : privilégiez des PR atomiques et ciblées ;
  • Incluez des tests automatisés ou des instructions de test pour démontrer que le code fonctionne dans des conditions réelles ;
  • Rédigez un message de commit qui explique la logique, les limites et les décisions prises ;
  • Vérifiez manuellement toute référence, lien ou exemple généré par l’IA afin d’éliminer les hallucinations ;
  • Expliquez quelles parties ont été écrites par une IA et quelles parties ont été revues ou créées par un humain.

Les mainteneurs et réviseurs ont la latitude d’ignorer, de fermer ou de rejeter des contributions qui, à leur avis, constituent de l’AI slop « sans valeur humaine ajoutée ». Cette latitude vise à préserver la qualité générale du code base et à protéger le temps des bénévoles impliqués dans la revue.

Points clés et conséquences pratiques

Globalement, les nouvelles directives montrent que WordPress adopte une position nuancée vis-à-vis de l’**IA** : l’outil est reconnu comme utile, mais son usage doit rester encadré. L’objectif est de préserver la confiance dans le processus de contribution tout en tirant parti des gains de productivité potentiels.

Les mesures principales à retenir :

  • Déclaration d’utilisation : toute assistance significative d’une IA doit être explicitée dans la PR ou le ticket Trac lié ;
  • Compatibilité GPL : il est interdit d’introduire du contenu dont la licence ou les conditions d’utilisation empêcheraient la redistribution sous GPLv2-or-later ;
  • Qualité : les mainteneurs peuvent rejeter les soumissions jugées de faible valeur ou non testées ;
  • Ressources non code : la règle s’applique également aux images, captures d’écran, tutoriels et autres actifs non code ;
  • Responsabilité humaine : l’IA assiste, mais ne remplace pas l’auteur ou le relecteur humain.

En pratique pour un contributeur, cela implique de structurer son travail comme suit :

  1. Choisir des outils dont les termes sont compatibles avec la GPL et conserver des preuves d’utilisation ;
  2. Utiliser l’IA pour accélérer des tâches (génération d’ébauches, suggestions de code, complétions) ;
  3. Effectuer une révision fine, adapter et simplifier le code généré ;
  4. Réaliser des tests documentés et joindre des captures de leurs résultats à la PR ;
  5. Rédiger une description de PR complète mentionnant l’aide de l’IA et les vérifications effectuées.

Considérations supplémentaires pour la documentation et les médias

Les directives rappellent explicitement que la contrainte de licence et la nécessité de qualité s’appliquent également aux éléments non techniques : documentation, captures d’écran, images, supports de formation, etc. Une image générée par une IA peut contenir des éléments protégés ou des artefacts reproduisant des œuvres non libres ; une documentation produite par l’IA peut citer des références inexistantes.

Pour ces actifs, il est recommandé :

  • De stocker les métadonnées et la provenance (outil utilisé, prompt, horodatage) ;
  • De s’assurer que les images ou ressources incluses n’enfreignent pas de droits d’auteur ;
  • De vérifier manuellement toutes les références, extraits ou copies d’exemples de code ;
  • De mentionner explicitement l’usage d’une IA dans la description du commit ou du ticket associé.

Exemples concrets et modèles de disclosure

Voici quelques modèles de formulation que l’on peut adapter dans une PR pour satisfaire l’exigence de transparence :

Modèle court :

« Cette PR inclut une assistance de l’IA (outil : nom_du_service) pour la génération initiale de X fichiers. Toutes les modifications ont été revues manuellement et testées (voir section Tests ci-dessous). Les parties critiques ont été réécrites ou vérifiées. »

Modèle détaillé :

« Aide IA : génération d’ébauches de code pour les fonctions A et B via nom_du_service (prompts : [description succincte]).

– Actions effectuées manuellement : refactorisation du code pour simplifier la logique, ajout de tests unitaires pour couvrir les cas X/Y/Z, vérification des appels API et des références citées par l’IA ;
– Tests : exécution de la suite de tests locale + résultats inclus dans les fichiers de tests ;
– Licences : vérification des TOS de nom_du_service — sorties autorisées pour une réutilisation sous GPLv2-or-later. »

Ces modèles permettent aux mainteneurs d’avoir un aperçu rapide et exploitable de l’étendue de l’assistance IA et des vérifications humaines réalisées.

Bonnes pratiques pour rédiger des PR adaptées aux relecteurs

Les relecteurs apprécient les PR bien préparées et faciles à analyser. Pour maximiser vos chances d’une intégration rapide :

  • Scindez les changements en petits commits logiques et atomiques ;
  • Ajoutez des descriptions de commit claires et concises (quoi, pourquoi, comment) ;
  • Incluez des captures d’écran, des logs de test ou des links vers des environnements de démonstration si pertinents ;
  • Expliquez les limites connues et les risques éventuels, par exemple les zones où l’IA a proposé une implémentation qui pourrait nécessiter une revue approfondie ;
  • Référencez explicitement les tickets Trac ou issues GitHub liés et précisez les vérifications effectuées côté documentation ou exécution.

Rôle des maintainers et des reviewers

Les maintainers et reviewers conservent la responsabilité finale d’accepter ou non une contribution. Les directives leur fournissent un cadre pour évaluer les contributions assistées par l’IA et pour rejeter celles qui ne satisfont pas aux exigences minimales de qualité ou de conformité de licence.

Les critères d’évaluation peuvent inclure :

  • Preuves de tests réels et reproductibles ;
  • Clarté du message de commit et de la description de la PR ;
  • Absence d’éléments manifestement générés et non vérifiés (hallucinations) ;
  • Conformité aux standards de code et aux bonnes pratiques du projet ;
  • Respect des exigences de licence et des politiques de réutilisation des sorties d’IA.

Si une contribution est jugée problématique, un maintainer peut demander des corrections, fermer la PR ou la mettre en attente jusqu’à ce que les éléments contestables soient résolus. Cette capacité d’intervention protège la base de code et le temps des volontaires engagés dans la revue.

Impact sur la communauté et perspectives

Cette politique est conçue pour préserver l’intégrité du processus collaboratif autour de WordPress tout en s’adaptant à l’avènement d’outils d’**IA** capables d’accélérer certaines tâches. En favorisant la transparence, la conformité aux licences et une exigence de qualité, WordPress cherche à intégrer l’IA sans compromettre les valeurs du logiciel libre.

Cela aura plusieurs effets pratiques :

  • Une augmentation probable des contributions assistées par IA, mais présentées de manière plus structurée ;
  • Une charge de revue possiblement réduite si les contributeurs suivent les bonnes pratiques (petites PR, tests, documentation) ;
  • Un renforcement de la vigilance concernant les licences et la provenance des contenus intégrés ;
  • Une responsabilisation accrue des contributeurs quant à la qualité et à la traçabilité des apports.

Résumé des recommandations pour les contributeurs

Pour synthétiser, voici une checklist pratique à suivre avant de soumettre une contribution assistée par l’IA :

  1. Vérifier les conditions d’utilisation de l’outil d’IA et confirmer la compatibilité avec la GPLv2-or-later ;
  2. Documenter l’utilisation de l’IA dans la description de la PR ou le ticket Trac ;
  3. Diviser les changements en commits atomiques avec des messages explicites ;
  4. Exécuter et documenter des tests réels, et inclure les résultats ou instructions de reproduction ;
  5. Revoir et corriger manuellement tout code généré, en simplifiant quand c’est possible ;
  6. Vérifier les références et liens générés par l’IA pour éviter les hallucinations ;
  7. Fournir des preuves de provenance si nécessaire (captures d’écran, exportations, logs) ;
  8. Préciser explicitement quelles parties ont été produites par l’IA et lesquelles ont été réalisées ou validées par un humain.

Conclusion

Les directives publiées par WordPress ne bannissent pas l’usage de l’**IA**, mais elles encadrent son emploi afin de protéger la qualité technique et juridique du projet. En imposant la transparence, la vérification humaine et la conformité aux licences, elles visent à maintenir la confiance des utilisateurs et des contributeurs tout en permettant d’exploiter les bénéfices des outils automatisés.

Adopter ces pratiques aidera la communauté à tirer parti de l’**IA** sans sacrifier la robustesse du code ni la liberté des logiciels distribués sous la **GPLv2-or-later**.

Image à la une : Shutterstock/Ivan Moreno sl

Références