# Un widget Algolia obsolète encore chargé sur 40 sites d’agence

> Une migration de moteur de recherche terminée sur le papier, mais un ancien widget continuait de charger silencieusement sur près de quarante sites d'un même parc.

- Auteur : WordPress Développement
- Publié le : 2024-02-16
- Mis à jour le : 2024-02-16
- Catégorie : Sécurité
- URL : https://www.wpmoderne.fr/securite/widget-algolia-obsolete-40-sites-agence/

## L’essentiel

- Une migration réussie côté fonctionnel ne garantit pas le retrait de l'ancien composant
- Un inventaire de parc doit vérifier les versions réellement chargées, pas seulement déclarées
- Une faille corrigée depuis ne protège plus rien si l'ancienne version reste active

Quarante sites sur lesquels un widget de recherche Algolia obsolète continuait de charger, plusieurs mois après que l'agence pensait avoir généralisé sa nouvelle intégration de recherche à l'ensemble du parc : c'est ce qu'a révélé un audit de sécurité mené sur les dizaines de sites WordPress gérés pour ses clients, après la découverte fortuite d'une ancienne version de ce widget encore active sur l'un d'entre eux.

L'inventaire complet qui a suivi cette découverte a révélé que le problème ne concernait pas un site isolé oublié par erreur, mais près de quarante installations sur l'ensemble du parc, toutes migrées « sur le papier » vers la nouvelle intégration, mais dont l'ancien widget n'avait en réalité jamais été retiré du thème ou de l'extension qui l'avait initialement chargé.

## Comment une migration peut laisser un composant actif sans le savoir

La migration initiale avait consisté à ajouter la nouvelle intégration de recherche Algolia via une extension dédiée, activée sur l'ensemble du parc via un script de déploiement centralisé. Le retrait de l'ancien widget, en revanche, avait été confié à une checklist manuelle distincte, suivie site par site par les intégrateurs au fil de leurs interventions respectives sur chaque client. Cette asymétrie entre un déploiement automatisé et un retrait manuel explique en grande partie l'écart constaté :

- L'ancien widget était souvent chargé directement dans le fichier `functions.php` du thème enfant de chaque site, un emplacement rarement revisité une fois la migration jugée terminée fonctionnellement.
- La nouvelle intégration masquait visuellement l'ancien widget sur la majorité des gabarits, sans toutefois empêcher son chargement JavaScript et ses appels réseau en arrière-plan.
- Aucun inventaire technique du parc ne recensait les versions réellement chargées site par site : le suivi reposait sur une simple case cochée dans un tableau de suivi de projet.

## L'inventaire technique qui a révélé l'ampleur réelle

> L'essentiel à retenir : Une migration réussie côté fonctionnel ne garantit pas le retrait de l'ancien composant ; Un inventaire de parc doit vérifier les versions réellement chargées, pas seulement déclarées ; Une faille corrigée depuis ne protège plus rien si l'ancienne version reste active

Face à ce constat, l'agence a mis en place un script d'inventaire automatisé, exécuté via WP-CLI sur l'ensemble du parc, recherchant les traces du chargement de l'ancien widget indépendamment de ce que déclarait le tableau de suivi de projet :

```
wp eval-file inventaire-widget-algolia.php --path=/var/www/site-client
```

```
<?php
// inventaire-widget-algolia.php
$theme_actif = wp_get_theme();
$fichier_functions = get_stylesheet_directory() . '/functions.php';

if ( file_exists( $fichier_functions )
    && false !== strpos( file_get_contents( $fichier_functions ), 'ancien_widget_algolia_enqueue' ) ) {
    echo "PRESENT: " . $theme_actif->get( 'Name' ) . "\n";
}
```

Exécuté site par site via une boucle sur l'ensemble des installations du parc, ce script a permis de dresser en quelques heures une liste précise des installations concernées, là où la vérification manuelle site par site aurait demandé plusieurs semaines de travail.

### Pourquoi une version obsolète reste un risque même invisible

L'ancien widget avait fait l'objet, entre-temps, d'un correctif de sécurité côté éditeur, concernant une faille de type script intersite exploitable via un paramètre de recherche mal échappé dans une version ancienne du composant. Les sites toujours migrés vers la nouvelle intégration officiellement, mais qui chargeaient encore l'ancien widget en parallèle, restaient exposés à cette faille corrigée depuis, sans que rien dans l'apparence du site ne le laisse deviner.

## Le protocole de retrait qui a suivi

1. Confirmation, site par site sur la liste des quarante installations concernées, de la version exacte de l'ancien widget encore chargée.
2. Retrait effectif du code de chargement dans le thème enfant ou l'extension concernée, vérifié par une seconde exécution du script d'inventaire après intervention.
3. Mise à jour de la checklist de migration pour intégrer une vérification automatisée systématique, plutôt qu'une case cochée manuellement en fin de projet.

> Une migration n'est terminée que lorsque l'ancien composant a été retiré et que son absence a été vérifiée techniquement, pas seulement lorsque le nouveau composant fonctionne visiblement à sa place.

## Ce qu'on retient de cet épisode

Ce cas ne concerne pas une faille propre à Algolia, dont l'éditeur avait correctement publié et documenté son correctif de sécurité en temps voulu : le problème vient entièrement du décalage entre une migration fonctionnelle jugée terminée et la réalité technique du code encore chargé sur le parc. Toute migration de composant, sur un parc de sites gérés par une même agence, mérite une vérification automatisée de son retrait effectif, et pas seulement une vérification visuelle du bon fonctionnement du remplaçant.