Reprendre la maintenance d’une extension abandonnée : l’audit avant de s’engager

Un client nous a demandé de reprendre la maintenance d’une extension de gestion de billetterie, développée par une agence ayant cessé son activité trois ans plus tôt. Le plugin fonctionnait, en apparence, sans incident majeur signalé. Avant d’accepter cette mission, notre process d’audit préalable a néanmoins révélé plusieurs problèmes qui ont directement influencé le devis final, et qui auraient pu, sans cette vérification, transformer une mission de maintenance simple en un chantier de réécriture non anticipé.

Ce billet ne traite pas de la fin de vie ou de la transmission d’une extension du point de vue de son auteur original, sujet déjà couvert par ailleurs, mais bien de la grille de vérification qu’une agence devrait appliquer systématiquement avant d’accepter la reprise du support d’un plugin tiers dont elle n’a pas écrit une seule ligne.

Étape 1 : l’inventaire des dépendances

La première vérification consiste à lister les dépendances tierces embarquées, qu’il s’agisse de bibliothèques PHP via Composer ou de paquets JavaScript via npm, et à comparer leur version installée à leur dernière version stable disponible :

composer outdated --direct --format=json | jq '.installed[] | {name, version, latest}'

Sur le plugin de billetterie audité, cette commande a révélé une dépendance à une version de la bibliothèque de génération de QR codes vieille de cinq ans, avec plusieurs versions majeures de retard, et une compatibilité PHP 8 jamais vérifiée par ses mainteneurs d’origine.

Étape 2 : rechercher les failles connues

Chaque dépendance identifiée doit ensuite être confrontée aux bases de vulnérabilités connues, en particulier la base de données du WPScan pour l’écosystème WordPress lui-même, et les avis de sécurité publiés sur GitHub pour les bibliothèques PHP ou JavaScript tierces. Sur ce projet, trois vulnérabilités documentées ont été retrouvées, dont une permettant potentiellement une injection SQL via un paramètre de recherche mal échappé dans l’écran d’administration des billets, jamais corrigée depuis sa découverte publique deux ans plus tôt.

Étape 3 : mesurer la dette de code, pas la deviner

Plutôt que de se fier à une impression de lecture, souvent trompeuse sur un code que l’on découvre, des outils d’analyse statique donnent une mesure objective, même imparfaite, de la complexité du code repris. Un outil comme PHP Mess Detector, exécuté sur l’ensemble du plugin, permet de repérer les fonctions les plus complexes cyclomatiquement, souvent les premières sources de bugs lors d’une future intervention :

phpmd wp-content/plugins/billetterie-tiers/ text codesize,unusedcode \
  --minimum-priority 2

Sur ce plugin précis, une seule fonction de calcul de tarification concentrait à elle seule plus de deux cents lignes et une complexité cyclomatique supérieure à trente, signe fiable qu’une future modification, même mineure en apparence, présenterait un risque de régression élevé sans une réécriture préalable de cette portion précise.

La grille complète appliquée avant le devis final

1. Inventaire des dépendances Composer et npm, avec comparaison aux versions actuelles disponibles.
2. Recherche systématique des vulnérabilités connues sur chaque dépendance identifiée, y compris sur le plugin lui-même s’il a déjà été référencé sur WordPress.org à un moment de son histoire.
3. Analyse statique de complexité pour repérer les zones de code les plus risquées à faire évoluer.
4. Vérification de la compatibilité déclarée avec la version de PHP et de WordPress actuellement en production chez le client, pas seulement celle annoncée dans l’en-tête du plugin, souvent obsolète.
5. Test de l’ensemble des fonctionnalités critiques sur un environnement de recette isolé, avant tout engagement contractuel, pour vérifier qu’aucune fonctionnalité annoncée comme fonctionnelle ne l’est en réalité que partiellement.

Ce que révèle cet audit sur le devis

Sur ce projet précis, l’audit préalable a transformé une demande initiale de « maintenance corrective légère » en un devis distinguant clairement deux phases : une correction de sécurité urgente sur les vulnérabilités identifiées, facturée en priorité absolue, et un chantier de réduction de dette de code sur la fonction de tarification, budgété séparément et présenté comme une recommandation plutôt qu’une obligation immédiate.

• Ne jamais accepter de devis de maintenance sur un plugin tiers sans avoir exécuté au minimum les vérifications de dépendances et de vulnérabilités connues.
• Distinguer clairement, dans la proposition commerciale, ce qui relève d’un risque de sécurité immédiat de ce qui relève d’une dette de code à traiter à moyen terme.
• Informer explicitement le client des limites de cet audit : une analyse statique et une recherche de vulnérabilités connues ne remplacent jamais un audit de sécurité manuel approfondi, si le contexte du site le justifie.

Une règle que nous appliquons sans exception avant toute reprise de maintenance d’un plugin tiers : le devis se construit après l’audit, jamais avant. Un chiffrage donné à l’aveugle sur un code jamais inspecté finit toujours par sous-estimer le travail réel une fois le chantier commencé.

En résumé

Reprendre la maintenance d’une extension abandonnée ne se limite jamais à accepter de corriger quelques bugs signalés au fil de l’eau. Sans un audit préalable structuré, portant sur les dépendances, les vulnérabilités connues et la dette de code réelle, une agence s’expose à découvrir, souvent au pire moment, l’ampleur réelle d’un chantier qu’elle avait initialement sous-estimé au moment de la signature.