Comment corriger la faille PHP2Shell sur un petit site : le guide pour indépendants et petites boutiques

Les préfectures et les grands groupes ont des équipes pour gérer la faille PHP2Shell. Vous, peut-être pas. Pourtant, une boutique WooCommerce avec trente clients réguliers, le site vitrine d’un artisan ou l’application maison d’un développeur freelance sont exposés exactement de la même façon. Les deux failles corrigées le 21 octobre 2026 (CVE-2026-109618 et CVE-2026-109619) se trouvent dans PHP lui-même : elles ne font aucune différence entre un ministère et un fleuriste. Ce guide vous explique, étape par étape, comment savoir si votre site est corrigé, comment mettre à jour PHP selon votre hébergement, que faire si c’est impossible tout de suite, et comment vérifier qu’aucun intrus n’est passé avant le correctif.

Si vous voulez d’abord comprendre ce qu’est cette faille et pourquoi tant de sites ont été coupés, lisez notre article PHP2Shell : la faille PHP qui a poussé préfectures et ministères à couper leurs sites.

Ce guide s’adresse :

• aux propriétaires de petits sites WordPress, WooCommerce, PrestaShop, Joomla ou Drupal ;
• aux développeurs indépendants qui gèrent les sites de leurs clients ;
• aux petites agences et aux associations qui ont un VPS ou un hébergement mutualisé.

Prérequis : un accès à l’espace client de votre hébergeur, ou un accès SSH si vous gérez votre serveur, et une sauvegarde récente. Comptez de quinze minutes (hébergement mutualisé déjà corrigé) à deux heures (VPS avec plusieurs sites, ou vieille version de PHP).

Ce qu’il faut retenir avant de commencer

Trois idées à garder en tête, parce qu’elles évitent la plupart des erreurs que l’on voit passer en ce moment.

1. Mettre à jour WordPress, PrestaShop, vos thèmes ou vos extensions ne corrige pas PHP2Shell. WordPress.org l’a confirmé : aucune mise à jour du cœur n’est prévue pour ce problème.
2. Les versions sûres sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 (ou plus récentes). Le projet PHP est catégorique : il n’existe pas de réglage qui remplace la mise à jour.
3. Une extension de « mode maintenance » WordPress ne vous protège pas. Elle fonctionne elle-même en PHP : la requête de l’attaquant atteint donc PHP, et avec mod_php l’attaque peut se déclencher avant que le code de votre site ne s’exécute. On y revient à l’étape 6.

Étape 1 : savoir qui gère PHP sur votre site

C’est la question qui décide de tout le reste. Sur un hébergement mutualisé, ce n’est pas vous qui installez PHP. Sur un VPS, personne ne le fera à votre place.

Si vous ne savez pas dans quelle case vous êtes, regardez votre facture : un abonnement « hébergement web » à quelques euros par mois est presque toujours un mutualisé. Si vous avez reçu un jour une adresse IP avec un identifiant root, vous avez un serveur à gérer.

Étape 2 : vérifier la version de PHP réellement utilisée

Le piège numéro un, c’est de regarder le mauvais PHP. Sur un serveur, il y a souvent plusieurs PHP : celui de la ligne de commande et celui qui sert vraiment vos pages (PHP-FPM ou le module Apache). Ils n’ont pas toujours la même version.

Depuis l’interface de votre site

• WordPress : Outils, puis Santé du site, onglet Infos, rubrique Serveur. La ligne « Version de PHP » indique la version utilisée par le site.
• PrestaShop : Paramètres avancés, puis Informations, section « Informations sur le serveur ».
• Joomla : Système, puis Informations système.
• Drupal : Rapports, puis Rapport d’état.

Avec un fichier phpinfo temporaire

C’est la méthode la plus fiable, puisqu’elle montre le PHP qui exécute réellement les pages. Créez à la racine du site un fichier au nom difficile à deviner, par exemple verif-7f3k2.php, contenant :

<?php phpinfo();

Ouvrez-le dans votre navigateur, notez la version affichée en haut de la page et la ligne « Server API » (FPM/FastCGI, Apache 2.0 Handler, LiteSpeed…), puis supprimez le fichier immédiatement. Un phpinfo oublié en ligne donne beaucoup d’informations à un attaquant.

En ligne de commande (VPS)

# Version de PHP en ligne de commande
php -v

# Version de PHP-FPM (adaptez le numéro de branche)
php-fpm8.3 -v

# Debian / Ubuntu : versions exactes des paquets installés
dpkg -l | grep -E 'php[0-9.]+-(fpm|cli|common)|libapache2-mod-php'

Le cas particulier d’Ubuntu et Debian

Ici, le numéro de version peut tromper. Ubuntu intègre les correctifs de sécurité sans changer la version principale : un Ubuntu 24.04 corrigé affiche toujours PHP 8.3.6. C’est le numéro du paquet qui compte. Selon l’avis USN-8948-1 publié le 21 octobre, les versions corrigées sont notamment :

Pour Debian 12 (bookworm), aucun avis n’était encore publié pour php8.2 lors de nos vérifications : surveillez le suivi de sécurité Debian, ou passez par le dépôt sury.org (voir étape 4).

Bon à savoir : pour vérifier qu’un paquet contient bien le correctif, cherchez les identifiants CVE dans son journal de modifications.

apt changelog php8.3-common | grep -m3 CVE-2026-10961

Étape 3 : faire une sauvegarde avant de toucher à quoi que ce soit

Une mise à jour de PHP dans la même branche (8.3.35 vers 8.3.36, par exemple) casse très rarement un site. Un changement de branche (8.1 vers 8.3) peut, lui, faire tomber une vieille extension ou un module de paiement. Dans les deux cas, sauvegardez :

• les fichiers du site (au minimum wp-content pour WordPress, ou le dossier complet) ;
• la base de données (export depuis phpMyAdmin, ou mysqldump en SSH) ;
• sur un VPS, la configuration PHP (/etc/php/) et celle du serveur web.

La plupart des hébergeurs mutualisés proposent des sauvegardes automatiques. Vérifiez qu’il en existe une datée d’avant le 17 octobre : elle vous servira aussi si vous découvrez plus tard une intrusion.

Prenez aussi l’habitude de garder une copie chez vous, sur un support débranché après usage. Une sauvegarde qui reste connectée au serveur peut être effacée ou chiffrée par la même personne qui l’a compromis. Un petit SSD externe fait très bien l’affaire pour les fichiers et l’export de la base.

Samsung T7 SSD externe 1 To

SSD de poche rapide et résistant pour garder chez vous une copie hors ligne des fichiers et de la base de données de vos sites. Débranché, il est hors de portée d'un pirate.

• AmazonVoir chez Amazon

Étape 4 : mettre à jour PHP selon votre cas

Sur un hébergement mutualisé (cPanel, Plesk, panneau maison)

Vous n’avez pas la main sur les binaires PHP, mais vous avez deux leviers.

Premier levier : vérifier que votre hébergeur a bien appliqué le correctif. Consultez sa page de statut ou ses e-mails. Ne vous contentez pas d’un « nos clients sont protégés » : Clubic a constaté chez o2switch, plusieurs heures après la sortie du correctif, que des protections provisoires étaient en place alors que les binaires installés restaient en 8.3.35 et 8.4.26. Ce n’est pas forcément une faute, mais c’est une nuance importante. Protégé par un filtre n’est pas la même chose que corrigé.

En cas de doute, envoyez un ticket clair. Par exemple :

Bonjour, pouvez-vous me confirmer que les versions de PHP utilisées par mon hébergement [nom de domaine] intègrent le correctif de sécurité du 21 octobre 2026 (CVE-2026-109618 et CVE-2026-109619), c’est-à-dire PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou un paquet rétroporté équivalent ? Si ce n’est pas encore le cas, quelle est l’échéance prévue ? Merci.

Second levier : choisir une version supportée. Dans cPanel (« Sélecteur de version PHP » ou « MultiPHP Manager »), dans Plesk ou dans l’espace OVHcloud, vous pouvez généralement changer la version de PHP de votre site. Si vous êtes encore en 8.1 ou plus ancien, c’est le moment de passer en 8.3 ou 8.4.

Attention : en changeant de version dans un sélecteur, vérifiez la liste des extensions PHP activées. Les modules ne suivent pas toujours. Clubic a relevé un cas où 66 extensions étaient actives pour PHP 8.1 contre 34 pour PHP 8.3 sur le même compte. Une extension manquante (intl, imagick, soap, gd…) suffit à casser un module de facturation ou de paiement.

Sur un VPS Debian ou Ubuntu

# 1. Mettre à jour la liste des paquets
sudo apt update

# 2. Installer les mises à jour (dont PHP)
sudo apt upgrade

# 3. Redémarrer PHP-FPM (adaptez le numéro de version)
sudo systemctl restart php8.3-fpm

# 4. Si vous utilisez Apache avec mod_php, redémarrez Apache
sudo systemctl restart apache2

Si vous utilisez le dépôt d’Ondřej Surý (ppa:ondrej/php sur Ubuntu, packages.sury.org sur Debian), les mêmes commandes suffisent : ce dépôt a publié les versions 8.2.35 à 8.5.12 le 21 octobre et a même rétroporté la correction jusqu’à PHP 5.6.

Sur un VPS AlmaLinux, Rocky Linux ou Red Hat

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm
sudo systemctl restart httpd

# Vérifier la présence du correctif dans le journal du paquet
rpm -q --changelog php-common | grep -m3 CVE-2026-10961

Attention : si vos paquets PHP viennent du dépôt communautaire Remi, sachez que le projet PHP a prévenu que ce dépôt ne serait pas mis à jour le jour de la sortie du correctif. Vérifiez où il en est, et si rien n’arrive, passez aux paquets de votre distribution ou à une autre source.

Avec Docker

Redémarrer un conteneur ne suffit pas : il faut reconstruire l’image à partir d’une image de base corrigée.

# Récupérer l'image officielle à jour (exemple avec PHP 8.4 FPM)
docker pull php:8.4-fpm

# Reconstruire vos images en forçant la récupération des bases
docker compose build --pull --no-cache

# Relancer les services
docker compose up -d

# Vérifier la version dans le conteneur
docker compose exec app php -v

Pensez aussi aux images construites il y a des mois et qui tournent toujours en production sans que personne n’y touche. Ce sont les plus dangereuses.

Avec Ploi, Laravel Forge, RunCloud ou Plesk

Laravel Cloud corrige automatiquement. Sur Laravel Forge, la mise à jour se fait depuis le tableau de bord du serveur. RunCloud a mis son panneau en maintenance le temps de mettre à jour PHP : une fois revenu, contrôlez la version de vos serveurs. Plesk a publié les versions corrigées de PHP 8.2 à 8.5, et cPanel ses paquets corrigés, y compris pour 8.1, 8.0 et 7.4.

En local (XAMPP, WAMP, Laragon, MAMP)

Votre machine de développement n’est normalement pas exposée sur Internet, donc l’urgence est moindre. Mettez tout de même à jour dès que votre outil propose la nouvelle version, surtout si vous avez déjà ouvert votre poste à des tests extérieurs ou à un tunnel de type ngrok.

Étape 5 : redémarrer tous les processus PHP et contrôler

Un PHP mis à jour mais pas redémarré continue de faire tourner l’ancien code en mémoire. Le projet PHP insiste : il faut redémarrer chaque worker.

Une fois le redémarrage fait :

1. recréez votre fichier phpinfo temporaire (étape 2), vérifiez la version, puis supprimez-le ;
2. testez les pages vitales : accueil, connexion, formulaire de contact, panier, paiement en mode test ;
3. surveillez les journaux d’erreurs pendant une heure.

# Suivre les erreurs PHP-FPM en direct (le chemin peut varier)
sudo tail -f /var/log/php8.3-fpm.log

Étape 6 : si vous ne pouvez pas mettre à jour aujourd’hui

Ça arrive : hébergeur en retard, site client ancien qui ne supporte pas une nouvelle branche, prestataire injoignable. Le bulletin officiel de PHP liste des mesures qui réduisent l’exposition sans la supprimer. À n’utiliser qu’en attendant.

Les réglages recommandés par PHP

Contre CVE-2026-109619, désactivez le suivi de progression des envois de fichiers. WordPress ne s’en sert pas, la désactivation est donc sans conséquence pour la plupart des sites.

; php.ini ou configuration appliquée avant le traitement de la requête
session.upload_progress.enabled = 0

; Uniquement sur PHP 8.5
fatal_error_backtraces = 0

Dans un pool PHP-FPM, la forme recommandée est celle qui empêche l’application de modifier la valeur :

php_admin_flag[session.upload_progress.enabled] = off

Le projet PHP précise de ne pas compter sur ini_set() ni sur un fichier .user.ini pour ce réglage : ils interviennent trop tard. Redémarrez ensuite tous les workers.

Contre CVE-2026-109618, PHP recommande de réduire la taille maximale des requêtes. Pour un site sans envoi de fichiers, post_max_size = 8M ; si des envois sont nécessaires, post_max_size = 32M, avec upload_max_filesize inférieur. PHP mentionne aussi la suppression de la limite de mémoire (memory_limit=-1) compensée par une limite au niveau du conteneur ou du système. C’est un réglage réservé à ceux qui maîtrisent leur serveur : mal fait, il ouvre la porte à des plantages.

Passer derrière Cloudflare

Cloudflare a activé des règles contre PHP2Shell sur toutes ses offres, gratuite comprise, dès le 21 octobre. Pour en profiter, votre domaine doit passer par son proxy (le nuage orange dans l’onglet DNS). Sur les offres payantes, vérifiez que les règles gérées sont réglées pour bloquer et pas seulement pour journaliser.

Deux limites à connaître : un attaquant qui connaît l’adresse IP réelle de votre serveur peut contourner Cloudflare, et Cloudflare lui-même rappelle qu’il faut mettre PHP à jour. Si vous le pouvez, restreignez l’accès direct à votre serveur aux seules adresses de Cloudflare.

Une vraie page de maintenance, au niveau du serveur

Si vous décidez de couper le site, comme l’ont fait de nombreuses administrations, faites-le en amont de PHP, pour que les requêtes n’atteignent jamais l’interpréteur. Une page HTML statique suffit.

Avec Apache, dans le .htaccess à la racine (créez d’abord un fichier maintenance.html) :

RewriteEngine On
# Facultatif : laisser passer votre propre adresse IP
# RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule ^ - [R=503,L]
ErrorDocument 503 /maintenance.html

Avec Nginx, dans le bloc server du site :

error_page 503 /maintenance.html;
location = /maintenance.html {
    root /var/www/maintenance;
    internal;
}
location / {
    return 503;
}

Puis sudo nginx -t && sudo systemctl reload nginx. Le code 503 indique aux moteurs de recherche une indisponibilité temporaire, ce qui protège votre référencement si la coupure ne dure pas des jours.

Étape 7 : sortir de PHP 8.1, 8.0 ou 7.x

Si votre site tourne encore sur une branche abandonnée, PHP2Shell est le signal qu’il ne faut plus repousser. Le projet PHP n’a publié que des correctifs minimaux sous forme de code source pour 7.4, 8.0 et 8.1. Certaines distributions, le dépôt sury.org, cPanel ou des éditeurs de support étendu (ELTS) proposent des paquets corrigés, mais ce n’est qu’un sursis.

La méthode la plus sûre pour migrer :

1. créez une copie de préproduction du site (beaucoup d’hébergeurs le proposent en un clic, ou via une extension de duplication) ;
2. passez cette copie en PHP 8.3 ou 8.4 ;
3. testez tout ce qui rapporte de l’argent ou des contacts : panier, paiement, formulaires, espace client, factures ;
4. activez l’affichage des erreurs uniquement sur la copie, et corrigez ou remplacez les extensions qui posent problème ;
5. basculez le site en production, puis refaites les tests.

Ne visez pas PHP 8.2 si vous partez de loin : sa fin de support est fixée au 31 décembre 2026. Autant ne faire la migration qu’une fois.

Étape 8 : vérifier qu’aucun intrus n’est passé avant le correctif

Mettre à jour ferme la porte. Cela ne fait pas sortir quelqu’un qui serait déjà entré. Les premières tentatives d’attaque ont été repérées par Cloudflare le matin du 21 octobre, avant la publication du correctif, et watchTowr a observé une exploitation réelle le même jour. Une boutique en ligne, même modeste, a donc intérêt à faire un contrôle rapide.

Les vérifications de base

Pour WordPress, avec WP-CLI :

# Lister les administrateurs : y en a-t-il un que vous ne connaissez pas ?
wp user list --role=administrator

# Vérifier l'intégrité des fichiers du cœur de WordPress
wp core verify-checksums

# Vérifier les extensions issues du répertoire officiel
wp plugin verify-checksums --all

Sur tout type de site :

# Fichiers PHP modifiés ces dix derniers jours
find /var/www -type f -name "*.php" -mtime -10

# Des fichiers PHP dans le dossier des médias, ce n'est jamais normal
find /var/www -path "*uploads*" -type f -name "*.php"

Regardez aussi :

• les tâches planifiées (crontab -l pour chaque utilisateur, et les tâches cron de WordPress) ;
• les journaux d’accès autour des 20, 21 et 22 octobre : des requêtes POST volumineuses vers des adresses inhabituelles, des pics d’erreurs 500 ;
• les journaux PHP : une avalanche de messages « Allowed memory size exhausted » sur une courte période mérite qu’on s’y arrête ;
• les connexions sortantes inattendues depuis votre serveur.

Changer les secrets, par précaution

La seconde faille peut faire fuiter des données présentes en mémoire. Si votre serveur a été exposé sans correctif, changer les éléments sensibles ne coûte pas grand-chose :

• les clés de sécurité de WordPress dans wp-config.php (cela déconnecte tout le monde, c’est voulu) ;
• le mot de passe de la base de données ;
• les clés d’API de paiement (Stripe, PayPal), d’envoi d’e-mails et de services tiers ;
• les clés de l’API REST de WooCommerce si vous en utilisez.

Profitez-en pour activer la double authentification sur l’espace client de votre hébergeur, sur votre registrar et sur le compte administrateur du site. Une clé physique de sécurité est la forme la plus solide : sans elle, un mot de passe volé ne suffit plus à entrer.

Yubico YubiKey 5 NFC, clé de sécurité

Clé physique de double authentification compatible FIDO2, USB-A et NFC. À activer sur votre hébergeur, votre registrar et votre compte administrateur : un mot de passe volé ne suffit plus.

• AmazonVoir chez Amazon

Si vous trouvez quelque chose

Ne supprimez pas tout dans la précipitation. Mettez le site en maintenance au niveau du serveur (étape 6), conservez une copie des fichiers suspects et des journaux, puis restaurez une sauvegarde saine datant d’avant le 17 octobre avant de remettre en ligne. Pour un site qui traite des données personnelles de clients européens, le RGPD impose de notifier une violation de données à l’autorité compétente (la CNIL en France, le Garante en Italie) dans les 72 heures lorsqu’elle présente un risque pour les personnes. En France, le dispositif cybermalveillance.gouv.fr peut vous orienter vers des prestataires.

Étape 9 : ne pas revivre ça à la prochaine faille

PHP2Shell ne sera pas la dernière alerte. Quelques habitudes simples changent tout :

• sur un VPS Debian ou Ubuntu, activez les mises à jour de sécurité automatiques avec unattended-upgrades ;
• abonnez-vous aux alertes du CERT-FR, ou du CSIRT Italia si vous êtes en Italie, et à la page de statut de votre hébergeur ;
• gardez une liste à jour de vos sites, de leur hébergement et de leur version de PHP, surtout si vous gérez des sites clients ;
• planifiez dès maintenant la sortie de PHP 8.2 avant le 31 décembre 2026 ;
• testez vos restaurations de sauvegarde au moins une fois par trimestre.

Pour aller plus loin côté WordPress, notre sélection des meilleurs plugins pour sécuriser votre site WordPress complète bien ce guide, et si votre hébergeur vous a déçu pendant cette crise, notre comparatif des meilleures sociétés d’hébergement WordPress vous aidera à en changer.

Protéger aussi le poste depuis lequel vous gérez vos sites

Un rappel qui vaut pour tous les indépendants : le serveur n’est pas le seul point d’entrée. Depuis le 21 octobre, de faux messages d’hébergeurs circulent pour pousser à « installer le correctif PHP » via un lien piégé. Si votre ordinateur se fait infecter, l’attaquant récupère vos accès SSH, FTP et vos mots de passe d’administration, et la mise à jour de PHP ne servira plus à grand-chose. Aucun antivirus ne corrige PHP2Shell sur un serveur, mais une suite de sécurité récente, dont les bases et les filtres anti-hameçonnage sont mis à jour en permanence, protège l’ordinateur qui détient les clés de vos sites. Voici notre sélection, prix relevés le 23 octobre 2026.

La boîte à outils du développeur indépendant

Voici le matériel que nous conseillons à un freelance ou à une petite boutique pour ne plus subir la prochaine alerte : des sauvegardes qui restent hors de portée, des comptes verrouillés par une clé physique, une alimentation protégée pour le petit serveur du bureau et un bon livre pour passer sereinement à PHP 8.

La liste de contrôle express

Pour ceux qui ont lu en diagonale, voici l’essentiel :

• ☐ Je sais qui gère PHP sur mon site (hébergeur ou moi).
• ☐ J’ai vérifié la version réellement utilisée (phpinfo supprimé ensuite).
• ☐ Version 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou paquet de distribution corrigé.
• ☐ Tous les processus PHP ont été redémarrés.
• ☐ Les pages vitales (paiement, formulaires) fonctionnent.
• ☐ Aucun administrateur inconnu, aucun fichier PHP suspect.
• ☐ Les clés et mots de passe sensibles ont été changés si le serveur est resté exposé.
• ☐ La sortie de PHP 8.1 ou 8.2 est planifiée.

Questions fréquentes

Mon petit site intéresse-t-il vraiment les pirates ?

Oui. Les attaques de ce type sont automatisées : des robots balaient Internet à la recherche de serveurs vulnérables, sans regarder la taille du site. Un petit e-commerce a des données clients, un serveur utilisable pour envoyer du spam et une réputation de domaine exploitable.

Mon hébergeur dit que je suis protégé : dois-je faire quelque chose ?

Vérifiez quand même la version de PHP de votre site, et demandez si le correctif est installé ou s’il s’agit d’une protection temporaire. Ensuite, faites les contrôles de l’étape 8 si vous gérez une boutique.

Une extension de sécurité WordPress (Wordfence, Sucuri…) suffit-elle ?

Non. Ces extensions fonctionnent dans PHP et ne remplacent pas la mise à jour de l’interpréteur. Un pare-feu externe comme Cloudflare apporte une protection supplémentaire, sans corriger la faille.

Comment savoir si mon site a été piraté via PHP2Shell ?

Il n’existe pas de signe unique. Les indices les plus fréquents sont un compte administrateur inconnu, des fichiers PHP récents dans des dossiers inhabituels, des redirections étranges, une alerte de Google Search Console ou une hausse soudaine des ressources consommées par le serveur.

PHP 8.3.35 est-il sûr ?

Non. Cette version de septembre corrigeait d’autres failles. Pour la branche 8.3, il faut PHP 8.3.36 ou un paquet de distribution qui intègre explicitement les deux correctifs.

Faut-il mettre mon site en maintenance ?

Si votre site est déjà corrigé, non. S’il ne l’est pas et que vous ne pouvez pas mettre à jour rapidement, c’est ce que recommandent l’ANSSI et le NCSC britannique, à condition de le faire au niveau du serveur web ou de Cloudflare, pas avec une extension WordPress.

En résumé

Pour un petit site, corriger PHP2Shell tient souvent en une vérification et un e-mail à l’hébergeur. Pour un VPS, c’est une mise à jour de paquets et un redémarrage. Le vrai travail, celui qu’on oublie, consiste à vérifier ensuite que personne n’est entré pendant les quelques jours où la porte était ouverte. Prenez une heure pour le faire : c’est toujours moins long que de reconstruire une boutique piratée.

Vous avez rencontré un souci en mettant à jour PHP, une extension qui refuse de fonctionner en 8.3 ou un hébergeur qui ne répond pas ? Dites-le-nous en commentaire, nous compléterons ce guide avec vos retours.

Sources : bulletin de sécurité officiel de php.net (21 octobre 2026), avis Ubuntu USN-8948-1, suivi de sécurité Debian, recommandations de WordPress.org, Cloudflare, CloudLinux, Plesk et cPanel, vérifications publiées par Clubic. Guide mis à jour le 23 octobre 2026.

En tant que Partenaire Amazon, Wanda-techs réalise un bénéfice sur les achats remplissant les conditions requises. Cela n’affecte ni notre analyse indépendante, ni le prix que vous payez.