Votre application fonctionne, vos clients s'en servent, personne ne se plaint. Faut-il vraiment y toucher ? Oui. Une application web repose sur des briques (système du serveur, langage de programmation, framework, bibliothèques) qui ont chacune une durée de vie. Quand une version cesse d'être maintenue, les failles découvertes ensuite ne sont plus corrigées. Votre application continue de tourner, mais elle devient plus facile à attaquer, sans que rien ne se voie.
La mise à jour de sécurité d'une application web n'est donc pas un chantier exceptionnel mais un entretien régulier, comme la révision d'un véhicule. L'actualité la rend plus pressante pour beaucoup de PME : PHP 8.2 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026, et Laravel 12 n'en reçoit plus que jusqu'au 24 février 2027.
Voici ce qu'il faut surveiller, le calendrier du moment, une méthode pour mettre à jour sans casser, et comment répartir la responsabilité dans une PME.
Mise à jour de sécurité d'une application web : pourquoi même quand tout marche
Une faille de sécurité n'empêche pas une application de fonctionner. Elle permet à quelqu'un d'en faire autre chose que ce que vous aviez prévu : lire des données, prendre le contrôle d'un compte, installer un programme sur le serveur. Vous ne la voyez pas tant que personne ne l'exploite.
Or l'exploitation de failles connues est l'une des voies d'attaque les plus courantes. Selon le Panorama ESET 2026 de la cybersécurité des PME en France, cité par WeLiveSecurity, le phishing et l'exploitation de vulnérabilités logicielles connues restent les deux causes de compromission les plus fréquentes. « Connues » signifie que la faille est publique et qu'un correctif existe souvent. Le problème vient de ceux qui ne l'ont pas appliqué.
Les composants tiers sont aussi un sujet à part entière. Le classement de référence OWASP Top 10 2025 place en troisième position les défaillances de la chaîne d'approvisionnement logicielle (Software Supply Chain Failures), c'est-à-dire les risques qui viennent des bibliothèques et outils dont votre application dépend.
Si votre application a été construite avec un assistant IA, la vigilance compte double : l'assistant propose ce qu'il a appris, pas forcément la version la plus récente ni le paquet le plus sûr. Nous en parlons dans notre article sur le slopsquatting.
Les trois couches à surveiller : serveur, langage, dépendances
Pour un dirigeant, il suffit de retenir trois couches, chacune avec son propre calendrier.
1. Le serveur
Le système d'exploitation (Debian, Ubuntu…), le serveur web, la base de données. Si vous êtes sur une plateforme gérée (Supabase, Vercel, Laravel Cloud…), une partie de cette couche est prise en charge par le fournisseur. Sur un serveur classique, c'est à quelqu'un de votre côté de le faire.
2. Le langage
PHP, Node.js, Python : le moteur qui exécute votre code. Chaque version a une date de fin de support publiée à l'avance. Une fois cette date passée, plus aucun correctif officiel.
3. Le framework et les bibliothèques
Laravel, React, et les dizaines (souvent centaines) de paquets installés avec eux. En PHP, ils sont listés dans un fichier composer.lock. En JavaScript, dans un package-lock.json. C'est la couche qui bouge le plus vite, et celle qui reste à votre charge même sur une plateforme gérée : le fournisseur n'actualisera pas les bibliothèques de votre code à votre place.
Le calendrier à connaître en ce moment : PHP 8.2 et Laravel 12
D'après la page officielle des versions supportées de PHP :
- PHP 8.2 : correctifs de sécurité jusqu'au 31 décembre 2026 ;
- PHP 8.3 : jusqu'au 31 décembre 2027 ;
- PHP 8.4 : jusqu'au 31 décembre 2028 ;
- PHP 8.5 : jusqu'au 31 décembre 2029.
Pour Laravel, la politique officielle prévoit 18 mois de corrections de bugs et 2 ans de correctifs de sécurité par version majeure :
- Laravel 11 : plus de correctifs de sécurité depuis le 12 mars 2026 ;
- Laravel 12 : corrections de bugs terminées le 13 août 2026, correctifs de sécurité jusqu'au 24 février 2027 ;
- Laravel 13 : corrections de bugs jusqu'au troisième trimestre 2027, sécurité jusqu'au premier trimestre 2028. Il exige PHP 8.3 au minimum.
Conséquence pratique : une application en Laravel 12 sur PHP 8.2, combinaison courante, doit avancer sur deux fronts dans les mois qui viennent. L'ordre logique consiste à passer d'abord à une version de PHP plus récente (Laravel 12 accepte de PHP 8.2 à 8.5), puis à préparer le passage à Laravel 13. Si votre application tourne sur une version encore plus ancienne, le sujet n'est plus une simple mise à jour mais une migration à planifier.
Mettre à jour sans casser : la méthode
La crainte légitime d'un dirigeant, c'est qu'une mise à jour casse ce qui marchait. Le risque existe, mais il se maîtrise avec une méthode simple.
- Faire l'inventaire. Quelle version du système, de PHP et de Laravel tourne en production ? Quelles bibliothèques sont installées ? Une heure suffit souvent pour le savoir.
- Brancher des alertes automatiques. La commande composer audit compare les paquets PHP installés aux failles connues, et signale aussi les paquets abandonnés ou identifiés comme malveillants. D'après la documentation de Composer, elle se lance par défaut après chaque mise à jour des dépendances. Sur GitHub, Dependabot peut ouvrir automatiquement une proposition de modification qui passe une dépendance vulnérable à la première version corrigée.
- Mettre à jour souvent, par petites étapes. Dix petites mises à jour mensuelles sont beaucoup moins risquées qu'une grosse tous les trois ans, où tout bouge en même temps et où plus personne ne sait ce qui a cassé.
- Tester avant la production. Des tests automatisés qui tournent à chaque modification (c'est le rôle de la CI, l'intégration continue), puis un essai sur un environnement de préproduction. Voir notre article Environnement de préproduction : pourquoi votre application en a besoin.
- Sauvegarder juste avant. Une sauvegarde récente et testée permet de revenir en arrière si quelque chose se passe mal (voir le minimum à mettre en place).
- Surveiller juste après. Un monitoring qui alerte en cas d'erreur permet de corriger avant que vos clients ne s'en aperçoivent (voir notre article sur le monitoring).
Qui doit s'en charger dans une PME ?
Le vrai problème des mises à jour en PME n'est pas technique, c'est un problème d'organisation : personne n'en est clairement responsable. Le prestataire qui a développé l'application considère que la maintenance ne fait pas partie de sa mission, l'équipe interne n'a pas les compétences, et le sujet ne refait surface qu'à l'occasion d'un incident.
Quelle que soit l'organisation choisie, trois choses doivent être claires :
- un nom : la personne ou l'entreprise responsable, écrit dans un contrat ;
- un rythme : par exemple un passage mensuel sur les dépendances et un point annuel sur les versions majeures ;
- un compte rendu : ce qui a été mis à jour, ce qui reste à faire, les prochaines échéances.
Pour savoir où vous en êtes, posez ces quatre questions à la personne qui s'occupe de votre application :
- Quelles versions de PHP et de Laravel tournent en production ?
- Jusqu'à quand reçoivent-elles des correctifs de sécurité ?
- De quand date la dernière mise à jour des dépendances ?
- Y a-t-il en ce moment des alertes de sécurité non traitées ?
Si personne ne sait répondre, vous savez par où commencer. La formule Autopilote de Devnco (100 € par mois) pose le socle qui rend ces mises à jour régulières sans stress : hébergement, sauvegardes, monitoring, CI/CD et contrôle qualité par agents IA. Une migration de version majeure, elle, se chiffre à part, une fois l'inventaire fait.
Questions fréquentes
Que se passe-t-il le 1er janvier 2027 si je suis toujours en PHP 8.2 ?
Rien de visible : votre application continue de fonctionner. Mais le projet PHP ne publiera plus de correctifs pour cette version, et chaque faille découverte ensuite restera ouverte. Certaines distributions Linux et certains hébergeurs maintiennent leurs propres paquets plus longtemps : renseignez-vous auprès du vôtre, mais ne comptez pas là-dessus pour remplacer une montée de version.
Faut-il activer les mises à jour automatiques ?
Pour les correctifs de sécurité du système du serveur, c'est souvent une bonne idée. Pour les bibliothèques de votre application, préférez des propositions automatiques (comme celles de Dependabot) validées par les tests puis par un humain, plutôt qu'une installation à l'aveugle en production.
Mon application est sur Lovable et Supabase, suis-je concerné ?
En partie. La plateforme gère l'infrastructure, mais les bibliothèques JavaScript de votre code sont les vôtres et vieillissent comme les autres. Le même principe s'applique : inventaire, alertes, petites mises à jour testées.
Vous ne savez pas quelles versions font tourner votre application, ni si une échéance approche ? Envoyez-nous un message : on regarde ensemble, et vous repartez au moins avec un état des lieux clair.