Mis à jour le 63 min de lecture
Sébastien Nobour
Fondateur de DEVEDANOS
PHP est un langage de programmation. Ses développeurs le décrivent comme un langage de script polyvalent, particulièrement adapté au web : sur le serveur, il fabrique chaque page d’un site au moment où un visiteur la demande. Selon W3Techs, un service qui mesure les technologies utilisées par les sites web, PHP est utilisé, en octobre 2026, par 69,3 % des sites web dont on connaît le langage côté serveur. WordPress, Drupal, Magento, PrestaShop, Laravel et Symfony sont écrits en PHP.
Le 21 octobre 2026, l’équipe de PHP a publié en urgence de nouvelles versions du langage. Elles corrigent deux failles critiques, que leurs découvreurs ont baptisées PHP2Shell. Avec quelques requêtes, sans compte ni mot de passe, un attaquant peut faire exécuter son propre code par le serveur qui héberge un site. Et tout se joue avant même que le code du site ne commence à s’exécuter. Ces failles remontent à PHP 5.4, sorti le 1er mars 2012. Des attaques ont été signalées avant la publication du correctif.
Si votre site ou votre application repose sur PHP, la question à poser dès aujourd’hui à votre hébergeur ou à votre prestataire est simple : quelle version de PHP utilisons-nous, et quand passe-t-elle à une version corrigée ? Les étapes à suivre, dans l’ordre, se trouvent dans la section « Site WordPress piraté ou faille découverte : que faire, dans l’ordre ».
Le même jour, GitLab et Node.js ont eux aussi publié des correctifs de failles graves. GitLab, une plateforme qui héberge le code des logiciels et automatise leurs tests et leur déploiement, a corrigé une faille (CVE-2026-110264) notée 10 sur 10, qui permettait, sans compte et dans certaines conditions, d’exécuter du code sur les installations que les entreprises hébergent elles-mêmes. Elle touchait toutes les versions depuis la 7.0. GitLab.com, la version hébergée par GitLab, était déjà corrigée.
Node.js, le logiciel qui exécute du JavaScript sur les serveurs, a publié des versions qui comblent quatre failles de gravité élevée, dont une, dans le décodage des données compressées au format Brotli, permet d’exécuter du code à distance. Ces versions mettent aussi à jour la liste des certificats de confiance, après la compromission d’une autorité de certification intermédiaire d’eMudhra.
Si votre entreprise héberge elle-même GitLab, ou si ses applications utilisent Node.js, la même question vaut pour ces logiciels : quelle version utilisons-nous, et quand passe-t-elle à une version corrigée ?
Des médias ont regroupé ces correctifs et d’autres incidents de la semaine sous le nom « Black October ». Ce nom est apparu, pour la première fois à notre connaissance, dans un message publié sur X par le développeur Muzzammil dans la nuit du 21 au 22 octobre, puis a été employé quelques heures plus tard par Axios et par 404 Media. SecurityToday, un site d’actualité allemand sur la sécurité informatique, y voit surtout un pic de publications : beaucoup des attaques révélées ces jours-là avaient commencé des semaines ou des mois plus tôt.
La suite vaut pour toute application, quel qu’en soit le langage. Cette faille n’est pas la première de cette ampleur, et rien n’indique qu’elle sera la dernière. Face à une faille, trois choses se préparent à l’avance : ce qu’elle permet d’atteindre, le temps qu’il faut pour s’en apercevoir, et le temps qu’il faut pour la corriger.
Les détails techniques sont regroupés dans les passages intitulés « Pour votre équipe technique ».
Sur un serveur web, PHP est le programme qui exécute le code d’un site : celui de WordPress, d’une boutique PrestaShop ou d’une application développée sur mesure. Les deux failles, référencées CVE-2026-109618 et CVE-2026-109619, ne se trouvent ni dans l’un de ces logiciels, ni dans un plugin. Elles se trouvent dans PHP lui-même.
L’équipe de PHP les décrit ainsi. La première se déclenche quand PHP manque de mémoire au milieu d’une requête : des données à moitié préparées sont ensuite traitées comme valides. La seconde laisse dans la mémoire du serveur des informations liées à une requête terminée, qu’une requête suivante peut réutiliser. Elle leur attribue une note de gravité de 9,2 sur 10 (échelle CVSS 4.0). Selon Calif, une société de recherche en sécurité dont les chercheurs ont signalé les premières failles à l’équipe de PHP, elles sont exploitables dans les configurations par défaut.
D’après le calendrier publié par Calif, le premier signalement à l’équipe de PHP date du 11 août 2026. L’équipe de recherche de Wiz, une société de sécurité du cloud, publie un autre calendrier : découverte le 19 août, signalement à l’équipe de PHP le 24 août. Calif compte OpenAI, l’éditeur de modèles d’IA, parmi les découvreurs. L’équipe de PHP, Calif, OpenAI et Wiz préparaient une publication coordonnée, c’est-à-dire annoncer la faille le jour où le correctif est disponible, pour laisser le moins de temps possible aux attaquants. Le 20 octobre, des détails ont fuité avant la date de publication prévue (Patchstack). L’équipe de PHP a avancé la publication d’un jour (CyberScoop). Les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont sorties le 21 octobre vers 16 h, heure de Paris. L’équipe de PHP est claire : « Il n’existe aucune parade complète, la mise à jour est le seul choix sûr ».
Des attaques précoces ont été signalées le matin du 21 octobre, avant la publication du correctif. Cloudflare, un fournisseur de services de protection et d’accélération de sites web, a observé des attaques contre ses clients entre la fuite et la publication officielle. Il a activé le 21 octobre à 5 h 02, heure de Paris, des règles de filtrage pour tous ses clients, offre gratuite comprise, tout en leur demandant d’appliquer le correctif malgré ces règles. Patchstack, qui suit les failles de l’écosystème WordPress, rapporte que des hébergeurs partenaires lui ont signalé des exploitations le même matin. Vers 16 h, heure de Paris, ses propres capteurs ne relevaient encore que des tentatives de repérage, sans preuve d’intrusion. watchTowr, qui suit les attaques au moyen d’un réseau de serveurs leurres, dit avoir observé des exploitations le 21 octobre. Selon l’équipe de veille d’Amazon, une tentative d’exploitation a même été enregistrée dès le 17 octobre, quatre jours avant la publication, sur ses serveurs leurres. Le directeur général de Cloudflare a publié l’évolution (The Register) : des milliers de tentatives d’exploitation (pas des intrusions confirmées) sur son réseau dans les dix heures qui ont précédé l’annonce, des dizaines de milliers dans les 45 minutes qui l’ont suivie, puis des millions. Au Japon, la Première ministre a demandé le jour même aux responsables de sites de vérifier s’ils utilisent PHP et d’appliquer le correctif dans la nuit, ou à défaut de suspendre leurs sites. Des banques, des compagnies de transport et des administrations, au Japon et en Europe, ont suspendu une partie de leurs services. Au 21 octobre, selon watchTowr, ces failles ne figuraient pas au catalogue des failles exploitées de la CISA, l’agence américaine de cybersécurité.
En France, le CERT-FR, le centre de réponse aux incidents de l’ANSSI, l’agence nationale de la sécurité des systèmes d’information, a publié le jour même une alerte. Il y recommande d’isoler les équipements concernés, puis de passer sur une version maintenue et à jour dès que le correctif est disponible. Le CERT-EU, son équivalent pour les institutions européennes, conseille de corriger immédiatement et, si ce n’est pas possible, d’envisager d’isoler d’Internet les applications exposées jusqu’à ce que le correctif soit appliqué et vérifié. Aux États-Unis, la CISA demande de mettre hors ligne les systèmes PHP qui ne peuvent pas être mis à jour immédiatement ou qui fonctionnent encore avec PHP 8.1 ou une version plus ancienne ; la division cyber du FBI a publié la même consigne le 21 octobre.
session.upload_progress.enabled=0 (avec php_admin_flag pour PHP-FPM) ; Calif précise que ce réglage ne remplace pas un correctif. Le CERT-FR propose de bloquer, ou au moins de surveiller, les requêtes de type multipart au niveau d’un pare-feu applicatif, en soulignant que ces contournements ne sont pas qualifiés par ses soins. Redémarrer tous les processus PHP après un changement de réglage (Patchstack), changement appliqué par le pipeline, ou par l’hébergeur, comme toute autre modification.Pour le comprendre, il faut savoir ce que fait PHP à l’arrivée d’une requête. Quand un visiteur envoie un formulaire ou un fichier, le serveur web transmet sa requête à PHP. PHP commence par la préparer : il découpe les données reçues, réserve de la mémoire, prépare la session du visiteur. Ensuite seulement, il lance le code du site, celui qui vérifie qui est connecté et ce qu’il a le droit de faire.
PHP2Shell se déclenche pendant cette préparation. Selon Calif, les deux chemins d’attaque se déroulent « avant que le fichier PHP visé ne s’exécute ». Wiz précise que l’attaque fonctionne même si l’application n’utilise jamais de session. Calif indique qu’avec PHP-FPM, des conditions supplémentaires s’appliquent (voir l’encadré technique plus haut).
Le mécanisme, simplifié, se déroule en trois temps.
À ce moment, ni la page de connexion ni les règles d’accès de l’application n’ont encore été exécutées.
Le code de l’attaquant s’exécute alors, très probablement, avec les droits du processus PHP, c’est-à-dire de l’utilisateur du système qui exécute PHP sur le serveur (php.net). Ce n’est pas automatiquement l’administrateur de la machine. Mais cet utilisateur peut lire tout ce dont PHP a besoin pour faire fonctionner le site. Et sur un système qui n’est pas lui-même à jour, d’autres failles connues permettent de passer de cet utilisateur à l’administrateur de la machine : c’était le cas de PwnKit et de Baron Samedit, dont il est question plus bas.
Voici un scénario plausible, qui enchaîne ce que ces failles permettent et ce que des attaquants ont déjà fait contre des sites PHP. À ce jour, aucune attaque de ce type n’a été décrite avec PHP2Shell.
Lire le mot de passe de la base de données. Un site a besoin de se connecter à sa base de données, et le mot de passe se trouve le plus souvent dans un fichier de configuration. Pour WordPress, c’est le fichier wp-config.php, qui contient, selon la documentation de WordPress, « la configuration de base de votre site, comme les informations de connexion à la base de données ». Le guide de sécurisation de WordPress conseille d’en limiter la lecture à son propriétaire « et au serveur web ». Or, si PHP est exécuté par le même utilisateur du système que le serveur web, ce qui dépend de la configuration, le code de l’attaquant peut lire ce fichier. Chercher des mots de passe dans les fichiers de configuration est une technique répertoriée par MITRE ATT&CK, la base de connaissances de référence sur les techniques d’attaque.
Se servir dans les données. Avec ce mot de passe, l’attaquant se connecte à la base comme le ferait l’application : comptes clients, commandes, adresses. Si le compte de base de données a aussi le droit de supprimer ou de modifier des tables, il peut faire bien plus que lire.
S’installer pour revenir. L’attaquant peut déposer un web shell : un petit fichier placé sur le serveur web, qui lui permet de revenir commander le serveur depuis son navigateur (MITRE ATT&CK). Ce fichier reste en place après la mise à jour de PHP. Corriger la faille ne le supprime pas.
Détourner les paiements. Sur une boutique en ligne, l’attaquant peut insérer dans la page de paiement un code qui copie les numéros de carte saisis par les clients. C’est ce qu’ont fait les attaquants de CosmicSting, décrit plus bas.
Lire la mémoire du serveur, sans exécuter de code. Selon Wiz, ces failles permettent aussi de lire une partie de la mémoire des processus PHP, où peuvent se trouver « des mots de passe, des jetons d’authentification, des clés d’API et des certificats ».
Deux attaques récentes montrent ce que deviennent ces failles une fois publiques. En juin 2024, une faille de PHP sous Windows (CVE-2024-4577) a fait l’objet de nombreuses tentatives d’exploitation dans les 24 heures qui ont suivi sa publication, selon l’équipe de recherche d’Akamai, une société de services de sécurité et de diffusion de contenus sur Internet. Les attaquants y installaient des outils de prise de contrôle à distance, des logiciels qui minent de la cryptomonnaie aux frais du serveur, et le logiciel d’un réseau de machines piratées. Selon Help Net Security, qui cite la société Imperva, la même faille a servi à déployer un rançongiciel, deux jours après la publication du correctif.
La même année, CosmicSting (CVE-2024-34102) a touché Magento et Adobe Commerce, deux solutions de boutique en ligne écrites en PHP. Selon Sansec, une société spécialisée dans la sécurité des boutiques en ligne, sept groupes d’attaquants ont piraté 4 275 boutiques. Ils volaient la clé secrète de chiffrement de la boutique, s’en servaient pour fabriquer un accès à son interface de programmation, puis inséraient dans la page de paiement un code qui copiait les cartes bancaires. Quand les attaquants ont commencé à chercher ces clés, 75 % des installations n’avaient pas appliqué le correctif. Et selon Sansec, cité par The Hacker News, même des boutiques corrigées restaient vulnérables tant qu’elles n’avaient pas remplacé leur clé : une clé volée avant le correctif fonctionnait toujours après. Appliquer le correctif ne termine donc pas l’incident.
Les systèmes de gestion de contenu d’abord. Selon W3Techs, WordPress est utilisé à lui seul, en octobre 2026, par 39,6 % de l’ensemble des sites web. Joomla (2,4 %), Drupal (0,6 %), PrestaShop (0,5 %), Bitrix, TYPO3 et OpenCart (0,3 à 0,4 % chacun) sont eux aussi écrits en PHP.
Les applications développées sur mesure ensuite. Laravel et Symfony sont des frameworks, des ensembles de composants sur lesquels on développe des applications sur mesure en PHP. Symfony indique que Drupal, PrestaShop et Laravel reposent sur ses composants. Côté logiciels de gestion, Dolibarr, un ERP et CRM libre destiné aux petites comme aux grandes entreprises, est écrit en PHP.
Calif dit avoir confirmé l’exploitation sur WordPress, Drupal, Joomla, Magento, MediaWiki, Nextcloud, phpMyAdmin, Roundcube et WHMCS, ainsi que sur Laravel et Symfony. Et d’autres produits embarquent PHP sans le montrer : le CERT-EU prévient que des produits qui intègrent PHP peuvent être touchés même s’ils ne l’exposent pas directement. Palo Alto Networks l’a confirmé le 21 octobre : toutes les versions du système de ses pare-feu, PAN-OS, et de sa console Panorama sont touchées, par leur interface d’administration. À cette date, aucune version corrigée n’est disponible ; l’éditeur conseille de limiter l’accès à cette interface à des adresses internes de confiance. Le NCSC-NL, le centre national de cybersécurité des Pays-Bas, tient une liste des logiciels qui dépendent de PHP : c’est le meilleur point de départ pour savoir lesquels vous utilisez.
Combien de sites utilisent une version que l’équipe de PHP ne corrige plus ? En octobre 2026, d’après nos calculs sur les chiffres de W3Techs, près de la moitié des sites PHP dont la version est connue : environ 35 % sont en PHP 7 ou plus ancien, et environ 14 % en PHP 8.0 ou 8.1 (répartition par version, détail de PHP 8). Ce chiffre est à prendre avec prudence : certaines distributions Linux corrigent elles-mêmes d’anciennes versions sans en changer le numéro, et une version ancienne n’est donc pas toujours une version vulnérable. Selon une estimation de chercheurs rapportée par CyberScoop le 21 octobre 2026, plus de 1,3 million de serveurs exposés sur Internet pourraient être vulnérables. Vérifiez donc la version de PHP de votre site, ou demandez-la à votre hébergeur. Si elle ne figure plus parmi les versions que l’équipe de PHP maintient, elle ne recevra pas de nouvelle version officielle corrigeant PHP2Shell. L’équipe de PHP a publié des correctifs minimaux pour PHP 7.4, 8.0 et 8.1, sous forme de code source (encadré technique plus haut) : la plupart des sites ne les reçoivent que par leur distribution Linux ou leur hébergeur. Sinon, il faut passer à une version maintenue.
Quatorze ans et demi entre l’écriture d’un code et la découverte de sa faille, cela semble énorme. C’est souvent ce qui arrive, y compris pour des failles parmi les plus graves de ces dernières années.
| Faille | Logiciel touché | Présente depuis | Rendue publique | Durée |
|---|---|---|---|---|
| Shellshock | Bash, l’interpréteur de commandes des systèmes Unix et Linux | 1989 | septembre 2014 | environ 25 ans (D. A. Wheeler) |
| PwnKit | pkexec, un outil de polkit qui permet de lancer une commande avec d’autres droits sous Linux | mai 2009 | janvier 2022 | environ 12 ans et demi (Qualys) |
| Baron Samedit | sudo, la commande qui permet d’agir en administrateur sous Linux | juillet 2011 | janvier 2021 | environ 9 ans et demi (Qualys) |
| Heartbleed | OpenSSL, une bibliothèque de chiffrement | mars 2012 | avril 2014 | environ 2 ans (heartbleed.com) |
| PHP2Shell | PHP | mars 2012 | octobre 2026 | environ 14 ans et demi (php.net) |
Des chercheurs avaient mesuré dès 2006 combien de temps les failles restent cachées. Andy Ozment et Stuart Schechter, deux chercheurs en sécurité informatique, ont suivi les failles d’OpenBSD, un système d’exploitation libre réputé pour sa sécurité, sur sept ans et demi et quinze versions. 62 % des failles signalées pendant l’étude étaient déjà présentes au début de celle-ci, et la moitié des failles du code d’origine restaient cachées au moins 2,6 ans avant d’être découvertes (USENIX Security 2006).
Pour PHP2Shell, des signes avaient même précédé la découverte. Selon Calif, un premier problème de PHP lié à la limite de mémoire avait été trouvé dès 2004, un bogue voisin signalé en 2020, et un audit de 2024 avait relevé un problème proche sans pouvoir montrer qu’il était exploitable.
Ces failles ont un point commun : elles se trouvaient dans du code écrit des années plus tôt, sur lequel reposent un très grand nombre de systèmes.
Mandiant, l’équipe d’analyse des menaces de Google Cloud, mesure chaque année le délai entre la publication d’une faille et sa première exploitation observée. En moyenne, ce délai était de 63 jours en 2018 et 2019, de 44 jours entre 2020 et le début de 2021, de 32 jours en 2021 et 2022, puis de 5 jours seulement en 2023 (Mandiant). Dans son rapport M-Trends 2026, Mandiant estime qu’en moyenne, la première exploitation précède de sept jours la publication de la faille. L’exploitation a couramment lieu « avant même la publication d’un correctif » (M-Trends 2026).
VulnCheck, une société de veille sur les failles, a regardé seulement les failles dont l’exploitation est avérée. Au premier semestre 2026, 23,43 % d’entre elles ont été exploitées le jour même de leur publication, ou avant. Les logiciels de gestion de contenu, comme WordPress et ses plugins (c’est ainsi que l’on appelle les extensions sur WordPress), sont la catégorie la plus visée : un tiers de ces failles (VulnCheck). Pour les failles de WordPress les plus exploitées, Patchstack, qui vend des protections contre ces attaques, a mesuré en 2025 un délai médian de cinq heures avant la première exploitation (Patchstack). Et selon le rapport annuel de Verizon sur les violations de données, dans son édition 2026, 31 % des violations commencent par une faille logicielle, devant les mots de passe volés (Verizon DBIR 2026).
PHP2Shell en est une illustration : une première tentative relevée par Amazon dès le 17 octobre, une fuite le 20, des attaques signalées le 21 au matin par Cloudflare et watchTowr, le correctif publié le 21 dans l’après-midi.
Ces chiffres expliquent la suite. Si l’attaque peut commencer avant que le correctif soit publié, l’appliquer ne suffit pas. Il reste à préparer trois choses : que la faille, le jour où elle est exploitée, n’ouvre pas tout ; qu’on en soit alerté immédiatement ; que le correctif, une fois publié, parte en production dans la journée.
Les chercheurs de Calif racontent qu’ils ont relu le code source de PHP en se faisant assister par un modèle de langage. Des agents d’IA ont suivi les chemins du code, et un modèle a généralisé la première faille en une méthode de recherche, qui a permis d’en trouver une seconde. Selon eux, ils n’ont eu besoin d’aucun outil particulier ni d’aucun accès à un modèle non public ; leur connaissance de l’histoire des failles de PHP a compté. Wiz, de son côté, prévient que les modèles de langage peuvent aider à adapter une attaque à différentes versions de PHP, configurations et organisations de la mémoire, et que « cela abaisse nettement la barrière pour mener des attaques à grande échelle ».
Ce n’est pas le premier cas. En 2024, Big Sleep, un agent d’IA de Google, a trouvé dans SQLite, une base de données présente dans un très grand nombre d’applications, une faille exploitable, corrigée avant d’arriver dans une version publiée (Google Project Zero). En août 2025, lors de la finale du concours AIxCC de la DARPA, l’agence de recherche du ministère américain de la Défense, des systèmes d’IA ont trouvé 54 failles introduites pour le concours et en ont corrigé 43, en 45 minutes en moyenne par correctif. Ils ont aussi trouvé 18 failles réelles, qui n’avaient pas été introduites pour l’occasion (DARPA).
Le 21 octobre, deux projets ont corrigé des failles trouvées avec des outils d’IA : PHP, selon les découvreurs de ses failles, et Node.js, pour l’une des siennes (CVE-2026-111497), que son équipe attribue à OpenAI Codex Security et à deux chercheurs. La faille de GitLab a été signalée par un chercheur, et GitLab ne mentionne aucun outil d’IA.
Le 21 octobre, Microsoft a décrit une campagne menée avec ARTEX par Storm-0940, un acteur que Microsoft dit aligné sur l’État chinois. Microsoft présente ARTEX comme un outil libre de tests d’intrusion, qui confie à des agents d’IA les étapes d’une attaque. Selon Microsoft, Storm-0940 s’en est servi pour automatiser des attaques contre des centaines d’organisations. Après avoir compromis ConnectWise, un éditeur de logiciels pour les prestataires informatiques, il a tenté de se connecter à plus de 2 250 environnements Microsoft 365 de ses clients. Les agents se chargeaient de la reconnaissance, de la modification d’identifiants d’applications et de tentatives de modifier des droits pour élargir ou prolonger leur accès. Microsoft précise que la plupart de ces tentatives ont échoué.
Le 19 octobre, Reuters a rapporté qu’un cybercriminel sinophone s’est servi d’agents d’IA pour s’introduire dans les sites web de plus de 100 entreprises, pour environ 5 000 dollars de consommation d’IA. L’agence n’a pas pu établir dans quelle mesure des données ont été extraites. Reuters s’appuie sur le rapport d’un chercheur, Snorre Fagerland, de la société NorForge ; parmi les entreprises citées, deux disent avoir traité un incident sur un site web.
Amazon décrit une tendance générale : l’analyse assistée par l’IA rend moins coûteux le passage d’un correctif ou d’un avis de sécurité à une attaque qui fonctionne, et davantage d’attaquants peuvent agir dans les heures, voire les minutes, qui suivent la publication des détails d’une faille. Amazon ne dit pas que les attaquants de PHP2Shell se sont servis de l’IA, et indique ne pas savoir comment l’attaquant a obtenu des informations sur la faille avant sa publication.
Big Sleep et AIxCC montrent que des systèmes d’IA trouvent des failles dans du code réel ; selon Wiz, un modèle peut aider à adapter une attaque ; et selon Microsoft, des agents d’IA mènent déjà des attaques contre des organisations. L’IA sert donc aussi bien ceux qui corrigent les failles que ceux qui les exploitent. Nous la tenons pour une hypothèse : le délai entre la découverte d’une faille et les premières attaques pourrait encore se raccourcir.
Les autorités de sécurité s’accordent sur un point : l’IA raccourcit le temps dont disposent ceux qui appliquent les correctifs. En février 2026, le CERT-FR écrivait, dans sa synthèse de la menace liée à l’IA générative, que celle-ci « permet aux acteurs malveillants d’agir plus rapidement et donc à plus grande échelle ». En mai, le NCSC, le centre national de cybersécurité du Royaume-Uni, annonçait une vague de mises à jour, pour des failles de toutes gravités, parce que l’IA, entre des mains compétentes, permet d’exploiter les faiblesses accumulées dans les logiciels « à grande échelle et à un rythme soutenu ». En juin, la CISA a changé les délais qu’elle impose aux administrations fédérales américaines pour appliquer les correctifs : ils dépendent désormais du risque (exposition à Internet, exploitation avérée, impact). Le délai le plus court est de trois jours. Elle justifie ce changement par l’usage de l’IA par les attaquants, qui « pourrait réduire encore » le temps dont disposent les défenseurs. Nous en tirons une règle : un correctif critique s’applique le jour même de sa publication (voir les délais d’exploitation plus haut), ce que permet une approche de livraison où chaque modification passe déjà par le pipeline.
L’IA sert aussi à écrire du code, et plusieurs de ces autorités recommandent de le contrôler. En mars 2026, le directeur général du NCSC a prévenu que des logiciels peu sûrs, produits « sans relecture humaine », pourraient propager des failles. L’ANSSI et le BSI, son homologue allemand, relèvent dans leur rapport sur les assistants de programmation un risque de dépendance excessive à ces outils et d’acceptation sans examen du code qu’ils génèrent, en particulier chez les développeurs débutants. Ils recommandent que le code généré soit en règle générale vérifié par les développeurs, avec une relecture critique des erreurs de l’outil et des risques de sécurité. Le CERT-FR signale un autre piège : un assistant d’IA peut inventer le nom d’un composant qui n’existe pas, et des attaquants enregistrent ces noms pour y publier des versions malveillantes. Pour les agents d’IA, le principe du minimum de droits s’applique comme pour le processus PHP (détail plus bas).
Concrètement, nous conseillons à une équipe qui développe avec l’IA de relire chaque ligne que l’outil écrit et de la faire passer par les tests du pipeline, comme le reste du code ; de vérifier qu’un composant proposé par l’IA existe, et qui le publie, avant de l’ajouter ; et de ne donner à un agent que les droits dont sa tâche a besoin. Pour une application créée avec l’IA, notre article « Peut-on créer une application avec l’IA ? » détaille ce que l’outil fait seul.
Une PME ou une start-up n’a pas besoin de chercheurs en sécurité dans ses équipes. Trouver une faille comme PHP2Shell demande des spécialistes, et leur recherche s’est déroulée avant la publication : de huit à dix semaines séparent le premier signalement du correctif, selon les calendriers de Wiz et de Calif. Pour le reste, le guide d’hygiène informatique de l’ANSSI rassemble, dans son édition de 2017, 42 mesures. L’agence y écrit que la majeure partie des attaques pour lesquelles elle est intervenue auraient pu être évitées si ces mesures avaient été appliquées. Pour ceux qui manquent de connaissances, elle conseille de solliciter un spécialiste pour un diagnostic, et de désigner dans l’entreprise un référent en sécurité.
Dave Farley est l’inventeur du pipeline de déploiement, qu’on appelle souvent pipeline CI/CD. La livraison continue consiste à garder le logiciel prêt à être mis en production à tout moment, par petites modifications vérifiées automatiquement. Le pipeline de déploiement est la chaîne automatique qui prend chaque modification du code, la teste, l’enregistre et la rend prête à partir en production. Dave Farley est coauteur, avec Jez Humble, du livre « Continuous Delivery » (Livraison continue), et auteur de « Modern Software Engineering » (Ingénierie logicielle moderne). Dans « Continuous Delivery Pipelines » (Pipelines de livraison continue), il écrit que la sécurité peut demander l’avis de spécialistes, mais qu’elle est « la responsabilité de chacun dans l’équipe ». Les spécialistes conseillent ; ils ne doivent pas servir de « gardiens » qui valident chaque mise en production.
Ce que l’équipe qui développe et maintient l’application peut faire se résume à quatre objectifs, et aucun ne demande de chercher des failles :
Les sections « Limiter ce qu’une faille permet d’atteindre » et « Être alerté immédiatement » traitent les deux premiers objectifs. Les sections sur les dépendances, sur les mises à jour et sur l’approche de livraison traitent le troisième, et la section « Site WordPress piraté ou faille découverte » le quatrième.
Selon M-Trends 2026, le délai médian entre l’entrée d’un attaquant dans un système et sa découverte est de 14 jours. Pendant ce délai, l’attaquant agit : les deux premiers objectifs réduisent ce qu’il peut atteindre et le temps qu’il reste inaperçu.
Un service numérique ne se résume pas à un site. Une application web typique comprend plusieurs éléments : un point d’entrée qui reçoit les requêtes venues d’Internet et les transmet, le serveur qui exécute le code, une base de données, des sauvegardes, et les comptes des personnes qui administrent le tout. Chacun de ces éléments peut être réglé pour qu’une faille dans l’un ne donne pas accès à tous les autres. C’est ce qu’on appelle la défense en profondeur.
Donner à chaque programme le minimum de droits. Le processus PHP n’a besoin ni d’être administrateur de la machine, ni de pouvoir modifier le code du site. Le compte qu’il utilise pour se connecter à la base de données n’a besoin, selon le guide de sécurisation de WordPress, que de lire et d’écrire des données ; les droits de supprimer, de modifier la structure ou d’accorder des droits peuvent lui être retirés. Jez Humble et Dave Farley le disent dans « Continuous Delivery » : les réglages par défaut des systèmes d’exploitation et des bases de données ne conviennent pas à une application en production ; il faut des pare-feu, des services inutiles désactivés, et des utilisateurs de base de données aux droits ajustés.
Rendre le code impossible à modifier depuis le site. Si le processus PHP ne peut pas écrire dans les dossiers du code, un attaquant qui en prend le contrôle ne peut pas y déposer un web shell aussi facilement. WordPress le prévoit : seul le dossier des contenus envoyés (wp-content) doit être modifiable par le serveur web, et l’éditeur de code intégré à l’administration, souvent « le premier outil qu’un attaquant utilise s’il parvient à se connecter » selon WordPress, peut être désactivé.
Cloisonner. La base de données n’a aucune raison d’être joignable depuis Internet : seul le serveur d’application doit pouvoir s’y connecter. L’ANSSI demande de segmenter le réseau, de cloisonner les services visibles depuis Internet du reste du système, et d’administrer les serveurs depuis un réseau dédié (mesures 19, 23 et 28 de son guide).
Filtrer en amont, en connaissant les limites du filtre. Un pare-feu applicatif, ou WAF, examine les requêtes avant qu’elles n’atteignent le serveur et bloque celles qui ressemblent à une attaque connue. Le guide de sécurisation de WordPress recommande d’en installer un. Il a ses limites : Cloudflare demande lui-même d’appliquer le correctif malgré ses règles contre PHP2Shell, et le CERT-FR précise que le blocage qu’il propose n’est pas qualifié par ses soins. Un pare-feu applicatif fait gagner du temps ; il ne remplace pas le correctif.
Sortir les secrets du code. Les mots de passe et les clés d’accès à d’autres services (paiement, envoi d’e-mails, stockage) ne devraient pas être écrits dans les fichiers du code. MITRE ATT&CK recommande une règle qui interdit de stocker des mots de passe dans des fichiers. Placés dans les variables d’environnement du serveur ou dans un coffre-fort de secrets, ils restent lisibles par PHP pendant qu’il s’exécute : cela ne les protège pas d’une prise de contrôle du processus PHP. Ce que l’on y gagne, à notre avis, c’est qu’ils ne se trouvent plus dans l’historique du code ni dans ses sauvegardes, et qu’on peut les changer sans toucher au code. Cela compte le jour où il faut tous les remplacer.
Protéger les comptes des personnes. Un attaquant n’a pas toujours besoin d’une faille : un mot de passe réutilisé lui suffit. L’ANSSI demande de protéger les mots de passe, de changer ceux fournis par défaut, et de privilégier une authentification forte (mesures 11 à 13). Concrètement, nous conseillons un gestionnaire de mots de passe, pour que chacun ait un mot de passe différent par service, et une double authentification sur les comptes qui donnent accès à la production, à l’hébergement et au code.
Interdire les modifications à la main en production. Dans « Continuous Delivery Pipelines », Dave Farley fixe un objectif : « supprimer tout accès humain en écriture aux systèmes de production ». Chaque changement passe par le pipeline de déploiement. Dans « Continuous Delivery », les deux auteurs ajoutent que la production doit être fermée aux personnes extérieures comme aux personnes de l’entreprise, équipes d’exploitation comprises. Sans cela, quand quelque chose tourne mal, plus personne ne sait qui a fait quoi, ni quand.
Garder des sauvegardes hors ligne, et les tester. Une sauvegarde accessible depuis le serveur compromis peut être chiffrée ou effacée avec le reste. L’ANSSI demande une politique de sauvegarde qui prévoie des copies hors ligne et des tests de restauration, avec au moins un exercice de restauration par an (mesure 37). Une sauvegarde qui n’a jamais été restaurée n’a pas fait la preuve qu’elle fonctionne.
user, obligatoire (php.net). Les réglages posés par php_admin_value et php_admin_flag ne peuvent pas être modifiés par ini_set(). Ne pas exposer PHP-FPM sur une adresse joignable de l’extérieur.expose_php = Off, display_errors = Off, allow_url_fopen = Off, allow_url_include = Off, open_basedir, disable_functions (system, exec, shell_exec, passthru, proc_open…), des cookies de session secure, httponly et use_strict_mode. Mais la documentation de PHP prévient elle-même que disable_functions « peut être contourné » et que open_basedir n’est qu’« un filet de sécurité supplémentaire, loin d’être complet », qui ne restreint pas l’accès aux sockets Unix. Ces réglages compliquent la suite d’une attaque ; ils ne l’empêchent pas, et PHP2Shell se déclenche avant que l’application ne s’exécute.DROP, ALTER et GRANT peuvent être retirés, en gardant à l’esprit que certaines mises à jour modifient le schéma) ; wp-config.php en permission 400 ou 440 ; DISALLOW_FILE_EDIT ; pare-feu applicatif, ModSecurity étant cité comme l’option libre la plus répandue.Une fois la défense en place, il reste à être prévenu quand elle est franchie. L’objectif est triple : savoir qu’il se passe quelque chose d’anormal, couper l’accès, puis trouver d’où vient l’attaque. Dans « Continuous Delivery », Jez Humble et Dave Farley demandent que les équipes d’exploitation soient « informées immédiatement » d’un incident, et qu’elles disposent des outils pour en trouver la cause. Ils relèvent aussi une erreur fréquente : ignorer les erreurs au lieu de les enregistrer, ce qui empêche de les détecter.
Une solution de supervision surveille des signaux précis, et ses journaux sont conservés ailleurs que sur le serveur surveillé. Les équipes d’exploitation suivent l’état des serveurs en permanence sur des tableaux de bord, comme Grafana ou Kibana, qui rassemblent les mesures et les journaux et déclenchent une alerte quand un seuil est franchi. Voici les signaux que ces alertes doivent surveiller.
Le serveur web lance un programme. Un serveur web sert des pages ; il n’a aucune raison de lancer un interpréteur de commandes ou un outil de téléchargement. Quand il le fait, c’est souvent qu’un web shell est utilisé (MITRE ATT&CK).
Le serveur se connecte à des adresses inconnues. Un logiciel qui mine de la cryptomonnaie, un outil de prise de contrôle à distance ou une fuite de données ont tous besoin de connexions sortantes. Nous conseillons de bloquer par défaut les connexions sortantes du serveur, sauf vers les services dont l’application a besoin : cela limite aussi l’usage de ces outils.
Un fichier de code change. En production, le code ne change que lors d’un déploiement. Un nouveau fichier .php dans les dossiers du site, hors déploiement, est un signal d’intrusion. WordPress recommande de surveiller l’intégrité des fichiers, et rappelle qu’une attaque « laisse toujours des traces, dans les journaux ou dans les fichiers ».
Un nouveau compte administrateur apparaît. L’ANSSI demande de tenir à jour l’inventaire des comptes à privilèges (mesure 5). Un compte administrateur créé hors de toute procédure est un signal à traiter.
Les erreurs se multiplient. L’ANSSI demande d’enregistrer les erreurs des services web, en citant les erreurs 403, 404 et 500, ainsi que les arrêts inopinés (mesure 36).
Garder les journaux hors du serveur. Un attaquant qui contrôle le serveur peut effacer ses traces dans les journaux qui s’y trouvent. L’ANSSI recommande donc de centraliser les journaux sur un autre système, et de conserver les événements de sécurité au moins un an.
Quelques outils libres, donnés en exemple :
/etc (documentation Falco).Une application n’est pas écrite entièrement par ceux qui la développent. Elle s’appuie sur des composants publiés par d’autres, les dépendances, que des outils installent et mettent à jour : Composer pour PHP, npm ou pnpm pour JavaScript. Et elle s’exécute sur un environnement, PHP lui-même, fourni par le système du serveur, par l’hébergeur ou par l’image qui sert à la déployer.
Dans « Continuous Delivery », Jez Humble et Dave Farley sont catégoriques : un projet doit toujours indiquer « la version exacte des bibliothèques externes » qu’il utilise. Sans cela, écrivent-ils, on ne peut pas reconstruire à l’identique ce qui est en production. À notre avis, on ne sait pas non plus si l’on est exposé à une faille.
Quand un projet accepte « toute version à partir de celle-ci », une version nouvellement publiée entre dans l’application à la prochaine mise à jour, sans que personne ne l’ait choisie. C’est, à ce jour, le réglage par défaut de npm (npm), et Composer le recommande pour les bibliothèques destinées à être réutilisées par d’autres projets (Composer). Le détail de la notation figure dans l’encadré « Pour votre équipe technique » plus bas.
Toutes les nouvelles versions ne se traitent pas de la même façon. Le correctif d’une faille grave s’installe dès sa publication : attendre, c’est laisser la porte ouverte. Les autres nouvelles versions peuvent attendre quelques jours, parce que c’est dans une version tout juste publiée que se glisse le code malveillant. En 2018, un attaquant a pris la maintenance du paquet event-stream et y a ajouté du code qui visait les portefeuilles de bitcoins de l’application Copay (npm). En septembre 2025, le compte du mainteneur de chalk, de debug et d’une vingtaine d’autres paquets JavaScript a été piraté au moyen d’un faux e-mail de réinitialisation ; selon StepSecurity, une société de sécurité informatique, ces paquets étaient alors téléchargés des milliards de fois par semaine (StepSecurity). Quelques jours plus tard, le ver Shai-Hulud, qui se propageait seul d’un paquet à l’autre, en avait compromis plus de 500 ; la CISA a alors recommandé de fixer les dépendances sur des versions sûres, publiées avant le 16 septembre 2025 (CISA).
D’où quatre pratiques.
Inscrire la version exacte dans le fichier qui déclare les dépendances. L’application reçoit alors une nouvelle version quand quelqu’un le décide, pas quand elle est publiée. Avec un fichier de verrouillage enregistré avec le code (pratique suivante), une plage de versions ne joue qu’au moment d’une mise à jour. Elle n’est donc pas une faille en soi : la version exacte est une règle d’équipe, qui rend chaque mise à jour délibérée.
Conserver le fichier de verrouillage avec le code. Ce fichier enregistre la version exacte de chaque composant installé, y compris les composants dont dépendent vos composants, et la documentation de Composer demande de l’enregistrer avec le code du projet (Composer).
Installer depuis ce fichier, et ne mettre à jour que sur décision. Le pipeline installe exactement les versions du fichier de verrouillage. Une mise à jour se décide composant par composant, et se teste.
Attendre avant d’adopter une version tout juste publiée. Le gestionnaire pnpm propose ce délai, fixé par défaut, à ce jour, à un jour depuis sa version 11, « pour réduire le risque d’installer des paquets compromis ou défectueux ». Sa documentation indique que les versions malveillantes sont en général découvertes et retirées en moins d’une heure (pnpm). Le correctif d’une faille grave ne suit pas ce délai : il s’installe dès sa publication, une fois vérifié qu’il est bien annoncé par l’éditeur ou par le CERT-FR.
Le risque inverse existe aussi : fixer ses versions et ne plus jamais les mettre à jour. D’après nos calculs sur les chiffres de W3Techs, près de la moitié des sites PHP utilisaient, en octobre 2026, une version que l’équipe de PHP ne corrige plus. Une version exacte ne protège que si les mises à jour suivent, souvent, une à une, et vérifiées. Jez Humble et Dave Farley en font un principe général : « si c’est douloureux, faites-le plus souvent, et attaquez la difficulté plus tôt ». Une mise à jour faite chaque semaine change peu de choses à la fois ; une mise à jour repoussée pendant deux ans devient un chantier.
De nouvelles failles sont publiées chaque jour sur du code qui, lui, n’a pas changé. Une vérification lancée seulement au moment d’une modification laisse passer les failles publiées entre-temps. Composer, l’outil qui gère les composants d’une application PHP, sait comparer les composants installés aux avis de sécurité publiés sur Packagist, le dépôt principal des composants PHP, et signale aussi les composants abandonnés (Composer). Lancée chaque jour par une tâche planifiée du pipeline, cette vérification signale une faille dès que son avis de sécurité est publié. Dans « Continuous Delivery Pipelines », Dave Farley demande que la sécurité soit testée dans le pipeline, dès la première étape, et non traitée comme un contrôle à part.
Une fois par semaine, une autre vérification liste les composants pour lesquels une nouvelle version existe. Ce rappel évite l’écart de deux ans.
Une alerte ne demande pas toujours la même réponse. Deux informations décident de l’urgence. La gravité d’abord : la plupart des avis de sécurité donnent une note CVSS, de 0 à 10, que le FIRST, l’organisation internationale qui publie cette échelle, range en cinq niveaux : aucune (0), faible (0,1 à 3,9), moyenne (4 à 6,9), élevée (7 à 8,9) et critique (9 à 10) (CVSS 4.0). Les failles de PHP2Shell sont notées 9,2 : critiques. Cette note compare la gravité d’une faille à celle des autres ; elle ne mesure pas le risque pour votre entreprise.
L’exploitation ensuite : une faille déjà exploitée passe avant une faille plus grave qui ne l’est pas encore. La CISA tient la liste des failles exploitées : elle impose aux administrations fédérales américaines des délais pour les corriger, et recommande à toute organisation de les corriger en priorité. Le FIRST publie chaque jour l’EPSS, une estimation de la probabilité qu’une faille soit exploitée dans les trente jours. En France, le CERT-FR distingue ses alertes, « destinées à prévenir d’un danger immédiat », de ses avis, qui font état de failles et des moyens de s’en prémunir. PHP2Shell a fait l’objet d’une alerte.
En pratique, une faille critique, déjà exploitée ou visée par une alerte du CERT-FR se corrige le jour même où le correctif est publié. Les autres suivent le rythme normal des mises à jour, une à la fois.
Ces outils ont une limite, et PHP2Shell la montre. Ils examinent les bibliothèques déclarées par l’application, pas le langage qui l’exécute. Une vérification des composants sans alerte ne dit rien de PHP2Shell. La version de PHP se surveille à part : l’équipe de PHP publie la liste des versions prises en charge et un fil d’actualité de ses versions ; le CERT-FR publie ses alertes, et l’ANSSI demande de s’informer de l’apparition de nouvelles failles par ce canal (mesure 34). L’ANSSI demande aussi d’anticiper la fin de maintenance des logiciels (mesure 35) : PHP 8.2 n’en reçoit plus après le 31 décembre 2026.
Un composer.json avec des versions exactes (noms de composants donnés pour l’exemple) :
{
"require": {
"vendor/component-a": "2.3.1",
"vendor/component-b": "5.0.4"
}
}
À la place de "^2.3.1", qui accepterait toute version de 2.3.1 à 3.0.0 exclue (Composer). À ce jour, npm inscrit ^ par défaut : ^1.2.3 accepte toute version à partir de 1.2.3 et avant 2.0.0 (node-semver). Pour npm, save-exact=true dans .npmrc fait inscrire la version exacte par défaut (npm).
Un exemple de pipeline GitLab, donné pour illustration et à adapter : une vérification à chaque envoi de code, une tâche quotidienne et une tâche hebdomadaire, chacune déclenchée par sa propre planification GitLab (planifications, règles).
# Exemple d'illustration, à adapter à votre projet
stages: [commit, audit]
.php:
# Image de votre projet avec PHP et Composer, épinglée par son empreinte
image: registry.example/php-composer@sha256:<digest>
commit:
extends: .php
stage: commit
script:
# Vérifie que composer.json et composer.lock sont cohérents
- composer validate --strict
# Échoue si un composant, de production ou de développement, a un avis de sécurité
- composer audit --locked
# Installe exactement les versions du fichier de verrouillage
- composer install --no-interaction --prefer-dist
rules:
- if: $CI_PIPELINE_SOURCE == "push"
daily-audit:
extends: .php
stage: audit
script:
# Même vérification chaque jour, sans changement de code ; échoue aussi si un composant est abandonné
- composer audit --locked --abandoned=fail
rules:
- if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_KIND == "daily"
weekly-reminder:
extends: .php
stage: audit
script:
# Liste les nouvelles versions disponibles, sans faire échouer le pipeline : c'est le rappel
- composer outdated --direct
rules:
- if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_KIND == "weekly"
composer.lock, ou package-lock.json pour npm) est enregistré avec le code. Le pipeline lance composer install, qui installe exactement les versions de ce fichier ; composer update recalcule les versions et réécrit le fichier : il ne sert qu’à une mise à jour décidée, par exemple composer update vendor/component-a (Composer).minimumReleaseAge pour pnpm, min-release-age pour npm (noms des réglages en octobre 2026). Pour Composer, nous conseillons de tenir ce délai par une règle d’équipe, ou par l’outil qui propose les mises à jour.composer audit renvoie un code de sortie non nul quand un composant est concerné par un avis : la tâche passe au rouge, et c’est l’alerte. --locked lit le fichier de verrouillage, même sans dossier vendor (Composer) : l’exemple lance donc la vérification avant composer install, et la tâche s’arrête avant d’installer un composant concerné par un avis. L’exemple vérifie aussi les composants de développement : ils s’exécutent dans le pipeline, qui a accès au code et aux secrets de déploiement.php de Docker, d’où l’image de projet dans l’exemple.@sha256:…) : la documentation de Docker indique que l’on obtient alors toujours la même image, et prévient que l’image ne reçoit plus les mises à jour, « qui peuvent inclure des correctifs de sécurité » (Docker). L’épinglage n’a donc de sens qu’avec une mise à jour régulière de l’empreinte, testée par le pipeline.integrity), et l’installation échoue si le paquet téléchargé ne correspond pas. Pour un script ou une feuille de style chargés depuis un autre domaine, l’attribut integrity (Subresource Integrity) fait refuser au navigateur un fichier modifié (MDN) ; l’ANSSI recommande ce contrôle pour les ressources JavaScript et CSS, internes comme tierces, en particulier celles d’un CDN (recommandations R11 et R12). L’OWASP demande d’activer la vérification des empreintes et des signatures des paquets téléchargés. Renovate ou Dependabot peuvent proposer ces mises à jour sous forme de demandes de fusion ; ils ne déploient rien eux-mêmes (Renovate, Dependabot).https://www.php.net/feed.atom) et les alertes du CERT-FR. OSV-Scanner, de Google, lit à ce jour composer.lock et, dans une image de conteneur, les paquets Alpine et Debian ou Ubuntu : il peut repérer un PHP installé par le système de l’image.Le NCSC demande à toutes les organisations d’« appliquer les mises à jour logicielles dès que possible, et idéalement de façon automatique », parce que les attaquants étudient souvent une faille corrigée pour écrire une attaque qui l’exploite ; selon Amazon, cité plus haut, l’IA rend ce travail moins coûteux. Le NCSC rappelle que l’éditeur teste lui-même ses mises à jour, tout en demandant de les tester aussi sur ses propres systèmes et de les déployer par étapes. Pour un logiciel que l’on installe et que l’on utilise tel quel (Windows, macOS, un téléphone, un navigateur, un logiciel de bureautique), nous conseillons donc d’activer les mises à jour automatiques de ces logiciels. Pour un service en ligne, c’est son fournisseur qui applique les correctifs. Un site WordPress n’entre dans aucune de ces deux catégories : son propriétaire ne développe pas le logiciel et ne l’utilise pas tel quel, il l’assemble et le configure. Notre position est différente pour un site ou une application que l’on assemble.
WordPress est utilisé, en octobre 2026, par près de quatre sites sur dix, et l’essentiel de ses failles ne se trouve pas dans WordPress lui-même. Selon Patchstack, 11 334 nouvelles failles ont été trouvées dans l’écosystème WordPress en 2025 : 91 % dans des plugins, 9 % dans des thèmes, et seulement 6 dans le cœur de WordPress. Et 46 % de ces failles n’avaient pas reçu de correctif de leur développeur au moment de leur publication (Patchstack). Ces chiffres viennent d’une société qui vend des protections contre ces failles.
Notre position est la suivante : nous déconseillons les mises à jour automatiques de PHP, des plugins et des thèmes. Nous préférons des versions fixées, et une mise à jour à la fois, testée avant d’atteindre la production : par le pipeline de déploiement pour une application développée sur mesure, sur une copie du site pour un site WordPress, vérifiée si possible par des tests automatisés. Cette position n’est pas la nôtre seulement. Dans « Continuous Delivery », Jez Humble et Dave Farley demandent d’indiquer la version exacte de chaque bibliothèque externe et de vérifier chaque changement sur un environnement semblable à la production. L’OWASP, dans son classement 2025 des risques les plus critiques pour les applications web, demande de « choisir délibérément la version de chaque dépendance, et de ne mettre à jour qu’en cas de besoin », et d’« éviter de déployer les mises à jour sur tous les systèmes à la fois ». Son classement des risques propres aux pipelines CI/CD demande de ne pas configurer les outils pour qu’ils prennent toujours la dernière version d’un paquet. La raison tient à la nature de l’écosystème. Un site WordPress assemble le cœur de WordPress, une version de PHP, et des plugins et des thèmes écrits par des auteurs indépendants les uns des autres. Rien ne garantit que la nouvelle version d’un plugin fonctionne avec la version d’un autre, ni avec la version de PHP du serveur. Une mise à jour automatique installe pourtant la nouvelle version en production, sans qu’aucun test n’ait vérifié que le site fonctionne encore.
WordPress adopte par défaut la position inverse. À ce jour (octobre 2026), depuis WordPress 3.7, les mises à jour mineures du cœur s’installent automatiquement par défaut (WordPress). Pour les plugins et les thèmes, les mises à jour automatiques sont à activer une par une depuis WordPress 5.5, et WordPress les lance alors deux fois par jour. La même page de WordPress commence par cette phrase : « Pour garder votre site WordPress sûr, vous devriez toujours mettre à jour vos plugins et vos thèmes vers leur dernière version » (WordPress). Cela donne un avantage réel aux mises à jour automatiques : face à un délai médian mesuré à cinq heures en 2025 entre la publication d’une faille très exploitée et sa première exploitation, une mise à jour automatique appliquée deux fois par jour est plus rapide qu’une mise à jour manuelle faite une fois par mois.
Notre position suppose donc quelqu’un pour assurer la maintenance. Ce qui s’automatise, ce sont les alertes : une alerte quand une faille touche les versions en place, une alerte quand quelque chose d’anormal se passe sur le serveur, signe qu’une faille est peut-être en train d’être exploitée. C’est à une personne de décider quand mettre à jour, puis de le faire aussitôt, sans attendre. La mise à jour elle-même, elle, s’automatise : l’administrateur la lance en un clic, et elle est testée avant d’atteindre la production, par le pipeline pour une application sur mesure, sur une copie du site pour WordPress, dans les heures qui suivent. Sans cette organisation, des versions fixées laissent le site exposé plus longtemps qu’une mise à jour automatique.
Deux autres leviers comptent autant. Puisqu’en 2025, près de la moitié des failles de plugins n’avaient pas de correctif le jour de leur publication, aucune politique de mise à jour, automatique ou manuelle, ne les couvre ce jour-là. Moins de plugins installés, c’est moins de failles possibles : l’OWASP, la fondation de référence sur la sécurité des applications web, demande de retirer les dépendances inutiles, et l’ANSSI de limiter les dépendances entre logiciels (« adhérences logicielles », dans son guide). Et un plugin abandonné par son auteur ne recevra plus de correctif : il se remplace.
Enfin, les mises à jour de WordPress ne mettent à jour que WordPress. Aucune ne touche à PHP. PHP est fourni par l’hébergeur ou par le système du serveur : c’est pourquoi l’équipe de PHP renvoie vers la distribution Linux ou le fournisseur qui assure la maintenance de PHP à long terme. Mettre à jour PHP pour un site WordPress se fait donc chez l’hébergeur, ou dans l’environnement qui sert à déployer le site.
Pour un site WordPress, rien n’oblige à assurer cette maintenance soi-même. Cybermalveillance.gouv.fr présente ses bonnes pratiques de sécurité d’un site comme des mesures « à adopter ou faire appliquer par son prestataire ». Des hébergeurs spécialisés dans WordPress se chargent de la mise à jour des logiciels du serveur, dont PHP, et des sauvegardes automatiques. Le guide de WordPress sur la sécurité décrit l’hébergeur de confiance : il « fournit les versions stables les plus récentes de tous les logiciels du serveur », « des méthodes fiables de sauvegarde et de restauration », et parle volontiers des mesures de sécurité qu’il propose. Avant de choisir, demandez-lui s’il met PHP à jour lui-même, s’il teste les mises à jour sur une copie du site avant de les appliquer, et comment restaurer une sauvegarde.
Une application développée sur mesure se met à jour, elle aussi, sur décision. Le référentiel Cyber Essentials du NCSC exclut de son périmètre les composants développés sur mesure des applications web, et recommande pour eux « un développement et des tests rigoureux ». Chaque mise à jour, de PHP comme d’un composant, passe par le pipeline de déploiement et ses tests automatisés, puis part en production le jour même de sa publication.
Tout change le jour où il faut toucher au code. La première règle de WordPress vaut pour tous : « ne touchez pas au cœur de WordPress », parce que chaque mise à jour en écrase les fichiers ; ce que l’on veut ajouter ou modifier passe par un plugin. Pour un thème, un thème enfant permet de le modifier sans toucher à son code, tout en continuant à recevoir ses mises à jour. Ce code écrit sur mesure, thème enfant ou plugin, est un logiciel que l’on développe. Dans « Continuous Delivery », Jez Humble et Dave Farley demandent de garder sous gestion de versions tout ce qui sert à construire et à déployer le logiciel, et de faire passer chaque changement par le pipeline de déploiement. Concrètement, ce code vit dans un dépôt Git et part en production par le pipeline, jamais copié à la main sur le serveur.
Personne n’a besoin de modifier le cœur de WordPress. Ce qui manque à une installation classique est ailleurs. Les plugins s’installent depuis l’administration, sans que leurs versions soient déclarées nulle part, et la configuration tient dans un seul fichier, le même pour tous les environnements. On ne peut donc pas reconstruire à l’identique, sur un environnement de test, le site qui est en production, ce que demandent pourtant Jez Humble et Dave Farley. C’est ce manque que comble Bedrock, de Roots. Il ne modifie pas le cœur de WordPress : il l’enveloppe. WordPress, ses plugins et ses thèmes y deviennent des dépendances, installées par Composer à une version précise et verrouillées dans composer.lock. La configuration change selon l’environnement (développement, recette, production) par des variables d’environnement. Le dépôt Git ne contient plus que le code écrit sur mesure, la configuration et la liste des dépendances, et, selon Roots, le cœur et les plugins ne peuvent plus être modifiés en dehors de l’environnement de développement. Roots présente cette organisation comme l’application à WordPress de la méthode « The Twelve-Factor App » (l’application à douze facteurs), qui décrit comment construire des applications web faciles à déployer et à maintenir. Les mises à jour se font alors dans le code, un plugin à la fois, puis passent par le pipeline. La configuration par défaut de Bedrock désactive, à ce jour, les mises à jour automatiques et l’installation de plugins depuis l’administration (config/application.php).
À notre avis, Bedrock se justifie dès qu’un site WordPress est maintenu comme un logiciel : du code sur mesure, plusieurs environnements, une équipe de développement, un pipeline. Pour un site que l’on configure, auquel on ajoute un thème enfant ou un plugin, il n’est pas nécessaire. Et Bedrock organise le projet, sans plus : la qualité du code écrit sur mesure reste l’affaire de ceux qui le développent.
// config/application.php de Bedrock, configuration par défaut
// Désactive les mises à jour automatiques de WordPress
Config::define('AUTOMATIC_UPDATER_DISABLED', true);
// Désactive l'éditeur de fichiers de l'administration
Config::define('DISALLOW_FILE_EDIT', true);
// Interdit d'installer ou de mettre à jour des plugins depuis l'administration
Config::define('DISALLOW_FILE_MODS', true);
# Avec Bedrock : mettre à jour un seul plugin, dans le code, puis passer par le pipeline
composer update wp-plugin/plugin-name
Sans Bedrock, le guide de WordPress sur le renforcement de la sécurité conseille de désactiver l’éditeur de fichiers de l’administration, qui permet par défaut de modifier le code PHP des plugins et des thèmes ; il précise que cela n’empêche pas tout, mais peut arrêter certaines attaques (WordPress) :
// Dans wp-config.php : désactive l'éditeur de fichiers de l'administration
define( 'DISALLOW_FILE_EDIT', true );
Pour mettre à jour un plugin à la fois, WP-CLI, l’outil en ligne de commande de WordPress, permet de garder la main : wp plugin update accepte --version pour viser une version précise, --patch pour ne prendre que les corrections, et --dry-run pour voir ce qui serait mis à jour sans rien changer (WP-CLI). La documentation de WordPress elle-même cite les personnalisations et le test préalable sur un environnement de recette comme raisons de désactiver les mises à jour automatiques, et demande, avant de les activer pour les plugins, de pouvoir revenir à la version précédente du site.
Tout ce qui précède repose sur une même capacité : mettre un correctif en production le jour même, sans rien casser. Cette capacité ne s’improvise pas le jour de l’alerte. Elle dépend de la façon dont le logiciel est livré au quotidien.
D’expérience, dans une organisation où chaque mise en production est une opération rare (un soir par trimestre, des tests faits à la main, plusieurs personnes mobilisées), une faille critique arrive comme un imprévu. Il faut monter une correction d’urgence en dehors du calendrier, réunir les personnes qui savent déployer, refaire les tests à la main, réserver une fenêtre d’intervention, parfois obtenir l’accord d’un comité. Le correctif devient un projet, et pendant ce temps, l’application reste exposée. Ce rythme de livraison pousse à corriger directement sur le serveur, à la main. Dans « Continuous Delivery », Jez Humble et Dave Farley refusent ce raccourci sans détour : face à un défaut critique, « ne contournez sous aucun prétexte votre processus ». Ils rappellent aussi qu’il vaut parfois mieux revenir à la version précédente que de déployer une correction. Une correction faite à la main en production n’est pas testée, peut aggraver le problème, et n’est souvent enregistrée nulle part.
Avec la livraison continue logicielle, pratiquée dans le cadre d’une approche adaptative, c’est-à-dire en ajustant le logiciel en continu à partir de son usage, le même correctif est une modification comme une autre. Jez Humble définit la livraison continue comme « la capacité de mettre en production, ou entre les mains des utilisateurs, des modifications de tous types, y compris de nouvelles fonctionnalités, des changements de configuration, des corrections de bugs et des expériences, de manière sûre, rapide et durable » (continuousdelivery.com). Dave Farley précise que le pipeline de déploiement est « la SEULE route vers la production » : chaque modification y passe, la mise à jour de PHP comme la nouvelle fonctionnalité. Elle subit les mêmes tests automatisés, puis part en production. Comme chaque modification suit ce chemin, la procédure est déjà rodée le jour où un correctif arrive.
Cette discipline change aussi la façon de gérer le projet. Une faille critique ne se planifie pas pour la fin de la semaine : elle passe devant le reste, le jour même. Une équipe qui respecte la discipline de la livraison continue peut changer ses priorités dans la journée, en fonction de ce qui arrive, parce que rien de ce qui est en cours ne bloque la mise en production du correctif.
DORA (DevOps Research and Assessment), le programme de recherche de Google Cloud sur le développement et la mise en production des logiciels, mesure ce que cette pratique change. DORA ne mesure pas directement le délai d’application d’un correctif. L’indicateur le plus proche est le délai de mise en production d’une modification, du moment où elle est enregistrée dans le code à celui où elle est en production. Dans « Modern Software Engineering », Dave Farley pose une question voisine : combien de temps faut-il pour qu’une modification d’une seule ligne passe de l’idée au logiciel qui fonctionne ? À notre avis, ce délai est aussi celui qu’il faudra pour appliquer le prochain correctif de sécurité. Les recherches de DORA montrent régulièrement que « la vitesse et la stabilité ne sont pas des compromis » (DORA). Selon un résumé du rapport 2024 publié par Octopus Deploy, un éditeur d’outils de déploiement, les équipes les plus performantes mettent une modification en production en moins d’un jour, et se remettent d’une mise en production ratée en moins d’une heure (Octopus Deploy).
Les comités d’approbation des changements ne compensent pas une livraison lente. Dans « Modern Software Engineering », Dave Farley cite les travaux de recherche publiés dans le livre Accelerate : « l’approbation par un organe externe, comme un responsable ou un comité d’approbation des changements, ne permet tout simplement pas d’augmenter la stabilité des systèmes en production […] C’est même pire que de n’avoir aucun processus d’approbation des changements ».
Les références de la sécurité ne fixent pas le même délai. L’ANSSI, dans son guide de 2017, demande d’appliquer les correctifs de sécurité « dans le mois qui suit leur publication par l’éditeur », et prévoit une éventuelle qualification des correctifs et un déploiement progressif (mesure 34). L’OWASP, dans son classement 2025 des dix risques les plus critiques pour les applications web, met en garde contre cette cadence : l’exposition « arrive souvent dans les environnements où l’application des correctifs est une tâche mensuelle ou trimestrielle soumise à un contrôle des changements, ce qui laisse les organisations exposées pendant des jours ou des mois à des failles déjà corrigées ». Le délai d’un mois date de 2017, avant que le délai d’exploitation ne tombe à quelques jours, et se présente comme un maximum. Avec des attaques qui commencent parfois avant que le correctif soit publié, il ne suffit plus comme objectif. La vérification des correctifs que demande l’ANSSI n’impose pas d’attendre un mois : des tests automatisés dans le pipeline la réalisent à chaque modification.
Devant l’Economic Club of Chicago, selon Business Insider le 16 octobre, Jamie Dimon, président-directeur général de JPMorgan Chase, a pointé deux risques : des agents d’IA qui agissent sur les comptes bancaires de leurs utilisateurs, et des outils d’IA qui mettent au jour des failles plus tôt. Pour payer à la place de leurs utilisateurs, ces agents ont besoin de leur code bancaire : « s’ils peuvent effectuer des paiements pour vous, il faut leur donner votre code bancaire […] vous supposez qu’ils vont agir correctement en votre nom, et ce n’est peut-être pas le cas ». La veille, lors de la présentation des résultats trimestriels de la banque, il avait prévenu que JPMorgan ne laisserait pas « n’importe quel agent extérieur entrer dans l’entreprise ». À ce jour, JPMorgan empêche les agents d’IA externes d’agir sur les comptes de ses clients particuliers, en leur laissant un accès en lecture seule. Selon Benzinga, il a aussi averti que les outils d’IA mettent au jour des centaines de failles graves dans du code libre, ce qui laisse des industries « complètement sans protection ».
Pour les failles que l’IA met au jour plus tôt, la livraison continue répond au délai d’application du correctif. Dès 2010, dans « Continuous Delivery », Jez Humble et Dave Farley demandaient de pouvoir publier rapidement une nouvelle version « au cas où l’on découvrirait des défauts critiques ou des failles de sécurité ». Ils demandaient aussi que la production soit « entièrement verrouillée », pour que seul le pipeline de déploiement puisse y apporter des changements. Avec ces pratiques et celles décrites dans la section sur l’approche de livraison, le correctif d’une faille trouvée par une IA part en production comme toute autre modification. À notre avis, la livraison continue raccourcit le temps pendant lequel une faille dont le correctif existe reste exploitable chez vous ; trouver les failles et arrêter les attaques relève des autres pratiques décrites dans cet article.
L’autre risque que décrit Jamie Dimon relève des droits d’accès : savoir si un agent agit bien pour la personne qui l’a autorisé, pour une banque comme pour toute application. L’OWASP range l’« autonomie excessive » parmi les risques des applications d’IA, et le NCSC demande d’appliquer aux agents le principe du minimum de droits. Si votre application laisse des agents d’IA agir pour vos utilisateurs, nous conseillons, comme l’OWASP, de ne leur donner que le minimum de droits, de les faire agir dans le contexte de l’utilisateur concerné, et de faire approuver par une personne les actions à fort impact.
Le jour où une faille touche votre logiciel, la marche à suivre tient en huit étapes. Elle s’appuie sur quatre documents publics : le guide « Que faire en cas de cyberattaque ? » de cybermalveillance.gouv.fr, le service public d’assistance aux victimes d’attaques informatiques, écrit pour les dirigeants ; sa fiche sur la défiguration de site ; le guide d’hygiène de l’ANSSI ; la fiche réflexe du CERT-FR, vers laquelle renvoie son alerte sur PHP. Mieux vaut avoir lu ces étapes avant ce jour-là, et savoir qui fait quoi.
1. Savoir si vous êtes exposé. Quels sites et quelles applications utilisent le composant touché, dans quelle version, sur quels serveurs, chez quel hébergeur ? Pour PHP2Shell, la question vaut aussi pour les produits qui embarquent PHP sans le montrer. Si un prestataire ou un hébergeur gère votre site, c’est la première question à lui poser. Tenir un registre de chaque action menée, conservé en dehors du système touché, comme le demande le CERT-FR.
2. Mettre à jour, ou isoler. La protection complète, c’est la mise à jour : pour PHP2Shell, PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou une version plus récente de la même branche, ou le correctif de votre distribution. Comme la prise en charge de PHP 8.2 se termine le 31 décembre 2026, mieux vaut passer à PHP 8.3 ou plus récent. Si elle n’est pas possible tout de suite, isoler les applications exposées à Internet jusqu’à ce qu’elle le soit, comme le conseillent le CERT-FR et le CERT-EU.
Attention à un piège : pour PHP2Shell, le mode maintenance d’un site WordPress ou d’une application Laravel ne protège pas de cette faille. La faille se déclenche pendant la préparation de la requête par PHP, avant que le code du site ne s’exécute. Le blocage doit se faire avant PHP : sur le serveur web ou le serveur mandataire, qui renvoie une page statique, ou au niveau du réseau.
Si le serveur semble compromis, l’ANSSI donne le bon réflexe : déconnecter la machine du réseau, mais la laisser sous tension et ne pas la redémarrer, pour ne pas perdre les informations utiles à l’analyse (mesure 40).
3. Chercher des traces d’intrusion. Amazon conseille de chercher au moins à partir du 17 octobre, et non du jour de la publication. Pour PHP2Shell : des requêtes inhabituelles d’envoi de fichiers suivies d’erreurs de mémoire ou d’erreurs 500 répétées, des cookies de session anormalement longs ou malformés, des redémarrages inexpliqués de PHP (Patchstack). Plus généralement, les signaux de la section sur la supervision : nouveaux fichiers dans les dossiers du site, programmes lancés par le serveur web, connexions sortantes inconnues, nouveaux comptes administrateurs. Patchstack recommande de traiter un serveur ciblé comme potentiellement compromis.
4. Préserver les preuves avant de nettoyer. Cybermalveillance.gouv.fr demande de récupérer les journaux du pare-feu, du serveur mandataire et des serveurs touchés, et de réaliser une copie complète de la machine attaquée et de sa mémoire. Le guide pour les dirigeants demande de déposer plainte « avant toute action de remédiation ». Redéployer une version propre avant cette copie efface justement ce qui permettrait de comprendre ce qui s’est passé.
5. Changer tous les secrets que le serveur détenait. Nous conseillons de changer les mots de passe de la base de données, les clés de l’application (clés et sels de WordPress, APP_KEY de Laravel, clé de chiffrement de Magento), les clés d’accès aux services tiers (paiement, envoi d’e-mails, stockage), les comptes d’envoi de messages, les jetons de déploiement présents sur le serveur, les clés privées des certificats et les comptes administrateurs, et de fermer les sessions ouvertes. Les nouveaux secrets se génèrent depuis un environnement sain et ne se déploient que sur le serveur reconstruit à l’étape suivante, jamais sur le serveur encore compromis. Le CERT-FR demande de « changer les secrets potentiellement compromis », cybermalveillance.gouv.fr de changer tous les mots de passe avant toute remise en ligne. CosmicSting l’a montré : une clé volée avant le correctif reste valable après, et Sansec recommande de remplacer la clé de chiffrement et d’invalider l’ancienne. Changer la clé de l’application déconnecte tous les utilisateurs ; c’est attendu. Attention, en revanche, aux données chiffrées avec l’ancienne clé : elles deviennent illisibles, sauf si l’ancienne clé reste disponible pour les déchiffrer ou si elles sont rechiffrées avec la nouvelle. Laravel permet de garder les anciennes clés pour le déchiffrement (APP_PREVIOUS_KEYS), et Adobe fournit pour Magento une procédure de changement de clé et une commande qui rechiffre les données.
6. Si le serveur a été compromis, reconstruire à partir d’une source saine. Nous conseillons de ne pas restaurer l’ancienne image du serveur ni l’ancien code, qui peuvent contenir le web shell. Avec un pipeline, on reconstruit le serveur et l’application depuis le dépôt de code, à une version saine, avec le correctif. Les données, elles, se restaurent à notre avis depuis une sauvegarde antérieure à la première date d’intrusion possible. C’est là que les sauvegardes hors ligne et testées font la différence. Cybermalveillance.gouv.fr demande ensuite une remise en service progressive, après s’être assuré que la faille est corrigée.
7. Déclarer. Si des données personnelles ont pu être consultées, modifiées ou détruites, il faut notifier l’incident à la CNIL dans les 72 heures, rappelle cybermalveillance.gouv.fr. Déclarer aussi le sinistre à votre assureur. Pour être accompagné, l’ANSSI conseille de faire appel à un prestataire qualifié de réponse aux incidents de sécurité (mesure 40 de son guide). En cas d’urgence, la police et la gendarmerie répondent au 17.
8. Tirer les leçons. Poser la question que cybermalveillance.gouv.fr place à la dernière étape de son guide : qu’a-t-on appris ? Combien de temps a-t-il fallu pour appliquer le correctif, et pourquoi ? C’est le délai dont DORA mesure l’indicateur le plus proche, présenté plus haut : plus il est court au quotidien, plus le prochain correctif sera appliqué tôt après sa publication. Qu’est-ce qui a permis, ou aurait permis, de s’apercevoir de l’attaque ?
Un correctif de sécurité est une modification comme les autres : il passe par le même pipeline que le reste. Nous ne cherchons pas les failles ; cette recherche revient aux chercheurs. Notre rôle est de limiter ce que la prochaine faille permettra d’atteindre, d’être alerté dès qu’elle est exploitée, et d’appliquer son correctif dès qu’il est publié.
La même équipe développe, teste, déploie et maintient votre logiciel en continu, dans le même pipeline. Chaque déploiement en production transite par un pipeline de déploiement : sécurité, performance, accessibilité, tout est vérifié automatiquement avant d’atteindre la production. Nous mettons en production une modification à la fois, après vérification par le pipeline. En cas d’incident, nous revenons à la version précédente.
Pour les applications que nous développons, voici ce que nous mettons en place grâce à un pipeline de déploiement. Chaque dépendance est inscrite à sa version exacte. Une version tout juste publiée n’est adoptée qu’après trois jours, sauf le correctif d’une faille grave, installé dès sa publication. Chaque matin, une tâche planifiée vérifie si une faille connue touche les composants en place. Nous mettons aussi en place la supervision des serveurs, avec des alertes sur les signaux décrits plus haut. Une mise à jour de PHP ou d’un composant passe par le même pipeline que le reste.
Pour le développement d’un logiciel sur mesure, nous travaillons pour un budget fixe, facturé chaque fin de mois pour le travail réalisé. Votre application est utilisable en un mois, en quelques fonctionnalités essentielles : vos utilisateurs s’en servent immédiatement, et c’est leur usage qui définit les fonctionnalités suivantes à développer. La maintenance est incluse, y compris la maintenance adaptative : mises à jour de dépendances, correctifs de sécurité, compatibilité navigateur. Et pour que ce qui fonctionnait le mois dernier fonctionne encore ce mois-ci, nous appliquons une garantie zéro régression : chaque régression est corrigée et couverte par un test automatisé, pour qu’elle ne revienne pas, et sans surcoût.
Nous offrons également l’audit de chaîne de production logicielle et la formation d’équipes techniques. L’audit vérifie si les pratiques décrites dans cet article sont en place dans votre pipeline de déploiement et dans votre logiciel, et ce qu’il reste à appliquer.
Une mise à jour de sécurité atteint la production le jour même de sa publication quand chaque modification y arrive déjà par petits changements. Notre article sur la livraison continue et le déploiement continu explique comment cela fonctionne, et notre article sur l’approche prédictive ou adaptative pourquoi cette façon de livrer relève d’une approche adaptative.
Pour reprendre une application dont la version de PHP n’est plus maintenue, notre page reprise et refonte d’application explique comment nous procédons.
Vous avez une application à faire développer, ou à reprendre en main ? On en parle ?
DISALLOW_FILE_EDIT).config/application.php.save-prefix, save-exact, min-release-age).
GTA 6 repoussé deux fois, The Line remise en cause, Akon City abandonnée, des projets informatiques publics hors budget : pourquoi l'estimation de l'inédit ne tient pas, et comment on bâtissait les cathédrales.
Livraison continue (continuous delivery) et déploiement continu (continuous deployment) ne diffèrent que d'un geste. Pourquoi un petit changement fréquent est moins risqué qu'un gros, sources à l'appui.
Feature flag, c'est quoi ? Quatre types de toggles, ce qu'il faut essayer avant d'en ajouter un, et sept anti-patterns qui font tourner du code jamais testé.