Votre logiciel est-il à jour ? La question paraît simple. Elle est pourtant l’une des plus difficiles à trancher sur un projet web, y compris pour l’équipe qui le développe au quotidien. En effet, c’est un sujet subtil car la notion d’être “à jour” n’a pas de définition commune d’une technologie à l’autre et l’appréciation dépend de la manière dont vous souhaitez gérer votre projet.
Cet article s’adresse autant au dirigeant qui doit arbitrer un budget qu’au développeur qui suit un projet. Le suivi des versions est un angle mort fréquent des deux côtés : le premier ne sait pas quoi demander, le second se concentre sur le code qu’il écrit plutôt que sur le calendrier des éditeurs.
Pour que nos clients gardent à tout moment une vision claire de l’état de leur projet, nous avons construit un outil de diagnostic simple et rapide à remplir. Rodé d’abord en interne, l’analyse de montée de version est désormais accessible depuis ce site : six versions à renseigner, et vous situez votre projet vous-même, sans avoir à poser la question à votre prestataire. Vous trouverez également sur le blog les articles qui détaillent la marche à suivre pour chaque type de mise à jour.
Le cycle de mise à jour dépend de l’éditeur de la dépendance
Chaque éditeur applique sa propre politique de support, et le cycle de vie d’une version n’a ni la même durée ni le même sens d’un cas à l’autre. Deux projets peuvent afficher des numéros de version proches et se trouver dans des situations opposées. Les six situations ci-dessous sont relevées au moment où nous écrivons ces lignes : leurs dates bougeront, les mécanismes qu’elles illustrent non.
-
Symfony 8.0, la dernière version majeure publiée en novembre 2025, ne reçoit plus aucun correctif depuis juillet 2026. Une version standard de Symfony est maintenue huit mois, correction de bugs et correctifs de sécurité confondus : les deux fenêtres se referment le même jour, comme l’indique la politique de publication officielle. Pendant ce temps, Symfony 5.4, sortie en 2021, reste couverte jusqu’en février 2029 parce qu’elle est une LTS dont le support de sécurité a été étendu par un sponsor. Si nous ouvrons par cet exemple, c’est qu’il pousse le paradoxe au bout : sortie quatre ans avant la 8.0, la 5.4 reste couverte des années après que celle-ci a cessé de l’être. Ici, le numéro le plus élevé est le moins protégé.
-
PHP 8.1 ne reçoit plus rien depuis décembre 2025, alors que le numéro sonne récent. PHP maintient chaque version mineure séparément, avec deux ans de correction de bugs puis deux ans de correctifs de sécurité. Un projet en PHP 8.1 est dans la même situation qu’un projet en PHP 7.4, même si l’écart de numéro suggère l’inverse.
-
Node.js ne promeut en LTS que ses versions majeures paires. Une version impaire vit six mois et n’a jamais vocation à tourner en production. Node 20, pourtant LTS, est sortie de support en avril 2026.
-
MySQL alterne les versions LTS et les versions Innovation, supportées seulement jusqu’à la suivante. La 8.4 LTS reste en support actif jusqu’en avril 2029, la 9.0 n’est plus couverte du tout.
-
Vue.js ne maintient que la dernière version mineure de chaque branche. La date de fin de support de Vue 3.2 est en réalité la date de sortie de Vue 3.3 : la branche 3 reste vivante. Vue 3.2 est une version remplacée, elle n’est pas en fin de vie. Rester en 3.2 est une mise à jour à planifier, pas un risque de sécurité, ce qui n’est pas du tout le cas d’un projet resté en Vue 2.
-
Tailwind CSS ne publie aucun calendrier de support formel. Le suivi se fait par branche majeure, et l’écart se mesure au coût de la montée de version plutôt qu’à une date.
| Technologie | Ce qui fait référence | Le piège |
|---|---|---|
| PHP | chaque version mineure a son cycle propre | un 8.x récent en apparence peut être hors support |
| Symfony | les LTS, tous les deux ans | la dernière majeure vit moins longtemps qu’une LTS ancienne |
| Node.js | les majeures paires uniquement | une majeure impaire n’est jamais destinée à la production |
| MySQL | les versions LTS | les versions Innovation expirent à la suivante |
| Vue.js | la dernière mineure de la branche | fin de support d’une mineure ne signifie pas branche abandonnée |
| Tailwind CSS | la branche majeure | aucune date publiée, l’écart se mesure en coût de migration |
Retenez une seule chose de ce tableau : un numéro de version ne dit rien par lui-même, et plus récent ne veut pas dire mieux protégé. C’est exactement pour cette raison que la question posée en ouverture reste si souvent sans réponse fiable.
Pour sortir de l’appréciation au jugé, nous ramenons chaque version à l’un de quatre états, quelle que soit la technologie.
| État | Ce que l’éditeur publie encore | Ce que ça implique |
|---|---|---|
| Support actif | bugs et failles de sécurité | rien à faire, la prochaine échéance se planifie |
| Sécurité seule | les failles uniquement | les anomalies connues restent en production |
| Version remplacée | rien sur cette mineure, la branche reste maintenue | mise à jour peu coûteuse, aucune date obligatoire |
| Fin de vie | plus rien, failles de sécurité comprises | chantier à engager, le projet est exposé |
C’est ce vocabulaire que rend notre analyse de montée de version : elle applique ces quatre états aux six versions en production d’un projet et affiche, pour chacune, la date d’où sort le constat.
Suivre les technologies maîtresses, pas la liste des dépendances
Un projet Symfony embarque plusieurs dizaines de dépendances PHP et l’univers des dépendances Javascript peut vous donner le vertige. Vouloir toutes les suivre individuellement est ingérable, et surtout inutile : la plupart se mettent à jour dans le sillage d’une technologie maîtresse.
Deux exemples que nous rencontrons sur presque tous les projets. La migration de Doctrine 2 vers Doctrine 3 n’est jamais un chantier isolé chez nous : elle se mène en même temps que la montée de version de Symfony, parce que c’est le framework qui impose la compatibilité. De la même façon, le passage de Webpack à Vite arrive avec la refonte de l’outillage front, rarement comme une décision autonome.
Le bon niveau de suivi est donc court, et il se lit en deux groupes selon qui monte la brique. Ce que fournit l’hébergeur : le langage PHP, la base de données MySQL et l’environnement Node.js, qui se montent par configuration sans toucher au code. Ce dont dépend le code : le framework back Symfony, le framework front Vue.js et le framework CSS Tailwind, dont une version majeure casse la compatibilité et demande du développement. Six lignes structurantes, pas soixante : ce socle technique suffit à situer un projet, et la distinction entre les deux groupes est ce qui permet d’en chiffrer le chantier. Tout le reste se traite dans la méthode de migration, et c’est là que le détail a sa place : nos guides de montée de version documentent les dépendances impactées, les dépréciations à traiter et les points de vigilance, que ce soit pour PHP 8, Symfony 6 vers 7, Vue 2 vers Vue 3 ou Tailwind v3 vers v4.
Ce découpage a une conséquence directe sur le pilotage. Un tableau de suivi à six lignes se relit en une minute avec un client. Il permet d’intégrer plus sereinement ses montées de version dans le planning annuel sans se perdre dans les détails.
Mise à jour technique et scan de sécurité sont deux sujets différents
C’est la confusion la plus fréquente dans les discussions budgétaires, et elle mérite d’être levée explicitement, parce que les deux sujets n’ont ni le même coût ni le même rythme.
Le scan de vulnérabilités détecte qu’une faille publiée, référencée par un identifiant CVE, touche une dépendance de votre projet. Chez
SmartBooster, il ne relève pas du suivi de version mais de la sécurité : il tourne automatiquement dans nos pipelines d’intégration continue (avec des
outils comme composer audit, npm audit et osv-scanner sur nos images Docker). La correction consiste presque toujours à appliquer un patch,
c’est-à-dire une montée de version corrective sans impact fonctionnel. Nos tests automatisés vérifient la non-régression, et le déploiement suit
rapidement, la plupart du temps sans arbitrage à demander au client.
La mise à jour technique est d’une autre nature. Passer d’une version majeure à la suivante modifie le code : des fonctions disparaissent, des signatures changent, des bundles deviennent incompatibles. Il faut lire les notes de version, traiter les dépréciations, relire, tester, valider en recette. C’est un chantier qui se planifie et qui se budgète.
Confondre les deux mène à deux erreurs symétriques. Croire qu’un scan de sécurité automatisé suffit à maintenir un projet à jour, alors qu’il ne traite jamais l’obsolescence d’une version majeure. Ou à l’inverse, repousser un patch de sécurité au prochain chantier de migration, alors qu’il aurait pu partir en production dans la journée. La qualité de livraison est ce qui permet de traiter la première catégorie sans y consacrer de réunion.
Un logiciel en ligne ne se maintient pas comme un logiciel installé
Un logiciel installé sur un poste de travail vit derrière le réseau de l’entreprise. Pour l’atteindre, il faut déjà être entré. Une faille non corrigée y reste longtemps sans conséquence, ce qui explique que beaucoup d’outils métier historiques aient tourné des années sans mise à jour.
Une application web est dans la situation inverse : elle est exposée en permanence, accessible depuis n’importe où, et parcourue en continu par des robots qui testent automatiquement les failles connues. Entre la publication d’une vulnérabilité et les premières tentatives d’exploitation, il s’écoule des heures, pas des mois. Le délai acceptable entre une faille publiée et son correctif n’a donc rien à voir d’un cas à l’autre.
La contrepartie est favorable, et elle est rarement mise en avant : sur une application web, la mise à jour est centralisée. Une seule mise en production couvre tous les utilisateurs, sans installation sur les postes, sans version qui traîne chez un utilisateur qui a refusé la mise à jour. Ce qui rend l’exposition plus forte rend aussi la correction plus rapide.
La stratégie de mise à jour se décide selon la criticité et l’activité du projet
Il n’existe pas de bon rythme universel. Appliquer le même régime à une application de facturation utilisée toute la journée et à un outil interne ouvert deux fois par mois revient à dépenser pour rien d’un côté ou à prendre un risque de l’autre. Nous convenons d’un rythme adapté à la situation du client, projet par projet.
-
Projets critiques. Engagement de migration vers la nouvelle version LTS dans les six mois suivant sa sortie, avec un budget mensuel de maintenance évolutive ou TMA dimensionné selon la taille du projet pour absorber les mises à jour mineures au fil de l’eau. C’est le régime des applications actives dont l’indisponibilité ou la compromission aurait un effet immédiat sur l’activité.
-
Projets courants. Une mise à jour annuelle, planifiée en général pendant l’été, quand la pression métier est plus faible et qu’une recette peut se dérouler sans bousculer un pic d’activité accompagnée d’un budget mensuel pour traiter les CVE.
-
Projets peu actifs. La migration est engagée six mois avant la fin des correctifs de sécurité de la version en place. Ni plus tôt, ce qui reviendrait à payer pour une modernisation sans bénéfice, ni plus tard, ce qui laisserait le projet sans filet.
Ce calibrage est une décision partagée, qu’il est difficile de chiffrer précisément pour nous car nous sommes complètement dépendants des mises à jour des éditeurs. Il suppose en revanche que le client comprenne le principe et allouer un budget en fonction de ses exigences ou revoir ses exigences en fonction de son budget.
Que faire si votre entreprise traverse une passe difficile et que vous avez besoin de réduire vos budgets ? Même si ce ne sont pas les situations que nous préférons, nous avons déjà eu l’occasion d’accompagner des clients dans ce genre de situation. Notre choix de travailler uniquement sur des versions LTS, vous apporte le confort de pouvoir compter sur des supports plus long de l’éditeur. Dans cette situation, nous vous conseillons d’aller au maximum du support de sécurité. Nos applications étant stables vous avez peu de risques d’arriver à une situation de blocage. Le seul inconnu serait des changements sur des solutions tierces auxquelles votre logiciel serait connecté qui imposeraient l’intervention d’un développeur pour ajuster.
Ce qui rend une montée de version sereine
Le coût d’une migration ne se déduit pas de la distance entre deux versions. Il dépend surtout de l’état du code qu’on ouvre le jour où on la lance. Deux projets sur la même version de Symfony peuvent demander trois jours ou trois semaines pour exactement le même saut.
C’est une des raisons pour lesquelles nous nous inscrivons dans la durée avec nos clients plutôt que de livrer un projet et de passer au suivant. Nous suivons aujourd’hui une application en production depuis plus de neuf ans. Sur cette durée, aucune montée de version n’a été une découverte : chacune a été préparée par la précédente et l’équipe qui l’exécute est celle qui a écrit le code qu’elle modifie.
Trois pratiques font l’essentiel du travail, et aucune n’est spectaculaire.
L’analyse statique est ce qui transforme une migration en liste finie. Une fois la nouvelle version installée, l’outil relit l’intégralité du code sans l’exécuter et signale ce qui ne tient plus : fonction supprimée, signature modifiée, type devenu incompatible. Vous obtenez la liste des points à traiter avant même d’avoir ouvert l’application, là où sans elle les mêmes problèmes se découvrent un par un en recette quand ils n’attendent pas la production pour se manifester.
Les tests automatisés répondent à la question d’après : le comportement a-t-il changé ? Ce qui compte ici n’est pas le taux de couverture global, chiffre facile à gonfler sur du code sans enjeu. C’est la couverture des parties métier : le calcul de commission, la règle de facturation, le circuit de validation. Ce sont ces règles-là qu’un utilisateur repère immédiatement si elles se mettent à produire un résultat différent, et ce sont donc elles qui doivent être vérifiables en quelques minutes après une migration.
La documentation fonctionnelle couvre ce qu’un test automatisé ne sait pas juger : un parcours utilisateur, la mise en page d’un document, le comportement d’une intégration avec un outil tiers. Elle permet de faire dérouler une recette par quelqu’un qui n’a pas écrit le code, y compris côté client, et de savoir ce qui a été vérifié plutôt que de le supposer.
Mises bout à bout, ces trois pratiques changent la nature du chantier. La migration cesse d’être un pari sur ce qui va casser pour devenir une liste de tâches qu’on peut chiffrer, planifier et découper. C’est ce qui rend tenables les rythmes décrits plus haut, sans que chaque échéance se rejoue en négociation. C’est aussi ce qui explique qu’une même montée de version soit routinière sur un projet et redoutée sur un autre.
Votre équipe repousse les montées de version d’année en année ? Le problème est rarement la charge de travail elle-même. Une équipe qui ne sait pas dire à l’avance ce qu’une migration va casser travaille sans filet : pas d’analyse statique dans la chaîne d’intégration, pas de tests sur les règles métier, pas de documentation à jour pour cadrer la recette. Dans ces conditions, chaque montée de version devient un pari, et un pari se repousse. Ce sont donc les méthodes et l’outillage qu’il faut regarder en premier, avant le calendrier des éditeurs.
Ce que nous suivons, et comment
En interne, nous maintenons un référentiel de versions couvrant l’ensemble des projets gérés par SmartBooster : pour chacun, les six technologies maîtresses, leur version en place et l’échéance de support associée. C’est lui qui déclenche les conversations de migration, plusieurs mois avant l’échéance plutôt qu’au moment où elle devient urgente. Il n’a rien de confidentiel : nous le publions tel quel sous l’outil d’analyse, avec pour chaque brique le cycle de ses mineures, la version que nous recommandons et le lien vers le calendrier de l’éditeur.
Pour l’analyse détaillée d’un projet, nous nous appuyons en complément sur un outil interne d’audit de code qui relève les versions réellement installées, les mises à jour disponibles et l’état du code à migrer. C’est ce qui sépare le constat, que vous pouvez faire seul, du chiffrage, qui suppose d’ouvrir le projet.
Nous avons également développé un outil disponible en ligne pour réaliser votre analyse et prévoir vos mises à jour en étant bien informé : Accéder à l’analyse de montée de version
Si vous voulez évaluer votre situation dès maintenant, trois questions suffisent à dégrossir. Quelle version du langage et du framework
tourne en production, et jusqu’à quand est-elle supportée ? À quand remonte la dernière mise à jour des dépendances, information que donne
la date de modification du fichier composer.lock ou package-lock.json ? Existe-t-il un scan de vulnérabilités programmé,
indépendamment du rythme des livraisons ?
Si l’une des trois questions reste sans réponse, ce n’est pas nécessairement le signe d’un problème technique. C’est d’abord le signe que le suivi n’est pas outillé, et c’est par là qu’il faut commencer. La suite se traite sereinement : nous avons détaillé la méthode dans notre plan d’action pour réduire la dette technique, et la reprise d’un projet existant commence toujours par cet état des lieux.
