Panne du plugin Advanced Access Manager : ce qui s’est passé et comment nous sommes intervenus 

Le 8 septembre 2026 au matin, la version 7.1.3 du plugin WordPress Advanced Access Manager (AAM) a été publiée sans un fichier indispensable à son fonctionnement : autoloader.php. Résultat, tout site utilisant AAM et mettant à jour vers cette version s’est retrouvé instantanément hors ligne, y compris deux sites que nous gérons directement. Nous les avons remis en ligne dans l’heure qui a suivi l’alerte, avant même que l’éditeur ne publie un correctif fiable. 

Ce qui s’est passé techniquement 

AAM est un plugin de gestion des droits d’accès WordPress, largement utilisé pour restreindre du contenu, gérer des rôles ou sécuriser une zone d’un site. Son fichier principal (aam.php) charge un fichier autoloader.php dès l’activation du plugin. Dans le paquet distribué pour la version 7.1.3, ce fichier était tout simplement absent. 

Selon la configuration d’affichage des erreurs PHP du serveur, deux messages différents apparaissaient à la place du site, pour la même cause : 

PHP Fatal error: Uncaught Error: Failed opening required 

'.../wp-content/plugins/advanced-access-manager/autoloader.php' 

Warning: require(.../wp-content/plugins/advanced-access-manager/autoloader.php): 

Failed to open stream: No such file or directory

Le premier message correspond à un site totalement bloqué (écran blanc ou erreur 500), le second à un site qui continue de tourner mais accumule des avertissements PHP à chaque requête. Dans les deux cas, la cause est la même : un fichier manquant dans le paquet livré par l’éditeur, pas une erreur de configuration côté client. 

Le problème a été signalé en masse sur le forum d’assistance de WordPress.org dès la matinée du 8 septembre, avec des dizaines de sites concernés remontés en quelques heures (premier fil de discussion, second fil, plus de dix témoignages). 

Comment nous sommes intervenus 

Deux sites que nous gérons étaient concernés. Ce chiffre est resté bas parce que notre supervision a bloqué les mises à jour automatiques d’AAM sur l’ensemble du parc dès la première alerte, avant que le problème ne se propage à d’autres sites. 

1. Détection de l’anomalie par notre supervision, dans la nuit du 7 au 8 septembre. 

2. Blocage immédiat des mises à jour automatiques d’AAM sur tous les sites que nous gérons. 

3. Ajout manuel du fichier autoloader.php manquant sur les deux sites déjà touchés, à partir de la version précédente du plugin. 

4. Maintien du blocage des mises à jour et attente de la version 7.1.4 avant de rouvrir la mise à jour automatique. 

Le délai entre l’alerte et la remise en ligne des deux sites a été d’environ une heure. Ce délai s’est depuis nettement réduit grâce à la nouvelle version de notre outil de supervision TYTAE Site Guardian, qui détecte désormais ce type d’anomalie de façon quasi instantanée. 

Sur l’impact réel pour les visiteurs : la coupure a duré le temps de notre intervention, mais la majorité des requêtes ont été servies par le cache serveur pendant cette fenêtre. Une bonne partie des visiteurs des deux sites concernés n’a donc jamais vu l’erreur s’afficher. 

Un correctif à vérifier plutôt qu’à supposer 

L’éditeur a publié la version 7.1.4 le jour même, et plusieurs utilisateurs ont confirmé qu’elle réglait le problème. Ce n’est pourtant pas garanti pour tout le monde : le 10 septembre, un utilisateur signalait sur ce même forum que l’erreur persistait après la mise à jour vers 7.1.4 (fil de discussion). C’est la raison pour laquelle nous avons choisi d’ajouter le fichier manquant nous-mêmes plutôt que de compter sur le correctif officiel pour rouvrir nos sites : une mise à jour présentée comme corrective reste une hypothèse tant qu’elle n’a pas été vérifiée sur le site concerné. 

Si vous utilisez ce plugin sur votre site 

Si Advanced Access Manager est installé sur un site que nous ne gérons pas, trois vérifications avant de mettre à jour ou de laisser une mise à jour automatique s’appliquer : 

1. Vérifiez la version actuellement installée (menu Extensions de WordPress) : si vous êtes déjà en 7.1.3, contrôlez que votre site répond normalement plutôt que de supposer que tout va bien. 

2. Avant de passer en 7.1.4, testez-le sur un environnement de préproduction si vous en avez un, ou surveillez votre site juste après la mise à jour plutôt que de partir du principe que le correctif a définitivement réglé le problème. 

3. En cas d’écran blanc ou d’erreur après une mise à jour de ce plugin, le fichier autoloader.php manquant est la première chose à vérifier avant d’envisager une réinstallation complète. 

Un doute sur l’état de votre site ? Demandez un audit gratuit et nous vérifierons ça pour vous.