Failles PHP : l’État contraint de suspendre des services en ligne

Pour protéger leurs systèmes, plusieurs administrations ont dû renoncer temporairement à leur présence en ligne. Des sites de préfectures, certains services fiscaux, le site de la CNIL et des services universitaires ou territoriaux ont été rendus inaccessibles. Ce retrait préventif réduit l’exposition à une menace informatique, mais interrompt aussi l’accès des usagers à des informations et à des démarches.

Le ministère de l’Intérieur indique avoir placé plusieurs de ses sites en maintenance à la demande de l’ANSSI. À l’origine de cette décision : deux vulnérabilités critiques affectant PHP, un composant logiciel employé pour faire fonctionner des sites web. L’agence a signalé un risque d’exploitation rapide. Les éléments disponibles ne permettent pas d’établir que ces failles ont été exploitées contre les administrations concernées.

L’épisode met la sécurité des sites publics à l’épreuve d’un arbitrage concret : maintenir un service accessible avec un risque technique identifié, ou le suspendre pour appliquer les correctifs et procéder aux vérifications. La fermeture n’est donc pas, à elle seule, la preuve d’une intrusion. Elle constitue ici une mesure de réduction du risque.

Un composant commun, plusieurs administrations exposées

PHP intervient côté serveur. Il permet notamment de produire des pages dynamiques, de traiter des formulaires ou de faire fonctionner des espaces personnels. Il ne se confond ni avec un hébergeur ni avec une application administrative particulière. Des organismes distincts peuvent ainsi partager une même dépendance technique sans utiliser les mêmes services en ligne.

C’est cette présence dans de nombreux systèmes qui donne à l’alerte sa portée. Une vulnérabilité découverte dans un composant largement diffusé impose des interventions simultanées à des équipes qui n’ont pas nécessairement les mêmes moyens, les mêmes prestataires ou les mêmes procédures. La dispersion des sites n’empêche pas une exposition commune.

Selon les explications du ministère de l’Intérieur, la maintenance a suivi l’annonce d’une vulnérabilité critique du composant. Les correctifs ont été publiés de manière anticipée après la circulation d’informations sur les failles. Pour les organismes utilisateurs, l’enjeu devient alors la durée séparant la connaissance du risque de la sécurisation effective de leurs services.

Installer une mise à jour ne clôt pas nécessairement l’intervention. Il faut aussi vérifier que les fonctions du site restent opérationnelles et que les configurations utilisées sont compatibles avec la correction. Une réouverture trop rapide pourrait rétablir un service dégradé ; une fermeture prolongée reporte la contrainte sur les usagers et les agents.

La sécurité des sites publics dépend de leur maintenance

La réponse coordonnée autour de l’ANSSI, autorité nationale en matière de cybersécurité, illustre l’importance de l’alerte technique. Mais diffuser une consigne ne suffit pas à remettre chaque site en service. L’exécution dépend ensuite des responsables informatiques, des exploitants et, lorsque la maintenance est externalisée, des prestataires concernés.

Pour apprécier la sécurité des sites publics, le nombre de services fermés ne constitue donc qu’un indicateur partiel. Il faudrait aussi connaître les délais d’identification des systèmes vulnérables, d’application des correctifs et de validation avant réouverture. Les informations disponibles ne fournissent pas ce bilan détaillé. Elles ne permettent pas davantage de comparer la rapidité de réaction des différents organismes.

La capacité à dresser un inventaire fiable des composants utilisés devient déterminante. Une administration doit pouvoir savoir quels sites dépendent du logiciel concerné, qui peut intervenir et selon quelle procédure. Sans cette visibilité, une alerte nationale risque de se traduire par une succession de vérifications locales, plus difficiles à coordonner.

Pendant l’interruption, les préfectures ont utilisé leurs comptes officiels sur les réseaux sociaux pour diffuser des informations. Ce relais préserve une partie de la communication institutionnelle. Il ne remplace toutefois pas les fonctions d’un portail administratif : publier une consigne et permettre l’accomplissement d’une démarche sont deux services différents.

Le logiciel libre ne dispense pas d’une capacité d’intervention

PHP est un logiciel libre. L’incident ne relève donc pas directement d’une dépendance commerciale à un éditeur propriétaire. Cette distinction compte : disposer d’un code ouvert et pouvoir choisir ses prestataires ne supprime ni les vulnérabilités ni la nécessité d’organiser leur traitement.

L’autonomie numérique comporte ainsi deux dimensions distinctes. La première concerne les conditions d’utilisation et la maîtrise des choix techniques. La seconde tient à la capacité effective de maintenir les systèmes, de recevoir les alertes et de déployer les corrections. L’ouverture du code ne garantit pas, à elle seule, que chaque organisme dispose de ces compétences et de ces procédures.

Le cadre européen aborde précisément cette dimension opérationnelle. La directive NIS 2 prévoit des mesures de gestion des risques comprenant le traitement des vulnérabilités, la gestion des incidents et la continuité des activités pour les entités relevant de son champ. Ces exigences portent sur une organisation durable, pas uniquement sur l’achat d’un outil de protection.

La sécurité des sites publics se mesure finalement aussi à leur capacité de retour en service. Pour tirer les enseignements de ces maintenances, les données utiles seront les délais de rétablissement, les éventuelles compromissions constatées et les difficultés rencontrées lors des corrections. Elles permettront de distinguer une interruption préventive maîtrisée d’une fragilité persistante dans l’exploitation des services numériques.