En bref : un processus de gestion des correctifs définit comment les mises à jour circulent de leur réception à leur preuve : dans quelle classe tombe un correctif, dans quelle fenêtre il est installé, comment on teste et on revient en arrière, qui redémarre et comment le succès est prouvé. Les mises à jour de routine se déroulent de façon planifiée, à un rythme régulier ; les correctifs d'urgence suivent une voie rapide convenue à l'avance. Les interventions de pompiers deviennent ainsi une procédure reproductible.
Quand chaque correctif est une urgence
Dans la soirée du 21/10/2026, le même schéma s'est répété dans de nombreuses entreprises. Les correctifs étaient là, le BSI (office fédéral allemand de la sécurité des technologies de l'information) pressait, et les questions ont commencé : avons-nous le droit de simplement mettre à jour maintenant ? Qui teste ? Qui redémarre les services ? Qui prévient la direction que la boutique sera brièvement indisponible ? Et comment prouver ensuite que cela a fonctionné ?
Dans les entreprises sans processus, tout cela doit être réglé sur le moment. Dans celles qui en ont un, la réponse est déjà connue. La différence ne tient pas à la technique, mais à des accords pris à l'avance.
Les éléments d'un processus de gestion des correctifs
Un processus solide distingue d'abord l'urgence d'un correctif. Trois classes suffisent généralement :
| Classe | Motif typique | Fenêtre | Test | Validation |
|---|---|---|---|---|
| Routine | corrections de bogues, mises à jour de sécurité à faible risque | date mensuelle fixe | préproduction, tests standard | informatique, selon le plan |
| Urgent | classification élevée, système accessible publiquement | avancée à court terme | abrégé, flux les plus importants | responsable informatique |
| Urgence | faille critique, attaques signalées, par ex. PHP2Shell | immédiate | test de fumée après l'installation | validation d'urgence accordée à l'avance |
Qui attribue quelle classe doit être établi, tout comme les critères. L'évaluation elle-même relève de l'étape en amont, voir La gestion des vulnérabilités dans les PME.
La validation d'urgence accordée à l'avance est importante. La direction décide une fois, au calme, que pour les correctifs d'urgence on peut agir immédiatement, même si cela implique une brève interruption. En situation réelle, personne n'a alors à obtenir un accord en pleine nuit.
Les rôles sont tout aussi importants. Pour chaque système, il doit être établi qui installe les mises à jour, qui teste sur le plan métier si la boutique ou le portail fonctionne ensuite, et qui est informé. Pour les systèmes externalisés, l'hébergeur et l'agence en font expressément partie, avec leur nom et leurs coordonnées. La fenêtre de maintenance fixe doit être connue en interne, afin que la vente et le service client sachent quand de brèves interruptions sont possibles.
Mesurez en outre le temps que votre processus prend réellement : de la publication d'un correctif à la clôture prouvée, par classe. Ces valeurs propres montrent où cela coince et rendent les améliorations visibles. Un processus dont personne ne connaît la durée se pilote difficilement.
Le déroulement d'un correctif en huit étapes
Chaque correctif, quelle que soit sa classe, passe par les mêmes stations. Seuls le rythme et la profondeur des tests diffèrent.
- Réception : l'alerte ou la mise à jour disponible est enregistrée, avec la date et la source.
- Classification : fixer la classe, déterminer les systèmes concernés d'après l'inventaire.
- Préparation : sauvegarde ou instantané, décrire le retour arrière, informer les personnes concernées.
- Test : d'abord en préproduction ou sur un système moins critique.
- Installation : dans la fenêtre convenue, système par système.
- Redémarrage : tous les services et processus concernés, pas seulement les paquets.
- Preuve : consigner l'état du paquet, l'entrée du journal des modifications et le démarrage des processus.
- Contrôle : vérifier le fonctionnement et, pour les failles de sécurité, rechercher en plus des traces d'une intrusion antérieure.
L'étape 6 est étonnamment souvent oubliée. PHP charge son code au démarrage des processus. Tant que d'anciens workers PHP-FPM ou des processus Apache avec mod_php tournent, ils continuent à travailler avec l'ancien état vulnérable. Pourquoi il en est ainsi et comment redémarrer correctement est expliqué dans Après la mise à jour : redémarrer PHP-FPM et tous les workers.
Des preuves qui comptent plus tard
Un correctif sans justificatif est, dans le doute, un correctif non installé, du moins vis-à-vis des clients, des assureurs ou des auditeurs. Consignez pour chaque système quel état de paquet est installé, si les numéros CVE figurent dans le journal des modifications et quand les processus en cours ont été démarrés. Sur les systèmes Debian et Ubuntu, des commandes en lecture seule comme celles-ci aident (adaptez le nom du paquet à votre système) :
# Le paquet installé contient-il les corrections ?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Quand les processus PHP-FPM en cours ont-ils été démarrés ?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
Si l'heure de démarrage des processus est antérieure à l'installation du paquet, le redémarrage manque. Cela est décrit en détail dans Prouver les numéros CVE dans le journal des modifications d'un paquet.
Un correctif ferme une faille pour l'avenir. Il ne supprime aucun logiciel malveillant introduit auparavant et ne prouve pas que rien ne s'est passé avant. Pour les correctifs d'urgence, une recherche de traces fait donc partie intégrante de la procédure.
Automatiser là où c'est sûr
Les mises à jour de sécurité automatiques pour les paquets du système d'exploitation allègent beaucoup le travail de routine. Mais elles ne soulagent que si des sauvegardes existent, si quelqu'un lit les résultats et si les services concernés sont aussi redémarrés. La manière de les configurer sous Linux et leurs limites sont décrites dans Mises à jour de sécurité automatiques sur les serveurs Linux.
Les conteneurs demandent une voie propre. On n'y met pas à jour le système en fonctionnement, mais on reconstruit l'image avec la version corrigée de PHP et on la déploie. Un processus de correctifs qui ne connaît que les serveurs oublie facilement ces systèmes. Intégrez donc aussi les pipelines de build et les registres d'images dans la liste des voies de correction, avec une personne responsable et la même preuve que pour les serveurs classiques : quelle version de PHP tourne dans le conteneur déployé, et depuis quand ?
Les applications, CMS et extensions demandent le plus souvent leur propre voie testée, car les mises à jour y modifient plus fréquemment des fonctions. La date mensuelle fixe est le bon endroit pour cela. Au final, il importe que toutes les voies convergent dans la même documentation : un endroit où l'on voit quel système est à quel niveau.
Comment PHP SOS aide-t-il concrètement ?
- Nous rédigeons avec vous les classes de correctifs, les fenêtres et les validations, adaptées à vos systèmes et à votre organisation.
- Nous mettons en place des mises à jour de sécurité automatiques avec contrôle du redémarrage et notification, là où c'est judicieux.
- Nous prenons en charge les correctifs d'urgence, y compris redémarrage, preuve et recherche de traces, via notre service de correctifs PHP.
- Nous tenons les preuves de chaque système de façon à ce que vous puissiez les présenter à des clients, des assureurs ou des auditeurs.
Conclusion : la gestion des correctifs paraît peu spectaculaire tant qu'elle fonctionne. C'est précisément le but : quand la prochaine alerte critique arrive, une procédure rodée se déroule, et personne n'a à improviser.
Questions fréquentes
Quelle est la différence entre gestion des correctifs et gestion des vulnérabilités ?
La gestion des vulnérabilités recense et évalue les failles et décide de ce qu'il faut faire. La gestion des correctifs met en œuvre la décision : tester les mises à jour, les installer, redémarrer les services et prouver le succès. Les deux s'imbriquent.
Les mises à jour de sécurité doivent-elles être installées automatiquement ?
Pour les paquets du système d'exploitation, c'est souvent judicieux, à condition que des sauvegardes existent et que l'on vérifie après l'exécution. Il est important que les services concernés redémarrent aussi. Avec PHP, sinon, d'anciens processus restent en mémoire avec le code vulnérable.
Comment prouver qu'un correctif est réellement effectif ?
Avec l'état du paquet installé et les numéros CVE dans le journal des modifications du paquet, la date d'installation et l'heure de démarrage des processus en cours, qui doit être postérieure à l'installation.
Que faire si une mise à jour casse quelque chose ?
C'est le rôle du retour arrière : une sauvegarde ou un instantané avant la mise à jour et une procédure décrite pour revenir en arrière. Pour les mises à jour de sécurité, le retour arrière doit rester l'exception et s'accompagner d'une mesure transitoire.