Abandonner ou transmettre une extension : la checklist de fin de vie

Une extension de gestion de dons pour associations que nous avions développée pour un client il y a plusieurs années s’est retrouvée, l’an dernier, dans une situation fréquente mais rarement anticipée : le client a changé d’activité, n’avait plus besoin de la maintenir, et l’extension comptait pourtant encore plusieurs centaines d’installations actives chez des associations tierces qui l’avaient adoptée via WordPress.org. Fermer purement et simplement le projet sans procédure aurait laissé ces utilisateurs avec une extension non maintenue, potentiellement vulnérable à terme, sans le moindre signal d’alerte. Voici la checklist qu’on a suivie, et qu’on recommande à tout éditeur dans cette situation.

1. Prévenir largement avant d’agir

La première erreur à éviter est la précipitation. Un arrêt de support annoncé et effectif le même jour ne laisse aucune marge de manœuvre aux utilisateurs pour migrer vers une alternative. Un préavis de plusieurs mois, annoncé à la fois dans le changelog de l’extension, dans un message affiché dans l’administration des sites qui l’utilisent, et sur les canaux de support existants, donne le temps nécessaire à une transition sereine.

add_action( 'admin_notices', function() {
    if ( ! current_user_can( 'activate_plugins' ) ) {
        return;
    }
    echo '<div class="notice notice-warning"><p>'
        . esc_html__(
            'Mon Extension Dons ne sera plus maintenue à partir du 1er septembre 2026. '
            . 'Consultez notre page de fin de vie pour connaître les alternatives recommandées.',
            'mon-extension-dons'
        )
        . '</p></div>';
} );

2. Documenter précisément ce qui va changer

Un simple message d’avertissement ne suffit pas : il faut une page dédiée qui explique la date d’arrêt effectif du support, ce que cela implique concrètement (plus de correctifs de sécurité, plus de compatibilité garantie avec les futures versions de WordPress), et surtout quelles alternatives existent pour les fonctionnalités couvertes par l’extension. Recommander explicitement une ou plusieurs extensions concurrentes, même si cela semble contre-intuitif pour un éditeur, est le geste le plus utile pour les utilisateurs concernés.

3. Décider entre fermeture et transmission

Deux issues principales se présentent, et le choix dépend largement du volume d’installations actives et de la disponibilité d’un repreneur sérieux :

• Fermeture définitive : adaptée quand l’extension a un volume d’installations faible ou quand aucun repreneur fiable ne se présente. L’extension est retirée du répertoire WordPress.org à une date annoncée, après la période de préavis.
• Transmission à un repreneur : adaptée quand un éditeur ou une communauté sérieuse souhaite reprendre la maintenance. WordPress.org propose une procédure officielle de transfert de propriété d’une extension via son équipe de revue de plugins, qui vérifie l’identité et les intentions du repreneur avant de transférer les droits.

Pourquoi ne jamais laisser un slug à l’abandon

Un piège fréquent et dangereux : abandonner une extension en la laissant simplement inactive sur WordPress.org, sans la retirer ni la transférer officiellement. Des acteurs malveillants surveillent activement les extensions à fort volume d’installations mais sans mise à jour depuis longtemps, dans l’espoir de racheter les identifiants d’accès du compte auteur ou de convaincre ce dernier de céder les droits, pour ensuite y injecter du code malveillant dans une mise à jour ultérieure, en profitant de la confiance acquise par l’historique de l’extension. Une extension réellement abandonnée doit donc être retirée activement du répertoire, jamais laissée en sommeil indéfiniment.

4. Procédure de transfert officiel sur WordPress.org

1. Contacter l’équipe de revue des plugins de WordPress.org via le canal officiel de support des extensions, en précisant le slug concerné et l’identité du repreneur.
2. Le repreneur doit disposer d’un compte WordPress.org actif et accepter les conditions d’hébergement du répertoire.
3. Une fois le transfert validé, les accès SVN sont mis à jour pour donner au repreneur les droits de publication, l’éditeur d’origine perdant en parallèle ses propres accès s’il quitte définitivement le projet.
4. Le changelog de la première version publiée par le nouveau mainteneur doit mentionner explicitement le changement de responsable, pour la transparence des utilisateurs.

5. Archiver le code et documenter la dernière version sûre

Même en cas de fermeture définitive sans repreneur, conserver une archive du code source accessible (dépôt public en lecture seule, avec un message clair indiquant l’absence de maintenance) rend service aux utilisateurs qui souhaiteraient forker le projet pour leurs propres besoins, ou simplement comprendre le fonctionnement d’une fonctionnalité avant de migrer.

Sur l’extension de gestion de dons, on a choisi la transmission plutôt que la fermeture : une association technophile parmi les utilisatrices historiques s’est portée volontaire pour reprendre la maintenance basique. Six mois plus tard, l’extension recevait encore des correctifs de sécurité, ce qui n’aurait jamais été le cas avec une fermeture pure et simple.

6. Prévenir les canaux qui recommandent l’extension

Si l’extension est mentionnée dans des tutoriels, des comparatifs, ou des recommandations tierces (y compris les vôtres, sur votre propre blog technique), un signal de fin de vie mérite d’être répercuté sur ces contenus, avec une date de mise à jour visible, pour éviter que de nouveaux utilisateurs installent une extension déjà en fin de vie sans le savoir.

Checklist récapitulative

• Annoncer la fin de vie au moins plusieurs mois à l’avance, dans l’administration et le changelog.
• Publier une page de fin de vie avec les alternatives recommandées.
• Choisir explicitement entre fermeture et transmission, sans laisser le projet en sommeil.
• Suivre la procédure officielle de transfert WordPress.org en cas de reprise par un tiers.
• Archiver le code source avec une mention claire d’absence de maintenance en cas de fermeture.
• Mettre à jour tout contenu tiers qui recommandait encore l’extension.

En résumé

La fin de vie d’une extension mérite le même soin que sa publication initiale, précisément parce que des utilisateurs réels en dépendent encore. Un préavis suffisant, une décision claire entre fermeture et transmission, et surtout l’absence de tout abandon silencieux d’un slug à fort volume d’installations : ces gestes protègent à la fois les utilisateurs restants et la réputation de l’éditeur qui ferme le projet dans de bonnes conditions plutôt que dans la précipitation.